|
|
The following sections describe features and concepts related to interoperability between BEA ALSB and WebLogic JMS, and between ALSB and WebSphere MQ:
Java API for XML-Remote Procedure Call (JAX-RPC) is considered the core Java API to build and deploy Web services using J2EE. JAX-RPC provides a simple, robust platform for building Web services applications by abstracting the complexity of mapping between XML types and Java types and the lower-level details of handling XML SOAP messages from the developer. JAX-RPC introduces a method call paradigm by providing two programming models:
JAX-RPC mandates the use of SOAP and interoperability with other Web services built with other technologies. If you already have a stateless session EJB or a Java class that performs your business logic, J2EE 1.4 lets you expose it as a service in a standard manner using JAX-RPC.
ALSB is certified to work with the following JMS implementations:
All ALSB service types support JMS transport. Proxy services and business services must be configured to use JMS transport as described in the Proxy Services: Creating and Managing and Business Services: Creating and Managing sections of Using the AquaLogic Service Bus Console.
For information about ALSB service types and the transports for each of the service types, see “Selecting a Service Type” in Modeling Message Flow in ALSB in the AquaLogic Service Bus User Guide.
For information about WebLogic Server 10.0 JMS, see:
| Note: | ALSB 3.0 now supports the MQ Extended Transactional Client which is vital for remote transactional support configuration. |
Messaging can be categorized as follows:
However, messaging over JMS is only one-way or via asynchronous request-response. Asynchronous request-response messaging using JMS is an alternative to messaging using HTTP or HTTP(s).
Using asynchronous request-response messaging has the following advantages:
If you are using IBM WebSphere MQ, asynchronous request-response messages may be the best approach for interacting with some mainframes. The asynchronous service must echo the correlation ID or the message ID depending on the JMS request-response pattern that you use. The format of either ID used by ALSB is compatible with IBM WebSphere MQ and with target services that use MQ native interfaces. For more information, see Understanding Message ID and Correlation ID Patterns for JMS Request/Response.
Asynchronous request-response messages are handled by the outbound and inbound transports. That is, the message flow, except for the $outbound and $inbound transport specific data, does not distinguish between JMS request-response and HTTP request-response.
ALSB supports bridging between synchronous and asynchronous request and response. For example, a proxy service can be invoked using HTTP, and the proxy service routes to a JMS request-response business service. This is called synchronous-to-asynchronous service switching.
You can use JMS for SOAP transport instead of HTTP, as SOAP is transport-agnostic. SOAP JMS transport is necessary especially for enterprise customers. ALSB supports SOAP messages with JMS request-response. ALSB supports interoperation with WebLogic Server SOAP-based clients and services.
JMS is also an approach for reliable messaging.
This section contains examples for interoperating with SOAP-JMS as follows:
When you use JMS binding to configure a service in WebLogic Server 9.x and 10.0, use the following SOAP-JMS URL format with WebLogic Server:
jms://host:port/contextURI/serviceName?URI=destJndiName
When you configure the service in ALSB, the URL must have the following format:
jms://host:port/factoryJndiName/destJndiName
Both formats use the same destJndiName. The factoryJndiName must be the JNDI name of an existing QueueConnectionFactory in the target WebLogic Server.
When you invoke BEA WebLogic Server services from ALSB, you must set the URI as a JMS property with the value as /contextURI/serviceName, inside the message flow on the outbound variable ($outbound) before a request is sent to the business service. Use the Transport Headers action to set this property.
For information about setting $outbound, see “Inbound and Outbound Variables” in
Message Context of AquaLogic Service Bus User Guide.
When a WebLogic Server 9.x or 10.0 Web Services client invokes an ALSB proxy service, the URI property is ignored. However, it can be passed through to an invoked service using the pass through options of the Transport Headers action. For more information, see “Adding Transport Header Actions” in Proxy Services: Actions in Using the AquaLogic Service Bus Console.
ALSB can only invoke WebLogic request-response services running on version 9.2 or later. However, it can also invoke one-way JMS services.
When you configure the response queue for cross-domain JMS calls, make sure that there is a separate response queue corresponding to each requesting managed server. For example:
If there are two ALSB clustered domains (domain A and domain B) talking to a WLS domain. Let’s say the WLS domain has 2 managed servers. If domain A has 3 managed servers and domain B has 4 managed servers, you need to configure 7 distinct queues to serve as response queues (3 + 4 = 7) on the WLS domain for sending responses back to domain A and domain B. These queues could be distributed queues (with members on both the managed servers of the WLS domain).
| Note: | When the JMS requests come from multiple proxy services hosted by different remote domains, you must configure the back-end domain hosting the JMS business service with the separate sets of response queues corresponding to each requesting domain. |
When you use the JMS binding to configure a business service in BEA WebLogic Workshop 8.1, use the following the SOAP/JMS URL format with BEA WebLogic Workshop:
jms://host:port/factoryJndiName/destJndiName?URI=/process/myprocess.jpd
ALSB always uses JMS URLs with the following format:
jms://host:port/factoryJndiName/destJndiName
When you invoke BEA WebLogic Workshop services from ALSB, you must set the URI as a JMS property inside the message flow on the outbound variable ($outbound) before it is sent. Use the Transport Headers action to set this property. For more information, see “Adding Transport Header Actions” in
Proxy Services: Actions in Using the AquaLogic Service Bus Console.
When a WebLogic Workshop client (for example, a control) invokes an ALSB proxy service, the URI property is ignored. However, it can be passed through to an invoked service using the pass through options of the Transport Headers action.
ALSB cannot invoke WebLogic 8.1 JMS request-response services. However, it can invoke one-way JMS services.
For information about setting $outbound, see “Inbound and Outbound Variables” in
Message Context of AquaLogic Service Bus User Guide.
When you use the JMS binding to configure a business service in WebLogic Server 8.1, use the following SOAP-JMS URL format with WebLogic Server:
jms://host:port/factoryJndiName/destJndiName?URI=/contextURI/serviceName
This format differs from the ALSB JMS URL format shown in the preceding sections. When invoking BEA WebLogic Server services from ALSB, you must set the URI as a JMS property inside the message flow on the outbound variable ($outbound) before a request is sent to the business service. You can use the Transport Headers action to set this property.
When a WebLogic Server 8.1 Web Services client invokes a ALSB proxy service, the URI property is ignored. However, it can be passed through to an invoked service using the pass through options of the Transport Headers action. For more information, see “Adding Transport Header Actions” in Proxy Services: Actions in Using the AquaLogic Service Bus Console.
For information about setting $outbound, see “Inbound and Outbound Variables” in
Message Context of AquaLogic Service Bus User Guide.
If you are working with more than one domain, make sure that your configuration conforms to the following requirements:
Note the following rules for JMS Server names:
ReplyTo function. The ReplyTo message sent from a given domain is returned to the JMS server on the same domain that received the message instead of being returned to the domain that sent the original message.For more information on how to configure and manage WebLogic JMS:
For information about WebLogic Server domains, see Understanding Domain Configuration.
To support interoperability with heterogeneous endpoints, ALSB allows you to control the content type used, the JMS type used, and the encoding used when configuring message flows. The JMS type can be byte or text. For more information, see “Content Types, JMS Type, and Encoding” in Modeling Message Flow in ALSB in the AquaLogic Service Bus User Guide.
When consuming a WSDL that explicitly defines a fault, the WebLogic clientgen tool generates a subclass of java.lang.Exception for the XML fault type. When the WebLogic Server JAX-RPC stack inspects a SOAP response message and determines that the response message contains a SOAP fault, it tries to map the fault to a clientgen-generated exception Java class.
For example, if a WSDL contains the definitions shown in the following listing, the clientgen tool generates a Java class com.bea.test.TheFaultType that extends java.lang.Exception. A JAX-RPC client can catch com.bea.test.TheFaultType when invoking the related method of the service stub.
<definitions ... xmlns:s0="http://www.bea.com/test/">
...
<types>
<xsd:schema targetNamespace="http://www.bea.com/test/">
...
<xsd:complexType name="theFaultType">
<xsd:sequence>
<xsd:element name="ID" type="xsd:int" />
<xsd:element name="message" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
<xsd:element name="theFault" type="theFaultType" />
</xsd:schema>
</types>
...
<message name="theFaultMessage">
<part element="s0:theFaultPart" name="theFault" />
</message>
...
<binding ...>
<operation ...>
<soap:operation soapAction="..." style="document" />
<input ...>
...
</input>
<output ...>
...
</output>
<fault ...>
<soap:fault name="theFaultPart" use="literal" />
</fault>
</operation>
</binding>
...
</definitions>
The SOAP message must contain a fault of the correct format so that the JAX-RPC stack throws the correct exception. If the fault is constructed from inside an ALSB message flow, you must:
$body variable with the following sample SOAP: <soap-env:Body>
<soap-env:Fault>
<faultcode
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">soap:Server</faultcode>
<faultstring>Some literal string</faultstring>
<detail>
<test:theFault>
<test:ID>Any user defined code</test:Id>
<test:message>A specific literal message</test:message>
</test:theFault>
</detail>
</soap-env:Fault>
</soap-env:Body>
For information about configuring Reply Actions in the ALSB Console, see Proxy Services Actions in Using the AquaLogic Service Bus Console.
The clientgen tool is used to generate the client-side artifacts, such as the JAX-RPC stubs, needed to invoke a Web Service. See Ant Task Reference in WebLogic Web Services: Reference.
ALSB connects to WebSphere MQ via the WebSphere MQ JMS interface. That is, ALSB is a WebSphere MQ JMS client.
WebSphere MQ can interface with ALSB in two ways:
For more information, see Using the WebSphere JMS MQ Interface in MQ Transport User Guide.
|