Skip Headers
Oracle® Application Server Advanced Web Services Developer's Guide
10g (10.1.3.1.0)

Part Number B28975-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

8 Using JMS as a Web Service Transport

This chapter describes how to employ JMS as an alternative transport mechanism for Web Services. It describes these major topics:

Understanding JMS as a Transport Mechanism

Oracle Application Server Web Services can employ JMS as a transport mechanism to send messages in either one-way request messaging or two-way request and response messaging. One-way request messaging lets a Web service client unblock when the request message reaches a JMS queue. Two-way request and response messaging blocks a Web service client until the response message is received.

See Also:

For examples of one- and two-way messaging, see the following resources:

The SOAP protocol for exchanging XML messages is independent of any transport mechanism. Different mechanisms have different advantages. For example, HTTP provides a greater chance of interoperability with other Web services, since it follows standards developed by the Web Service Interoperability (WS-I) organization. In contrast, JMS provides support for asynchronous messaging and a greater degree of reliability and scalability.

When JMS is the transport mechanism, reliability is improved because messages sent by a service or client are placed on a queue and, optionally, in persistent storage. If communications between the service and client fail, then the message can be retrieved from storage and re-sent.

Note:

Reliability can also be enabled for SOAP messaging over HTTP. For more information, see Chapter 5, "Ensuring Web Service Reliability".

JMS supports the asynchronous invocation of Web services. With asynchronous invocation, the client is free to pursue other tasks while waiting for a response. For example, it can send requests, poll to see the status of the request, and retrieve responses independently.

The scalability designed into JMS allows it to accommodate high-traffic services. This is an advantage over HTTP which has limited support for scalability.

General Steps for Implementing JMS as a Transport Mechanism

Enabling JMS as a transport mechanism follows these general steps.

  1. Set up the queues that are to be used for sending and receiving SOAP messages. "How to Set Up JMS Queues" provides more information on this step.

  2. Assemble the Web service, specifying the JMS queue information for the SOAP transport.

  3. Assemble the proxy (if necessary). When assembling the proxy, you must identify the return queue. The return queue is the JMS queue on which you want to receive responses to Web service invocations. You can do this by declaring the return queue on the command line or in Ant tasks.

    "How to Assemble a Proxy that Uses JMS as a Transport" provides more information on this step.

Understanding Data Flow for JMS Transport

The following steps describe how data is passed between the Web service client and OracleAS Web Services when JMS is the transport mechanism. The WSDL elements and WebServicesAssembler arguments mentioned in the steps are described later in this chapter. Figure 8-1 illustrates the sequence of steps.

  1. In the Web service client, the message is sent as a request to a JMS queue in OC4J. The <jms:address> element in the WSDL provides the location of the target endpoint to which the message will be served from the JMS queue in OC4J.

  2. The client performs a JMS send operation to send the request to the sender queue in OC4J.

  3. The sender queue in OC4J accepts the request. If WebServicesAssembler was used to assemble the Web service, then the location of the sender queue is provided by the sendQueueLocation argument.

  4. The server runtime dequeues the request and serves it to the endpoint identified by the client's request.

  5. If the message has a reply (or response), the service puts the message on the reply-to queue. If WebServicesAssembler was used to assemble the Web service, then the location of the reply-to queue is provided by the replyToQueueLocation argument.

  6. The client blocks on waiting to receive a response on the reply-to queue (in case of a request-response operation), thus simulating a synchronous request-response. If the message exchange pattern was one way, the client does not wait for a response.

Figure 8-1 Data Flow for JMS Transport

Description of Figure 8-1 follows
Description of "Figure 8-1 Data Flow for JMS Transport"

WSDL Extensions for JMS Transport

The following WSDL extensions define JMS transport for a Web service.

These are Oracle proprietary WSDL extensions and may not be interoperable. If you are using Oracle JDeveloper or WebServicesAssembler to develop and deploy the endpoint bottom up, then these extensions are generated into the WSDL. If you are manually writing the WSDL or developing and deploying the Web service top down, then you should add these extensions.

The following URI is the namespace for the extensions described in this section.

xmlns:jms="http://www.oracle.com/technology/oracleas/wsdl/jms"

JMS Address Element

Only one <jms:address> element should be used in a port-component definition. This element should be used in place of a <soap:address> declaration. This element has the following format:

<jms:address 
    jndiConnectionFactoryName="xxx"
    jndiDestinationName="xxx"/>

Table 8-1 describes the attributes of the <jms:address> element.

Table 8-1 Attributes of the <jms:address> Element

Attribute Name Description

jndiConnectionFactoryName

The JNDI name of the connection factory that will be used. If you are generating the Web service bottom up, then this attribute is set by the sendConnectionFactoryLocation argument.

jndiDestinationName

The JNDI name of the JMS queue that messages will be sent to. If you are generating the Web service bottom up, then this attribute will be set by the sendQueueLocation argument.


JMS Property Value Element

The <jms:propertyValue> element must be added to the <jms:address> section of the binding operation to identify the endpoint location. This element has the following format:

<jms:propertyValue
    name="string"
    type="type"
    value="string"/>

Table 8-2 describes the attributes of the <jms:propertyValue> element.

Table 8-2 Attributes of the <jms:propertyValue> Element

Attribute Name Description

name

The name of a property defined by JMS, by the JMS implementation, or by the user.

type

The datatype of the attribute.

value

A value that hard codes the value of this property in the WSDL.


The WebServicesAssembler uri argument can provide the value for the propertyValue element in the WSDL. When the uri argument is specified, the name attribute is set to endpoint-location, the type attribute is set to string and the value attribute is set to the value of the uri argument.

<jms:propertyValue name="endpoint-location" type="string" value="value of uri argument"/>

How to Set Up JMS Queues

Queues must be set up in the OracleAS Web Services container to identify the sender queue and the receiver queue. Each queue is identified by a <queue> element and a <queue-connection-factory> element.

The <queue> element contains a name and a location attribute. The name attribute specifies the queue's JNDI name. The location attribute specifies the queue's JNDI location. The queue element can also contain an optional description element to provide a text description of the queue.

The queue-connection-factory element also contains a name and a location attribute. The name attribute specifies the JNDI name of the JMS connection factory used to produce connections for the send or receive operation. The location specifies the factory's JNDI location.

If the queues are set up in the OC4J/JMS jms.xml configuration file, you can add two clauses to that file: one for the sender queue and one for the reply-to queue.

See Also:

Oracle Containers for J2EE Services Guide.for more information on using JMS in the OC4J environment.

Example 8-1 illustrates XML code that identifies the SOAP sender queue at the JNDI location jms/senderQueue. This queue uses jms/senderQueueConnectionFactory as the JMS connection factory to produce connections for the send operation. Similarly, the second clause identifies the SOAP receiver queue at the JNDI location jms/replyToQueue as the receiver queue. This queue uses jms/replyToQueueConnectionFactory as the JMS connection factory to produce connections for the response messages from the Web service endpoint.

Example 8-1 XML Code to Identify Sender Queue and Receiver Queue

...
<queue name="SOAP sender" location="jms/senderQueue">
    <description>A queue for SOAP messages</description>
</queue>
<queue-connection-factory
    name="jms/senderQueueConnectionFactory"
    location="jms/senderQueueConnectionFactory"/>
 
<queue name="SOAP receiver" location="jms/replyToQueue">
    <description>A queue for SOAP response messages</description>
</queue>
<queue-connection-factory
    name="jms/replyToQueueConnectionFactory"
    location="jms/replyToQueueConnectionFactory"/>
...

How to Assemble a Web Service Bottom Up that Uses JMS Transport

To configure JMS transport into a Web service that you are generating bottom up, the extensions described in "WSDL Extensions for JMS Transport" must be added to the WSDL to identify ports that have JMS transport enabled. WebServicesAssembler provides two arguments that will add this information to the WSDL.

Steps to Assemble a Web Service Bottom Up that Uses JMS Transport

It is assumed that you have already configured the JMS queues for sending and receiving SOAP messages. The following steps describe how to assemble a Web service bottom up that uses JMS as its transport mechanism. The steps follow the standard procedure for assembling a Web service bottom up.

See Also:

  1. Generate the service artifacts by running the WebServicesAssembler with the assemble command. Specify the queue location and queue connection factory with sendQueueLocation and sendConnectionFactoryLocation. The WSDL generated by this Ant task is illustrated in Example 8-2.

    Note:

    Instead of specifying the queue location and queue connection factory on the command line or Ant task with sendQueueLocation and sendConnectionFactoryLocation, you can pass this information to WebServicesAssembler in a deployment descriptor file. For more information on this technique, see "How to Configure JMS Transport by using Deployment Descriptors"
    <oracle:assemble appName="echo"
            targetNamespace="http://www.oracle.com/echo"
            typeNamespace="http://www.oracle.com/echo"
            serviceName="EchoService"
            input="./build/classes/service"
            output="build"
            ear="build/echo.ear"
            style="rpc"
            use="encoded"
            createOneWayOperations="true"
            >
            <oracle:porttype 
               interfaceName="oracle.j2ee.ws.jmstransport.Echo"
               className="oracle.j2ee.ws.jmstransport.EchoImpl"
                >
                <oracle:port
                  uri="/echo"
                  sendQueueLocation="jms/senderQueue"
                  name="EchoPort"
                  sendConnectionFactoryLocation="jms/senderQueueConnectionFactory">
               </oracle:port> 
            </oracle:porttype>
     />
    

    In this Ant task:

    • assemble—Generates a Web service from Java files bottom up. The command creates all of the files required to create a deployable archive.

    • appName—Specifies the name of an application. Usually, this name is used as a base value for other arguments like context and uri.

    • targetNamespace—Specifies the target namespace to be used in the generated WSDL. The value can be either a conforming HTTP URL, a non-conforming HTTP URL, or even a URI.

    • typeNamespace—Specifies the type namespace to be used in the schema types in the generated WSDL. The name that you specify will always be used and it will not be reversed.

    • serviceName—Specifies the service name.

    • input—Specifies the directory or JAR containing the classes that should be copied to WEB-INF/classes. This argument will be added to the classpath used by the WebServicesAssembler.

    • output—Specifies the directory where generated files will be stored. If the directory does not exist, it will be created

    • ear—Specifies the name and location of the generated EAR.

    • style—For bottom up Web service assembly, this argument specifies the style attribute of the message format in the generated WSDL.

    • use—For bottom up Web service assembly, this argument specifies the use attribute of the message format in the generated WSDL.

    • createOneWayOperations—When this argument is set to true, methods that return void will have no response message. If it is not specified or set to false, the response message will be empty.

    • porttype—This tag enables you to configure different interfaces to a Web service.

    • interfaceName—Specifies the name of a Java class (including the package name) that contains the service endpoint interface (SEI).

    • className—Specifies the name of the class (including the package name) that is the implementation class for the Web service.

    • uri—Specifies the URI to use for the Web service.

    • sendQueueLocation—Specifies the JNDI name of the JMS queue to be used for the JMS send operation.

    • sendConnectionFactoryLocation—Specifies the JNDI name of the JMS ConnectionFactory used to obtain a connection for the JMS send operation.

    See Also:

    "Using WebServicesAssembler", in the Oracle Application Server Web Services Developer's Guide for more detailed information on these arguments.

  2. Deploy the service.

    Deploy the EAR file in the standard manner into a running instance of OC4J. For more information on deploying EAR files, see the Oracle Containers for J2EE Deployment Guide.

  3. Generate the client code.

    This step is described in "How to Assemble a Proxy that Uses JMS as a Transport".

Sample Generated WSDL for JMS Transport

Example 8-2 illustrates the WSDL created by the Ant task in "How to Assemble a Web Service Bottom Up that Uses JMS Transport". The JMS transport configuration is highlighted in bold.

Example 8-2 WSDL with a JMS Transport Configuration

<?xml version = '1.0' encoding = 'UTF-8'?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
   xmlns:tns="http://www.oracle.com/echo"
   xmlns:jms="http://www.oracle.com/technology/oracleas/wsdl/jms"
name="Echo" targetNamespace="http://www.oracle.com/echo">
    <types>
        <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soap11-enc="http://schemas.xmlsoap.org/soap/encoding/" targetNamespace="http://www.oracle.com/echo"/>
    </types>
    <message name="Echo_echo">
        <part name="String_1" type="xsd:string"/>
    </message>
    <message name="Echo_echoInt">
        <part name="int_1" type="xsd:int"/>
    </message>
    <message name="Echo_echoIntResponse">
        <part name="result" type="xsd:int"/>
    </message>
    <message name="Echo_echoResponse">
        <part name="result" type="xsd:string"/>
    </message>
    <portType name="Echo">
        <operation name="echo" parameterOrder="String_1">
            <input message="tns:Echo_echo"/>
            <output message="tns:Echo_echoResponse"/>
        </operation>
        <operation name="echoInt" parameterOrder="int_1">
            <input message="tns:Echo_echoInt"/>
            <output message="tns:Echo_echoIntResponse"/>
        </operation>
    </portType>
    <binding name="EchoBinding" type="tns:Echo">
        <operation name="echo">
            <input>
                <soap:body use="encoded" namespace="http://www.oracle.com/echo" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" parts="String_1"/>
            </input>
            <output>
                <soap:body use="encoded" namespace="http://www.oracle.com/echo" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" parts="result"/>
            </output>
            <soap:operation soapAction=""/>
        </operation>
        <operation name="echoInt">
            <input>
                <soap:body use="encoded" namespace="http://www.oracle.com/echo"
 encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" parts="int_1"/>
            </input>
            <output>
                <soap:body use="encoded" namespace="http://www.oracle.com/echo"
 encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" parts="result"/>
            </output>
            <soap:operation soapAction=""/>
        </operation>
        <soap:binding style="rpc"
 transport="http://www.oracle.com/technology/oracleas/wsdl/jms"/>
    </binding>
    <service name="Echo">
        <port name="EchoPort" binding="tns:EchoBinding">
            <jms:address
             jndiConnectionFactoryName="jms/OracleSyndicateQueueConnectionFactory" 
    jndiDestinationName="jms/OracleSyndicateQueue" >
                <jms:propertyValue name="endpoint-location" type="string" 
value="echo"/>
            </jms:address>
        </port>
    </service>
</definitions>

How to Configure JMS Transport by using Deployment Descriptors

A JMS transport configuration can be passed to the WebServicesAssembler by entering it into the oracle-webservices.xml deployment descriptor. This is an alternative to declaring the sendQueueLocation and sendConnectionFactoryLocation, arguments on the command line or Ant task.

When you enter the configuration into oracle-webservices.xml, use <jms-address> instead of <jms:address> and <jms-propertyValue> instead of <jms:propertyValue>. These elements should appear as subelements of the <port-component> element.

The <jms-address> and <jms-propertyValue> elements have the same attributes as described in "WSDL Extensions for JMS Transport".

Example 8-3 illustrates an oracle-webservices.xml deployment descriptor that includes a JMS transport configuration. During assembly, a new WSDL will be created. The resulting WSDL will look like the one in Example 8-2. The JMS configuration is highlighted in bold.

Example 8-3 oracle-webservices.xml with JMS Transport Configuration

<oracle-webservices
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="oracle-webservices-server-10_0.xsd"
    schema-major-version="10" schema-minor-version="0">
    <webservice-description name="Echo">
        <port-component name="EchoPort">
            <runtime enabled="true">
                <jms-address jndiDestinationName="jms/OracleSyndicateQueue" 
jndiConnectionFactoryName="jms/OracleSyndicateQueueConnectionFactory" />
            </runtime>
        </port-component>
    </webservice-description>
</oracle-webservices>

See Also:

"WSDL Extensions for JMS Transport" for descriptions of the <jms-address> element's jndiDestinationName and jndiConnectionFactoryName attributes.

How to Assemble a Web Service Top Down that Uses JMS Transport

For top down assembly, you must edit the WSDL to add the JMS address and property values for the endpoint.

The following steps describe how to generate a Web service that uses JMS as its transport mechanism. It is assumed that you have already configured the JMS queues for sending and receiving SOAP messages.

See Also:

  1. Provide a WSDL from which the Web service will be generated.

  2. Edit the WSDL to add the elements that define JMS transport.

    "WSDL Extensions for JMS Transport" describes the JMS transport elements.

  3. Use the WSDL as input to the WebServicesAssembler genInterface command.

  4. Compile the generated interface and type classes.

  5. Write the Java service endpoint interface for the Web service you want to provide.

  6. Compile the Java service endpoint interface.

  7. Generate the service by running the WebServicesAssembler tool with the topDownAssemble command.

    <oracle:topDownAssemble appName="bank"
                packageName="oracle.ws.server.bank"
                wsdl="./etc/Bank.wsdl"
                input="./build/classes/service}"
                output="build"
                ear="build/bank.ear"
                debug="true"
                fetchWsdlImports="true"
                >
                <oracle:classpath>
                    <oracle:pathelement path="${build.impl.dir}"/>
                    <oracle:pathelement location="${wsa.jar}"/>
                </oracle:classpath>
                <oracle:porttype
                  className="oracle.ws.server.bank.BankImpl"
                  classFileName="java/oracle/ws/server/bank/BankImpl.java"
                  >
                   <oracle:port name="BankPort" uri="bank2"/>
                   <oracle:port name="BankPortWithJMS" uri="/bank"/>
                   <oracle:port name="Soap12JmsEchoPort" uri="/soap12bank"/>
              </oracle:porttype>
            />
    

    In this Ant task:

    • topDownAssemble—Creates the required classes and deployment descriptors for a Web service based on a WSDL description. The files can be stored in either an EAR file, a WAR file, or a directory.

    • packageName—Specifies the package name that will be used for generated classes if no package name is declared in the JAX-RPC mapping file.

    • wsdl—Specifies the absolute file path, relative file path, or URL to a WSDL document.

    • input—Specifies the directory or JAR containing the classes that should be copied to WEB-INF/classes. This argument will be added to the classpath used by the WebServicesAssembler.

    • output—Specifies the directory where generated files will be stored. If the directory does not exist, it will be created.

    • ear—Specifies the name and location of the generated EAR.

    • debug—Indicates whether all detailed diagnostic messages should be printed for a given command.

    • fetchWsdlImports—Indicates if you want to make a local copy of the WSDL and everything it imports.

    • classpath—Specifies the classpath that contains any user-created classes given to WebServicesAssembler. One reason to specify this argument is if you have already created some value type classes or exceptions and you do not want WebServicesAssembler to overwrite them.

    • porttype—This tag enables you to configure different interfaces to a Web service.

    • className—Specifies the name of the class (including the package name) that is the implementation class for the Web service.

    • classFileName—Identifies the Java file name of the implementation class specified in the className argument. If necessary, this file will be compiled during an assembly.

    See Also:

    "Using WebServicesAssembler", in the Oracle Application Server Web Services Developer's Guide for more detailed information on these arguments.

  8. Deploy the service.

    Deploy the EAR file in the standard manner into a running instance of OC4J. For more information on deploying EAR files, see the Oracle Containers for J2EE Deployment Guide.

  9. Generate the client code.

    This step is described in "How to Assemble a Proxy that Uses JMS as a Transport".

  10. Add the following client JAR files to the client classpath.

    These client JAR files are required when the Web service client supports JMS as a transport mechanism. The J2EE_HOME environment variable in the paths represents the location where the Oracle Application Server or the standalone OC4J is installed.

    • J2EE_HOME/j2ee/home/lib/oc4j-unsupported-apis.jar

    • J2EE_HOME/j2ee/home/lib/oc4j-internal.jar

    See Also:

    "Web Service Client APIs and JARs" in the Oracle Application Server Web Services Developer's Guide, for a description of all of the available OracleAS Web Services client JARs.

How to Assemble a Proxy that Uses JMS as a Transport

When working with JMS as a transport mechanism you must ensure that the client code provides the JNDI names of the JMS queue and the connection factory for the reply-to queue which will be used for send operation JMS messages. The WebServicesAssembler arguments replyToQueueLocation and replyToConnectionFactoryLocation can provide these values. Used with the genProxy command, these arguments generate a proxy stub that can be used with JMS transport. The arguments will generate a stub configured with values for a queue that will receive response messages.

If you do not use the replyTo* arguments to generate a proxy stub, and the endpoint contains request/response operations, then you must set the replyTo* arguments programmatically so that response messages can be received.

See Also:

"How to Set the Send Queue Location and Connection Factory Programmatically" describes how to add replyTo* arguments directly to your code

It is assumed that you have already configured the JMS queues for sending and receiving SOAP messages. The following steps describe how to generate a proxy stub that uses JMS as its transport mechanism. The steps follow the standard procedure for assembling a proxy stub.

See Also:

  1. Provide the URI to the WSDL, the name of the output directory, the package name, and the locations of the JMS queue and connection factory as input to the WebServicesAssembler genProxy command.

    This Ant task generates the client proxy and stores it in the build/src/proxy directory. The client application uses the stub to invoke operations on a remote service.

    <oracle:genProxy
           wsdl="http://localhost:8888/bank/bank?WSDL"
           output="build/src/proxy"
           packageName="oracle.ws.client.bank"
           >
           <oracle:port 
             replyToConnectionFactoryLocation="jms/receiverQueueConnectionFactory"
             replyToQueueLocation="jms/receiverQueue"
           </oracle:port>
       />
    

    In this Ant task:

    • genProxy—Creates a static proxy stub that can be used by a J2SE Web service client.

    • wsdl—Specifies the absolute file path, relative file path, or URL to a WSDL document.

    • output—Specifies the directory where generated files will be stored. If the directory does not exist, it will be created.

    • packageName—Specifies the package name that will be used for generated classes if no package name is declared in the JAX-RPC mapping file.

    • replyToConnectionFactoryLocation—Specifies the JNDI name of the JMS connection factory to be used as the default reply-to of all send operation JMS messages.

    • replyToQueueLocation—Specifies the JNDI name of the JMS queue to be used as the default reply-to of all send operation JMS messages.

    See Also:

    "Using WebServicesAssembler", in the Oracle Application Server Web Services Developer's Guide for more detailed information on these arguments.

  2. Use the client utility class file created by genProxy as your application client, or use it as a template to write your own client code. The client utility class file is one of a number of files created by genProxy.

  3. Compile the client files and put them in the classpath.

    List the appropriate JARs on the classpath before compiling the client. As an alternative to listing individual JARs, you can include the client-side JAR, wsclient_extended.jar on the client classpath. This JAR file contains all the classes necessary to compile and run a Web service client.

    For JMS clients, you must also include the oc4j-internal.jar and oc4j-unsupported-apis.jar files on the classpath.

    To provide a JNDI configuration for the client, add the jndi.properties file to the client classpath.

  4. Run the J2SE JMS client from the command line.

See Also:

Writing Client Code to Support JMS Transport

The following sections describe how to write Web service clients that use JMS transport.

How to Write Client Stub Code for JMS Transport

Stub code for a client that uses JMS transport is very similar to code for clients that use HTTP transport. The difference is that the endpoint address must be set to the unique URI that identifies the JMS endpoint.

See Also:

"Writing Web Service Client Applications" in the Oracle Application Server Web Services Developer's Guide for more information on writing client code for J2SE client applications.

Example 8-4 illustrates client stub code that uses JMS transport to send messages. The code that sets the endpoint address to the unique URI that identifies the JMS endpoint is highlighted in bold.

Example 8-4 Client Stub Code to Send Messages with JMS Transport

...
ServiceFactory serviceFactory = ServiceFactory.newInstance();
        Echo_Service echoService = (Echo_Service) serviceFactory.loadService(Echo_Service.class);
        Echo_PortType echoPort = echoService.getEchoPort();
        ((Stub)echoPort)._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, "/echo/echo");  
         String echo = echoPort.echo("Test echo");
...

How to Set the Send Queue Location and Connection Factory Programmatically

When you are working with JMS as a transport, client stub code requires to you to identify the JNDI names of the JMS queue and the connection factory for the reply-to queue for send operation JMS messages. If you do not provide these values when you generate the proxy stub code, you can add them programmatically. OracleAS Web Services provides two properties in the oracle.webservices.OracleStub class that allow you to do this.

  • JMS_TRANSPORT_REPLY_TO_FACTORY_NAME—specifies the JNDI name of the JMS connection factory to be used as the default reply-to of all send operation JMS messages. This property is comparable to the replyToConnectionFactoryLocation WebServicesAssembler argument.

  • JMS_TRANSPORT_REPLY_TO_QUEUE_NAME—specifies the JNDI name of the JMS queue to be used as the default reply-to of all send operation JMS messages. This property is comparable to the replyToQueueLocation WebServicesAssembler argument.

Example 8-5 illustrates client stub code that uses these properties to set the JNDI name of the JMS queue and the connection factory for the reply-to queue for send operations. The code that sets the properties is highlighted in bold.

Example 8-5 Setting replyTo* Parameters Programmatically

ServiceFactory serviceFactory = ServiceFactory.newInstance();
   Echo_Service echoService = (Echo_service)serviceFactory.loadService(Echo_Service.class;
   Echo_PortType echoPort = echoService.getEchoPort();
      ((Stub)echoPort)._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, "/echo/echo");
      ((Stub)echoPort)._setProperty(OracleStub.JMS_TRANSPORT_REPLY_TO_FACTORY_NAME, "jms/receiverQueueConnectionFactory");
      ((Stub)echoPort)._setProperty(OracleStub.JMS.TRANSPORT_REPLY_TO_QUEUE_NAME, "jms/receiverQueue");
   String echo = echoPort.echo("Test echo");

How to Write DII Code for JMS Transport

If you are writing code for a Dynamic Invocation Interface (DII) client, you must create JmsAddress objects for the sender queue and the receiver queue. These objects are then used to declare an JmsClientTransportFactory object programmatically. This will allow the client to get response messages from a Web service invocation.

The JmsAddress and JmsClientTransportFactory classes belong to the oracle.webservices.transport package.

Example 8-6 illustrates DII client code for sending messages through JMS transport. The code which illustrates how JmsClientTransportFactory is created, set up, and used is highlighted in bold.

Example 8-6 DII Client Code to Send Messages Through JMS Transport

...
QName operation = new QName("http://www.oracle.com/echo", "echo");
            Call call = getCall(operation, SOAPVersion.SOAP_1_1);
            call.setTargetEndpointAddress("/echo/echo");
            JmsAddress jmsAddress = new JmsAddress("jms/senderQueue", "jms/senderQueueConnectionFactory");
            JmsAddress replyToAddress = new JmsAddress("jms/receiverQueue", "jms/receiverQueueConnectionFactory");
            JmsClientTransportFactory transportFactory = new JmsClientTransportFactory(jmsAddress, replyToAddress);
            ((OracleCall) call).setClientTransportFactory(transportFactory);
...

Limitations

See "Using JMS as a Web Service Transport".

Additional Information

For more information on: