(For more resources on BPEL, SOA and Oracle see here.)

If we want our SOA architecture to be highly fexible and agile, we have to ensure loose coupling between different components. As service interfaces and endpoint addresses change over time, we have to remove all point-to-point connections between service providers and service consumers by introducing an intermediate layer—Enterprise Service Bus (ESB). ESB is a key component of every mature SOA architecture and provides several important functionalities, such as message routing, transformation between message types and protocols, the use of adapters, and so on. Another important requirement for providing fexibility is service-reuse. This can be achieved through the use of UDDI (Universal Description, Discovery and Integration) compliant service registry, which enables us to publish and discover services. Using service registry we can also implement dynamic endpoint lookup, so that service consumers retrieve actual service endpoint address from registry in runtime.

Oracle Service Bus architecture and features

ESB provides means to manage connections, control the communication between services, supervise the services and their SLAs (Service Level Agreements), and much more. The importance of the ESB often becomes visible after the frst development iteration of SOA composite application has taken place. For example, when a service requires a change in its interface or payload, the ESB can provide the transformation capabilities to mask the differences to existing service consumers. ESB can also mask the location of services, making it easy to migrate services to different servers. There are plenty other scenarios, where ESB is important.

In this article, we will look at the Oracle Service Bus (OSB). OSB presents a communication backbone for transport and routing of messages across an enterprise. It is designed for high-throughput and reliable message delivery to a variety of service providers and consumers. It supports XML as a native data type, however, other data types are also supported. As an intermediary, it processes incoming service request messages, executes the routing logic and transforms these messages if needed. It can also transform between different transport protocols (HTTP, JMS, File, FTP, and so on.). Service response messages follow the inverse path. The message processing is specifed in the message fow defnition of a proxy service.

OSB provides some functionalities that are similar to the functionalities of the Mediator component within the SOA Composite, such as routing, validation, fltering, and transformation. The major difference is that the Mediator is a mediation component that is meant to work within the SOA Composite and is deployed within a SOA composition application. The OSB on the other hand is a standalone service bus. In addition to providing the communication backbone for all SOA (and non-SOA) applications, OSB mission is to shield application developers from changes in the service endpoints and to prevent those systems from being overloaded with requests from upstream applications.

In addition to the Oracle Service Bus, we can also use the Mediator service component, which also provides mediation capabilities, but only within SOA composite applications. On the other hand, OSB is used for inter-application communication.

The following figure shows the functional architecture of Oracle Service Bus (OSB). We can see that OSB can be categorized into four functional layers:

• Messaging layer: Provides support to reliably connect any service by leveraging standards, such as HTTP/SOAP, WS-I, WS-Security, WS-Policy, WS-Addressing, SOAP v1.1, SOAP v1.2, EJB, RMI, and so on. It even supports the creation of custom transports using the Custom Transport Software Development Kit (SDK).
• Security layer: Provides security at all levels: Transport Security (SSL), Message Security (WS-Policy, WS-Security, and so on), Console Security (SSO and role based access) and Policy (leverages WS-Security and WS-Policy).
• Composition layer: Provides confguration-driven composition environment. We can use either the Eclipse plug-in environment or web-based Oracle Service Bus Console. We can model message fows that contain content-based routing, message validation, and exception handling. We can also use message transformations (XSLT, XQuery), service callouts (POJO, Web Services), and a test browser. Automatic synchronization with UDDI registries is also supported.
• Management layer: Provides a unifed dashboard for service monitoring and management. We can defne and monitor Service Level Agreements (SLAs), alerts on operation metrics and message pipelines, and view reports.

Proxy services and business services

OSB uses a specifc terminology of proxy and business services. The objective of OSB is to route message between business services and service consumers through proxy services.

Proxy services are generic intermediary web services that implement the mediation logic and are hosted locally on OSB. Proxy services route messages to business services and are exposed to service consumers. A proxy service is confgured by specifying its interface, type of transport, and its associated message processing logic. Message fow defnitions are used to defne the proxy service message handling capabilities.

Business services describe the enterprise services that exchange messages with business processes and which we want to virtualize using the OSB. The defnition of a business service is similar to that of a proxy service, however, the business services does not have a message fow defnition.

Message fow modeling

Message fows are used to defne message processing logic of proxy services. Message fow modeling includes defning a sequence of activities, where activities are individual actions, such as transformations, reporting, publishing and exception management. Message fow modeling can be performed using a visual development environment (Eclipse or Oracle Service Bus Console). Message fow defnitions are defned using components, such as pipelines, branch nodes and route nodes, as shown in the following fgure:

A pipeline is a sequence of stages, representing a one-way processing path. It is used to specify message fow for service requests and responses. If a service defnes more operations, a pipeline might optionally branch into operational pipelines. There are three types of pipelines:

• Request pipelines are used to specify the request path of the message flow
• Response pipelines are used to specify the response path of a message flow
• Error pipelines are used as error handlers.

Request and response pipelines are paired together as pipeline pairs. Branch nodes are used as exclusive switches, where the processing can follow one of the branches. A variable in the message context is used as a lookup variable to determine which branch to follow.

Route nodes are used to communicate with another service (in most cases a business service). They cannot have any descendants in the message fow. When the route node sends the request message, the request processing is fnished. On the other side, when it receives a response message, the response processing begins.

Each pipeline is a sequence of stages that contain user-defned message processing actions. We can choose between a variety of supported actions, such as Publish, Service Callout, For Each, If… Then…, Raise Error, Reply, Resume, Skip, Delete, Insert, Replace, Validate, Alert, Log, Report, and more. Later in this article, we will show you how to use a pipeline on the Travel Approval process. However, let us frst look at the Oracle Service Registry, which we will use together with the OSB.