User’s Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Configuring Proxy Services and Business Services

ALSB 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 ALSB Console or the ALSB Plug-in for WorkSpace Studio. You can base proxy services or business services on existing WSDL resources, including those imported from a UDDI registry such as the AquaLogic Service Registry, and then further configure them in the console or the plug-in.

The following sections describe services and their configuration:

 


ALSB Proxy Services

ALSB proxy services are definitions of intermediary Web Services that ALSB implements and hosts locally. ALSB 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 Web Services Description Language (WSDL) document, the configuration also includes a WSDL port or a WSDL binding. (See Using a WSDL to Define a Service.)

 


ALSB Business Services

ALSB business services are definitions of enterprise Web Services to which ALSB is a client. Those external Web Services are implemented in and hosted by external systems, so ALSB must know what to call, how to call, and what to expect as a result of a call. ALSB business services model those interfaces so that ALSB 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 ALSB

ALSB defines some types of business services and proxy services using 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 ALSB, 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 in the console or the plug-in. You can also create new services that are not based on pre-existing WSDLs and then configure them completely in the console or the plug-in.

Effective WSDLs

An effective WSDL represents a services’s WSDL properties as configured in ALSB.

When you create a service based on a WSDL resource, ALSB generates an effective WSDL by combining settings from the original WSDL plus any transport configurations you set in the console or the plug-in, plus any other configuration settings you add or change from the original WSDL. Settings from the original WSDL resource that are not used in the new configuration are omitted from the effective WSDL.

ALSB 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, etc.

ALSB 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 ALSB 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

There are three ways to access an effective WSDL:

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 ALSB features.

Table 2-1 summarizes the main elements used to define WSDL services.

Table 2-1 High-level WSDL Elements
Element
Description
<types>
Type definitions for message content.
<message>
Abstract definition of the data being exchanged. A message consists of parts, which describe the logical, abstract content of the message.
<portType>
Abstract collection of operations supported by the service.
<operation>
Abstract description of an action supported by the service.
<binding>
Concrete protocol and data format specification for a port type.
<port>
A single endpoint, consisting of a network address and a binding.
<service>
Collection of related ports, or endpoints.

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

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.

Listing 2-1 WSDL Types Example
<types>
    <schema targetNamespace="http://example.com/stockquote.xsd"
            xmlns="http://www.w3.org/2001/XMLSchema">
        <element name="TradePriceRequest">
            <complexType>
                <all>
                    <element name="tickerSymbol" type="string"/>
                </all>
            </complexType>
        </element>
        <element name="TradePrice">
            <complexType>
                <all>
                    <element name="price" type="float"/>
                </all>
            </complexType>
        </element>
    </schema>
</types>

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.

Listing 2-2 WSDL Message Example
<message name="sellerInfoMessage">
    <part name="inventoryItem" type="xsd:string"/>
    <part name="askingPrice" type="xsd:integer"/>
</message>

<message name="buyerInfoMessage">
     <part name="item" type="xsd:string"/>
  <part name="offer" type="xsd:integer"/>
</message>

<message name="response">
    <part name="result" type="xsd:string"/>
</message>

<message name="negotiationMessage">
    <part name="item" type="xsd:string"/>
    <part name="price" type="xsd:integer"/>
    <part name="outcome" type="xsd:string"/>
</message>

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.

Listing 2-3 WSDL Port Type and Operation Example
<portType name="StockQuotePortType">
    <operation name="GetLastTradePrice">
        <input message="tns:GetLastTradePriceInput"/>
        <output message="tns:GetLastTradePriceOutput"/>
    </operation>
</portType>

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.

Listing 2-4 WSDL Binding Example

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

Listing 2-5 WSDL service and port Example
<service name="StockQuoteService">
    <port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
       <soap:address location="http://example.com:9999/stockquote"/>
    </port>
    <port name="StockQuotePortUK" binding="tns:StockQuoteSoapBinding">
       <soap:address location="http://example.uk:9999/stockquote"/>
    </port>
</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.

There are three types of WSDLs you can define. They are:

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.

Listing 2-6 WSDL for a Sample Document Style Web Service
<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.

Note: Namespace declarations have been removed from the XML in the listings that follow for the sake of clarity.
Listing 2-7 Body Variable Value
<soap-env:body>
  <req:purchaseorg>BEA Systems</req:purchaseorg>
</soap-env:body>

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.

Note: Namespace declarations have been removed from the XML in the listings that follow for the sake of clarity.
Listing 2-8 Body Variable Value
<soap-env:body>
  <req:legacyboolean>true</req:legacyboolean>
</soap-env:body>

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 BEA WebLogic Workshop 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.

Listing 2-9 WSDL for a Sample RPC Style Web Service
<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:

   http://example.com/lookup/service/defs

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.

Note: Namespace declarations have been removed from the XML in the listings that follow for the sake of clarity.
Listing 2-10 Body Variable Value
<soap-env:body>
  <ns:lookup>
    <request>
      <req:purchaseorg>BEA Systems</req:purchaseorg>
    </request>
  </ns:lookup>
<soap-env:body>

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.

Listing 2-11 Body Variable Value
<soap-env:body>
  <ns:lookupResponse>
    <result>
      <req:legacyboolean>true</req:legacyboolean>
    </result>
  </ns:lookupResponse>
<soap-env:body>

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 BEA WebLogic Workshop 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 benefits of using a WSDL include the following:

 


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:

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:

Characteristics of Effective WSDLs Generated for Transport-Type Business Services

ALSB 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, ALSB does not generate nor does it clean up extra service-port sections. ALSB 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, ALSB 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.

Listing 2-12 WSDL resource
<portType name=”StockQuotePortType”>
...
</portType>
<binding name=”StockQuoteSoapBinding” type=”tns:StockQuotePortType”>
    <soap:binding style=”document”
      transport=”http://schemas.xmlsoap.org/soap/http”/>
...
</binding>
<service name=”StockQuoteService”>
   <port name=”StockQuotePort” binding=”tns:StockQuoteSoapBinding”>
     <soap:address location=”http://example.com:9999/stockquote”/>
   </port>
   <port name="StockQuotePortUK" binding="tns:StockQuoteSoapBinding">
      <soap:address location="http://example.uk:9999/stockquote"/>
   </port>
</service>
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.

Listing 2-13 Effective WSDL for a Proxy Service Based on a Port
<binding name=”StockQuoteSoapBinding” type=”ns:StockQuotePortType”>
    <soap:binding style=”document”
      transport=”http://schemas.xmlsoap.org/soap/http”/>
...
</binding>
<service name=”StockQuoteService”>
  <port name=”StockQuotePort” binding=”ns:StockQuoteSoapBinding”>
    <soap:address location=”http://host:port/project/proxyname”/>
  </port>
</service>

Notice the following about the above example:

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.

Listing 2-14 Effective WSDL for a Proxy Service Based on a Binding
<binding name=”StockQuoteSoapBinding” type=”ns:StockQuotePortType”>
    <soap:binding style=”document”
      transport=”http://schemas.xmlsoap.org/soap/http”/>
...
</binding>
<wsdl:service name=”StockQuoteSoapBindingQSService
   <wsdl:port name=”StockQuoteSoapBindingQSPort
            binding=”ns:StockQuoteSoapBinding”>
      <soap:address location=”http:/host:port/project/proxyname”/>
   </wsdl:port>
</wsdl:service>

Notice the following about the above example:

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.

ALSB 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 AquaLogic Service Bus Console or Validate Action Properties in Using the AquaLogic Service Bus Plug-in for WorkSpace Studio. For more information on conditional XQuery expressions, see Proxy Services: Editors in Using the AquaLogic Service Bus Console or Condition Editor in Using the AquaLogic Service Bus Plug-in for WorkSpace Studio.

You can use ALSB 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 AquaLogic 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. ALSB 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 ALSB
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
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.
E-mail
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
Tuxedo

Note: All service types can send and receive attachments using MIME.

Transport and Security Configuration for Proxy Services

You must configure transport settings for all proxy service types in the ALSB Console or the ALSB Plug-in for WorkSpace Studio. 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.

For more information, see Service Key Providers in Using the AquaLogic Service Bus Console. See also Security-Related Validation for Proxy Services.

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 AquaLogic 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 ALSB.

Security-Related Validation for Proxy Services

When you activate a session that contains changes to an active proxy service, ALSB 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, ALSB 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, ALSB validates the change against all of the proxy services that use the service key provider. For example, if you remove the encryption key-pair, ALSB reports a validation error for any proxy service that references the service key provider and whose endpoint requires encryption.

The following criteria determine when ALSB 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. ALSB 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 ALSB 
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
Local1
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
Tuxedo2
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

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

2For 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.

2For information about configuring proxy and business services based on various transport protocols, see the AquaLogic 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:

The business service configuration properties described in Table 2-5, below, are common to all service types. Properties specific to individual service types are described in Configuration Settings For Each Business Service Type.

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.bea.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
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 ALSB Console or the ALSB Plug-in for WorkSpace Studio. This WSDL will not have a port defined.
The EJB Transport-Typed Service is an outbound transport to access EJBs from ALSB. 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.

 


Viewing Resource Details

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

The format of the URLs used to expose the resources is as follows:

You can use the following URL formats to expose the resource details:

Note: The URLs used to expose the resources in ALSB must be encoded in UTF-8 in order to escape special characters.

  Back to Top       Previous  Next