Today I attended a presentation on Service Orientation (SO) by Clemens Vasters. The presentation itself was very interesting, Clemens mentioned that SO is about business alignment and loose coupling (two claims I all heartedly agree with). He also made some claims about SOA which I only partially agree with (but that's not the point of this post).

Clemens, used the business practices of  the pre-computer era to build the case for service orientation - utilizing several metaphors such as Department = Service and folder+form = message etc.

From these metaphors we can basically  infer 2 types of service communication patterns:

• one way messages  - a service consumer can ask a service to perform some action
• Request/Reply - A consumer asks for a service and waits for the results (synchronously or asynchronously)

I guess there's a general limitation to metaphors - since a metaphor is (a kind of) a model of a problem, it doesn't catch/include all the properties or possibilities of the problem. Using a metaphor, we should be careful not to neglect options that are not covered by it.

In this particular case, it is hard to see other possible ways for services to communicate. Unlike business practices of the 1920s, things can be handles in parallel, a service may not care who deals with data it publishes e.g. in a publish subscribe  scenario or if there's an external (to the service) workflow that takes care of routing (read: orchestration in MS's lingo or Choreography in IBM's lingo) data to interested services. For example:

Using a publish/subscribe communication An Ordering service may publish any approved order and both the invoicing service  and a logistics service can trigger a JIT inventory process to ensure that supplies will be available to fulfill the order.

By the way, I think this point (regarding metaphors) is also valid for the "system metaphor" in extreme programming (but that's a point for another post)