In this article, InfoQ's Stefan Tilkov, consultant at innoQ, proposes 10 principles to serve as a basis for SOA discussions. The list starts with Don Box's four tenets (service with explicit boundaries, shared contract and schema, policy-driven, and autonomous) and expands them to include wire formats, document orientation, loose coupling, standards compliance, vendor independence, and metadata.
Read 10 Principles of SOA.
Read 10 Principles of SOA.
How might we improve InfoQ for you
Thank you for being an InfoQ reader.
Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.
Community comments
Bravo!
by Rajeev Kozhikkattuthodi,
Re: Bravo!
by Stefan Tilkov,
Good and interesting, however
by graham berri,
Re: Good and interesting, however
by Stefan Tilkov,
Re: Good and interesting, however
by graham berri,
Very Good!
by Carlos Rodriguez,
Bravo!
by Rajeev Kozhikkattuthodi,
Your message is awaiting moderation. Thank you for participating in the discussion.
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?
Re: Bravo!
by Stefan Tilkov,
Your message is awaiting moderation. Thank you for participating in the discussion.
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!
Good and interesting, however
by graham berri,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Good and interesting, however
by Stefan Tilkov,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Very Good!
by Carlos Rodriguez,
Your message is awaiting moderation. Thank you for participating in the discussion.
Good work!!..
It is very good principles!.
Re: Good and interesting, however
by graham berri,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.