There may be an existing MQ JMS or JMS client that you wish to communicate to with your service-oriented architecture (SOA) application. In this task, we will take you step by step through the steps necessary to do this.
There are two main types of information that need to be captured by the MQ JMS binding. One set of information is needed by the service component architecture (SCA). This includes information such as the interface, which we discussed earlier, and the serialization type, which we will discuss later. The other set of information is the configuration needed to communicate using JMS such as the specification of JMS destination objects, which we will also discuss later.
Open the assembly editor of your module. From the import group on the palette, select an export and drag it on to the canvas. An export with no implementation and no interface is created. Right-click the component, select Add Interface from the contextual menu and add the interface created in step 1. Generate the JMS skeleton binding by selecting the component and from the contextual menu select Generate Binding > Messaging Binding > MQ JMS Binding.
You may select the JMS messaging domain as either Publish-Subscribe or Point-to-Point. The consequences of selecting publish-subscribe is that the values for the JMS Destination type will default to use javax.jms.Topic. Similarly, the consequences of selecting point-to-point is that the values for the JMS Destination type will be default to use javax.jms.Queue. You may change these defaults within the wizard. If your interface contains a request-response operation, the wizard will default the JMS messaging domain to point-to-point.
Select if you wish to Configure new messaging provider resources (the default) or Use pre-configured messaging provider resources. If you choose pre-configured, then add the JNDI names for the connection factory and the send destination for a one-way operation, and send and receive destinations for a request-response operation. We chose to configure the messaging resources. With the MQ JMS binding, you must specify the WebSphere MQ queue name for the receive destination and send destination (for request-response operations, which in our case we will be using). The WebSphere MQ queue manager must also be specified. The existing default queue manager is selected by default.
In the Security configuration section, the J2C Authentication Data Entry property lets you specify an authentication alias that should be configured on the server with a userid and password.
You must choose the serialization type that is expected by the JMS client application. The serialization type is used to map between the business object used in your SOA application and the message format expected by the JMS client application. There are several serialization types provided as listed below. For serialization types beginning Simple JMS, you must have previously created the business objects required (see the Prerequisites section of Generating an MQ JMS export binding for a quick way of creating these business objects).
If the JMS client is expecting a different serialization style than those above, select User Defined and specify the appropriate data binding implementation. An example of this different serialization would be if the JMS client is expecting a JavaBean as the payload of a JMS object message, then a user-supplied data binding implementation would be used that would map between the Service Data Object (SDO) and the JavaBean. See Creating a user-defined JMS data binding for an illustration on how this would be done.
For more information on JMS data bindings, see JMS and MQ JMS data bindings.
Lastly, you must specify if you wish to use the default function selector class. Checking this box causes the wizard to use a specific message header property to determine which business method the incoming JMS message is associated with. However, for many cases when you are receiving messages from an existing JMS client, a different convention would be used to determine how to map them to the business methods. If that is the case, you would specify your own function selector class.
The serialization types beginning Simple JMS have their own function selector. See JMS and MQ JMS function selector for more information.
In this task, the JMS client is sending XML in a JMS text message so we chose the appropriate serialization type Business Object XML using JMS TextMessage and will use the default function selector.
Request or response | Connection factory | Send destination | Receive destination | Listener port | Correlation scheme |
---|---|---|---|---|---|
Configuration elements in a request or response | Creates the connection to the messaging provider. | Destination where the message is sent. | Destination where the response message is received. | Port that listens to the request from the WebSphere MQ server | Correlates response messages with request messages in request-response operations. |
Export request | A JNDI name or one created with default settings when the application is deployed. | Not applicable | A JNDI name or the queue name of the WebSphere MQ queue manager. | A name is created on deployment or one that is specified by you. | Not applicable |
Export response | Uses the same connection factory as the request or one that is specified by you. | A JNDI name or the queue name of the WebSphere MQ queue manager. | Not applicable | Not applicable | Adds a request ID to the request message (default) or adds a correlation ID to the request message. |
Select the End-point configuration tab under the Binding tab. Under the Request tab, you can accept the defaults and the tools will create a connection factory when the application is deployed or you can specify a connection factory JNDI name if it has been pre-configured on the messaging provider resource. In our case, we accepted the defaults.
We chose a BINDINGS transport option, which is the default.. With this setting, you do not need to specify host name, channel or port as WebSphere MQ JMS classes will use the Java Native Interface (JNI) to call directly into the existing queue manager API rather than communicating through a network. Bindings is a shared memory protocol and may offer better performance. An alternative is the CLIENT setting, which means you must specify the values for the client configuration including host name, channel and port and optionally the client channel definition table. The WebSphere MQ client connection is used to connect to the queue manager.
Expanding Receive Destination Properties, you can specify a JNDI name or you can accept the defaults, in which case the tools create the properties. Specify the appropriate settings to ensure your SOA application is able to communicate to the JMS client. For this task, we accepted the defaults for the settings but provided the receive destination, which was specified earlier when we created the bindings. The name contains the WebSphere MQ queue name.
The Asynchronous Reliability property can have these values: assured (default) or bestEffort. Select assured if you want a message to persist through a transaction. In other words, if you want guaranteed delivery of the message. Select bestEffort if you want a high throughput of messages and your application can accept and handle the loss of a message, as persistence is not guaranteed. Event sequence required specifies if the same order of events as received from WebSphere MQ must be followed by the component receiving the events.