Using SOAP over JMS to transport web services

You can use the SOAP over Java™ Message Service (JMS) transport protocol as an alternative to SOAP over HTTP for communicating SOAP messages between clients and servers.

Before you begin

A web service must be implemented as an enterprise bean for accessibility through the JMS transport.

About this task

這個產品支援新興的產業標準 SOAP over JMS 通訊協定。 SOAP over JMS 規格提供一組在 SOAP 訊息中使用 JMS 標準傳輸的標準交互作業準則,以便在不同供應商實作之間交互作業。 當使用這個標準,在透過 JMS 傳輸來交換 Java API for XML Web Services (JAX-WS) 及 Java API for XML-Based RPC (JAX-RPC) Web 服務兩者的 SOAP 要求和回應訊息時,不同供應商的用戶端和伺服器元件混合起來,仍然能夠交互作業。 藉由使用 JMS 傳輸,Enterprise Bean 型 Web 服務的用戶端和伺服器可以透過 JMS 佇列和主題來通訊,不用透過 HTTP 連線。

已淘汰的特性 已淘汰的特性: 在舊版應用程式伺服器中,支援 Java API for XML-Based RPC (JAX-RPC) 應用程式使用 IBM® 專用 SOAP over JMS 通訊協定。 現在,在 WebSphere® Application Server 7.0 以及更新版本中,已淘汰這個專用 SOAP over JMS 通訊協定,改用新興的產業標準 SOAP over JMS 通訊協定。 您可以將 IBM 專用 SOAP over JMS 通訊協定用於 Java API for XML Web Services (JAX-WS) 或 JAX-RPC Web 服務;不過,請利用新興的標準 SOAP over JMS 通訊協定。 如果您的用戶端應用程式會呼叫舊版 WebSphere Application Server 所支援的 Enterprise Bean 型 Web 服務,您就必須繼續利用 IBM 專用 SOAP over JMS 通訊協定來存取這些 Web 服務。depfeat
The benefits of using JMS include:
  • Reliable messaging transport for communicating request and response messages.
  • Flexible one-way requests for clients and servers. For example, the server does not have to be active when the client sends the one-way request. Simultaneous one-way requests can be sent to multiple servers through the use of a topic.
  • Synchronous two-way requests are supported for both Java API for XML-Based Web Services (JAX-WS) and Java API for XML-based RPC (JAX-RPC) clients.
  • Asynchronous requests are supported for JAX-WS clients.

The SOAP over JMS specification defines a JMS endpoint URI syntax for specifying JMS destinations. A JMS endpoint URL is used to access JAX-WS or JAX-RPC web services with the JMS transport. This URL specifies the JMS destination and connection factory, as well as the port component name for the web service request. This endpoint URL is similar to the HTTP endpoint URL, which specifies the host and port as well as the context root and port component name.

Procedure

  1. Develop the enterprise bean that you intend to use as your service implementation bean.
  2. For JAX-WS applications, add the @BindingType annotation to your endpoint implementation class and specify the SOAP over JMS binding id for your endpoint. For example:
    @WebService 
    @BindingType("http://www.w3.org/2010/soapjms/")
    public class MyServiceBeanImpl {
        ...
    }

    The @BindingType annotation is used to indicate the protocol (SOAP) and transport (JMS) to be used when sending request and response messages for the endpoint.

  3. Assemble the enterprise beans.
    1. Assemble a JAR file that is enabled for web services from an enterprise bean. You can assemble the artifacts that are required to enable the enterprise beans module for web services into a Java archive (JAR) file.
    2. Assemble a web services-enabled enterprise bean JAR file into an enterprise archive (EAR) file. You can assemble the artifacts that are required to enable the web services-enabled JAR file into an EAR file.
  4. Enable the enterprise beans-based endpoints by using the endptEnabler command. Use the -transport jms option to request that the endptEnabler command create a message-driven bean (MDB) listener for each Enterprise JavaBeans (EJB) JAR file that contains web services implementation beans. This message-driven bean serves as a listener for requests that are associated with the web service endpoints contained in the EJB JAR file.
  5. Decide on the names and the types of the JMS objects that your application uses.

    Before you install your application, you need to:

    • Decide whether your web service receives requests from a queue or a topic.
      • Decide whether to use a secure destination or a nonsecure destination.
      • Decide the names for your queues and topics, connection factory and activation specification.
    Use the following guidelines for deciding JMS object names and types. In typical situations, you can use a queue for receiving web services requests.
    • Queue
      • A queue receive all types of requests. Valid requests include one-way, two-way, and synchronous. Asynchronous requests are only valid with JAX-WS web services.
      • A queue is used only by a single EJB JAR file for receiving the requests for web services endpoints contained within that EJB JAR file.
    • Topic
      • A topic is used to receive only one-way requests.
      • You can share a topic among multiple EJB JAR files. Each request message that is sent to a topic is processed by each of the MDB listeners that are configured to listen on that topic. This means that each request message is processed by each EJB JAR file associated with that specific topic.

    The following example describes a typical configuration for a single EJB JAR file containing web services endpoints:

    • Suppose the EJB JAR file is StockQuoteEJB.jar and contains one or more web services endpoints related to the StockQuote service.
    • You have a single queue, StockQuote_Q, with the JNDI name, jms/StockQuote_Q, that is used to receive requests.
    • You have a connection factory, StockQuote_CF, with JNDI name, jms/StockQuote_CF, that can be used by clients to connect to the JMS provider.
    • You also have a connection factory, StockQuote_ReplyCF, with JNDI name, jms/StockQuote_ReplyCF, that is used by the MDB listener for the EJB JAR file to connect to the JMS provider when sending reply messages.
    • You have an activation specification, StockQuote_AS, with JNDI name, jms/StockQuote_AS, that is used to associate the StockQuoteEJB.jar's MDB listener with the queue named StockQuote_Q.
  6. Define the JMS administered objects.

    After you decide on the names and types of the JMS objects, use the administrative console or the wsadmin scripting tool to define the JMS objects. There are multiple ways to administer JMS resources depending on what type of JMS provider is being used. Read about choosing a messaging provider to learn more about administering JMS resources.

  7. Deploy the web services application.
    During the installation process you are prompted for two types of information for each enterprise bean JAR file that is enabled for web services and is contained in your EAR file:
    • The JNDI name of the connection factory that is used by the MDB listener to use for sending reply messages.

      If your web service contains two-way operations, the MDB listener that is defined by the endptEnabler command needs to access a queue connection factory to add a reply message to the reply queue. The MDB listener uses a resource environment reference of java:comp/env/jms/WebServicesReplyQCF. Therefore, during the application installation process, you must provide the actual JNDI name of the connection factory for the MDB listener to use for that web service. Using the previous example, the JNDI name is jms/StockQuote_ReplyCF.

    • The name of the activation specification for the MDB listener to use.

      An activation specification is an object that is used to associate a JMS connection factory with a JMS destination (queue or topic). When deployed, an MDB is configured with the correct activation specification so that messages from the queue or topic are properly delivered to the MDB. During deployment, you can modify the name of the activation specification that is associated with each MDB listener. The activation specification name contained in the input EAR file is displayed as a default value. If you specify the correct activation specification name to the endptEnabler command, you can accept the default value. Otherwise, enter the correct activation specification name.

  8. Decide whether to use the new industry standard SOAP over JMS protocol or the IBM proprietary SOAP/JMS protocol.
    最佳作法 最佳作法: It is a best practice to use the industry standard SOAP/JMS protocol. The IBM proprietary SOAP/JMS protocol has been deprecated with this release. However, if your application needs to interoperate with previous versions of the product, then use the proprietary protocol.bprac
    • If you use the industry standard SOAP over JMS protocol, use the Configure endpoint URL information for JMS bindings task to specify a JMS endpoint URL prefix that adheres to the JMS endpoint URI syntax that is associated with the standard; for example:
      jms:jndi:jms/StockQuote_Q&jndiConnectionFactoryName=jms/StockQuote_CF
    • If you use the IBM proprietary SOAP over JMS protocol, use the Configure endpoint URL information for JMS bindings task to specify a JMS endpoint URL prefix that adheres to the IBM proprietary SOAP over JMS protocol; for example:
      jms:/queue?destination=jms/StockQuote_Q&connectionFactory=jms/StockQuote_CF
  9. (Optional) Configure endpoint URL information for JMS bindings.

    Use the administrative console to configure a JMS endpoint URL prefix that you can associate with each EJB JAR module in your application. The WSDL publisher uses this partial URL string to produce the actual JMS URL for each port component that is defined in the enterprise bean JAR file. The clients that need to invoke the web service can use the published WSDL file.

    Perform this step only if you are publishing the WSDL file for your application.

  10. (Optional) Publish the WSDL file for your application.

    Publishing the WSDL file, this produces WSDL documents that you can use to develop your client applications. The publishing process produces fully-resolved endpoint location URLs within the WSDL files.

    Perform this step only if the published WSDL files are needed to develop your client applications.

Results

You have a web service that is configured to use SOAP over JMS to transport the requests.

What to do next

Develop a web services client.


指出主題類型的圖示 作業主題



時間戳記圖示 前次更新: July 9, 2016 11:18
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twbs_soapjmstransportwbs
檔名:twbs_soapjmstransportwbs.html