Sending web service messages directly over the bus from a JAX-RPC client
Use this task to send web service messages over a bus by retargeting the JAX-RPC client.
Java API for XML-based remote procedure calls (JAX-RPC) client applications send and receive web service request and response messages. JAX-RPC client applications that use the IBM JAX-RPC run-time environment can do this in a number of different ways, depending on the bindings in the WSDL document that they are developed against, and the configuration data used at run time.
For an introduction to basic JAX-RPC programming concepts, including the JAX-RPC client and server programming models, see Get Started with JAX-RPC.
To use a JAX-RPC client to send messages over the service integration bus, we have two choices:
- Use a SOAP binding (SOAP over HTTP or SOAP over JMS), and pass messages indirectly through an endpoint listener to an inbound service. You would do this if you had SOAP-specific JAX-RPC handlers that must run in the client application context.
- Pass messages directly into the service integration bus at a destination by "retargeting" the JAX-RPC client application as described in this topic.
There are currently limitations regarding the Java types used by services that are retargeted through a JAX-RPC client application.
Retargeting involves setting the following two values into the client application deployment descriptor, or specifying them dynamically at run time from within the client application:
- The binding namespace is set to indicate that the client uses the messaging bus directly.
- The endpoint address is set to include the particular destination and (optionally) the format of messages that the client uses.
The destination also needs to be configured so that it knows the port type of messages that the JAX-RPC client is using. There are two ways to achieve this:
- Create an outbound service. An outbound service represents an externally-provided web service. In this case, requests from the JAX-RPC client pass through the service destination and are then sent on to the service provider defined by the outbound service configuration.
- Create an inbound service. An inbound service represents a service provided somewhere within or beyond the messaging bus. We can create an inbound service on any existing destination. The creation of an inbound service associates a WSDL port type with the destination. When retargeting to a destination with an inbound service, the client application needs to specify both the destination name and inbound service name, because it is possible to configure more than one inbound service against a single destination. In this case, requests from the JAX-RPC client pass through the destination and then onwards through the service integration bus depending on routing that is done at the initial destination.
To have web service messages sent directly to a destination using a JAX-RPC client...
- Create the JAX-RPC client application.
- Create the outbound service or inbound service with which we want the JAX-RPC client application to exchange messages.
- Use the console to access the port information for the JAX-RPC client application, as described in Configure web services client bindings and Web services client port information.
- Override the default SOAP binding for the JAX-RPC client application. Change the binding namespace to http://www.ibm.com/ns/2004/02/wsdl/mp/sib
- Override the endpoint that the JAX-RPC client application uses to send web service requests. The new endpoint should use the sib: URL syntax and include either the outbound service destination name, or both the inbound service name and its corresponding destination name.
What to do next
After you change the binding namespace, any JAX-RPC handler lists that were configured for the retargeted port are ignored. For clients developed against WSDL with a SOAP binding, retargeting directly to the bus causes the handlers to be ignored. However if the client is developed against the non-bound WSDL for the service, retargeting to the bus is not considered to be changing the binding namespace, and so the handler information is retained. In this case the JAX-RPC handlers are called with the SDOMessageContext subclass.
Associated reference information:
Subtopics
Related
Implement JAX-RPC handlers to access SDO messages JAX-RPC: Core web services API in the Java platform Get Started with JAX-RPC A developer introduction to JAX-RPC, Part 2: Mine the JAX-RPC specification to improve web service interoperability Support for J2EE Web Services in WebSphere Studio Application Developer V5.1 -- Part 3: JAX-RPC Handlers
Related information:
Create a new JAX-RPC handler configuration Create a new JAX-RPC handler list