BT

InfoQ Article: 10 Principles of SOA

| by Floyd Marinescu Follow 38 Followers on Feb 27, 2007. Estimated reading time: less than one minute |
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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Bravo! by Rajeev Kozhikkattuthodi

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

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

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

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

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

Re: Good and interesting, however by graham berri

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss
BT