1 Learning About Oracle Service Bus

This chapter provides an overview of Service Bus, its architecture and components, and how to use Service Bus to develop services. It also provides roadmaps for developing Service Bus applications and descriptions of different development approaches.

This chapter includes the following topics:

1.1 Oracle Service Bus Overview

Oracle Service Bus is a configuration-based, policy-driven enterprise service bus designed for SOA life cycle management. It provides foundation capabilities for service discovery and intermediation, rapid service provisioning and deployment, and governance.

Service Bus provides scalable and reliable service-oriented integration, service management, and traditional message brokering across heterogeneous environments. It combines intelligent message brokering with routing and transformation of messages, along with service monitoring and administration. Service Bus leverages industry standards to connect services and support a high level of heterogeneity, connecting your existing middleware, applications, and data sources, and protecting existing investments.

Service Bus adheres to the SOA principles of building coarse-grained, loosely coupled, and standards-based services. These services create a neutral container in which business functions can connect service consumers and back-end business services, regardless of the underlying infrastructure. The following figure illustrates the role of Service Bus as a service intermediary in an enterprise IT SOA landscape.

Figure 1-1 Service Bus Intermediary

Description of Figure 1-1 follows
Description of "Figure 1-1 Service Bus Intermediary"

1.1.1 Functional Areas

The following diagram illustrates the primary functional areas of Service Bus, including virtualization, messaging, security, configuration, and runtime management.

Figure 1-2 Service Bus Functional Features

Description of Figure 1-2 follows
Description of "Figure 1-2 Service Bus Functional Features"

1.1.2 Adaptive Messaging

Adaptive messaging provides flexible message handling and manipulation between clients and services. For example, a client sends a SOAP message over HTTP through Service Bus, which in turn transforms the message and invokes a back-end EJB. Or a client sends a REST/JSON message over HTTP, and Service Bus transforms the message and invokes a back-end SOAP/XML service (or uses any of the available adapters). Adaptive messaging also supports a variety of communication patterns such as request/response, synchronous and asynchronous, split-join, and publish/subscribe. It supports different patterns for inbound and outbound messages in a single message life cycle.

1.1.3 Service Security

Service Bus ensures service security at all levels, based on Oracle Platform Security Services and Oracle Web Services Manager (OWSM) for web services. You can plug in custom or third-party security components. Built-in capabilities allow flexibility in implementation by enabling security at the following levels:

  • Transport-level security, including SSL, basic authorization, and custom security credentials

  • Message-level security, including WS-Security, SAML, user ID and password, X509, signing and encryption, and custom security credentials

  • Console security, including single-sign-on and role-based access

  • Policy security

1.1.4 Service Virtualization

Service virtualization provides agility through message manipulation and control. Service Bus lets you flexibly control messages using validation, transformation, routing based on message content, parallel processing of multiple items in a message, alert triggering, and error handling at different points in a message flow. For example, Service Bus provides the following capabilities:

  • 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 pipelines, which enables modification of routes without having to reconfigure pipelines.

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

  • Conditional routing, including dynamic content-based routing of messages and runtime protocol selection.

  • Database lookups, which can be used for message enrichment, routing decisions, or customizing the behavior of a pipeline.

  • Transformations using XQuery or XSLT maps.

1.1.5 Configuration Framework

The Configuration Framework gives you full control over your Service Bus production environment and its associated resources.The framework includes session management, the Test Console, and import/export tools. Service Bus configurations are managed in sessions, which provide the unique ability to lock the current configuration while changes are being made. Service Bus can continue to receive and process requests for services while configuration changes are being made in a session. These changes do not affect the runtime configuration until you activate the current session. This way, ongoing changes can be made without disrupting services. Configuration and resource changes you make are tracked, and you can undo or redo changes, resolve conflicts, maintain dependencies among resources, and test changes in the Test Console.

The built-in Test Console is a browser-based test environment used to validate resources as well as inline expressions used in pipelines or split-joins. Use the Test Console to configure the test object (such as a pipeline, business service, or XQuery expression), 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.

Service Bus allows the propagation of configuration data from environment to environment by exporting and importing resources and projects. For example, you can transfer configurations from a development domain to a test domain to a production domain. The import and export features let you maintain resource dependencies and preserve environment values between environments.

The Configuration Framework also includes a metadata-driven interface for service discovery, publishing, and synchronization using UDDI registries, including automatic import and synchronization of services with UDDI.

1.1.6 Service Management

Service management includes a powerful set of runtime configuration tools for monitoring, alerting, and reporting. Service Bus is fully integrated with Fusion Middleware Control for SOA-wide service management. Service management lets you do the following:

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

  • Send SLA and pipeline alerts as SNMP traps, enabling integration with third-party enterprise system management solutions.

  • Log selected parts of messages for both systems operations and business auditing purposes.

  • Search message reports by extracting key information from a message, which can then be used as a search index.

  • Integrate with widely adopted third-party reporting tools as well as custom enterprise system management frameworks.

  • Support open interfaces for operational and deployment customization, JMX monitoring interfaces, and SNMP Alerts.

1.2 Service Bus Architectural Concepts

Service Bus is an intermediary that processes incoming service request messages, determines routing logic, and transforms those messages for compatibility with other service consumers.

It receives messages through a transport protocol such as HTTP(S), JMS, File, or FTP, and sends messages through the same or a different transport protocol. Service response messages follow the inverse path. Message processing by Service Bus is driven by metadata, specified in the message flow definition (pipeline).

Service Bus provides message delivery services based on standards including SOAP, HTTP, and Java Messaging Service (JMS). It supports XML as a native data type, while also offering alternatives for handling other data types. Service Bus lets you establish loose coupling between service clients and business services, while maintaining a centralized point of security control and monitoring. It stores persistent policy, service, and related resource configurations in metadata, which can be customized and propagated from development through staging to production environments. The message-brokering engine accesses this configuration information from its metadata cache.

1.2.1 Message Processing

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

The processing of messages through Service Bus occurs in the following sequence of events:

  1. A client sends a message to Service Bus using a specific transport protocol.

  2. A transport provider processes the inbound message, handling communication with the service client endpoint and acting as the entry point for messages into Service Bus.

  3. The binding layer packs and unpacks messages, handles message security, and hands messages off to the pipeline.

  4. The pipeline performs any transformation, validation, logging, and reporting, and then routes the message to an endpoint (either a business service or another proxy service).

  5. Service Bus processes the response message in a similar manner as the above steps.

The following figure illustrates the flow of data through Service Bus, from inbound endpoint (proxy service) to outbound endpoint (in this case, a business service). The transports listed are a subset of those available through Service Bus.

Figure 1-3 Oracle Service Bus Message Processing

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

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

1.2.2 Proxy Service Role in Message Processing

Proxy services are the interfaces that service consumers use to connect with managed back-end services. Proxy services are definitions of intermediary web services that Service Bus implements locally. The proxy service interface is defined in terms of Web Services Description Language (WSDL) or Web Application Definition Language (WADL) and the type of transport it uses.

1.2.3 Transport Layer (Inbound)

The inbound transport layer is the communication layer between client services (or service consumers) and Service Bus. It is responsible for handling communication with the service client endpoint and acts as the entry point for messages into Service Bus. The inbound transport layer primarily deals with raw bytes of message data in the form of input/output streams. The transport layer provides support for compatible transport protocols, including HTTP(S), JMS, FTP, File, email, and others. It is not involved in data processing but is responsible for returning response messages to service consumers and handles metadata for messages, including endpoint URIs, transport headers, and so on.

1.2.4 Binding Layer

The binding layer for both inbound and outbound performs the following functions in message processing:

  • Packs and unpacks messages as necessary

  • Handles security for messages

  • Hands messages off to start the pipeline (request and response)

1.2.5 Pipeline Role in Message Processing

A pipeline defines the flow of request and response messages through Service Bus, including routing, transformations, validations, publishing, reporting and exception management. It accepts messages from the binding layer of the proxy service, performs any transformations or validations, and then forwards the message to the binding layer of the outbound service, either a proxy or business service. Along the way, the pipeline can make callouts to other services, Java objects, or POJOs.

1.2.6 Transport Layer (Outbound)

The outbound transport layer is responsible for the communication between external services (or service producers) and Service Bus. It is responsible for moving messages from Service Bus to the business service or proxy service and for receiving the response from the services. At the transport level, the message data are 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, email, and others. It is not involved in data processing but handles metadata for messages, including endpoint URIs, transport headers, and so on.

1.2.7 Business Service Role in Message Processing

Business services are the interfaces that connect with service producers. The business service interface is defined in terms of Web Services Description Language (WSDL) or Web Application Definition Language (WADL) and the type of transport it uses.

1.3 Service Bus Components

Service Bus routes message between external services (such as enterprise services and databases) and service clients (such as presentation applications or other business services). The service and flow components you create in a Service Bus project rely on local and system resources in Service Bus to define additional information like user names and passwords, keystore credentials, server connections, and transformations.

Service Bus resources are reusable definitions of entities that typically include metadata for those entities. Multiple services can use resources and provide standardized definitions or descriptions for use across an enterprise or department.

1.3.1 Service Components

Proxy services and business services define the endpoints in a Service Bus system. They include the binding and transport layers, and are the points at which Service Bus communicates with external services, including producers and consumers.

1.3.1.1 Proxy Services

Proxy services are Service Bus definitions of generic intermediary web services that are hosted locally on Service Bus. A proxy service communicates with external services through interfaces, which may or may not be identical to that of a service provider or service consumer business service. Through pipelines, you can route messages from a proxy service to multiple business services using their configured independent interfaces.

A proxy service's configuration includes its interface (service type), the type and configuration of the transport it uses to connect with client services, security requirements, and service level agreement (SLA) alert rules. When a proxy service interfaces with multiple business services, its associated pipeline is configured to route messages to the appropriate business service and map the message data into the format required by the business service's interface.

For more information, see Creating and Configuring Proxy Services.

1.3.1.2 Business Services

Business services are Service Bus definitions of the enterprise services that exchange messages during business processes. A business service's configuration includes its interface (service type), the type and configuration of transport it uses to connect with service producers, security requirements, message handling, performance tuning, and SLA alert rules. A business service also specifies the endpoint URI, and can specify multiple endpoints for load balancing and high availability. A business service definition is similar to that of a proxy service, but with additional options for message handling, endpoint throttling, and result caching, which help improve performance.

You can create a service account to provide authentication when connecting to a business service. It acts as an alias resource for the required user name and password pair. You can also use Oracle WebLogic Server to directly manage security credentials for a business service requiring credential-level validation.

For more information, see Creating and Configuring Business Services.

1.3.2 Message Flows

A message flow defines how messages are routed, validated, and transformed between services. The message flow is typically defined in a pipeline, but can also be defined in a split-join for parallel processing.

1.3.2.1 Pipelines

Pipelines define message routing and transformation logic, as well as message handling options. This logic includes activities such as transformation, publishing, logging, reporting, alerts, and exception management. Each of these activities are configured as individual actions within the message flow. Both JDeveloper and the Oracle Service Bus Console provide graphical modeling tools to help you model your pipelines.

The following primary elements are used to construct a pipeline:

  • A start node.

  • A pipeline pair, one for the request and one for the response. Each pipeline in a pair consists 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, to define the message destination. The default route node is an echo node that reflects the request as the response.

  • An error handler, which can be attached to any node or stage to handle potential errors at that location.

At a minimum, a start node and route node are required. While an error handler is not required, it is recommended. If an instance fails and no error handler is defined, the error is not recoverable. Pipeline 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) can be route nodes or echo nodes.

Since a pipeline can route messages to multiple business services, a pipeline can be configured with an interface that is independent of the business services it communicates with. Using generic templates, the pipeline can be a configured to dynamically route messages to appropriate business services based on content-based routing logic. A pipeline 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, see Working with Oracle Service Bus Pipelines

1.3.2.1.1 How Data Flows Through a Pipeline

In a pipeline, 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. 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 sent from the top of the tree if the interface or operation was request/response; otherwise the response is discarded.

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 variables.

1.3.2.1.2 Message Context

The context of a pipeline 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, and these variables can be shared across multiple pipelines or used locally within one pipeline. Predefined context variables contain information about the message, transport headers, security principles, metadata for the current pipeline, and metadata for the primary routing and publishing services invoked by the pipeline.

The context can be read and modified by XQuery or XSLT 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.

1.3.2.2 Split-Joins

The split-join message flow improves service performance by splitting a message payload and processing multiple operations in a message simultaneously and then combining, or joining, all results. A standard pipeline processes operations one after another.

The following primary elements are used to construct a message flow in a split-join:

  • A start node, which contains the request and response variables introspected from the WSDL operation.

  • A receive node, to receive incoming request messages.

  • A reply node, to send response messages.

  • A scope, which is a container that creates a context that influences the behavior of its enclosed elements.

  • A parallel node, which is a placeholder for a fixed number of processing branches, each with its own scope.

The available 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. The last node is always the reply.

For more information, see Improving Service Performance with Split-Join.

1.3.3 Transports, Adapters, and Bindings

Service Bus provides connectivity to external systems through a variety of transports, each of which is specific to a type of external system. Service Bus supports optimized database queries, and interoperability with web service integration technologies such as .NET, IBM MQ Series, IBM WebSphere, Apache Axis, and iWay adapters. The JCA transport expands the list of supported technologies by letting you connect to external systems using Oracle JCA technology and applications adapters. Additionally, Service Bus supports the REST binding, allowing you to connect to RESTful services using the HTTP transport.

You configure a transport's processing and connectivity information directly within a proxy or business service; you configure Oracle adapters using a configuration wizard specific to each adapter.

For more information, see Working with JCA Adapters, Transports, and Bindings

1.3.3.1 Supported Transport Protocols

Service Bus supports the following transport protocols:

  • DSP (Oracle Data Service Integrator)

  • EJB/RMI

  • Email (POP/SMTP/IMAP)

  • File

  • (S)FTP

  • HTTP(S)

  • JCA

  • JEJB

  • JMS (including MQ using JMS, and JMS/XA)

  • Local (Oracle proprietary for inter-ESB communication)

  • MQ (WebSphere MQ)

  • SB (RMI support)

  • SOA-DIRECT (Oracle SOA Suite) and BPEL

  • Tuxedo (Oracle Tuxedo)

  • WS (Web Services Reliable Messaging

Service Bus also provides the Custom Transport SDK so you can create new transports to connect with systems not covered above.

1.3.3.2 Service Types

Service Bus supports a variety of service types ranging from conventional web services (using XML or SOAP bindings in WSDL files) to non-XML (generic) services. You select and configure the service type when you create a business or proxy service. The available service types for a proxy or business service depend on the transport being used. Service Bus supports request and response as well as one-way paradigms, for both the HTTP and the JMS asynchronous transport protocols. If the underlying transport supports ordered delivery of messages, Service Bus also extends the same support.

Not all service types can be used with all transport protocols. The following table shows the service types and the transport protocols they support.

Service Type Transport Protocols

WSDL Based Service

BPEL-10g, DSP, HTTP(S), JCA, JMS, Local, SB, SOA-DIRECT, WS

JMS request and JMS response are not supported if WS-Security is enabled.

Any SOAP Service (non-WSDL)

HTTP(S), DSP, JMS, Local, SB

JMS request and JMS response are not supported if WS-Security is enabled.

Any XML Service (non-WSDL)

DSP, email, File, FTP, HTTP(S), JMS, Local, MQ, SB, SFTP, Tuxedo

HTTP GET is only supported for XML with no WSDL.

Messaging Service

email, File, FTP, HTTP(S), JMS, Local, MQ, SFTP, Tuxedo

Business services using the email, File, FTP, or SFTP transport support one-way messaging services only; the response message type should be none.

Native REST Service

HTTP(S), Local

The BPEL-10g, DSP, EJB, and SOA-DIRECT transports are only supported with business services.

1.3.4 Transformation Resources

In addition to creating inline XQuery expressions directly in message flow actions, you can reference transformation maps that define more complex mappings between source and destination services. When disparate message data types exist between source and destination services, data mapping ensures service compatibility. Service Bus supports data mapping using XQuery and eXtensible Stylesheet Language Transformation (XSLT) standards, along with XPath expressions. You can also use cross reference tables and domain value maps to map field values between services.

Messages can be transformed in the following ways:

  • Using XQuery or XSLT to reformat the message structure.

  • Manipulating message content by adding, removing, or replacing certain data elements.

  • Using cross reference or domain value map tables to map entities across systems.

1.3.4.1 XQuery Mappings

The XQuery Mapper in JDeveloper is a graphical tool that lets you define mappings that transform data between XML, non-XML, and Java data types so you can rapidly integrate heterogeneous applications. For example, XML data that is valid against one schema can be converted to XML that is valid against a different schema. The data can be based on XML schemas, Web Service Definition Language (WSDL) files, and Message Format Language (MFL) files. You can create an XQuery mapping in JDeveloper, and then upload the .xqy file generated by the mapper to an XQuery resource in the Oracle Service Bus Console. XQuery mappings are stored in XQuery resources in Service Bus, which can be referenced from the expressions you create using the expression editors in a message flow action.

The output of the XQuery Mapper is a query in the XQuery language, which is defined by the World Wide Web Consortium (W3C). For more information about W3C and the XQuery language, see http://www.w3.org/XML/Query/.

For more information, see Transforming Data with XQuery and "Creating Transformations with the XQuery Mapper" in Developing SOA Applications with Oracle SOA Suite.

1.3.4.2 XSLT Mappings

eXtensible Stylesheet Language Transformation (XSLT) maps describe XML-to-XML mappings. The XSLT mapper in JDeveloper is a graphical tool that lets you define mappings between schema root elements, Web Services Description Language (WSDL) message parts, or WSDL messages. Schema root elements can come from XSD schema files or WSDL files. Only those WSDL messages that contain a single message part can be mapped directly.

The XSLT Mapper in JDeveloper lets you define transformations that apply to the whole message body to convert messages from one XML schema to another, enabling data interchange among applications that use different schemas. You can create an XSLT mapping in JDeveloper, and then upload the .xsl file generated by the mapper to an XSLT resource in the Oracle Service Bus Console. XSLT mappings are stored in XSLT resources in Service Bus, which can be referenced from the expressions you create using the expression editors in a message flow action.

For more information, see Transforming Data with XSLT and "Creating Transformations with the XSLT Mapper" in Developing SOA Applications with Oracle SOA Suite.

1.3.4.3 Cross References

Cross reference tables map identifiers that represent equivalent objects across multiple applications, associating like objects created in different external applications. They are used to manage the runtime correlation between the various applications that share data through Service Bus. For example, you can use cross references to map customer identifiers for records that were created in multiple customer management systems. Cross reference values can be updated during runtime, allowing you to dynamically integrate values between systems. Any cross reference data updated at runtime is persisted in the database. Cross references can be used across Oracle SOA Suite components. In Service Bus, you can create cross reference tables in both JDeveloper and the Oracle Service Bus Console.

Service Bus provides a set of XPath functions for looking up and modifying cross reference values. These functions are available to use in the expressions you create using the expression editors in a message flow action. For more information, see Mapping Data with Cross-References.

1.3.4.4 Domain Value Maps

A domain value map associates terms used by different domains to describe the same entity, providing the capability to map the terms across vocabularies or systems. For example, each domain might use different terminology for country codes, city codes, currency codes, and so on. You can enter these values in a map and look up those values at runtime to transform the data when passing it from one domain to another. Domain value maps are similar to cross references, but they are defined statically rather than dynamically. You create and populate domain value maps in the design time, and deploy them to the runtime. Domain value map data are not changed by runtime activities as it is for cross references, but rather the domain value maps are used for lookups only.

Domain value maps can be used across Oracle SOA Suite components. In Service Bus, you can create domain value maps in both JDeveloper and the Oracle Service Bus Console. Service Bus provides a set of XPath functions for looking up domain value map values. These functions are available to use in the expressions you create using the expression editors in a message flow action. For more information, see Mapping Data with Domain Value Maps.

1.3.5 Transport and Adapter Related Resources

Some transports rely on specific types of files, such as JavaScript and JAR files or MQ connections. The JCA transport requires the JCA file and any files it references, such as a WSDL file. This section describes the resources that are specific to certain transports.

1.3.5.1 JCA Bindings

JCA binding resources in Service Bus let you create business and proxy services that interact with external services through Oracle SOA Suite JCA adapters. A JCA binding is made up of a service WSDL document and a corresponding JCA file created in Oracle JDeveloper. In JDeveloper, you can add a JCA adapter directly to a Service Bus project using the Service Bus Overview Editor by dragging and dropping the adapter type from the Components window to the editor's canvas. The proxy or business service is automatically generated from the JCA adapter configuration, and is based on the JCA transport. In the Oracle Service Bus Console, you need to upload the JCA file into a JCA binding resource in order to create a business or proxy service based on that JCA adapter. You can also import the JCA file and its associated WSDL file using the import feature.

For more information, see Working with JCA Binding Resources.

1.3.5.2 JAR Files (Archives)

A JAR (Java Archive) is a zipped file that contains a set of Java classes. It is used to store compiled Java classes and associated metadata that can constitute a program. A JAR acts like a callable program library for Java code elements, so a single compilation link provides access to multiple elements rather than requiring bindings for each element individually.

In JDeveloper, you can add JAR files to a project or component directly from the file system, but in the Oracle Service Bus Console, you need to upload each JAR file to add to a project into an archive resource. In Service Bus, JAR files are used the following components:

  • Java callout actions (in pipelines) that provide a Java exit mechanism

  • EJB-based business services

  • JEJB-based business and proxy services

  • Tuxedo-based proxy and business services

For more information, see Working with JAR Files.

1.3.5.3 JavaScript Files

JavaScript files are used by the JCA Socket Adapter as a mechanism for handling the handshake. XSLT and custom Java code are also supported handshake mechanisms. In JDeveloper, you can create a JavaScript file and then select the file when you configure a JCA socket adapter. You can also create the JavaScript when you configure the adapter. In the Oracle Service Bus Console, you can either upload an existing JavaScript file to a JavaScript resource, or you can create the text for the JavaScript in a text editor in the console. Alternatively, you can use the console's import feature to import the Socket adapter's JCA file and its dependencies, such as WSDL and JavaScript files.

Service Bus supports JavaScript handshake for both inbound and outbound socket adapters, and for one-way and request/response messaging. Request/response handshakes require a separate JavaScript file for the request and the response.

For more information, see Working with JavaScript Resources.

1.3.5.4 MQ Connections

MQ connection resources provide the connection parameters required to connect to an MQ queue manager. They are used in proxy and business services configured to use the MQ transport, and can be shared and reused across multiple services. MQ proxy and business services must connect to an MQ queue manager before they can access an MQ queue. Each MQ connection resource uses a connection pool, and every business or proxy service that connects to a queue manager using the same MQ connection resource also uses the same connection pool. Thus, multiple business and proxy services can use the same queue manager and share a connection pool.

In order to create MQ connections in the Oracle Service Bus Console, you must install the WebSphere MQ client library to the Service Bus domain. This is described in How to Create MQ Connections.

1.3.6 Schema and Document Resources

Service Bus services rely on different document types to define information like message structures and web interfaces. These documents include XML schemas, MFL files, and XML files to describe data, and WSDL and WADL documents to describe interfaces.

Service Bus has a built-in type system that is available for use at design time. When creating an XQuery expression in a condition, in-place update action, or transformation, the variable can be declared to be of a given type in an editor to assist in easily creating the XQuery. The types can be the following:

  • XML schema types or elements

  • WSDL types or elements

  • MFL types

1.3.6.1 XML Schemas

XML schemas are documents that define valid content for primitive or structured data in XML documents. XML schemas specify the structure of documents, the data type of each element and attribute contained in the document, and the rules that XML business data must follow. XML schemas can import or include other XML schemas. Schemas are used to add XML information to messages exchanged in Service Bus, and may be required for XQuery expressions, WSDL files, and so on.

For more information, see Working with XML Schemas.

1.3.6.2 XML Documents

XML document resources store XML files that can then be referenced when configuring proxy or business services. For example, you might use XML documents for TopLink mapping files needed in JCA proxy or business services that communicate with JCA-compliant systems.

XML documents are a standard feature in JDeveloper. In the Oracle Service Bus Console, the easiest way to create XML documents is to use the import feature. For example, if you import JCA resources (JCA file, along with its associated WSDL and mapping files), Service Bus automatically generates XML document resources out of mapping files and maintains the dependencies among resource files. You can also create an XML document resource, and upload the contents of an XML file to the resource.

For more information, see Working with XML Documents.

1.3.6.3 WSDL Documents

A Web Service Definition Language (WSDL) interface defines a service interface for a SOAP or XML service. For web services, a WSDL document describes what the web service's interface is, where it resides, and how to invoke it. Service Bus defines proxy and business services in terms of two WSDL entities:

  • The abstract WSDL interface, which defines the operations in that interface and the types of message parts in the operation signature.

  • The binding WSDL interface, which defines the binding of the message parts to the message (packaging), and the binding of the message to the transport.

A WSDL file can also describe the concrete interface of the service (for example, the transport URL).

You can base the definition of a proxy or business service on an existing WSDL file, which automatically configures portions of the service. WSDL files used as the basis for defining services are stored as Service Bus resources. In JDeveloper, you can create WSDL files using the built-in WSDL editor. You can then import those WSDL files, and any schemas used by the file, into the Oracle Service Bus Console. The console can also be used to resolve the references in the WSDL files, ensuring all schemas and WSDL files are linked correctly. Service Bus uses its own representation of the interface for messaging services.

For more information, see Working with WSDL Documents.

1.3.6.4 WADL Documents

A Web Application Definition Language (WADL) document is similar to a WSDL document, described above, but it is specifically used to described the interface for REST proxy or business services. When you create a proxy or business service based on the REST binding in JDeveloper, the required WADL document is automatically generated from the WSDL document you specify for the binding. A WADL file can have dependencies on a WSDL file and on one or more XML schemas.

If you are using the Oracle Service Bus Console, you can create WADL documents by importing them or by creating a WADL resource. For more information, see Creating WADL Documents.

1.3.6.5 MFL Resources

Service Bus uses Message Format Language (MFL) to describe the structure of typed non-XML data. MFL is an Oracle proprietary language used to define the rules that transform formatted binary data into XML data. MFL documents are used at runtime to transform an instance of a non-XML data record to an instance of an XML document (or the other way around).

You create MFL documents using the Format Builder tool in JDeveloper. The Format Builder allows you to describe the layout and hierarchy of the non-XML data so it can be transformed to or from XML. Using the Format Builder, you define each field in the message, including the type and size of data, the name of the field, any delimiters, and so on. You can also indicate whether the field is repeating, and whether it is optional or required.

For more information, see Defining Data Structures with Message Format Language.

1.3.7 Security Resources

Security information can be passed through proxy and business services using service accounts, which define how the user name and password are obtained, or using service key providers, which define encryption credentials.

1.3.7.1 Service Key Providers

Service Key Provider resources contain Public Key Infrastructure (PKI) credentials used by proxy services for decrypting inbound SOAP messages and for outbound authentication and digital signatures. PKI credentials are private keys paired with certificates that can be used for digital signatures and encryption (for Web Services Security) and for outbound SSL authentication. The certificate contains the public key that corresponds to the private key.

Service Bus uses service key providers to supply the following types of credential-level validation to proxy services.

  • SSL client authentication

  • Digital signature

  • Encryption

  • Web Services Security X509 token

For more information, see Working with Service Key Providers.

1.3.7.2 Service Accounts

Service account resources provide user names and passwords that Service Bus uses for authentication when connecting to a service or server. Service accounts are used by proxy and business services for outbound authentication or for authentication to a local or remote resource, such as an FTP server or a JMS server. You can configure a service account to use a specific user name and password pair, to use the user names and passwords received from incoming requests, or to map user names and passwords provided by clients to user names and passwords you specify. One service account can be used for multiple business and proxy services.

For more information, see Working with Service Accounts.

1.3.7.3 WS-Policy Resources

In previous versions, WS-Policy resources were used to store custom web service policies so they could be referenced by multiple WSDL documents. Beginning in 12c, Oracle Web Services Manager (OWSM) policies replace WLS9 policies, so there is no longer an option to create new services with WSDL-based WLS9 policies. While WS-Policy resources are still visible in imported projects, the associated web services should be updated to use OWSM policies. However, you can still import and activate a project from a previous version that uses WS-Policy resources.

1.3.8 Alert Destinations

An alert destination resource defines a list of recipients that can receive alert notifications from Service Bus. For example, when a service level agreement (SLA) or pipeline alert is generated, you can specify that notifications be sent to specific email addresses or JMS queues, ensuring that only the relevant people receive the notifications. An alert destination could include one or more of the following types of destinations: the Service Bus reporting data stream, SNMP trap, alert log, email, JMS queue, or JMS topic. In the case of email and JMS destinations, a destination resource could include a list of email addresses or JMS URIs, respectively.

For more information, see Working with Alert Destinations.

1.3.9 Throttling Group Resources

Throttling helps improve performance and stability by preventing message overload on high-traffic business services. To control the flow of messages to a business service and prevent backlogs, you can enable and configure message throttling for a business service or group of business services in your Service Bus applications. When messages are throttled, the business service can only concurrently process the number of messages you specify. When that capacity is reached, messages are stored in an in-memory queue until the business service is ready to process more messages.

For more information, see "Configuring Business Services for Message Throttling" in Administering Oracle Service Bus.

1.3.10 System Resources

System resources are globally available resources that can be shared across all projects in your Service Bus instance. They define server connections and authentication information, and include the following:

In the Oracle Service Bus Console, system resources are stored in a separate project named System. In JDeveloper, system resources are stored in the Application Resources panel under Service Bus System Resources.

1.3.10.1 JNDI Providers

JNDI provider resources define the connection and authentication information needed to access JNDI-named objects. They describe the URL (or list of URLs in the case of clustered deployments) of the JNDI providers used by Service Bus. For example, in a business service used to invoke an EJB, you include the name of a JNDI provider resource in the endpoint URI. When the business service is invoked, Service Bus uses the details in the referenced JNDI provider resource to make the initial connection to the JNDI provider.

If the JNDI provider is secured, then the JNDI provider resource also defines a user name and password to gain access. JNDI providers offer a great deal of flexibility. If a JNDI connection changes, you only need to modify the JNDI provider resource, and anything that references the JNDI provider automatically uses the updated configuration.

For more information, see Working with JNDI Provider Resources.

1.3.10.2 SMTP Servers

SMTP server resources define the address of SMTP servers corresponding to email destinations, port numbers, and, if required, authentication credentials. They describe the URL for the SMTP servers used by Service Bus. If the SMTP server is secured, the SMTP server resource description also includes a user name and password to gain access. SMTP server resources are referenced when configuring alert destination resources and email transport-based business services.

For more information, see Working with SMTP Server Resources.

1.3.10.3 Proxy Servers

Proxy server resources define the connection and authentication information needed to access JNDI-named objects. They describe the URL for the proxy servers used by Service Bus. If the proxy server is secured, the proxy server resource description also includes a user name and password to gain access. You can use a proxy server to proxy requests from a client application, and you typically use a proxy server when Service Bus is behind a firewall. When you configure business services to route messages through a proxy server, associate the proxy server resource with that business service. This instructs Service Bus to connect to the business service through the configured proxy server.

You can configure multiple proxy servers for each proxy server resource. In this case, Service Bus can perform load balancing and offer fault tolerance among the configured proxy servers.

For more information, see Working with Proxy Server Resources.

1.3.10.4 UDDI Registries

Universal Description, Discovery and Integration (UDDI) registries are used to share web services. UDDI provides a framework in which to classify your business, its services, and the technical details about the services you want to expose. A UDDI registry resource stores information about a UDDI registry accessed by Service Bus for service discovery, publishing, and synchronization. After the UDDI registry resource is configured, you can publish Service Bus proxy services to the associated registry, or import business services from the registry to be used by a proxy service. UDDI registry resources define the inquiry, publish, security, and subscription URLs, along with a user name and password to gain access to the registry.

For more information, see Working with UDDI Registries.

1.4 Service Bus Messaging

This section discusses the types of messaging supported by Service Bus, the message formats, and the context variables that are passed through, and optionally modified by, the components in a Service Bus project.

1.4.1 Service Bus Messaging Models

This section discusses the types of messaging supported by Service Bus, the message formats, and the context variables that are passed through the components in a Service Bus project.

Service Bus accommodates multiple messaging paradigms and supports the following types of communication:

  • Synchronous request/response

  • Asynchronous publish one-to-one

  • Asynchronous publish one-to-many

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

In sync-async bridging, a synchronous client issues a request to an asynchronous provider. For this pattern, you can publish a message to one JMS queue. You then configure a second JMS queue for the response, with a timeout value for listening for the response. This type of service appears as a synchronous service to the service consumer. Using asynchronous request/response messages has these advantages:

  • No blocking by the request thread, removing thread management issues that can occur when numerous blocking request/response invocations are made.

  • More reliable messaging.

1.4.2 Message Formats

Service Bus supports the following message formats:

  • Email with or without attachments

  • Java

  • JMS with headers

  • MFL (Message Format Language)

  • Raw Data (opaque non-XML data with no known schema)

  • Text

  • SOAP and SOAP with attachments (SOAP described or not described by a WSDL document)

  • XML and XML with attachments (XML described or not described by a WSDL document or a schema)

1.4.3 Message Context

All messages sent to and received by a proxy service are defined internally by a set of properties that hold the message data and metadata related to that message. This set of properties is known as the message context and is implemented using context variables. The context is defined by an XML schema. Some context variables are predefined and others are user defined.

Predefined context variables contain information about the message, transport headers, security principals, metadata for the current proxy service, and metadata for the primary routing and publishing services invoked by the proxy service. You typically use an XQuery expression in a pipeline to manipulate context variables as a message moves through Service Bus. You can also modify context variables using transformation and in-place update actions.

For a complete description of the message context and context variables used in the message flow, see Message Context.

1.4.4 Content Types

To support interoperability with heterogeneous endpoints, Service Bus lets service configurations control the content type, JMS type, and encoding used. It does not make assumptions about what the external client or service needs, but instead uses the configuration of the proxy or business service. Service Bus derives the content type for outbound messages from the service type and interface and uses the following specifications:

  • For XML or SOAP (with or without a WSDL file), the content type is text/XML.

  • For messaging services when the interface is MFL or binary, the content type is binary/octet-stream.

  • For messaging services when the interface is text, the content type is text/plain.

  • For messaging services when the interface is XML, the content type is text/XML.

  • For services using the REST binding, the content types is application/xml or application/json.

The content type can be overridden in the outbound context variable ($outbound) for pipelines invoking a service, and in the inbound context variable ($inbound) for a pipeline response. Additionally, there is a JMS type (byte or text) that can be configured when the service is defined. Encoding is explicitly configured in the service definition for all outbound messages.

1.5 Using Work Managers with Service Bus

Service Bus uses Oracle WebLogic Server Work Managers to optimize performance and to maintain service-level agreements. Work Managers prioritize work and allocate threads bases on rules you define and based on runtime performance. When you create and configure a Work Manager, you define the maximum and minimum number of threads to use, server capacity, and request and response classes that express scheduling guidelines. One default Work Manager is provided, but you can create as many Work Managers as necessary to optimize your services. In Service Bus, you specify a Work Manager for a proxy service or business service in the Dispatch Policy property of the transport configuration.

For more information about Work Managers, see "Using Work Managers to Optimize Scheduled Work" in Administering Server Environments for Oracle WebLogic Server. For more information about Work Managers in Service Bus, see Using Work Managers with Service Bus.

1.6 Service Bus Security

Service Bus uses Oracle Platform Security Services (OPSS) and Oracle Web Services Manager (OWSM) as the building blocks for higher-level security services. These services include authentication, identity assertion, authorization, role mapping, auditing, and credential mapping.

Service Bus uses Oracle Platform Security Services (OPSS) and Oracle Web Services Manager (OWSM) as the building blocks for higher-level security services. These services include authentication, identity assertion, authorization, role mapping, auditing, and credential mapping. To configure Service Bus access security, you must first configure Oracle WebLogic Server security. Service Bus uses OWSM to provide a policy framework to manage and secure web services consistently across your organization.

1.6.1 Service Bus Security Features

Service Bus provides the following security features:

  • Integration with OWSM and OPSS

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

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

  • One-way and two-way certificate based authentication

  • HTTP basic authentication

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

  • Service accounts and service key providers to define the user name, password, and credential alias binding

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

1.6.2 Service Bus Service Security Model

A Service Bus service can be secured by security policies that apply to messages in its interface. A security policy can be specified for a service or for individual messages associated with the operations of a service. When a security policy is specified for a service, the policy applies to all messages sent to that service.

You can secure Service Bus services using the following types of security:

  • Inbound security

  • Outbound security

  • Options for identity propagation

  • Administrative security

  • Supported standards and security providers

Figure 1-4 illustrates security features at different points in a message life cycle.

Figure 1-4 Optimized Pluggable Security Layer

Description of Figure 1-4 follows
Description of "Figure 1-4 Optimized Pluggable Security Layer"

1.6.3 Oracle Web Services Manager

You can secure your Service Bus services by attaching Oracle Web Services Manager (OWSM) policies. OWSM is a component of Oracle Enterprise Manager Fusion Middleware Control, a runtime framework that provides centralized management and governance of Oracle SOA Suite environments and applications. It provides capabilities to build, enforce, run, and monitor web service policies, such as security, reliable messaging, MTOM, and addressing policies. OWSM can be used by developers at design time and by system administrators in production environments. OWSM allows for policy-driven centralized management of web services with local enforcement. OWSM provides a policy framework to manage and secure web services consistently across your organization.

1.6.4 Oracle Platform Security Services

Oracle Platform Security Services (OPSS) provides a standards-based, portable, integrated, enterprise-grade security framework for Java Standard Edition (Java SE) and Java Enterprise Edition (Java EE) applications. OPSS provides an abstraction layer in the form of standards-based APIs that insulate developers from security and identity management implementation details. Developers do not need to know the details of cryptographic key management or interfaces with user repositories and other identity management infrastructures.

1.6.5 WS-Policies

Through OWSM, Service Bus security supports the Web Services Policy (WS-Policy) specification, a standards-based framework for defining a web service's security constraints and requirements using policies, each of which contains one or more assertions. WS-Policy assertions specify a web service's requirements for digital signatures and encryption, along with the security algorithms and authentication mechanisms that it requires.

You can include WS-Policy policies directly in a WSDL document or include them by reference. A WSDL document can import other WSDL documents that contain or refer to WS-Policy policies. The runtime environment recognizes both abstract and concrete WS-Policy statements. Abstract WS-Policy statements do not specify security tokens. Concrete WS-Policy statements specify the security tokens for authentication, encryption, and digital signatures. The Service Bus runtime environment determines which security token types an abstract policy will accept.

For more information on WS-Policy specification, see the Web Services Policy Framework (WS-Policy) and Web Services Policy Attachment (WS-PolicyAttachment) which is available at http://specs.xmlsoap.org/ws/2004/09/policy/.

1.6.6 Types of Security

The following sections discuss the security features available in the Service Bus security model.

1.6.6.1 Inbound Security

Inbound security ensures that proxy services handle only the requests that come from authorized clients, and that no unauthorized user has viewed or modified the data sent from the client. For outward-facing proxy services, which receive requests from service consumers, strict security requirements such as two-way SSL over HTTPS are used. If a proxy service uses public key infrastructure (PKI) technology for digital signatures, encryption, or SSL authentication, you can create a service key provider to provide private keys paired with certificates.

1.6.6.2 Outbound Security

Outbound security secures communication between a proxy service and a business service. Most of the tasks involve configuring proxy services to comply with the transport-level or message-level security requirements that business services specify. If a business service requires SSL authentication or PKI technology for digital signatures, a service key provider is required, which provides private keys paired with certificates.

1.6.6.3 Identity Propagation

The options provided by Service Bus for identity propagation allow for decision making when designing security, including how to propagate the identities that clients provide. Service Bus can be configured to authenticate the credentials provided by clients, perform authorization checks, pass credentials through as is, and map credentials.

1.6.6.4 User Management and Administrative Security

Service Bus user management is based on WebLogic Server security, which supports task-level authorization based on security policies associated with roles assigned to named groups or individual users. You use Fusion Middleware Control and the Oracle WebLogic Server Administration Console to manage Service Bus users, groups, and roles.

To give users access to functions, such as creating proxy services and other resources, you assign them to one or more of the predefined security roles with predefined access privileges. The access privileges for the Service Bus administrative security roles cannot be changed but the conditions under which a user or group is in one of the roles can be changed. By default, the first user created for an Service Bus domain is WebLogic Server administrator. This user has full access to all Service Bus objects and functions, and can execute user management tasks to provide controlled access to Service Bus functions.

For more information, see "Defining Access Security for Oracle Service Bus" in Administering Oracle Service Bus.

1.6.6.5 Transport-Level Security

Service Bus supports transport-level confidentiality, message integrity, and client authentication for one-way requests or request/response transactions over HTTPS. HTTP(S) proxy services or business services can be configured to require basic authentication, client certificate (two-way SSL) authentication, custom authentication, or no client authentication at all. Transport security for transports other than HTTP is supported in Service Bus as follows:

  • For the email and FTP transports, security is provided using credentials to connect to a FTP or email server.

  • For the file transport, security is provided using a login control to the machine on which the files are located.

1.6.6.6 Message-Level Security

Service Bus supports OASIS Web Services Security (WSS) 1.0. WSS defines a framework for message confidentiality, integrity, and sender authentication for SOAP messages. Using WSS, Service Bus provides support for securing messages using digital signatures, encryption, or both. Though it is not a substitute for transport-level security, WSS is ideal for end-to-end message confidentiality and integrity. WSS is more flexible than SSL since individual parts of the SOAP envelope can be signed, encrypted or both, while other parts are neither signed nor encrypted. This is a powerful feature when combined with the ability of Service Bus to make routing decisions and perform transformations on the data based on the message content. Service Bus supports WSS over HTTP(S) and JMS.

For more information on the WSS specification, see the OASIS Web Services Security TC which is available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss.

1.6.7 Custom Security Credentials

Service Bus supports client-specified custom authentication credentials for both transport-level and message-level inbound requests. The custom authentication credentials can be in the form of tokens, or a user name and password token combination. Service Bus accepts and attempts to authenticate the following:

  • A custom token passed to a proxy service in an HTTP header, SOAP header (for SOAP-based proxy services) or in the payload (for non-SOAP proxy services).

  • A user name and password token passed in a SOAP header (for SOAP based proxy services), or in the payload for non-SOAP proxy services.

For outbound requests, custom authentication is supported at the transport-level based on a custom authenticator Java class you create. The custom authentication mechanisms work alone or in concert with the message-level security for web services. For more information on custom security credentials, see Configuring Custom Authentication..

1.7 Approaches for Designing Service Bus Services

When creating Service Bus services, you have a choice of approaches, depending on whether you use the Oracle Service Bus Console or JDeveloper. JDeveloper supports both approaches; the console supports the bottom-up approach.

  • Top-Down: With this approach, you analyze your processes and identify activities in support of this process. You create a Service Bus application and project, and define the Service Bus components through the Service Bus Overview Editor.

  • Bottom-Up: With this approach, you analyze existing applications and assets to identify those that can be used as services. As you create a Service Bus application, you build the services on an as-needed basis. This approach works well when IT must react to a change.

1.7.1 Service Bus Top-Down Roadmap

With this approach to developing Service Bus services, you can create all your primary components at one time using the Service Bus Overview Editor. This includes proxy and business services, pipelines, split-joins, and JCA adapters. The editor simplifies the creation and configuration of project components, and provides a graphic view of the overall structure of the data flow. Once you create and wire these components, you can define the configuration options for each, and define message routing and transformation in pipelines and split-joins.

The following table outlines the steps and provides links for further information.

Table 1-1 Service Bus Development Roadmap - Top-Down Approach

Step Description More Information

1

Create the necessary supporting resources, such as service accounts, WSDL files, or XQuery maps.

Links for each type of resource are provided in Oracle Service Bus Overview.

2

Create any proxy services, pipelines, business services, and optionally split-joins.

Adding Service Bus Components

3

Wire the components together.

Wiring Service Bus Components

4

Configure the proxy services and their transports.

Configuring Proxy Services

Working with JCA Adapters, Transports, and Bindings

5

Configure the pipelines and split-joins.

Working with Oracle Service Bus Pipelines

Improving Service Performance with Split-Join

6

Configure the business services and their transports.

Configuring Business Services

Working with JCA Adapters, Transports, and Bindings

7

Configure security for the business and proxy services.

Securing Business and Proxy Services

8

Test and debug the services and resources.

Debugging Oracle Service Bus Applications

Using the Test Console

9

Deploy the service.

Deploying Oracle Service Bus Services

10

Monitor and administer the runtime.

Oracle Service Bus Runtime Monitoring

1.7.2 Service Bus Bottom-Up Roadmap

With this approach to developing Service Bus services, you create and configure each project component individually. The flow of messages through the system is defined by references you create between project components, such as proxy services, business services, pipelines, split-joins. This approach does not use the Service Bus Overview Editor, so you are not working with a graphical representation of the components. However, if you are working in JDeveloper, the components you create are added to the overview file and appear in the Service Bus Overview Editor.

The following table outlines the steps and provides links for further information.

Table 1-2 Service Bus Development Roadmap - Bottom-Up Approach

Step Description More Information

1

Create the necessary supporting resources, such as service accounts, WSDL files, or XQuery maps.

Links for each type of resource are provided in Oracle Service Bus Overview.

2

Create a proxy service and pipeline. You can generate a proxy service when you create the pipeline.

Creating Proxy Services

Working with Oracle Service Bus Pipelines

3

Configure the proxy service and its transport.

Configuring Proxy Services

Working with JCA Adapters, Transports, and Bindings

4

Define the message flow in the pipeline.

Working with Oracle Service Bus Pipelines

5

Optionally, create and configure a split-join for parallel processing.

Working with Split-Joins in JDeveloper

6

Create and configure a business service.

Creating Business Services

Configuring Business Services

7

Configure security for the services.

Securing Business and Proxy Services

8

Test and debug the services and resources.

Debugging Oracle Service Bus Applications

Using the Test Console

9

Deploy the service.

Deploying Oracle Service Bus Services

10

Monitor and administer the runtime.

Oracle Service Bus Runtime Monitoring

1.8 Naming Guidelines for Service Bus Components

Some special characters are allowed in a directory or resource name in a Service Bus project.

Characters such as / \ * : " < > ? | are not allowed.

1.9 Viewing Service Bus Resources in a Web Browser

You can view some of the Service Bus resources described in this document in a standard web browser using the URLs, described in these sections.

1.9.1 WSDL Documents

  • URL to display a WSDL document:

    http://host:port/sbresource?WSDL/project_path/wsdlname

  • URL to display the WSDL document for WSDL-based HTTP proxy services:

    http://host:port/proxy_service_endpoint_URI?WSDL

  • URL to display the WSDL document for WSDL-based proxy services:

    http://host:port/sbresource?PROXY/project_path/proxyname

  • URL to display the WSDL document for proxy services with Oracle Web Services Manager policies attached:

    http://host:port/sbresource?ORAPROXY/project_path/proxyname

  • URL to display the WSDL document for WSDL-based business services:

    http://host:port/sbresource?BIZ/project_path/bizname

  • URL to display the WSDL document for WSDL-based business services with Oracle Web Services Manager policies attached:

    http://host:port/sbresource?ORABIZ/project_path/bizname

1.9.2 WS Policies

Use the following URL to display WS security policies:

http://host:port/sbresource?POLICY/project_path/policyname

1.9.3 Message Format Language (MFL) Resources

Use the following URL to display an MFL file:

http://host:port/sbresource?MFL/project_path/mflname

1.9.4 Schema Resources

Use the following URL to display an XML schema:

http://host:port/sbresource?SCHEMA/project_path/schemaname

1.9.5 Notes About Viewing Service Bus Resources in a Web Browser

You can also retrieve WSDL documents containing Oracle Web Services Manager policies so the policies conform to supported WS-Policy and WS-Security Policy standards. For more information, see Advertising WSDL Files to Support WS Standards..

If you use special characters in your resource names, the URLs used to expose the resources in Service Bus must be encoded in UTF-8 in order to escape special characters.

1.10 Accessibility Options

Service Bus uses both JDeveloper and the Oracle Service Bus Console for development. These sections describe accessibility options for both environments.

1.10.1 Setting Accessibility Options in JDeveloper

JDeveloper provides accessibility options, such as support for screen readers, screen magnifiers, and standard shortcut keys for keyboard navigation. You can also customize JDeveloper for better readability, including the size and color of fonts and the color and shape of objects. For information and instructions on configuring accessibility in JDeveloper, see "Oracle JDeveloper Accessibility Information" in Developing Applications with Oracle JDeveloper.

1.10.2 Notes on Screen Reader Mode

When you log in to the Oracle Service Bus Console with the screen reader mode enabled, selecting the context menus from the Project Navigator requires extra steps. To access the context menus for projects and components in the Project Navigator, navigate to the component using the Tab key, press Enter to select the component, and then press Ctrl+Alt+M to launch the menu. Use the up and down arrows to navigate the options in the menu.

1.10.3 How to Set Accessibility Options in the Oracle Service Bus Console

Accessibility settings help you read all components of the application. You can set accessibility options in the Oracle Service Bus Console for the current instance only. The console presents the Accessibility menu on the login page, so you can configure accessibility before you log in.

To set accessibility options:

  1. Launch the Oracle Service Bus Console.
  2. On the login page, click Accessibility in the bottom right corner of the screen.

    The Edit Accessibility Settings page appears, as shown below.

    Figure 1-5 Edit Accessibility Settings Page

    Description of Figure 1-5 follows
    Description of "Figure 1-5 Edit Accessibility Settings Page"

    Note:

    This page indicates that settings can also be changed using the Preferences option once you log in. Currently, you can only configure accessibility options from the Accessibility Settings page.

  3. Select the Use Screen Reader option.
  4. Click Use for this session.

1.11 Additional Resources

In addition to this guide, Oracle also offers these resources to help you learn how you can best use Service Bus.

  • Understanding Oracle SOA Suite introduces you to Oracle SOA Suite and Oracle Service Bus, and provides you with a high-level understanding of what you can accomplish with the suite.

  • Administering Oracle Service Bus Services provides information on how to monitor running services and update the runtime environment.

  • Oracle Service Bus samples provide more learning tools to help you get started with Service Bus features at http://www.oracle.com/technetwork/middleware/service-bus/learnmore/index.html.

  • You can use the following cloud adapters with Oracle Service Bus to send and receive messages from a cloud server:

The Oracle Fusion Middleware Documentation Library provides a complete list of Service Bus documents.

You can use the following cloud adapters with Oracle Service Bus to send and receive messages from a cloud server.

  • Cloud Adapter for Eloqua

  • Cloud Adapter for ERP

  • Cloud Adapter for NetSuite

  • Cloud Adapter for RightNow

  • Cloud Adapter for SalesCloud

  • Cloud Adapter for Salesforce

The Cloud Adapters section in Oracle Fusion Middleware Documentation Library provides links to these cloud adapters.