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:
- Everything within a SOA can be perceived as a service provider (even things like a printer or that annoying guy from purchasing)
- Service providers expose capabilities through publicly abstract interfaces (this is WSDL today, possibly something more expressive in the future)
- Service capabilities can be aggregated into processes (processes may extend, constrain or reconfigure existing services)
- 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?