After several years, the IT industry is still buzzing with SOA (Service-Oriented Architectures). With the adoption of “The Cloud”, SOA is being positioned as the way to implement your applications into The Cloud. As with all technological fashions SOA promises to deliver better, faster, and cheaper IT support than was previously possible. All of the hype has resulted in a great deal of confusion around what SOA is, and what it isn’t. Is it a generation of middleware based on web services and the WS-* (Web service) family of standards? Is it a new generation of process modeling tools based on BPEL(Business Process Execution Language)? Is it something to do with enterprise architecture? Or is it another over hyped technology?
For many, SOA is very simple idea: break a solution into a number of discrete services and then organize the services into an end-to-end solution. This might sound very similar to the component based architectures of the late 90s as it is—the main difference being that SOA takes a more coarsely-grained view of functionality.
The most contentious point between SOA proponents has been defining a service; it is nearly impossible to get any two “experts” to agree on a single definition. Are they stateful or stateless? Do they support synchronous or asynchronous interfaces? Is WS-* mandatory? What makes them loosely coupled? It may not be necessary to create such a detailed definition when it is usually quite easy to find an exception invalidating it. For example, a data service (responsible for CRUD operations to persist a business object) can be considered either stateful or stateless depending on your point of view. The data service appears stateful to clients using it, as it allows them to persist objects and then retrieve them; the service’s state is the objects that are persisted. However, an implementer might create the service with an object-relational mapping tool making the implementation essentially stateless, as it simply passes all data through to an underlying database. Is the service stateful or stateless? It depends. It may be more productive to stick with a rather abstract definition.
An Abstract Definition of a service is: "A service is a coherent block of functionality that represents a distinct function or activity within the business."
A service-oriented architecture then becomes an architecture created by arranging a set of services. Rather than representing a solution as application layers—where each layer covers the full width of the solution—break the problem into a number of distinct services. Typically these services come on two flavors:
Business Services. Containing implemented business logic (processes and rules).
Technical Services. Supporting technical functionality required to ensure the smooth operation of the overall solution. This might include data services (for persisting business objects), services for authentication or identification, or even services that provide online access to catalogs of other services.
It may be obvious what technical services are required (typically one for each technical function supported) a major challenge in developing an SOA can be deciding on what business services need to be created. The answer is surprisingly simple: create a business service for each business function or supported activity.
It is important to note that technology must not have any impact on the high-level structure of the application landscape or cause dependencies between components. Actually, SOA must decouple business applications from technical services and make the enterprise independent of a specific technical implementation or infrastructure.
Since the 80s the business community has expended significant effort developing activity-based models of business (mostly based on Michael Porter’s book “Competitive Advantage: Creating and Sustaining superior Performance”) which break business into a number of discrete activities based on the idea of a value-chain. Rather than reinvent the wheel, technologists can leverage this work to simplify the creation of service-oriented architectures, with the added bonus that the resulting architecture will be meaningful for the business.
Once we’ve discovered the business services, the processes of identifying the required technical services becomes fairly straight forward. A business service that wants to persist business objects needs a technical data service. A business service connected to external partners requires a B2B gateway. Any user represented in a business process will require a user interface. And so on.
SOA tells an incredible story. However, there are a number of issues to consider when designing an enterprise service-oriented architecture. Service orientation will continue to be a moving target as the standards, tools, and runtime environments evolve. Service orientation has become the focus of all the primary development platforms. Tools are also being enhanced to provide developers with what they need to overcome many of the current obstacles.
SOA has the potential to become the best approach for building reusable application building blocks that can stand the test of time.
