The World of SOA: Laundries, Legos, and Home Construction

As an architect explaining SOA concepts to developers of traditional enterprise applications, I encountered various analogies comparing the concepts of SOA to LegoTM blocks, which are actually considered by some experts as being misleading and superficial. Therefore, recent analogies by Antony Reynolds and Richard Veryard comparing services to a laundry, brought back memories of yet another analogy I used a couple of years ago – comparing business process driven SOA to home construction.

Let’s pretend you want to build a house from the ground up. You hire a general contractor, who is responsible for the overall execution of the project. The contractor locates a provider of concrete and makes a phone call to ask for estimates and the schedule for pouring the foundation slab. Next, the contractor will call and coordinate the lumber delivery, following which the framers can come out to do their job. In parallel, the contractor gets estimates from electricians and has to decide on the one that not only has the best rates, but also someone who is certified as per city code and who can meet the schedule. And finally, the roofers, plumbers and painters are arranged to complete the job.

Let’s put this in the perspective of SOA technologies.

SOA Orchestration Analogy

SOA Orchestration Explained

The general contractor is a BPEL Process, whose purpose is to orchestrate all the Services from disparate heterogeneous systems. The services in this example are the different actors – the concrete provider, foundation company, lumber company, framers, electricians, roofers, plumbers and painters. The contractor found the providers by searching the Yellow Pages (UDDI) and found the phone listing (WSDL); communicated by voice (XML) over the phone (standards based Web Service) in English (Standardized Semantics). He got quote and availability information, without having to really understand much about the inner workings of the concrete business (Service Abstraction), and as long as the provider abides by the contract, the contractor does not care who the actual electrician is (Service Virtualization).

I found that this metaphor helped many a legacy developer understand the complex SOA technologies better than the overly simplistic LegoTM blocks analogy. However, as recommended in the other blogs too, it is best to not push the metaphor too far. Once the SOA basics have been understood, its purpose is served; and no other simplistic metaphor can then explain every one of the prolific WS-<insert your favorite noun here> specifications.

UPDATE 07/30/2008: Richard points out a sequel to his laundry post: Services Not All Like Laundry. And just when we thought we had it all sorted out 🙂


Schema Centralization Pattern

The SOA Design Patterns site (and book) has an interesting chapter on the topic of schema centralization.  The recommended solution is essentially the pattern used in AIA.

1. Establish your service inventory using a top-down business process model driven approach.

2. Identify the Enterprise Business Objects (EBO) and Enterprise Business Messages (EBM).

3. Create the EBO Schema canonical definitions using the industry standards.

4. Create the Enterprise Business Services (EBS) utilizing the EBMs created above.

The Case Study section in the end is empty, but AIA could very well be its best case study!

Welcome to my blog!

Welcome to my blog!

Update: September 09, 2010

The goals of this blog as well as information about me are listed on the side bar, so I would like to take this opportunity to spell out the code of ethics for this blog, adapted from my colleague’s excellent blog.

  1. The views expressed on this blog are mine (and those of any future guest authors) and do not necessarily reflect the views of my employer (or those of future guest authors’ employers).
  2. Authors’ opinions about products/services – ranging from enthusiasm to skepticism – do not necessarily represent the views of the owning companies. This applies to Oracle (my current employer) products as well.  Comments on the technical abilities of these products/services should not be interpreted to be endorsements or criticisms of the same. Of course, opinions and views may continue to evolve over time.
  3. Factual errors found (or reported) will be corrected as soon as possible.  Changes will be documented, as appropriate.
  4. Any copyright violations found should be reported using the comments and will be rectified as soon as possible.
  5. This blog will not make any statements about upcoming features, releases and certifications, instead it will link back to the product’s official home page or blog.
  6. This blog does not permit speculation about unreleased, non-public information and discussion of confidential information.
  7. This blog may cross-post articles with the authors other hosted blogs e.g. The Official AIA Blog. Such cross-posts shall typically be tagged using its own category.

– Rajesh Raheja