Overview

Service-Oriented Architecture (SOA) is an architectural approach that emphasizes the delivery of functionality as services. Whether you create services based on legacy systems or are modeling and monitoring the business processes built upon new services, the Cape Clear ESB Platform provides the support you need to create an enterprise wide SOA.

The Cape Clear ESB Platform

Figure 1: The Cape Clear ESB platform

The deployment of a SOA requires the conversion of existing systems into services. The tasks involved in achieving this can be repeated for each system and a common set of components may be needed to provide additional functionality such as security and auditing. An Enterprise Service Bus (ESB) is a collection of servers and components that provide these functions and a set of tools to assist in the conversion of existing systems to services. All this must be achieved without conflicting with the principles of SOA.

The ESB solves integration problems at the transport layer by providing reliable transports based on WS-ReliableMessaging (WS-RM) or by using JBoss JMS. It also supports a variety of commonly used transports including HTTP, SMTP, FTP, or queue-based messaging systems accessed through JMS, as well as legacy systems such as shared folders, so that existing systems can be connected to the ESB.

The ESB also provides for the routing of messages across various transports based on static routing configuration, content-based rules, or load balancing.

In addition to solving integration problems at the transport layer, the ESB supports a variety of data transformations in order to convert between legacy data formats and XML or between different XML formats.

The act of exposing an existing system as a Web service solves many of the integration issues. However, SOA specifies a number of principles to which services should conform. In most cases, these applications were not originally intended for such exposure and, as a result, lack many of the features needed to operate in this environment. Service mediation on the ESB provides a way of taking simple Web services or legacy applications and building new services that conform to all the principles of SOA.

The ESB provides many facilities by which the quality of service (QOS) for the new services created can be improved beyond that of the legacy systems on which they are based. Legacy applications can be protected from invalid requests through data validation performed by the ESB. Performance issues can be addressed through load balancing and throttling can ensure that legacy applications are not overloaded at peak times.

The ESB can also provide protection through the use of security. Messages on the ESB can be authenticated and then authorization policies ensure that users can only send messages to the services for which they are authorized. WS-Security can be used to ensure the integrity and confidentiality of messages. The use of other security protocols such as HTTPS is also supported and can be enforced by the ESB.

The Cape Clear ESB supports the core Web services protocols: SOAP 1.1, HTTP 1.1, XML 1.0, XML Schema 1.0, WSDL 1.1 and UDDI v2. Interoperability is ensured through conformance to the WS-I Basic Profile 1.1, WS-I Attachments Profile 1.0 and WS-I Basic Security Profile 1.0. Additional features are provided through support for WS-Security 1.0, WS-Addressing 1.0, WS-RM 1.0, and BPEL 1.1.

An Overview of SOA

A Service-Oriented Architecture is the result of careful and consistent deployment of services. Let’s start by defining the characteristics of an individual service.

What Is a Service?

A service can be invoked remotely. It cannot assume that the client of the service is operating in the same environment.

A service has a well-defined interface described in an implementation-independent manner. This interface description should describe not only the API to the service, but should include all details necessary for a client to invoke the service. Such details include protocol bindings and transport details.

A service is self-contained, that is, it can be used independently of any other services. Notice that this does not preclude the composition of services built on top of other services. However, it does preclude an implicit sharing of state between services where the client would be required to understand such internal behavior in order to use the service.

A service performs a specific task. The task performed is typically a business task, for example, validating a credit card number.

A service is loosely coupled. This characteristic covers a number of issues, including:

• The use of document passing in preference to Remote Procedure Calls (RPCs). This also implies that the services should be coarse-grained, as opposed to fine¬grained. For example, a coarse-grained service might accept a document containing all the details required to apply for a loan, while a fine-grained RPC API might provide separate operations to set data such as customer details, the loan amount, and the purpose of the loan.
• Asynchronous message exchange, as opposed to synchronous systems, where the client demands that the service is available to handle its request immediately.

The references to services can be discovered rather than fixed at development or deployment time.

Service-Oriented Architecture (SOA)

SOA is a way of approaching the task of creating software. It can be thought of as either a collection of architectural concepts or a programming model. Within a SOA, all functionality is provided by services as described above. This provides a level of flexibility in deploying and reusing services not previously attained.

However, a SOA is more than just a collection of services; it adds a number of principles. Interoperability is the most important of these and is core to the idea of SOA. Interoperability is achieved through the use of standards. The Web services standards stand out above all others in satisfying this requirement: remote invocation is provided through SOAP, service interfaces are described using WSDL, and services are discovered through the use of UDDI. In fact, wherever possible, all aspects of the services should conform to the relevant standards.

Another core feature in a SOA is the reuse of existing assets. Deployment of a SOA within an organization is an exercise in creating services from the existing IT systems and infrastructure. For example, systems exposed using object-based middleware are instead exposed using services that accept documents. Legacy systems such as mainframes can be exposed over standard transports and protocols.

Services should be self-contained, enabling them to be invoked directly by clients where necessary. SOA extends this idea to the aspects of services that might not be considered business logic, including features such as security, logging, and auditing. This means that each service within the architecture should provide these features directly. This approach is vital if the deployed services are to form a truly distributed system. For example, a single point through which messages must flow in order to be audited will lead to a hub-and-spoke architecture, instead of the desired distributed system.

The use of a standardized protocol envelope is an important part of any SOA. The document payload for each service may differ, but a standardized protocol envelope provides a mechanism to support the processing of messages by intermediaries. Such mechanisms are used to support features such as addressing, routing, security, and policies. SOAP defines the envelope and numerous other standards define how headers within the envelope are used.

Once the SOA is in place, the existing IT systems within an organization can be viewed as services that provide business functions. These are easily integrated, because they provide well-defined interfaces and can be accessed using standard protocols and transports. This provides the basis on which to orchestrate services into new services that reflect business processes.