2 Oracle Service Bus Architecture

This section 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). It includes the following sections:

• Section 2.1, "Architecture Overview"

• Section 2.2, "Key Architecture Concepts"

• Section 2.3, "Oracle Service Bus Core Features"

• Section 2.4, "Oracle Service Bus Deployment"

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 Oracle Service Bus Service Interactions"

The following high-level architecture diagram illustrates Oracle Service Bus and its functional subsystems: service management, message brokering, configuration framework, security and transport layer, and messaging protocols.

Figure 2-2 Oracle Service Bus High-Level Architecture

Description of "Figure 2-2 Oracle Service Bus High-Level Architecture"

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-3 Binding and Transport Layers in Oracle Service Bus

Description of "Figure 2-3 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-4 Oracle Service Bus Message Processing

Description of "Figure 2-4 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 E-mail. 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, etc.

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 E-mail. It is not involved in data processing but handles meta-data for messages, including endpoint URIs, transport headers, etc.

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 Console allows configuration of a proxy service by defining its interface in terms of Web Services Description Languages (WSDLs) 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 run-time 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-5 Sample Message Flow

Description of "Figure 2-5 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 Core Features

By fusing the concepts of the ESB, message brokering, and operational services management into a single product, Oracle Service Bus allows management and integration of messages and services across a services network. Its core functional features are separated into the following categories:

• Service Integration - features used for integrating disparate service end-points, message brokering, and mediating and exposing services for reuse

• Service Security - features used for service authentication and authorization, message security enforcement, and user identity validation

• Service Composition - features used for configuring message routing logic, message transformation, service configuration, validation and registry

• Service Management - features used for monitoring and managing service activity and availability

2.3.1 Service Integration

This section describes service integration features of Oracle Service Bus.

2.3.1.1 Communication Types

To support heterogeneous environments, Oracle Service Bus accommodates multiple messaging paradigms. It supports the following types of communication:

• Synchronous request/response

• Asynchronous publish one-one

• Asynchronous publish one-many

• Asynchronous request/response (synchronous-to-asynchronous bridging)

2.3.1.2 Message Brokering

A high performance message broker is a core component of Oracle Service Bus. It enables content-based routing of messages and data transformation. Oracle Service Bus message brokering capabilities are implemented with the following operational features:

• XQuery-based policies or callouts to external services for message routing

• Routing policies that apply to both point-to-point and one-to-many routing scenarios (publish). For publish, routing policies serve as subscription filters

• Routing table abstracted from proxy services, that enables modification of routes without having to re-configure proxy service definitions

• Identity-based routing, to classify clients into user-defined groups and apply routing policies based on these groups

2.3.1.3 Conditional Routing

All routing logic pertaining to communications with a service end point is handled via the configured proxies. This frees service consumers from having to understand any of the complexities of communicating with back-end services. Decoupling the routing, transformation, security, and transport details from the service consumers and providers and placing them within configurable proxy services, provides for more flexible service integration.

Oracle Service Bus supports dynamic content-based routing of messages and run-time protocol selection. It facilitates these capabilities by allowing the configuration of proxy services with interfaces that are independent of the end-point business services. Using generic proxy templates, proxy services can be configured as message-flow definitions with routing logic that dynamically route messages to appropriate business services, based on message content.

2.3.1.4 Message Transformation

Oracle Service Bus supports the following capabilities for the transformation or processing of messages:

• Validates incoming messages against schemas

• Selects a target service or services, based on the message content or message headers

• Transforms messages based on the target service

• Transforms messages based on XQuery or XSLT

• Supports transformations on both XML and MFL messages

• Message enrichment

• Supports callouts to Web services to gather additional data for transformation (for example, country code, full customer records, and so on)

2.3.1.5 Service Callouts

Oracle Service Bus provides a service callout action that offers greater flexibility for more sophisticated message flows for complex dynamic-routing processing, or to perform message enrichment. The service callout action is used inside a message flow routing stage, to call on the destination service to perform some action on the message. The Service Callout functionality supports features such as RPC Encoding and URL replacement and offers extensibility of Oracle Service Bus capabilities by using Java Callouts and POJOs. For more information on service callouts, see "Constructing Service Callout Messages" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

2.3.1.6 Database Lookup from Proxy Services

Oracle Service Bus provides a database lookup function using a new XQuery function in the Oracle XQuery engine. This can be used for message enrichment, for routing decisions or for customizing the behavior of a proxy service. Read-access to databases from proxy services is supported without requiring writing of a custom EJB or custom Java code and without the need for a separate database product like Oracle Data Service Integrator.

It is implemented using the execute-sql() function to make a JDBC call to a database to perform simple database reads. For more information, see "Accessing Databases using XQuery" in "Modeling Message Flow in Oracle Service Bus" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

2.3.1.7 Native Transport for Oracle Data Service Integrator

Oracle Service Bus provides optimized transport for 1-way or 2-way communication for invoking services on Oracle Data Service Integrator data using a native transport (DSP). This allows a more efficient and flexible approach to accessing data services than exposing them as Web services via Eclipse and Java Web Services (JWS), and it supports security and identity propagation.

2.3.1.8 Data Transformation Tools

Two data transformation tools are installed with Oracle Service Bus and Eclipse—the Oracle XQuery Mapper plug-in for Eclipse and Format Builder. Eclipse and Format Builder are supported on Windows platforms only.

2.3.1.9 Interoperability

For information about Oracle Service Bus interoperability, including information about support for compliance with messaging standards including SOAP, HTTP, JMS, SMTP/POP/IMAP, FTP, SSL, XML, XML Schema, WSDL, WSRP, and WS-Security, see "Oracle Fusion Middleware Supported System Configurations" at http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html.

2.3.1.10 EJB and JEJB Transports

You can design business or proxy services in Oracle Service Bus to use the EJB or JEJB transport. Both transports are fully integrated into the Oracle Service Bus configuration, management, monitoring, and test consoles. Business services built with the EJB transport can be used for Publish, Service Callout, and service invocations.

An EJB can be exposed as a Web service, without the need for tools or the modification of the legacy code on the application server that hosts the EJB.

The JEJB transport also lets you invoke services through Oracle Service Bus with plain old Java objects (POJOs)

2.3.2 Service Security

Oracle Service Bus supports open industry standards for ensuring the integrity and privacy of communications and to ensure that only authorized users can access resources in an Oracle Service Bus domain. It uses the underlying WebLogic security framework as building blocks for its security services. The WebLogic security framework divides the work of securing a domain into several components (providers), such as authentication, authorization, credential mapping, and auditing.

2.3.2.1 Message Security Features

Oracle Service Bus provides the following security features:

• Authentication, encryption and decryption, and digital signatures as defined in the Web Services Security (WS-Security) specification

• Uses SSL to support traditional transport-level security for HTTP and JMS transport protocols

• One-way and two-way certificate based authentication

• HTTP basic authentication

• Encrypt and export of resources (such as service accounts, service key providers, UDDI registries, SMTP providers, and JNDI providers) that contain username and passwords

• Create service accounts and service key providers within a session, and add the user name, password, and credential alias binding within the same session.

• Configure a service account to pass through user ID and password credentials or map the user to a new user ID and password supplied to a business service

• Client-specified custom authentication credentials for both transport- and message-level inbound requests

The Oracle Service Bus security model includes the following:

• Inbound Security

• Outbound Security

• Options for Identity Propagation

• Administrative Security

• Configuring the WebLogic Security Framework

• Supported Standards and Security Providers

For more information on the above features of Oracle Service Bus security model, see Section 3.3, "Oracle Service Bus Security."

2.3.3 Service Composition

This section describes service composition features of Oracle Service Bus.

2.3.3.1 Change Center

Oracle Service Bus Console Change Center is key to making configuration changes inside the service bus. The Change Center has the unique ability to lock its current configuration while changes are being made, letting the service bus continue to receive and process requests for services while configuration changes are being made in the console.

Changes being made to the configuration do not affect the current system configuration until they are "activated". The service bus uses the new service and resource configuration when changes are activated. This way, ongoing changes can be made without disrupting services.

For more information on Change Center, see "Using the Change Center" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

2.3.3.2 Test Console

Oracle Service Bus built-in test console is a browser-based test environment used to validate resources and inline XQuery expressions used in the message flow. It is an extension of the Oracle Service Bus Console. Using the test console, it is possible to configure the test object (proxy service, business service, XQuery, XSLT, MFL resource), execute the test, and view test results. It allows message flow tracing when testing a service, to examine the state of the message at specific trace points.

Design time testing helps isolate design problems before deploying a configuration to a production environment. The test console can test specific parts of a system in isolation and it can test a system as a unit. The test console can be invoked in a number of ways in the Oracle Service Bus Console, from:

• The Project Explorer

• The Resource Browser

• The XQuery Editor

For more information, see "Using the Test Console" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

2.3.3.3 Resource Management

Oracle Service Bus provides the following resource management capabilities:

• Stores information about services, schemas, transformations, WSDLs (Web Service Definition Language), and WS Policies

• Provides centralized management and distributed access to resources and services

• Allows browsing of services registered in Oracle Service Bus and import of resources from Eclipse or other applications

• Allows the propagation of configuration data from environment to environment (for example, from a development domain to a test domain to a production domain). The system allows environment specific settings to be overridden during import.

• Allows for better synchronization and notification capabilities.

2.3.3.4 Resource Customization

Oracle Service Bus provides a number of APIs for customization of service definitions, WSDLs, schemas, XQueries and other design-time resources through programmatic interfaces. The supporting APIs allow loading ZIP files containing resources, in addition to moving, renaming, cloning, or deleting resources, folders and projects. For more information, see "Oracle Service Bus APIs" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

2.3.3.5 UDDI Service Registry

Proxy services developed in Oracle Service Bus can be published to a UDDI registry. Oracle Service Bus can interact with any UDDI 3.0 compliant registry including Oracle Service Registry.

Service definitions in Oracle Service Bus can be synchronized (both ways) with those in UDDI. Services can be auto-published to UDDI after they are created or changed within Oracle Service Bus and business service definitions can be imported from UDDI.

Business services in Oracle Service Bus are also automatically updated (with no human intervention) when the original service is changed in UDDI. Alternatively, the Oracle Service Bus Console can be configured to prompt users for approval for synchronization when a service changes in the UDDI registry. For more information about UDDI registries, see "UDDI" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus and the Oracle Service Registry documentation.

2.3.3.6 Error Handling

Oracle Service Bus supports the following error handling capabilities:

• Configure system to format and send error messages, and return messages for consumers of services who expect a synchronous response

• Configure error handling logic for pipeline stages, entire pipeline, and for proxy services

• Generate alerts based on message context in a pipeline, to send to an alert destination.

2.3.4 Service Management

This section describes service management features of Oracle Service Bus.

2.3.4.1 Service Logging and Monitoring

Oracle Service Bus allows the following capabilities for auditing and monitoring services:

• Gather statistics about message invocations, errors, performance characteristics, messages passed and SLA violations

• Send SLA-based alerts as SNMP traps, enabling integration with third-party ESM solutions

• Support for logging selected parts of messages for both systems operations and business auditing purposes

• Search capabilities by extracting key information from a message and use as it as a search index.

The Oracle Service Bus Console provides a cluster-wide view of service status and statistics. Both business services and Oracle Service Bus proxy services are monitored, as are response times, message counts, and error counts.

JMX Monitoring API provided as a polling interface for the retrieval of metrics. This API enables integration with management partners and enables customers who have their own monitoring consoles to display metrics that can be used for performance analysis.

2.3.4.2 Custom Operations Console

The Oracle Service Bus Console supports tasks performed by users in the operator (IntegrationOperator) role. It provides operational functions and settings that allow users to easily search for resources using the new SMart Search functionality, monitor SLA alerts, pipeline alerts, logs, reports, turn tracing on and off, and to enable and disable services.

Users can readily distinguish between SLA and pipeline alerts since the metrics reported for each are distinguished on the console and via the JMX monitoring APIs. Service-level flags and global flags help control alerting (SLA & pipeline), reporting, and logging. Operators have privileges to edit operational settings, create new SLA alert rules, and create and edit alert destination resources.

For more information on console operational tasks, see the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

2.3.4.3 Service Versioning

Oracle Service Bus provides the ability to deploy new versions of services and allows you to have multiple versions of message resources such as WSDLs and schemas. Versions can include changes to the WSDL, the message schema, the headers, and the security parameters.

2.3.4.4 Service Level Agreements

In Oracle Service Bus, monitoring statistics are gathered locally and aggregated centrally. SLA rules are run against aggregated data and the system raises alerts, following which services can be enabled or disabled. Administrators can set service level agreements (SLAs) on the following attributes of proxy services:

• Average processing time of a service

• Processing volume

• Number of errors, security violations, and schema validation errors

• Administrators can configure alerts for SLA rule violations

2.4 Oracle Service Bus Deployment

This section describes Oracle Service Bus deployment capabilities.

2.4.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 administration server.

• On a cluster of servers.

Figure 2-6 Oracle Service Bus Deployments

Description of "Figure 2-6 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.4.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 administration server in every clustered domain. For more information on clustering, see "Understanding Oracle Service Bus Clusters" in 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 Console.

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

Figure 2-7 Clustering and High Availability

Description of "Figure 2-7 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.4.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 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.4.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 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.4.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 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 run time) 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.4.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 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 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 Console Change Center, see "Using the Change Center" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

2.4.5 Scripting Support

Though all Oracle Service Bus configuration and deployment can be performed using the Oracle Service Bus 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.4.6 Related Topics

• "Modeling Message Flows in Oracle Service Bus" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus

• "Oracle Service Bus APIs" in Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus

• Oracle Fusion Middleware Deployment Guide for Oracle Service Bus