Configuring Proxy Services and Business Services

Oracle Service Bus proxy services and business services provide the means for managing services, transforming messages, and routing messages through the enterprise.

You can create and configure proxy services and business services using either the run-time environment (Oracle Service Bus Console) or the development environment (Oracle Service Bus Plug-ins for Workshop for WebLogic). You can base proxy services or business services on existing Web Services Description Language (WSDL) resources, including those imported from a UDDI registry such as the Oracle Service Registry, and then further configure them in the console or the plug-in.

Oracle Service Bus Proxy Services

Oracle Service Bus proxy services are definitions of intermediary Web services that Oracle Service Bus implements and hosts locally. Oracle Service Bus uses proxy services to route messages between business services (such as enterprise Web services and databases) and service clients (such as presentation applications or other business services).

A proxy service configuration includes its interface, transport settings, security settings, and a message flow definition. The message flow definition defines the logic that determines how messages are handled as they flow through the proxy service. If a proxy service is based on a WSDL document, the configuration also includes a WSDL port or a WSDL binding. (See Using a WSDL to Define a Service.)

Oracle Service Bus Business Services

Oracle Service Bus business services are definitions of enterprise Web services to which Oracle Service Bus is a client. Those external Web services are implemented in and hosted by external systems, so Oracle Service Bus must know what to call, how to call, and what to expect as a result of a call. Oracle Service Bus business services model those interfaces so that Oracle Service Bus can invoke the external services.

A business service configuration includes its interface, transport settings, and security settings. (It does not include a message flow definition.) If the business service is based on a WSDL, the configuration also includes a WSDL port or a WSDL binding. (See Using a WSDL to Define a Service.)

How WSDL is Used in Oracle Service Bus

Oracle Service Bus defines some types of business services and proxy services using a WSDL, an XML-based specification for describing Web services. A WSDL document describes service operations, input and output parameters, and how a client application connects to the service. For the WSDL 1.1 specification, see the W3C Note, W3C Web Services Description Language (WSDL) 1.1.

About Effective WSDLs and Generated WSDLs

In Oracle Service Bus, you can base a new proxy service or a new business service on an existing WSDL (called a “WSDL resource”) and then override or add configuration properties. You can also create and configure new services that are not based on existing WSDLs.

Effective WSDLs

For WSDL-based services, Oracle Service Bus uses effective WSDLs instead of actual .wsdl files. An effective WSDL represents a service’s WSDL properties as configured in Oracle Service Bus.

A source WSDL serves as a template for an effective WSDL. When you create a service based on a WSDL, Oracle Service Bus generates an effective WSDL by combining settings from the original WSDL and any transport configurations you set, plus any other configuration settings you add or change from the original WSDL. Settings from the original WSDL that are not used in the new configuration are omitted from the effective WSDL.

Oracle Service Bus can generate effective WSDLs for these types of proxy services and business services:

Effective WSDLs can be generated for those types of services using any transport that supports WSDL-based services, including HTTP, JMS, SB, and so on.

Oracle Service Bus cannot generate effective WSDLs for these types of proxy services and business services:

Effective WSDLs have different characteristics for proxy services and business services and for services based on WSDL ports and services based on WSDL bindings. Those characteristics are discussed throughout this documentation. In particular, see Basing Services on WSDL Ports and on WSDL Bindings.

Generated WSDLs

A generated WSDL is an effective WSDL that Oracle Service Bus generates for transport-type services that were not created from a WSDL resource but which can be described using a WSDL. For example, a WSDL generated from an EJB-based service is a generated WSDL.

Accessing Effective WSDLs

In a Web browser, enter the URL for an HTTP-based proxy service, appended with ?WSDL.

This works only for HTTP-transport-based services for which Oracle Service Bus can generate effective WSDLs.)

In a Web browser, enter the fixed HTTP URL, for example:

http://host:port/sbresource?PROXY/project/folder/proxyname

http://host:port/sbresource?BIZ/project/folder/businessservicename

This works for all services for which Oracle Service Bus can generate effective WSDLs.

Export the WSDL from the console or from the plug-in. See:

Exporting a WSDL in Using the Oracle Service Bus Console
Generating an Effective WSDL in Using the Oracle Service Bus Plug-ins for Workshop for WebLogic

Exporting the WSDL generates a .zip file that contains the effective WSDL along with associated dependencies, including schemas and WS-Policies. Oracle Service Bus evaluates the dependencies, and the appropriate location is added to the location attribute of the WSDL import element.

There is no import element for WS-policies. For WS-policies, the policy reference is retained, and the policy resource is included in the export.

You cannot export a generated WSDL.

See also Viewing Resource Details.

WSDL Overview

A WSDL document describes a service, its location, its operations, and the way in which clients can communicate with it. This section provides a very brief introduction to WSDL, to provide context for discussing Oracle Service Bus features.

WSDL specifies SOAP, HTTP, MIME, and Oracle Service Bus-specific binding extensions, which extend the WSDL binding mechanism to support protocol-specific or message format-specific features.

Types

The <types> element is a container for data type definitions. It uses a type system, such as XML Schema (XSD), to define the vocabulary of messages handled by this service. For example, a service that provides stock quotes might define an XML vocabulary, with the terms TradePriceRequest and TradePrice, as shown in Listing 2-1.

Message

The <message> element provides an abstract, typed definition of the data being communicated. A message consists of parts, each of which describes one logical, abstract unit of the message. A WSDL can define one or more messages, each of which may have one or more parts. For example, the WSDL fragment in Listing 2-2 defines four message types, sellerInfoMessage, buyerInfoMessage, response, and negotiationMessage, each of which has one or more parts.

Port Type

The <portType> element defines a set of operations supported by one or more endpoints (which are defined in the <port> element). The port type provides the public interface for the operations provided by the service. Each operation is defined in an <operation> element, each of which is an abstract description of an action supported by the service.

For example, the fragment in Listing 2-3 defines a port type with one operation, GetLastTradePrice, which can handle an input message, GetLastTradePriceInput, and an output message, GetLastTradePriceOuput. The concrete descriptions of these messages are defined in the WSDL binding, as shown in the <soap:operation> subelement in Listing 2-4.

Binding

The <binding> element specifies a concrete data format specification and a concrete transport protocol for a port type.

The fragment in Listing 2-4 specifies the binding for the StockQuotePortType port type, which is provided as the value for the type attribute. The <soap:binding> subelement signifies that the binding is bound to the SOAP protocol format. In that subelement, the style attribute specifies that the data format is SOAP document style, and the transport attribute specifies that the transport protocol is HTTP.

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType

">
    <soap:binding style="document"

transport="http://schemas.xmlsoap.org/soap/http"/>

    <operation name="GetLastTradePrice">
        <soap:operation 
            soapAction="http://example.com/GetLastTradePrice"/>
            <input>
                <soap:body use="literal"/>
            </input>
            <output>
                <soap:body use="literal"/>
            </output>
    </operation>
</binding>

Service and Port

The <service> element defines a collection of related endpoints, each of which is defined in a child <port> element. A port is defined as a binding associated with a network address. For example, the fragment shown in Listing 2-5 defines two ports, StockQuotePort, and StockQuotePortUK. They both use the same binding, tns:StockQuoteSoapBinding, (which is concretely defined in <binding>) but have different network addresses: http://example.com/stockquote vs. http://example.uk/stockquote. These are alternative ports available for this service.

Using a WSDL to Define a Service

If a service has a well defined WSDL interface, it is recommended, although not required, that you use the WSDL to define the service.

SOAP Document Wrapped Web Services

A document wrapped Web service is described in a WSDL as a Document Style Service. However, it follows some additional conventions. Standard document-oriented Web service operations take only one parameter or message part, typically an XML document. This means that the methods that implement the operations must also have only one parameter. Document-wrapped Web service operations, however, can take any number of parameters, although the parameter values will be wrapped into one complex data type in a SOAP message. This wrapped complex data type will be described in the WSDL as the single document for the operation.

SOAP Document Style Web Services

You can configure proxy services as SOAP style proxy services and configure business services as SOAP style business services.

Listing 2-6 provides an example of a WSDL for a sample document style Web service using SOAP 1.1.

<definitions name="Lookup"
targetNamespace="http://example.com/lookup/service/defs"
xmlns:tns="http://example.com/lookup/service/defs"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:docs="http://example.com/lookup/docs"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
  <types>
    <xs:schema targetNamespace="http://example.com/lookup/docs" elementFormDefault="qualified">
      <xs:element name="PurchaseOrg" type="xs:string"/>
      <xs:element name="LegacyBoolean" type="xs:boolean"/>
    </xs:schema>
  </types>
  <message name="lookupReq">
    <part name="request" element="docs:purchaseorg"/>
  </message>
  <message name="lookupResp">
    <part name="result" element="docs:legacyboolean"/>
  </message>
  <portType name="LookupPortType">
    <operation name="lookup">
      <input message="tns:lookupReq"/>
      <output message="tns:lookupResp"/>
    </operation>
  </portType>
  <binding name="LookupBinding" type="tns:lookupPortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="lookup">
      <soap:operation/>
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>
  </binding>
</definitions>

The service has an operation (equivalent to a method in a Java class) called lookup. The binding indicates that this is a SOAP 1.1 document style Web service.

When the WSDL shown in the preceding listing is used for a request, the value of the body variable ($body) that the document style proxy service obtains is displayed in Listing 2-7.

In Listing 2-7, soap-env is the predefined SOAP 1.1 namespace and req is the namespace of the PurchaseOrg element (http://example.com/lookup/docs).

If the business service to which the proxy service is routing uses the above WSDL, the value for the body variable ($body) given above is the value of the body variable ($body) from the proxy service.

The value of the body variable ($body) for the response from the invoked business service that the proxy service receives is displayed in Listing 2-8.

This is also the value of the body variable ($body) for the response returned by the proxy service using this WSDL.

There are many tools available (including Oracle Workshop for WebLogic tools) that take the WSDL of a proxy service (obtained by adding the ?WSDL suffix to the URL of the proxy service in the browser) and generate a Java class with the appropriate request and response parameters to invoke the operations of the service. This Java class can be used to invoke the proxy service that uses this WSDL.

SOAP RPC Web Services

You can configure proxy services as RPC style proxy services and configure business services as RPC style business services.

Listing 2-9 provides an example of a WSDL for a sample RPC style Web service using SOAP 1.1.

<definitions name="Lookup"
targetNamespace="http://example.com/lookup/service/defs"
xmlns:tns="http://example.com/lookup/service/defs"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:docs="http://example.com/lookup/docs"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
  <types>
    <xs:schema targetNamespace="http://example.com/lookup/docs" elementFormDefault="qualified">
      <xs:complexType name="RequestDoc">
        <xs:sequence>
          <xs:element name="PurchaseOrg" type="xs:string"/>
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="ResponseDoc">
        <xs:sequence>
          <xs:element name="LegacyBoolean" type="xs:boolean"/>
        </xs:sequence>
      </xs:complexType>
    </xs:schema>
  </types>
  <message name="lookupReq">
    <part name="request" type="docs: RequestDoc"/>
  </message>
  <message name="lookupResp">
    <part name="result" type="docs: ResponseDoc"/>
  </message>
  <portType name="LookupPortType">
    <operation name="lookup">
      <input message="tns:lookupReq"/>
      <output message="tns:lookupResp"/>
    </operation>
  </portType>
  <binding name="LookupBinding" type="tns:lookupPortType">
    <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="lookup">
      <soap:operation/>
      <input>
        <soap:body use="literal" namespace="http://example.com/lookup/service"/>
      </input>
      <output>
        <soap:body use="literal" namespace="http://example.com/lookup/service"/>
      </output>
    </operation>
  </binding>
</definitions>

The service described in the preceding listing includes an operation (equivalent to a method in a Java class) called lookup. The binding indicates that this is a SOAP RPC Web service. In other words, the Web service’s operation receives a set of request parameters and returns a set of response parameters. The lookup operation has a parameter called request and a return parameter called result. The namespace of the operation in the binding is:

When the WSDL shown in Listing 2-9 is used for a request, the value of the body variable ($body) that the SOAP RPC proxy service obtains is displayed in Listing 2-10.

Where soap-env is the predefined SOAP 1.1 name space, ns is the operation namespace (<http://example.com/lookup/service>) and, req is the namespace of the PurchaseOrg element (http://example.com/lookup/docs).

If the business service to which the proxy service routes the messages uses the WSDL shown in Listing 2-10, the value for the body variable ($body), shown in Listing 2-11, is the value of the body variable ($body) from the proxy service.

When this WSDL is used for a request, the value of the body variable ($body) for the response from the invoked business service that the proxy service receives is displayed in Listing 2-10.

This is also the value of the body variable ($body) for the response returned by the proxy service using this WSDL.

There are many tools available (including Oracle Workshop for WebLogic tools) that take the WSDL of a proxy service (obtained by adding the ?WSDL suffix to the URL of the proxy in the browser) and generate a Java class with the appropriate request and response parameters to invoke the operations of that service. You can use such Java classes to invoke the proxy services that use this WSDL.

The system can provide metrics for each operation in a WSDL.
Operational branching is possible in the pipeline. For more information, see Branching in Message Flows.
For SOAP 1.1 services, the SOAPAction header is automatically populated for services invoked by a proxy service. For SOAP 1.2 services, the action parameter of the Content-Type header is automatically populated for services invoked by a proxy service.
A WSDL is required for services using WS-Security. WS-Policies are attached to WSDLs.
The system supports the <url>?WSDL syntax, which allows you to dynamically obtain the WSDL of a HTTP proxy service. This is useful for a number of SOAP client generation tools, including Oracle Workshop for WebLogic.
In the XQuery and XPath editors and condition builders, it is easy to manipulate the body content variable ($body) because the editor provides a default mapping of $body to the request message in the WSDL of a proxy service. See Message Context.
The run-time contents of $body for a specific action can be different from the default mapping displayed in the editor. This is because Oracle Service Bus is not a programming language in which typed variables are declared and used. Instead, variables are untyped and are created dynamically at run time when a value is assigned. In addition, the type of the variable is the type that is implied by its contents at any point in the message flow. To enable you to easily create XQuery and XPath expressions, the design time editor allows you to map the type for a given variable by mapping the variable to the type in the editor. To learn about using the XQuery and XPath editor to create expressions, see Working with Variable Structures.

Basing Services on WSDL Ports and on WSDL Bindings

When you create a service based on a WSDL resource, you must base the service on a WSDL port or on a WSDL binding:

When creating or modifying the service, you can change the transport, but you cannot override the data format.

The port and binding definitions from the original WSDL resource are modified in the effective WSDL depending on a number of factors, as described below.

Characteristics of Effective WSDLs Generated for Proxy Services

The following characteristics apply to effective WSDLs generated for proxy services:

The effective WSDL has one and only one wsdl:service section.
The wsdl:service section has one and only one wsdl:port section.
For SOAP services, any existing <wsdl:service> definition is removed, and a new service definition containing a single <wsdl:port> is created.
For SOAP binding over any of the supported transports the wsdl:binding section contains the standard WSDL SOAP binding elements along with a unique transport URI that identifies the transport.
For XML binding over HTTP, the wsdl:binding section uses the standard binding elements specified in the WSDL 1.1 specification.
For XML binding over any of the other supported transports the wsdl:binding section uses Oracle (Oracle Service Bus) proprietary WSDL XML binding elements.
If the service is based on a binding:

If the service is generated from binding Y in the WSDL resource, the effective WSDL defines a new service and port (<bindingname>QSService and <bindingname>QSPort). None of the ports defined in the WSDL resource are included in the effective WSDL.
There may be multiple ports in that WSDL associated with that binding. Each port can use a different URL. Therefore, the effective WSDL uses the binding but generates an artificial port from the configuration on the service for that binding. All other ports will be removed.

If the service is based on a port:

If the service is generated from port X in the WSDL resource, then port X is also defined in the effective WSDL. Any other ports defined in the WSDL resource are not included. Furthermore, if you base the proxy service on a WSDL port, the effective WSDL uses that port name. The binding is determined from the port, and in turn, the port type is determined from the binding.
The effective WSDL preserves any WS-Policies associated with the port defined in the resource WSDL.
The transport address specified in the port definition in the resource WSDL is never used as the address for a proxy service in the effective WSDL:

For HTTP services, you must specify a transport address when configuring the transport in the console or the plug-in. That address is used in the port definition in the effective WSDL.

The URL specified as the transport address for a proxy service is always relative to a path in an Oracle Service Bus domain, because Oracle Service Bus always hosts proxy services.

For SOAP-protocol-based WSDL services, the transport URI in the SOAP binding depends on the transport implementation. For standard transports (like HTTP and JMS), this value is as per the SOAP specification or another universally accepted value. For transports for which SOAP does not define a standard value, Oracle Service Bus sets one consisting of a predefined namespace with the transport ID appended at the end: http://www.oracle.com/transport/2007/05/.
There is one service element in the effective WSDL, and the port address contains a URL whose syntax and semantic is defined by the transport selected in the binding.

Characteristics of Effective WSDLs Generated for Non-Transport-Type Business Services

The following characteristics apply to effective WSDLs generated for non-transport-type business services:

The effective WSDL has one and only one wsdl:service section.
The wsdl:service section may have more than one wsdl:port sections. This is generally true when load balancing is used and there are multiple end point addresses that can be used using one of the load-balance algorithms supported.
For SOAP binding over any of the supported transports, the wsdl:binding section contains the standard WSDL SOAP binding elements along with a unique transport URI that identifies the transport.
For XML binding over any of the supported transports, the wsdl:binding section contains the Oracle WSDL XML binding elements.
The URL specified as the transport address is a remote location where the remote service is hosted.
If the service is based on a port:

The effective WSDL defines a port with the same name as the port in the template on which the new service is based. If multiple endpoint addresses are configured for the business service, the effective WSDL generated from it defines ports for all the endpoints, with the names <portname_in_template>_1, <portname_in_template>_2,...
The binding for the new service is determined from the port, and the port type is in turn determined from the binding.
The transport address URL is a remote location where the remote service is hosted.

If the service is based on a binding:

The effective WSDL defines a new service and port, based on the port in the WSDL resource. None of the ports defined in the WSDL resource are included in the effective WSDL.
A binding in the WSDL resource may be associated with multiple ports. Each port can use a different URL and have a different WS-Policy attached to it. Therefore, the generated WSDL uses the binding but generates an artificial port for that binding with no WS-Policy.
For XML-based WSDL services, standard HTTP binding is used only if the service uses HTTP transport. For all other services created from an XML-based WSDL, the effective WSDL uses Oracle binding.

Characteristics of Effective WSDLs Generated for Transport-Type Business Services

Oracle Service Bus does not guarantee one and only one wsdl:service section in effective WSDLs generated for transport-type business services. Because the WSDL is generated by the transport, Oracle Service Bus does not generate nor does it clean up extra service-port sections. Oracle Service Bus does, however, evaluate dependencies and sets their references during export.

Generating Effective WSDLs in Clustered Domains

When generating the effective WSDL in a clustered domain, Oracle Service Bus rewrites the endpoint URL based on the server or cluster configuration. If a front-end HTTP host/port (or a front-end HTTPS host/port for HTTPS endpoints) has been specified, it will be used; otherwise, the Managed Server host or port will be used. It is strongly advised that a front-end HTTP or HTTPS host/port is assigned in clustered domains.

Examples of Proxy Services Based on a Port and on a Binding

Listing 2-12 shows fragments of port and binding definitions in a WSDL resource.

Basing the Service on a Port

If you create a proxy service based on the StockQuotePort port in Listing 2-12, the effective WSDL will look something like the fragment in Listing 2-13.

The service name, StockQuoteService, is the same in both the template and the effective WSDL.
The binding is the same in both the template and the effective WSDL. In this example, it specifies that the service will use the HTTP transport protocol for SOAP document style messages. (The binding also specifies the same binding operation in both the template and the effective WSDL, but that is not shown in this example.)
The second port defined in the WSDL resource, StockQuotePortUK, is not defined in the effective WSDL.
The transport address (URI) defined in the WSDL resource’s port, http://example.com:9999/stockquote, is different from the address generated in the effective WSDL’s port, http://host:port/project/proxyname. The effective WSDL uses the address specified for the transport configuration in the Oracle Service Bus Console or the Oracle Service Bus Plug-ins for Workshop for WebLogic.

Basing the Service on a Binding

If you create a proxy service based on the StockQuoteBinding binding in Listing 2-12, the effective WSDL will look something like the fragment in Listing 2-14.

The service and the port in the WSDL resource are different from the service and the port generated in the effective WSDL.
The service name in the WSDL resource and the effective WSDL are different: StockQuoteService in the template and StockQuoteSoapBindingQSService in the effective WSDL.
The binding is the same in both the WSDL resource and effective WSDL. In this example, it specifies that the service will use the HTTP transport protocol for SOAP document style messages.
The binding also specifies the same binding operation in both the template and the effective WSDL, but that is not shown in this example.
The transport address (URI) defined in the WSDL resource’s port, http://example.com:9999/stockquote, is different from the address generated in the effective WSDL’s port, http://host:port/project/stockquote.

Using Any SOAP or Any XML Service Types

If you want to expose one port to clients for a variety of enterprise applications, use Any SOAP or Any XML service types. For Any SOAP, you must specify if it is SOAP 1.1 or SOAP 1.2.

Using the Messaging Service Type

If one of the request or response messages is non-XML, you must use the messaging service type.

Oracle Service Bus does not automatically perform “misunderstand” SOAP header checking. However, you can use XQuery conditional expressions and validate actions to explicitly perform this type of check. For more information on the validate action, see Adding Validate Actions in Using the Oracle Service Bus Console or Validate Action Properties in Using the Oracle Service Bus Plug-ins for Workshop for WebLogic. For more information on conditional XQuery expressions, see Proxy Services: Editors in Using the Oracle Service Bus Console or Condition Editor in Using the Oracle Service Bus Plug-ins for Workshop for WebLogic.

You can use Oracle Service Bus to configure a validate action and use XQuery conditional expressions to perform validation checks explicitly in the message flow.

For more information on service types, see “General Configuration page” in Creating and Configuring Proxy Services in Using the Oracle Service Bus Console.

Configuring Proxy Services

The following sections provide an overview of proxy service configuration. For specific instructions for configuring proxy services, see:

Proxy Service Types and Transports

Each proxy service is of a certain type, and each can be used with the transport protocols appropriate for that type. Oracle Service Bus supports several standard transports plus custom transports. The service types are described in Table 2-2, including the standard transports available for each type.

Table 2-2 Proxy Service Types and Transports Supported by Oracle Service Bus
Service Type	Description	Standard Transport Protocols Supported for this Service Type
WSDL Web service	A SOAP or XML proxy service whose interface is described by a WSDL document.	HTTP JCA JMS Local SB WS
Any SOAP service (no WSDL)	A SOAP service that does not have an explicitly defined, concrete interface.	HTTP JMS Local SB
Any XML service (non-SOAP, no WSDL)	An XML service that does not have an explicitly defined, concrete interface.	Email File FTP HTTP JMS Local MQ SB SFTP Tuxedo
Messaging service (no WSDL)	A messaging service where the request message and the response message can be of different data types, including binary, text, MFL, and XML.	E-mail File FTP HTTP JMS Local MQ SFTP Tuxedo

Transport and Security Configuration for Proxy Services

You must configure transport settings for all proxy service types in the Oracle Service Bus Console or the Oracle Service Bus Plug-ins for Workshop for WebLogic. Configuration details vary, depending on the transport type. For specific configuration settings, see:

The transport you select should support the transport mode (request/response, one-way, or both) required by the binding definition, and it should be configured accordingly.

For services exchanging messages in both modes, you must configure the binding layer to choose the transport mode accordingly (for any transport implementing the request/response as two asynchronous calls, for example, JMS). This occurs automatically when the service is a concrete type, as it is described in the binding definition. When it is not a concrete type, to configure the binding layer, you must set the mode in the $outbound variable.

Based on the transport and WSDL, the transport mode is automatically selected, but you can overwrite it in $inbound or $outbound.

You can specify security for proxy services, using service providers. A service provider is required if the proxy service routes messages to HTTPS services that require client-certificate authentication and may be required in some message-level security scenarios.

A service account can be created to provide authentication when connecting to a business service. It acts as an alias resource for the required username and password pair.

WebLogic Server can be used to directly manage security credentials for a business service requiring credential-level validation.

Configuration Settings For Each Proxy Service Type

Each proxy service type is modeled following the same pattern. Each service type must define these configurations:

Configuration properties specific to individual proxy service types are described in Table 2-3:

Table 2-3 Configuration Properties for Different Proxy Service Types
Proxy Service Type	Configuration Properties
WSDL Web service	Binding Definition: See Using a WSDL to Define a Service. Run-Time Variables: For SOAP-based WSDL services, the variables are similar to Any SOAP service except that `$operation` is initialized based on the Operation Selection algorithm (See Operation Selection Configuration page in Using the Oracle Service Bus Console. For XML-based WSDL services, the variables are similar to Any XML service except that the `$operation` will be initialized based on the Operation Selection algorithm.
Any SOAP service	Binding Definition: The only information this service type defines is that the service is receiving or sending SOAP messages—regardless of their WSDL binding definition. Therefore the binding configuration for this type is empty. In addition, as there is no binding configuration, the combination of this type and the content-type of the message is sufficient to determine whether or not there are attachments to the message. As per their definition, “any” services (SOAP or XML) do not have any WSDL definition. It is not possible to generate or view a WSDL document for those services. Run-Time Variables: The `$body` and `$header` variables respectively hold the `<soap:Body>` and `<soap:Header>` of the incoming SOAP message. (For SOAP 1.1 proxies, `$body` and `$header` use SOAP 1.1 namespace Body and namespace; for SOAP 1.2 proxies, they use SOAP 1.2 namespace Body and namespace.) The `$attachments` variable contains the SOAP message attachments, if any. The `$operation` variable is not applicable to this service type as you do not define a port type. To learn more about the message context variables, see Message-Related Variables and Constructing Messages to Dispatch.
Any XML service	Binding Definition: The only information this service type defines is that the service is receiving/sending XML messages—regardless of their WSDL binding definition. Therefore, the binding configuration for this type is empty. In addition, as there is no binding configuration, the combination of this type and the content-type of the message is sufficient to determine whether or not there are attachments to the message. As per their definition, “any” services (SOAP or XML) do not have any WSDL definition. It is not possible to request a WSDL document for those services. Run-Time Variables: The `$body` variable holds the incoming XML message wrapped in a `<soap:Body>` element. (For SOAP 1.1 proxies, `$body` and `$header` use SOAP 1.1 namespace Body and namespace; for SOAP 1.2 proxies, they use SOAP 1.2 namespace Body and namespace.) The `$attachments` variable contains message attachments, if there are any. The `$header` variable is not applicable to this service type and is set to its default value. The `$operation` variable is not applicable to this service type as you do not define a port type. To learn more about the message context variables, see Message-Related Variables and Constructing Messages to Dispatch.
Messaging service	Binding Definition: The binding definition for messaging services consists of configuring the content-type of the messages that are exchanged. The content-type for the response does not need to be the same as for the request; therefore, the response is configured separately (for example, the service could accept an MFL message and return an XML acknowledgment receipt) and could also be set to None. As per their definition, messaging-based services do not have any WSDL definition. It is not possible to request a WSDL document for those services. There are four available content types to choose from for the request (and response): Binary Text XML MFL Run-Time Variables: This service type is message-based. There is no concept of multiple “operations” as for Web services. Therefore, the `$operation` variable is left empty. The `$body` variable holds the incoming message wrapped in a `<soap:Body>` element. (For SOAP 1.1 proxies, `$body` uses the SOAP 1.1 namespace Body; for SOAP 1.2 proxies, it uses SOAP 1.2 namespace Body.) The `$header` variable is not applicable to this service type, and is set to its default value. The `$attachments` variable contains message attachments if there are any. To learn more about the message context variables, see Message-Related Variables and Constructing Messages to Dispatch.

Configuring Message Flow

A proxy service’s message flow definition defines the logic that determines how messages are handled as they flow through the proxy service. A message flow definition transforms messages, as needed, to map the message data to the format required by a business service (for outbound messages) or the originating client (for inbound messages). They then route the messages to the appropriate location. For information about configuring message flows, see Modeling Message Flow in Oracle Service Bus.

Security-Related Validation for Proxy Services

When you activate a session that contains changes to an active proxy service, Oracle Service Bus validates the changes to ensure that you have created all of the credentials that the proxy service’s static endpoints require. For example, if you configured a proxy service to have a Web service as a static endpoint and the Web service requires a digital signature, Oracle Service Bus verifies that you have associated a service key provider with the proxy service and that the service key provider contains a key-pair binding that can be used as a digital signature.

If a session contains a change to the key-pair bindings of a service key provider, Oracle Service Bus validates the change against all of the proxy services that use the service key provider. For example, if you remove the encryption key-pair, Oracle Service Bus reports a validation error for any proxy service that references the service key provider and whose endpoint requires encryption.

The following criteria determine when Oracle Service Bus performs this security-related validation and the actions that it takes during validation:

Configuring Business Services

The following sections provide an overview of business service configuration. For specific instructions for configuring business services, see:

Business Service Types and Transport

Each business service is of a certain type, and each can be used with the transport protocols appropriate for that type. Oracle Service Bus supports several standard transports plus custom transports. The service types are described in Table 2-4, including the standard transports available for each type.

Table 2-4 Business Service Types and Transports Supported by Oracle Service Bus
Service Type	Description	Transport Protocols
WSDL Web service	A SOAP or XML business service whose interface is described by a WSDL document.	DSP HTTP JMS JPD Local¹ SB WS
Any SOAP Service (no WSDL)	A SOAP service that does not have an explicitly defined, concrete interface.	DSP HTTP JMS JPD Local SB
Any XML Service (no WSDL)	An XML service that does not have an explicitly defined, concrete interface. Only HTTP GET is supported for XML with no WSDL.	DSP E-mail File FTP HTTP GET JMS JPD Local MQ SB SFTP Tuxedo²
Transport Typed Service (no WSDL)	A service that uses an EJB transport.	EJB Flow
Messaging Type Service (no WSDL)	A messaging service where the request message and the response message can be of different data types, including binary, text, MFL, and XML.	E-mail File FTP HTTP GET JMS Local MQ SFTP Tuxedo

¹Oracle recommends using the local transport for communication between two proxy services. For more information on local transport, see the Local Transport User’s Guide..

²For a Tuxedo transport-based service, if the service type is XML, an FML32 buffer with an FLD_MBSTRING field from a Tuxedo client will not be transformed to XML.

² For information about configuring proxy and business services based on various transport protocols, see the Oracle Service Bus Transports page.

Configuration Settings for All Business Service Types

Each business service type is modeled following the same pattern. Each service type must define these configurations:

Table 2-5 Common Configuration Properties for Business Services
Property	Description
Resource Definition	The resource definition consists of: The service name (that is, project, path, and local name) An optional description for the service The service type
Transport Configuration	You can configure the following parameters for each business service: List of `<string URI, integer weight>` pairs—for example, `<http://www.oracle.com, 100>`. For a random-weighted list, the list should contain at least one element. Load-balancing algorithm—enumeration, one of round-robin, random, or random-weighted. If you select random-weighted, the weights are applicable for each URI. Retry Count Retry Iteration Interval Retry Application Errors The transport you select must be able to support the transport mode (that is, request/response, one-way or both) required by the binding definition, and be configured accordingly. For services exchanging messages in both modes (i.e., request/response and one-way), you must configure the binding layer so that it can select the transport mode accordingly. This occurs automatically when the service is a concrete type, as it is described in the binding definition. When it is not a concrete type, to configure the binding layer, you must use the routing options action in the message flow to set the mode for a route or publish. Based on the transport and WSDL or interface, the transport mode is automatically selected, but you can overwrite it using the routing options action for a route or publish action.

Configuration Settings For Each Business Service Type

Configuration properties specific to individual business service types are described in Table 2-6:

Table 2-6 Configuration Properties for Different Business Service Types
Property	Description
WSDL Web service	See Using a WSDL to Define a Service.
Any SOAP Service	Binding Definition: The only information this service type defines is that the service is receiving or sending SOAP messages—regardless of their WSDL binding definition. Therefore the binding configuration for this type is empty. In addition, as there is no binding configuration, the combination of this type and the content-type of the message is sufficient to determine whether or not there are attachments to the message. As per their definition, any services (SOAP or XML) do not have any WSDL definition. Run-Time Variables: The `$body` and `$header` variables respectively hold the `<soap:Body>` and `<soap:Header>` of the SOAP message to the business service being routed to or published. (For SOAP 1.1 proxies, `$body` and `$header` use SOAP 1.1 namespace Body and namespace; for SOAP 1.2 proxies, they use SOAP 1.2 namespace Body and namespace.) The `$attachments` variable contains the SOAP message attachments if any. To learn more about the message context variables, see Message-Related Variables.
Transport-Typed	Transport-typed services have an empty binding definition and only apply to EJB business services. A WSDL is not specified. Instead the transport automatically defines the WSDL for the service. A zip containing this WSDL can be exported from the Oracle Service Bus Console or the Oracle Service Bus Plug-ins for Workshop for WebLogic. This WSDL will not have a port defined. The EJB Transport-Typed Service is an outbound transport to access EJBs from Oracle Service Bus. It is a self-described transport that generates a WSDL to describe its service interface. The EJB transport features transaction and security context propagation. Business services built using an EJB transport can be used for publish, service callout, and service invocation.
Any XML Services	Binding Definition: The only information this service type defines is that the service is receiving/sending XML messages—regardless of their WSDL binding definition. Therefore, the binding configuration for this type is empty. In addition, as there is no binding configuration, the combination of this type and the content-type of the message is sufficient to determine whether or not there are attachments to the message. As per their definition, any services (SOAP or XML) do not have any WSDL definition. Run-Time Variables: The `$body` variable holds the incoming XML message wrapped in a `<soap:Body>` element. (For SOAP 1.1 proxies, `$body` uses SOAP 1.1 namespace Body; for SOAP 1.2 proxies, it uses SOAP 1.2 namespace Body.) The `$attachments` variable contains message attachments if there are any. The `$header` variable is not applicable to this service type and is set to its default value. To learn more about the message context variables, see Message-Related Variables.
Messaging Services	Binding Definition: The binding definition for messaging services consists of configuring the content-type of the messages that are exchanged. The content-type for the response does not need to be the same as for the request; therefore, the response is configured separately (for example, the service could accept an MFL message and return an XML acknowledgment receipt). By definition, messaging-based services do not have any WSDL definition. It is not possible to request a WSDL document for those services. The following content types are available for the request (and response): Binary Text XML MFL None Run-Time Variables: This service type is message based. The `$body` variable holds the incoming message wrapped in a `<soap:Body>` element. (For SOAP 1.1 proxies, `$body` uses SOAP 1.1 namespace Body; for SOAP 1.2 proxies, it uses SOAP 1.2 namespace Body.) The `$header` variable is not applicable to this service type, and is set to its default value. The `$attachments` variable contains message attachments if there are any. To learn more about the message context variables, see Message-Related Variables.

If a business service requires Web service security, make sure the WSDL you specify has the necessary WS-Policies attached when you create the business service. Furthermore, if the WS-Policy of the business service requires encryption, make sure the public certificate of the business service is embedded in the WSDL. If the business service is a WebLogic Server 9.0 or later Web service, you can retrieve its WSDL using the http://<host>:<port>/<service url>?WSDL URL, the public certificate will be automatically embedded for you if necessary.

Using Proxy Servers

You can configure business services to route messages through a proxy server. You do this by creating a proxy server resource that specifies one or more proxy servers together with the necessary credentials. You can then associate this proxy server resource with a business service. This instructs Oracle Service Bus to connect to the business service through the configured proxy server.

Adding multiple proxy servers to a resource enables Oracle Service Bus to perform load balancing and offer fault tolerance among the configured proxy servers. The credentials are used when opening a connection to the proxy server. If a particular proxy server is not reachable, Oracle Service Bus attempts to use the next proxy server in the configuration. If all proxy servers are unreachable, Oracle Service Bus tries to connect to the back end service directly. If that too fails, a fault is raised and sent back to the caller.

When configuring a proxy server, you can specify the clear text or SSL port number for the server, in addition to the host name or IP address. Note that the port specified in the proxy server resource configuration corresponds to the actual physical port of the Web proxy server and not the port of the back end service. The end point configuration on the business service, however, corresponds to the actual end point of the back end service. This is true even in the case of SSL/TLS Tunneling using HTTP CONNECT command.

NOTE: While some Web proxy servers support HTTP CONNECT using both clear text and SSL sockets, other servers support HTTP CONNECT using only clear text sockets. For example, Sun Proxy Server 4.0 supports HTTP CONNECT using clear text and SSL sockets while Apache Web Server 2.2 in proxy server mode supports HTTP CONNECT using only clear sockets.

Typically, for SSL/TLS Tunneling support, you do not need to install server or Certificate Authority (CA) certificates on the physical proxy server. Instead, the Web proxy server uses the certificate received from the caller (Oracle Service Bus, in this case) to open a secure socket. Similarly, when the server hosting the business application requires a client certificate, the certificate of the server hosting the proxy service (Oracle Service Bus) is used for authentication.

Viewing Resource Details

Oracle Service Bus provides a resource servlet that is used to expose the resources registered in Oracle Service Bus. The resources registered with Oracle Service Bus include:

User Guide