Partager via

The SOA Elephant

  • Article

SOA is like that old fable from India about the blind men and the elephant - everyone describes it a bit differently (analyst definitions are omitted because I want to focus on implementations, not forecasts or speculations):

  • To IBM SOA appears to be an IT infrastructure for business enablement:
    • “SOA is an enterprise-scale IT architecture for linking resources on demand. These resources are represented as business-aligned services which can participate and be composed in a value-net, enterprise, or line of business to fulfill business needs. The primary structuring element for SOA applications is a service as opposed to subsystems, systems, or components.” (from a recent IBM Webcast)
  • To BEA SOA appears to be about making IT more efficient using web services:
    • “SOA is a design methodology aimed at maximizing the reuse of application-neutral services to increase IT adaptability and efficiency. While these concepts have existed for decades, the adoption of SOA is accelerating due to the emergence of standards-based integration technologies like web services and XML." (from a recent BEA white paper)
  • To Sun SOA appears to be business-centric services using the web services specifications:
    • “SOA is an architectural style that emphasizes well-defined, loosely coupled, coarse-grained, business-centric, reusable shared services. Services are well-defined encapsulations of business assets. They are network based, described using standards-based interface languages, such as the web services Description Language (WSDL), and accessed via Web-based protocols such as the Simple Object Access Protocol (SOAP). A service can be accessed by any client capable of making SOAP invocations. However, services are typically accessed by Business Process Execution Language (BPEL) engines, portals, and/or applications. Additionally, services descriptions and APIs are published in a common registry to enable easy discovery by potential service consumers.” (from a recent Sun white paper)

These definitions are all well and good, but I believe they miss the point - SOA is a means, not an end. In other words, SOA is just a way to enable an agile enterprise - its not the endgame. Its only after SOA that things really start to get interesting.

I think the concept of Service Orientation (lose the "A") is a much more exciting idea. If we think purely in terms of service orientation, then:

  1. Everything within a SOA can be perceived as a service provider (even things like a printer or that annoying guy from purchasing)
  2. Service providers expose capabilities through publicly abstract interfaces (this is WSDL today, possibly something more expressive in the future)
  3. Service capabilities can be aggregated into processes (processes may extend, constrain or reconfigure existing services)
  4. The SO model is fractal (processes (entire SOAs even) can be viewed as a whole, aggregated, or cleaved into more granular services)

What are your thoughts (or flames) on this?

Comments

  • Anonymous
    November 23, 2004
    Is there anywhere a code sample available (C#, VB, java perl ...) which shows how to take an existing web service and make it service oriented?

    There is lot of talk on SOA but very few samples available.
  • Anonymous
    November 23, 2004
    Well, I must admit that two different pattern types: architectural and implementational - are mixed too often, but in most cases it is done by business people (not the architects). Business people are promoting their solutions by adding the terms like SOA mixed with web services, because it is understood by customers as "cool".
  • Anonymous
    November 23, 2004
    Abhishek,

    If you ask 5 people you'll probably get 5 different answers. Here's mine:

    - Design your services to comply with the WS-I Basic Profile

    - Adopt the (now infamous) 4 tenets of service design:

    - Services share schema (not classes)
    - Services have well-defined boundaries
    - Services should be autonomous
    - Use policy-based assertions

    If you adopt these simple design principles you'll save yourself a lot of trouble (especially as the number of deployed services within your organization grows).

    I'm currently working with the Patterns & Practices (PAG) Team to develop some Patterns and Anti-Patterns for SOA. I'll be posting some of these to my blog (along with some code snippets of course) to generate some critical feedback. Stay tuned!

  • Anonymous
    November 25, 2004
    David Parnas said as much about OO back before SOA was even a twinkle in anyone's eye... (See, e.g., http://blog.fivesight.com/prb/space/start/2004-08-06/2)
  • Anonymous
    November 25, 2004
  • Services Share Schema not classes.

    Isn't the schema of the web service embeded in the WSDL? and we only expose the WSDL?