Services are, and are not...

Been speaking with colleagues, partners, and customers a lot around SOA lately.

A common technique for systems integration these days is to use some form of message queueing technology. This is particularly the case in large companies with host-bases systems. IBM's MQSeries is pretty prevalent here, and is used to pass "messages" back and forth between systems. These messages are in the form of some well-known data format. In other words, there is some intimate knowledge required by both systems to understand the contents of the message.

When discussing SOA, people of make the mistake of interpreting this type of service-based design with a service oriented architecture. As Don Box puts it, there are four basic tenets of SOA:

-Services are autonomous

-Services share schema and contract, not class

-Boundaries are explicit

-Service compatibility is determined based on policy

Clearly, a message queueing solution does not meet this criteria. Particularly, Message queues are not autonomous, and while they may share schema and contract, they don't normally do so. Particularly, service compatibility is in no way determined based on runtime evaluation of policy, as most queueing systems do not support this behaviour.

This is not to say that queuing technologies can play no part in SOA. As a matter of fact, the basis of SOA is the nature of being transport agnostic, and queueing infrastructures meet this criteria very well. But a queue cannot always be a service in the SOA sense. In can be a port that participates in SOA message communication.