InfoQ Article: 10 Principles of SOA

That was very well written piece. I couldn't have agreed more with the points that you have brought up. My favorite one is the one about document-centric interaction paradigm. In my experience atleast, it is one of the most difficult, yet conceptually elegant concepts to get a "buy-in". Especially from IT/IS departments who have been so habituated to RPC. OTOH, I feel that probably you could also have touched upon the notions of Service Granularity and Service Governance. Or do you think it kind of "folds into" one of the above tenets?

With service granularity, I would claim it's sort of implied in document-orientation that services are coarse-grained. With regards to governance, you are probably right: the only "real" reference is the metadata aspect. This would probably be worth expanding -- I'll think about it. Thanks for the feedback!

I'd like to see more to resolve the confusion around sync v async. The consumers view of async (I can carry on) is different and separable from from the services view (I can queue up requests). The fact that there is a buffer for requests does not mean the consumer either can or should carry on without a reply.

Good point. I like to distinguish between blocking and non-blocking (on the client side) and synchronous vs. asynchronous (on the communication side). These are orthogonal to each other - i.e. one can do blocking asynchronous, non-blocking asynchronous as well as blocking or non-blocking synchronous calls. Each have their value.

Good work!!..
It is very good principles!.

Stefan

Let me challenge you a bit more. I propose you can trim point 1 down quite a bit! It says: Everything needed by the service to provide its functionality should be passed to it when it is invoked. The only way into and out of a service are [is?] through messages.

I have seen others say much the same. And people who already know the meaning may not notice, but surely the words are misleading?

The fact is that a service may not get all it needs from the invocation message. E.g. it may have to query a database before it can begin to process the input message.

And there are others ways out of and into a service. E.g. when it queries that database it might do so by sending a message to what some call a data service*, or it might issue a remote procedure call, or (I guess) it might be actually be an SOA-enabled stored procedure.

* BTW, how can a client distinguish a data service from a business service? I don't think there is in fact a distinction between them, only some designer expectations about where the service is deployed.