Opinion: When Designing Your SOA - Taste is Everything

| by Dilip Krishnan Follow 0 Followers on Jun 24, 2008. Estimated reading time: 1 minute |
Dan Creswell claims that "taste is everything" when it comes to putting together the pieces that make a good SOA. Dan  says that picking the technology stack for distributed services, how you layer the service "units", etc, are a matter of taste as well as consideration of a number of guidelines, as opposed to just taking a cookie cutter approach to SOA as some seem to claim is possible. Dan concludes providing some of his own guidelines for SOA.

According to Dan:

[...] we’d like to believe that architecture (and much of development) can be done with fixed rules, cookie cutter style, get your catalog of patterns and technology, apply them - job done. The ultimate embodiment of this behaviour is ... [thinking that] ... deploying an ESB [...] makes your system [an] SOA.

He says that even in good architectures data dependency is unavoidable, and suggests layering the code and data vertically to isolate service "units" higher up in the chain from having direct dependency on the data. This form of layering does have its own drawbacks because its bakes in assumptions of location agnosticity and synchronicity of invocation into the higher order service units. To avoid issues related to these assumptions, he suggests that "we deploy each unit in it’s own process accessed via some network endpoint that dependants use to interact with it". Such a deployment, he says, afford run-time performance benefits via techniques like 'sharding, horizontal scaling and load-balancing and maintainability in terms of testing and hot-patching these units. It also allows teams to work "independently of development efforts elsewhere, making for less contention in development".

He proposes the following set of guidelines on layering code and data and choosing distributed architectures and cautions that one still needed to think about consistency issues related with this design choice and "also take [into consideration] the fallacies of [distributed computing]":

  1. Considering similarities in consistency, availability and partitioning (CAP) requirements
  2. Data access localities
  3. Data relationships
  4. Jurisdictional requirements
  5. Roles and responsibilities (at coarser level than OO)
  6. Features (e.g. recommendations)
  7. Business processes
  8. Constituent elements of an overall business process

... and concludes by saying "most systems likely require a combination of these [guidelines] rather than one fixed approach, taste and gut instinct count for a lot." Be sure to check out the original post.

Rate this Article

Adoption Stage

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
Community comments

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


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you