The infrastructure for SOA is implemented within the context of the SOA Reference Architecture. SOA places unique requirements on enterprise IT infrastructure. Good choice of infrastructure products, and their effective integration, are crucial for SOA implementation.

An effective architecture makes this possible.

• The architecture should have building blocks to which vendors can match their products, so that you can compare products like-for-like.
• The building blocks should be defined by open standards for interoperability.
• The architecture should be expressed in terms of a standard reference architecture, so that it can easily be comunicated to developers and integrators.

This section of the SOA Reference architecture will help you to achieve these goals. It describes a number of SOA infrastructure building blocks that correspond to products that are available today. It identifies the key standards to which those products can conform. And it is based on the conceptual building blocks of SOA, the high-level SOA model, and the detailed models for SOA features described in this Source Book.

Service Repository

Re-use of software services is a very important aspect of SOA for many enterprises. They often introduce governance mechanisms to ensure that services are developed with re-use in mind, and that the possibility of re-using existing services is explored before new ones are written. But, for re-use to be possible at all, the services must be clearly described, and their descriptions must be readily available to developers.

The simplest way of making service descriptions available is to publish them as documents. A more sophisticated mechanism, which has advantages where there are large numbers of services to keep track of, is a service repository, which enables you to maintain and search a database of service descriptions.

In a large enterprise you may have a very large number of services, and you will need a common vocabulary and data model, as well as some sort of knowledge management system, as the basis for your services repository.

Registries used in service discovery can be used as service repositories. There are a number of specialist service registry products that are commercially available, but they tend not to provide good support for searches conducted by people, and are useful at run time, rather than at design time.

The Web Services Description Language (WSDL) defined by the World-Wide Web Consortium (W3C) is a commonly-accepted standard for service descriptions. There is no commonly-accepted standard for repository management and search operations.

Messaging Program

Between enterprises, services typically exchange messages via the Web. Within an enterprise, they are often exchanged using an enterprise services bus (ESB). The term ESB can mean many different things; the term messaging program used here describes a program that has essential ESB functionality. Commercial ESB products should include this functionality, but often also have additional features, such as those of other building blocks of the detailed messaging model that are described later in this section.

A messaging program transports messages between other programs. It performs the messaging service shown in the basic messaging model, and may interface to management programs, encryption engines, data translators, policy decision points, policy enforcement points, and activity monitors as described in the detailed messaging model.

A messaging program must support the following functions:

• Acceptance of submitted messages;
• Message delivery; and
• Message routing.

A messaging program may optionally support the following additional functions:

• Routing configuration;
• Configuration of attached encryption engines, data translators, policy decision points, policy enforcement points, and activity monitors;
• Logging;
• Auditing;
• Assurance of delivery; and
• Protocol transformation (between different message submission and delivery interface formats).

A messaging program has one principle interface: message submission and delivery. The Simple Object Access Protocol (SOAP) defined by W3C is a commonly-accepted standard for this. In use, SOAP is layered on top of more basic communication protocols, such as the Hypertext Transfer Protocol (HTTP).

SOAP is the core message transmission standard. W3C also defines related standards for addressing, resource representation, and message transmission optimization.

SOAP and its related standards were defined in the first instance for web services. They are also supported, at least to some extent, by many messaging program products.

SOAP does not provide assurance of message delivery. Another protocol, Web Services Reliable Messaging (WS-ReliableMessaging), defined by OASIS, includes mechanisms that enable messages to be transferred reliably in the presence of software component, system, or network failures. Its specification includes a SOAP binding, so that it can be layered on top of SOAP.

SOAP is a standard that enables interoperability between messaging systems. For portability across messaging systems, software services should use a standard interface dependant on the programming language, such as the Java Messaging Service (JMS).

The Web Services Security (WS-Security) standards defined by OASIS are commonly-accepted standards that provide for message encryption and encapsulation of security tokens. A messaging program that interfaces to an encryption engine may support WS-Security for encryption, and a message bus that interfaces to policy decision points and policy enforcement points may support WS-Security for security tokens.

A message bus that interfaces to management programs, encryption engines, data translators, policy decision points, policy enforcement points, or activity monitors can communicate with them using the same interface as for message submission and delivery, but is more likely to use different interfaces that are designed to support the particular programs concerned.

Activity Monitor

An activity monitor is a program that interfaces to a messaging program as described in the detailed messaging model, and monitors the messaging activity.

An activity monitor has three principal interfaces:

• Message bus;
• Results; and
• Configuration.

SOAP is a commonly-accepted standard for the interface to the message bus.

There are no commonly-accepted standards for output of the results of the monitoring, or for configuration of the monitor.

PDPs and PEPs

A Policy Decision Point (PDP) is a program that decides, in accordance with a policy, whether resource access requests should be granted. A Policy Enforcement Point (PEP) is a program that implements decisions to grant or deny resource access requests.

PDPs and PEPs co-operate as part of an overall policy framework. Such a framework can be used to enforce policies of various kinds, including security and performance management.

PDPs and PEPs can be attached to messaging programs, as shown in the detailed messaging model. When used in this way, they can control acceptance of messages for transport over the bus, and can control delivery of messages to services.

PEPs can also be embedded within the services themselves.

There are a number of standards that are relevant to PDPs and PEPs, including the Web Services Policy Framework (WS-Policy) defined by W3C, the Web Services Security Policy (WS-Security-Policy) standard defined by OASIS, the eXtensible Access Control Markup Language (XACML) defined by OASIS, and the Security Assertion Markup Language (SAML) defined by OASIS.

Data Translator

A data translator is a program that converts data from one representation to another. It can interface to a message bus, as shown in the detailed messaging model.

A data translator has three principal interfaces:

• Input data format;
• Output data format; and
• Translation Specification.

The eXtensible Markup Language (XML) defined by W3C is a commonly-accepted generic standard for the input and output data formats. Document type definitions (DTDs) and XML schemas are used to define specific XML data formats.

Where the data translator interfaces to a message bus, SOAP (with XML layered on top) is a commonly-accepted standard for transport of the input and output data.

Encryption Engine

An encryption engine is a program that:

• Encrypts and decrypts data; and
• Applies and verifies integrity checks based on encryption technology.

As shown in the detailed messaging model, an encryption engine can be connected to a messaging program. In this situation it encrypts or applies integrity checks to messages, either for transmission over the bus or for transmission from the bus over the Internet, and decrypts or verifies the integrity of messages prior to delivery to services using the bus.

An encryption engine has five principal interfaces:

• For submission of data for encryption, and return of the encrypted data;
• For submission of data for decryption, and return of the decrypted data;
• For application of integrity checks;
• For verification of integrity checks; and
• For configuration and management (including encryption key management).

WS-Security includes extensions to SOAP that provide message integrity and confidentiality. They also provide the ability to send security tokens in SOAP messages, and this feature enables higher-level security mechanisms.

Where an encryption engine is connected to a message bus, or sends and receives data via the Internet, WS-Security is a commonly-accepted standard for submission of data for encryption and decryption, and for application and verification of integrity checks. However, product-specific interfaces are often used instead.

There is no commonly-accepted standard for the configuration and management interface.

Event Processor

An event processor is a program that processes input events and combines them to generate output events, as described in the model for event processing.

An event processor has three principal interfaces:

• Input event;
• Output event; and
• Configuration.

Input events and output events can be SOAP messages. SOAP is however not necessarily an appropriate standard for all event interfaces.

There is no commonly-accepted standard for the configuration interface.

Composition Engine

A composition engine is a program that executes scripts that control services and describe interactions between them. It is used to perform one or more of the services in a composition, as described in the model for scripted service composition.

A composition engine has two principal interfaces:

• With the scripts; and
• With the services with which it interacts.

The Web Services Business Process Execution Language (BPEL) defined by OASIS is a widely-accepted standard language for describing service compositions. It is based on XML and integrated with WSDL. It can be used by an enterprise to define compositions of internal and external services. The composed services can include both short-term and long-running transactions.

SOAP is a commonly-accepted standard for the interface between a composition engine and the services with which it interacts.

Service Registry

A service registry is an organized collection of service descriptions, maintained by a registry service that returns the descriptions that match specifications in submitted enquiries, as described in the model for service discovery.

A registry service has two principle interfaces:

• For management of the service descriptions that it maintains; and
• For enquiries and responses.

The Universal Description Discovery and Integration (UDDI) standards published by OASIS are the most commonly-accepted standards for both of these interfaces. They apply to web-based registries that expose information about businesses or other entities.

The original UDDI concept was of public registries for businesses and services, and several well-known companies provided public UDDI nodes. However, in January 2006 those companies announced the closure of their nodes. UDDI is now mostly used as an internal registry standard within corporations.

The UDDI standards define interfaces, based on SOAP and XML, for publication and inquiry of registry contents. Publication and inquiry are services, and the UDDI standards include descriptions of these services in WSDL. Also, it is possible to map UDDI service descriptions to WSDL service descriptions. This means that UDDI can be used together with WSDL in a service-oriented architecture.

A significant limitation of UDDI, which has made service discovery less useful than had been hoped, is the difficulty of matching service descriptions to consumer needs. A person reading a “Yellow Pages” directory understands that a building contractor may provide roofing services, and looks under “Building Contractors” as well as under “Roofing Services” when a roof needs repair. Software programs can not yet make this kind of connection in a general way. There is however another possible approach, which is not yet established, but which promises better search capabilities. This is the use of the Web Ontology Language (OWL) defined by W3C for service descriptions published as part of the Semantic Web. A group of researchers is developing an OWL web service ontology known as OWL-S, which includes a core set of markup language constructs for describing the properties and capabilities of Web services, and is designed to be used with WSDL.

Service Components

A service component is a program that plays a a part in performing a service. Service components include programs that implement service interfaces using underlying assets, as in the asset wrapping model.

These service components often employ container-based technologies, such as Enterprise JavaBeans technology (EJB).

Service components are a limiting influence on performance. The technology selected as the basis for service components must be carefully considered from this point of view.

Service component building blocks that implement service interfaces must conform to the same interface standards as the services. In a SOA that uses messaging, these typically include WSDL and SOAP.

Model-Implementation Environment

A model-implementation environment is a set of programs that support:

• The creation of models for services or service compositions; and
• The implementation of programs and scripts that perform the services and compositions directly from the models, without substantial human intervention.

A model-implementation environment has two principal interfaces:

• Model-description language; and
• Implementation metamodel.

OWL is also sometimes used for describing models of systems and applications, instead of, or together with, the OMG standards.