Introduction to OSB

Introduction to OSB

Oracle Service Bus (OSB) was earlier known as AquaLogic Service Bus (ALSB) which was the product of BEA systems. Once it is acquired by Oracle ALSB become OSB.

Oracle Service Bus is component of Oracle Fusion Middleware stack and it is used for light weight messaging. Along with messaging, it also do message transformation and service monitoring.

• The Oracle Service Bus (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 specified in the message flow definition of a proxy service.
• The Service Bus should also perform the routing of messages between the components so no components would have to be dependent on the knowledge of the location of another component.
• OSB provides some functionality that are similar to the functionality of the Mediator component within the SOA Composite, such as routing, validation, filtering, 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.

Functional View of OSB

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

1. 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).
2. 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).
3. Composition layer: Provides configuration-driven composition environment. We can use either the Eclipse plug-in environment or web-based Oracle Service Bus Console. We can model message flows 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.
4. Management Layer:Provides a unified dashboard for service monitoring and management. We can define and monitor Service Level Agreements (SLAs), alerts on operation metrics and message pipelines, and view reports.

Proxy services and business services

OSB uses a specific 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:

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 configured by specifying its interface, type of transport, and its associated message processing logic. Message flow definitions are used to define the proxy service message handling capabilities.

Business services:

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

OSB Service Invocation:

OSB service invocation happens through two different layers: 

• proxy service and business service. Proxy service is an entry point for all service invocations. Ideally proxy service should present a canonical interfaces to clients.
• Proxy service then routes inbound message through a series of steps (using request and response pipelines).
• Each step can perform distinct operations such as transformation and logging etc., Eventually this message is routed to Business Service which is just a reference to target service.
•  Similarly, output message from business services follows reverse flow through outbound pipeline, proxy service and finally to the client.

Input and output pipe lines are also responsible for transforming data from and to canonical format.