2 Oracle Service Bus Architecture

This chapter provides an architectural overview of Oracle Service Bus and highlights operational features that enable rapid service integration, provisioning, and management across a heterogeneous IT infrastructure. It is intended for integration-focused IT architects responsible for messaging and service oriented architectures (SOA).

This chapter includes the following sections:

2.1 Architecture Overview

Oracle Service Bus architecture is centered around an Enterprise Service Bus. The bus provides message delivery services, based on standards including SOAP, HTTP and Java Messaging Service (JMS). It is typically designed for high-throughput, guaranteed message delivery to a variety of service producers and consumers. It supports XML as a native data type, while also offering alternatives for handling other data types.

Oracle Service Bus is policy driven and enables you to establish loose coupling between service clients and business services, while maintaining a centralized point of security control and monitoring. It stores persistent policy, proxy service, and related resource configurations in metadata, that can be customized and propagated from development through staging to production environments required. The message-brokering engine accesses this configuration information from its metadata cache.

Oracle Service Bus is an intermediary that processes incoming service request messages, determines routing logic, and transforms these messages for compatibility with other service consumers. It receives messages through a transport protocol such as HTTP(S), JMS, File, and FTP, and sends messages through the same or a different transport protocol. Service response messages follow the inverse path. The message processing by Oracle Service Bus is driven by metadata, specified in the message flow definition of a proxy service.

Figure 2-1 Oracle Service Bus Service Interactions

Description of Figure 2-1 follows
Description of "Figure 2-1 Oracle Service Bus Service Interactions"

The following high-level architecture diagram illustrates Oracle Service Bus and its functional subsystems.

2.2 Key Architecture Concepts

This section describes key architectural concepts in Oracle Service Bus.

2.2.1 Message Processing

Messages can contain data or status information about application processes, or instructions for the recipient, or both. Oracle Service Bus enables you to route messages based on their contents and to perform transformations on that content. The processing happens through the transport and binding layers of Oracle Service Bus.

Figure 2-2 Binding and Transport Layers in Oracle Service Bus

Description of Figure 2-2 follows
Description of "Figure 2-2 Binding and Transport Layers in Oracle Service Bus"

The processing of messages occurs in the following sequence of events:

  1. Processing of the inbound transport

  2. Message flow execution

  3. Processing of the outbound transport

After a message is sent to an endpoint (either a business service or another proxy service), Oracle Service Bus processes the response message in a similar model as that described in the preceding sequence of events.

The following figure illustrates a high-level message flow process through the Oracle Service Bus, from inbound endpoint (proxy service) to outbound endpoint (service transport URL - a business service or another proxy service).

Figure 2-3 Oracle Service Bus Message Processing

Description of Figure 2-3 follows
Description of "Figure 2-3 Oracle Service Bus Message Processing"

The following sections describe each layer involved in this message processing.

2.2.1.1 Binding Layer

The binding layer:

  • packs and unpacks messages as necessary

  • handles security for messages

  • hands messages off to start the message flows (request and response)

2.2.1.2 Transport Layer (Inbound)

The inbound transport layer is the communication layer between client services (or service consumers) and Oracle Service Bus. It is responsible for handling communication with the service client endpoint and acts as the entry point for messages into Oracle Service Bus. The inbound transport layer primarily deals with raw bytes of message data in the form of input/output streams.

It provides support for compatible transport protocols, including HTTP(S), JMS, FTP, File, and email. It is not involved in data processing but is responsible for returning response messages to service consumers and handles meta-data for messages, including endpoint URIs, transport headers, and so on.

2.2.1.3 Transport Layer (Outbound)

The outbound transport layer is responsible for the communication between business services (or service producers) and Oracle Service Bus. It is responsible for moving messages from Oracle Service Bus to the business service or proxy service and for receiving the response from the services. The message data, at the transport level, is in raw bytes in the form of input/output streams. The outbound transport layer provides support for compatible transport protocols, including HTTP(S), JMS, FTP, File, and email. It is not involved in data processing but handles meta-data for messages, including endpoint URIs, transport headers, and so on.

2.2.2 Proxy Services

Proxy services are a fundamental concept in the architecture of Oracle Service Bus. They are the interface that service consumers use to connect with managed back-end services. Proxy services are definitions of intermediary Web services that the Service Bus implements locally. Oracle Service Bus Administration Console allows configuration of a proxy service by defining its interface in terms of Web Services Description Language (WSDL) and the type of transport it uses. Message processing logic is specified in message flow definitions when defining a proxy service. For more information on proxy services, see Section 5.1.1.1, "Proxy Services".

2.2.2.1 Message Context

The context of a proxy service is a set of XML variables that are shared across the request flow and response flow. New variables can be dynamically added or deleted to the context. Predefined context variables contain information about the message, transport headers, security principles, metadata for the current proxy service, and metadata for the primary routing and publishing services invoked by the proxy service.

The context can be read and modified by XQuery expressions and updated by transformation and in-place update actions. The core of the context contains the variables $header, $body, and $attachments. These wrapper variables contain the Simple Object Access Protocol (SOAP) header elements, SOAP body element, and Multipurpose Internet Mail Extensions (MIME) attachments, respectively. The context gives the impression that all messages are SOAP messages, and non-SOAP messages are mapped to this paradigm.

Since a proxy service can route messages to multiple business services, a proxy service can be configured with an interface that is independent of the business services it communicates with. Using generic proxy templates, the proxy service can be a configured as a message-flow definition that dynamically routes messages to appropriate business services based on content-based routing logic.A proxy service can also map message data into appropriate protocol formats required by the end-point business service, allowing for dynamic runtime protocol switching.

For more information on proxy templates, see Chapter 5, "Service Composition."

2.2.3 Message-Flow Definitions

The implementation of a proxy service is specified by a message flow definition. The message flow defines the flow of request and response messages through the proxy service. The following four elements are used to construct a message flow:

  • A pipeline pair, one for the request and one for the response. The pipelines consist of a sequence of stages that specify actions to perform during request or response processing.

  • A branch node to branch based on the values in designated parts of the message or message context or to branch based on the operation invoked.

  • A route node used to define the message destination. The default route node is an echo node that reflects the request as the response.

  • A start node.

Figure 2-4 Sample Message Flow

Description of Figure 2-4 follows
Description of "Figure 2-4 Sample Message Flow"

Message flow elements can be combined in arbitrary ways to form a tree structure with the start node always (and only) occurring as the root of the tree and the route nodes. The last nodes in a branch (leaf nodes) may be route nodes or echo nodes.

The request message starts at the start node and follows a path to a leaf node, executing actions in the request pipelines. If the leaf is a route node, a response is generated (could be empty if the service is a one way service). If the leaf is an echo node, the request is also considered to be the response. The response follows the inverse path in the tree skipping actions in the branch nodes, but executing actions in response pipelines.

A response is then finally sent from the top of the tree, if the interface or operation was request/response; otherwise the response is discarded. For more information on message flow definitions, see "Modeling Message Flow in Oracle Service Bus" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

A set of transformations that affects context variables can be defined before the message is sent to the selected endpoint or after the response is received. A Web services callout can be an alternative to an XQuery or XSLT transformation to set the context variable. For information on how to configure Oracle Service Bus transformation maps, see the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.

WS-Security processing as well as authorization is transparently performed at the Start node, when invoking a business service with a WS-policy. For information on how to configure Oracle Service Bus security, see "Security" in the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.

2.3 Oracle Service Bus Deployment

This section describes Oracle Service Bus deployment capabilities.

2.3.1 Deployment Topology

Oracle Service Bus is designed to centrally manage and control many distributed service endpoints. Oracle Service Bus can be deployed in the following configurations:

  • On a single server that also serves as the Admin Server.

  • On a cluster of servers.

Figure 2-5 Oracle Service Bus Deployments

Description of Figure 2-5 follows
Description of "Figure 2-5 Oracle Service Bus Deployments"

Using Oracle Service Bus you can configure autonomous ESB instances across the enterprise. These instances have their own sets of configuration artifacts such as services and transformations. Such deployments typically map to various IT departments within an organization. Communication between different departments is achieved through a federated network of ESBs, which talk to each other, often through firewalls. For more information on Oracle Service Bus deployment, see the Oracle Fusion Middleware Deployment Guide for Oracle Service Bus.

2.3.2 Distributed Configurations for Large-Scale Deployments

Oracle Service Bus enables management and coordination of many distributed service endpoints, thereby providing centralization in the enterprise. It is possible to horizontally scale heterogeneous Oracle Service Bus hubs by clustering the underlying Oracle WebLogic Server, to create a distributed Oracle Service Bus network.

A cluster consists of a set of clustered Managed Servers that perform message processing. A domain can have only one cluster with Oracle Service Bus deployed to it. This cluster can host other applications in addition to Oracle Service Bus. There is one Admin Server in every clustered domain. For more information on clustering, see "Understanding Oracle Service Bus Clusters" and "Oracle Service Bus Deployment Topology" in the Oracle Fusion Middleware Deployment Guide for Oracle Service Bus.

In this case, a central deployment of Oracle Service Bus is used for governance and coordination, and every ESB in the network communicates through the central ESB. It propagates configuration and metadata automatically to the Managed Servers for fast local retrieval, and it automatically collects monitoring metrics from all the Managed Servers for aggregation and displays them on the Oracle Service Bus Administration Console.

The following figure shows the flow of message data in a basic Oracle Service Bus cluster topology.

Figure 2-6 Clustering and High Availability

Description of Figure 2-6 follows
Description of "Figure 2-6 Clustering and High Availability"

Oracle Service Bus enables reliable and guaranteed messaging through the federated network through JMS store and forward. The dynamic routing capability also simplifies configuration of such a network. Spreading the messaging load homogeneously over the clustered servers prevents bottlenecks in the system.

2.3.3 Development, Staging, and Production Domains

Oracle Service Bus supports best practices for change management in enterprise systems by configuration of resources and services in a controlled environment. It allows export of system configurations into separate staging domains for testing and final preparation for promotion into a production domain. Java programs or scripts can be used to automate deploying an application or for moving a configuration from staging to production.

The Oracle Service Bus Administration Console has options for numerous deployment customization options. An extended list of environment variables allows settings to be preserved or tailored when moving from one environment to another. For more information, see "Finding and Replacing Environment Values" and "Creating Customization Files" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

2.3.4 Configuration Metadata Export and Import

An important part of large scale development is the ability to develop, test, stage, and deploy resources to a production system. Oracle Service Bus Administration Console enables Oracle Service Bus resource configurations to be saved as metadata and exported in JAR files to other Oracle Service Bus domains. This functionality supports an orderly promotion process of Oracle Service Bus resource configurations from staging and test environments into production and minimizes the expertise, time, and resources needed to achieve various deployment scenarios.

In addition to exporting and importing resources, it is also permitted to export and import entire projects. Using the features of existing source code control system in conjunction with the configuration JAR files, provides version and change management for Oracle Service Bus configurations.

2.3.4.1 Metadata Export

The Export feature provides the ability to export existing configurations using a JAR file, to another Oracle Service Bus domain. This capability allows system configuration to be propagated from one instance of Oracle Service Bus to another instance by exporting all, or a subset of, the resources deployed in the source Oracle Service Bus domain. There are no restrictions on what can be exported. One or more projects, or select resources from one or more projects can be exported.

The Oracle Service Bus Administration Console also allows export of a resource and all the other resources on which it depends, using the dependency tracking feature. It is necessary to be working outside a session to export configurations. Only configurations that have been activated (that is, deployed to runtime) can be exported.

There are two types of operational values: Global Operational Settings and operational values for proxy and business services. Global Operational Settings is a resource located in the System project folder and can be exported like any other resource. It is possible to preserve operational settings in the importing domain from being overwritten during import. This is achieved by specifying the Preserve Operational Values setting. If Preserve Operational Values is not specified, the values from the JAR file being imported are set in the domain.

2.3.4.2 Metadata Import

The Import feature provides the ability to import resource configurations into a session on another Oracle Service Bus domain. To use the Import feature, it is necessary to be working in the session into which the configuration JAR file is to be imported. Many configuration updates and import of multiple JAR files is permitted in a single session. It is also possible to import only a subset of the exported data.

Oracle Service Bus provides the ability to reconfigure environment-specific elements as necessary to meet the requirements of the importing domain, using the Change Center in the Oracle Service Bus Administration Console. Using this customization feature, imported resources can be tailored for the new domain before activating them.

It supports the global change of environment-specific attributes for resources, using the import functionality along with the find and replace feature. This facilitates changing of many similar environment values in a convenient way. It is not meant to replace a more careful tuning of configuration that may be required by complex deployment scenarios. For more information, see the Oracle Fusion Middleware Deployment Guide for Oracle Service Bus.

For information on how to export and import configuration metadata using the Oracle Service Bus Administration Console, see "Customization" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus. For information on how to modify configurations for new environments using the Oracle Service Bus Administration Console Change Center, see "Using the Change Center" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

2.3.5 Scripting Support

Though all Oracle Service Bus configuration and deployment can be performed using the Oracle Service Bus Administration Console, the Oracle WebLogic Server Scripting Tool (WLST) can be used to automate deployment tasks. For information about WLST, see "WLST Command and Variable Reference" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

2.3.6 Related Topics