It is very important to note that the "Message Orientation" has
"won" over the "web service orientation". Up until the summer
2003 most people viewed the world through service providers and
service consumers. A consumer would send a request to a provider
who will answer with a response. This model is very
"client/server" like and does not reflect at all the more
abstract nature of services which are simply peers interacting
with each other via messages. I have been pushing this idea
since the summer 2002, and I would like to think that I have
been influential in bringing this idea to fruition (via my
participation as an
invited expert in the WS-CHOR working group).
By the summer of 2003 Microsoft had already
aligned its marketing message along these lines.
Please take also a look at my comments on
REST as they related to the peer-to-peer nature of services.
Composition, Choreography, Collaboration, Orchestration,
Simon Woodman asks whether these terms have been defined
with respect to each other, here is my attempt.
most abstract level we find "Coordination", which
represent an exchange of messages between services with a shared
context. This context can be passed by value or by reference, it
can be managed by a third party other than the services
participating in the coordination. Note that the definition does
not require that a given service makes use of the context. The
coordination boundaries may be explicit or implicit, i.e. "begin
coordination" and "end coordination" are part of the context.
service is a composition of other web service, when all
its operations are implemented by invoking operations from other
web services. Obviously, this is a bit misleading, because, you
need a "composition language" or some code, that will related
the series of operation to invoke when the composite operation
is invoked. BPEL can be used to specify the "code" executed as a
composite web service.
orchestration is a generalization of composition. The same
language can be used to perform a complex unit of work achieved
by invoking a series of web service operations. Any given
orchestration is not forced to expose a web service interface.
If it does, it is a composition. An orchestration is executed by
an orchestration engine. BPEL is a programming language.
transaction is a form of composition, a very constrained
form (almost like a template). It is so constrained that it is
often called a “transaction protocol”.s
choreography is the observed sequence of message exchanged
by peer services when performing a unit of work.
Services do not need to be orchestrated
to perform a unit of work (this is concept that emerged and
should have stayed in the last century). This is a very
common misconception, actually most units of work are
accomplished by a series of "orchestrated services" performing a
choreography. Please see this
explaining the difference between choreography and orchestration
using an example.
Collaboration (OASIS/ebBP) is a "business" choreography.
There are a lot of details which are specific to the way we
conduct electronic-business that it is important to make a
distinction between the two.
Unfortunately, some of the members of the BPEL working group
have repeated over and over that BPEL can do it all. I urge you
to consider that:
- BPEL is a nothing more or nothing less
than programming language and something like BPEL-J
or Cw give us an idea about what it will ultimately look like
It is not suited for expressing any kind
- business processes
SO versus OO
Well, this debate may sound like an old debate
but as momentum behind SOA starts picking up, it might be
important to underline the differences.
We all know the fundamentals and benefits of
OO: encapsulation, inheritance, polymorphism, containment...
overtime we had to tweak OO a bit and add concepts like
"interfaces", but at the end of the day, OO is still about
encapsulating a data structure and associating to it a bunch of
code that in general is about changing its content. A typical OO
run-time is in charge of managing the lifecycle of object
instances. I know this is a bit trivial, but where are the
differences with services:
Of course in services, the data structure(s)
are not internal to the service but simply the arguments of the
service operations, so services are not about explicit data
encapsulation but rather "process" encapsulation. The operations
of a service are the interaction points with that particular
process. Now the most fundamental difference is a bit more
subtle, in OO what is explicit is the method you can call on the
object. The "callbacks" (though I hate this term forcefully) are
not explicit. A typical class has no way to express that it
requires an (UML) aggregate to work and that it needs this
aggregate to implement a specific interface. There are a few
more differences (like the fact that a service has invocation
instances but not multiple instances of a service...), but let's
push the reasoning on that last argument:
What does that mean for taking an OO language
and making it a SO language? Well a service declaration could
look like this:
(public | private[domain]) service MyOrderEntryService : extends
Operations: //Inbound operations
Friends: //This is a bit more than outbound operations, since we
group them into
dynamic ShippingService shipper; //specified by buyer
static BillingService billing;