The Enterprise Application Architecture, Part 2
SOA. Sons of A…. I mean Service-Oriented Architecture. What exactly is this? And what’s the big deal?
In Part 1, I talked about Software as a Service, and mentioned Platform as a Service as well as Infrastructure as a Service. Each of those strategies is taking a commonly used aspect of technology and converting it to a service that can be accessed over the Internet. SaaS, as I mentioned in Part 1, is about delivering an application over the Internet to an end consumer, or simply, a distribution method. SOA, on the other hand, is architectural approach for application development, or a development method. By converting all parts of a system to act as independent services, then those same pieces can be used by multiple applications, all having a common framework for communication, referred to as a service bus. These pieces become the building blocks for a larger system, enabling the parts to easily interact with one another.
IBM uses a combination of multiple definitions to elaborate on SOA :
- A set of services that a business wants to provide to their customers, partners, or other areas of an organization
- An architectural style that requires a service provider, mediation, and service requestor with a service description
- A set of architectural principles, patterns and criteria that address characteristics such as modularity, encapsulation, loose coupling, separation of concerns, reuse and composability
- A programming model complete with standards, tools and technologies that supports web services, REST services or other kinds of services
- A middleware solution optimized for service assembly, orchestration, monitoring, and management
The more you search around the Internet, the more varied and diverse definitions you find for SOA. As Martin Fowler, software developer, author and Chief Scientist for ThoughtWorks (a technology consulting company), says in his 2005 article Service Oriented Ambiguity:
- For some SOA is about exposing software through web services. This crowd further sub-divides into those that expect the various WS-* standards and those that will accept any form of XML over http (and maybe not even XML).
- For some SOA implies an architecture where applications disappear. Instead you have core services that supply business functionality and data separated by UI aggregators that apply presentations that aggregate together the stuff that core services provide.
- For some SOA is about allowing systems to communicate over some form of standard structure (usually XML based) with other applications. In it’s worse form this is “CORBA with angle brackets”. In more sophisticated forms this involves coming up with some form of standard backbone for an organization and getting applications to work with this. This backbone may or may not involve http.
- For some SOA is all about using (mostly) asynchronous messaging to transfer documents between different systems. Essentially this is EAI without all the expensive EAI vendors locking you in.
So do we have a better understanding of SOA? Or is it chaos and anarchy? I think his definition by Oracle was simple enough for a begining understanding: “A service-oriented architecture is a way of sharing functions (typically business functions) in a widespread and flexible way.”