BT

InfoQ Homepage News InfoQ Article: 10 Principles of SOA

InfoQ Article: 10 Principles of SOA

Bookmarks
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
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.

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

Community comments

  • 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.

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

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

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.