InfoQ Article: 10 Principles of SOA

Posted by Floyd Marinescu on Feb 27, 2007

Sections

Enterprise Architecture

Topics

SOA ,

Web Services

Tags

XML ,

Web services ,

Best Practices ,

Patterns

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.

1. Back to top

   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?

   Reply

2. Back to top

   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!

   Reply

3. Back to top

   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.

   Reply

4. Back to top

   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.

   Reply

5. Back to top

   Very Good!

   by Carlos Rodriguez

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

   Reply

6. Back to top

   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.

   Reply

• Older >