In my day job I often talk with other people in the HPC and distributed
systems field. I am often dismayed to hear people's views on SOA and how it
is "just like OO." One thing I notice keeps cropping up in these discussion
is the notion of what a message transferred between services actually is.
One school of thought is that it is a flattened object from an application,
which is wrapped up in SOAP, adorned with appropriate QoS headers, and sent.
The same happens in reverse at the receiving end.
At the wire level, this seems OK since we've put the application payload
into the SOAP body, and the QoS information into SOAP header blocks.
Therefore, the thinking is that what differentiates a service-oriented
system from an object-oriented system is that services pass-by-value,
whereas objects pass-by-reference. It is a comfortable picture because it
"helps" people to think that in terms of the familiar method call paradigm.
I thoroughly dislike this school of thought since it undermines both
service- and object-oriented systems. In (distributed) OO systems both
pass-by-reference and pass-by-value can be supported. On the other hand, in
service-oriented systems the messages exchanged between services need have
no resemblance to any objects from which the service is built. It is likely
that a message may be constructed from data from a number of different
objects, processes, or systems at the service's back end. In short, the only
mode of communication in service-oriented systems is "pass-by-message." :-)
So at the application level, don't think of messages as a container for
serialising objects into, think of messages as first-class application-level
entities themselves. Write your Web Services to use messages as the
fundamental abstraction and this in turn helps to promote loose-coupling.
At this point in my rant, I remember that
Savas and I
wrote something
on this for Web Services
Journal.
Today's Web Services super-hero: SOAP Messages
(the above idea shamelessly borrowed from
Don's blog)