C/C++ Users Journal February, 2005
The rapid concurrent growth of web services/SOAP (Simple Object Access Protocol) and SOA (Service-Oriented Architecture), compounded with the associated hype, has lead to confusion between these two key technologies. In this article, I examine some defining aspects of an SOA and the importance of accessibility of its services. I also look at how SOAP is one of many different middlewares that may be used to access services, and then present some examples of where SOAP and other middlewares are appropriately applied.
SOAs have become popular recently, in many cases because of their strength as an integration and consolidation platform. In fact, such architectures are often called "SOIA," where "I" is for "Integration." SOA platforms have been adopted by companies that know all too well the costs of maintaining large, complex, heterogeneous enterprise systems with significant redundancy, often built up over time through acquisitions, and patched together.
The building block of an SOA is a service. A service at its core consists of an interface and implementation, neither of which needs to be middleware specific. For example, a service could be implemented as POJOs (Plain Old Java Objects). Services may be classified as application, business, infrastructure, or data services. Application services have a one-to-one relationship with applications but exclude presentation since services must be usable by multiple clients that may have different or no presentation. An example of an application service is a Finance Service. Business services are more vertical and contain business logic that is reused across application services; for example, a Stock Quote Service. Infrastructure services, on the other hand, are more horizontal or foundational; for example, a Security Service. Data services are similar to infrastructure services except they are focused on data access; a Query Service, for instance.
Each service in an SOA contains centralized logic that exists in that service for the use of all clients, including other services, in order to eliminate redundancy in enterprise systems. Given this goal, and the typically long lifetime of large enterprise systems, it is extremely important to provide convenient access to services in the SOA. Having an existing service that is easy to access greatly eases reuse. In contrast, if developers perceive it is easier to rewrite required aspects of a service than access an existing service, they will have the incentive to recreate required aspects of the service and introduce redundancy, undermining the benefits of an SOA.
To make a service easily accessible to an application client, requirements for the middleware between the client and service must be taken into consideration. For example, if the middleware must be asynchronous-message based and fault tolerant, you could use a messaging middleware that enables persistent queues. However, in a worst-case scenario, if the only middleware that is supported in an SOA is web services with SOAP/HTTP, then for the given application client, the service is not easily accessible and developers may be tempted to consider whether to solve the middleware gap or recreate the logic in the required service. The latter choice, of course, would lead to the introduction of redundancy in the SOA and is, therefore, highly undesirable as it undermines a key reason for choosing to do SOA.
While messaging can be a good choice for fault tolerance and integration with legacy systems, other middlewares can be appropriate given different requirements. For example, for external-client B2B access to services, where the client and service are maintained by separate organizations and flexibility is paramount, web services with SOAP/HTTP can be a good choice. However, given the performance penalty of SOAP, it is often undesirable to use SOAP/HTTP internally in an SOA pervasively between components maintained by the same organization since flexibility in this case is not as big a factor as in external interfaces, and the performance penalty of SOAP/HTTP can severely compromise the overall SOA performance. For such internal synchronous interactions in a J2EE SOA, you could, for example, use EJB RMI/IIOP for substantially better performance. Here, I don't attempt to evaluate or contrast all possible middlewares, but rather to simply illustrate how different practical requirements across applications within an SOA can prompt the use of different middlewares. In all but the smallest and simplest SOAs, this necessitates access to services using different middlewares, possibly including, but not limited to, SOAP. In fact, often the same service may be accessed using a variety of different middlewares concurrently. Regardless of middleware, it is desirable to keep services loosely coupled to improve performance, but this is not sufficient in itself to ensure SOA performance, and appropriate choice of middleware is often pivotal.
In practice, it is unlikely that all middleware requirements over the lifetime of the SOA will be known at the initial implementation time. The SOA should be tolerant to the easy addition of future middlewares to access existing services. This can be achieved by separating services from access by keeping service implementations middleware-independent and front-ending services with middleware-specific bindings. For example, in a J2EE SOA, the service may be POJOs, while various middleware bindings including EJB, MDB, and SOAP may front-end services. These bindings would not contain any logic, and would simply delegate to the service they are associated with. Furthermore, by maximizing the use of autogeneration in the creation of the middleware bindings, one adds agility that enables rapid addition of new middleware without rewriting services.
Only once an SOA is clearly defined as separate from middleware and the need for multiple different types of middleware to access services is recognized, can the true and maximum benefits of the SOA be realized.