This article shows you how to connect non-SOAP HTTP service requesters and providers to the IBM WebSphere Application Server V6 Service Integration Bus. This lets requesters and providers leverage the integration capabilities of an enterprise service bus.

Last month's article shows you how to connect non-HTTP service requesters and providers to the IBM WebSphere Application Server V6 Service Integration Bus. This lets requesters and providers leverage the integration capabilities of an enterprise service bus. In this continuation we pick up at Listing 4.

Listing 4 shows the details of the sendJMSMessage() method for the servlet. It creates a JMS bytes message and, if appropriate, inserts the HTTP payload into the body of the bytes message. It then sets the HTTP method in an application-specific JMS property. Next the method inserts any HTTP headers and parameters into the message as application-specific properties in the JMS message. Note that the names used for the JMS properties are derived from the HTTP header or parameter names; the names are given a prefix that should make them unique and distinguish the headers from parameters; also the utility function XMLHTTPUtil.fixName() replaces any dash characters in a name with underscore characters. The method also puts pathInfo from the HTTP request into the JMS message as an application-specific JMS property. Finally the method sends the message to the request queue. Once the message is sent, sendJMSMessage() forms a JMS message selector that tests whether the correlation ID of an incoming response message equals the message ID of the outgoing request message, which supports correlation of the response with the request.

Listing 5 shows the details of the getJMSResponse() method for the servlet. It creates a consumer listening for a message with the selector that correlates the response to the request, as discussed above. The method then places information from the response into an HTTPOutput instance, including the HTTP status code, the response body and any response headers. Note that getJMSResponse() removes the a prefix from the returned HTTP headers.

Listing 6 shows the skeleton for the MDB that forms the off-ramp. When the MDB gets created, the ejbCreate() method creates all of the JMS resources required; in this case, the connection factory, the reply queue and the connection. These exist until the MDB is destroyed. At that time, the ejbRemove() method closes the connection, which releases all the JMS resources.

The ejbCreate() method also determines the root URL used to form the new outbound HTTP request. In the code show in Listing 6, the default value is derived from an EJB environment variable set in the deployment descriptor of the EJB module containing the MDB. The default value could be over-ridden by setting a new JMS property in some mediation that runs in the SIBus; however, over-riding is not implemented in this example.

Listing 7 shows the details of the onMessage() method of the MDB. The method first retrieves the information about the original HTTP request from the incoming JMS message, including the request body, the HTTP parameters and headers, the HTTP "infoPath" and the HTTP method. Note that HTTP headers and parameters are distinguished by the prefix on the JMS property names. The HTTP parameters are added onto the root URL set in the ejbCreate() method. The onMessage() method then calls the private sendHTTPRequest() method to send the new HTTP request and wait for the response.

After receiving the HTTP response, the onMessage() method extracts the HTTP response information and puts it in a JMS message sent to the reply queue. This message includes the response status, any headers and the body, as needed. The headers must have the names converted, as described above. Note in particular that the method sets the correlation ID of the JMS message to the message ID of the incoming request to support correlation of the response with the request in the servlet. The method then sends the JMS message to the reply queue.

Listing 8 shows the details of the sendHTTPRequest() method of the MDB. The method inserts the headers, the body and the HTTP method into the request. The outgoing HTTP request is therefore semantically equivalent to the original HTTP request except for the root URL. The method sends the HTTP request to the target provider and waits for the HTTP response.

Once it receives the HTTP response, the sendHTTPRequest() method extracts the response and puts it into an instance of HTTPOutput. The instance contains the status code, and may also contain headers and a body. Note that if there is an error in the HTTP response from the provider, the attempt to get the HTTP response InputStream causes an exception. In that case, the HTTPOutput instance contains only the HTTP status code.

Configuration
In Figure 4, you can see that two SIBus queue destinations need to be created for the ESB to support XML/HTTP in the manner described in this article. The two queues, one for the request and one for the response, must be exposed as part of a JMS provider. In particular, you need to create a JMS connection factory for your SIBus and a JMS queue for both SIBus queues. Since the MDB shown in Figure 4 listens for messages on the request queue, you must also create a JMS activation specification for the request queue. Building an Enterprise Service Bus with WebSphere Application Server V6, Part 3 describes these steps in more detail. In the sample configuration that corresponds to the sample code described above, the JMS connection factory has a JNDI name of jms/MDBCF, the request JMS queue has a JNDI name of jms/MRequest, the response JMS queue has a JNDI name of jms/MReply, and the JMS activation specification has a JNDI name of eis/TestMDBAS.

The servlet references the JMS resources defined above. The deployment descriptor for the Web module containing the servlet must define resource references for the connection factory and both the request and reply queues. In Rational® Application Developer, you can define the resource references on the References tab of the Web project deployment descriptor editor, by entering the JNDI names: jms/MDBCF, jms/MRequest and jms/MReply.

The MDB listens for incoming requests on the request queue and sends responses on the reply queue. To allow the MDB to send the response, the deployment descriptor for the EJB module containing the MDB must define resource references for the connection factory and reply queue. In the Rational Application Developer environment, you can define the resource references for the MDB on the References tab of the EJB project deployment descriptor editor, entering the JNDI names: jms/MDBCF and jms/MReply. To listen for the request, the deployment descriptor for the EJB module containing the MDB must define the JMS activation specification and the request queue resources. In Rational Application Developer, you can define the resource references for the MDB on the Bean tab of the EJB project deployment descriptor editor by entering the JNDI names eis/TestMDBAS and jms/MQ in the WebSphere Bindings area under the JCA Adapter property.

The MDB also uses an environment variable to set the root URL for the outbound HTTP request. The deployment descriptor for the EJB module containing the MDB must define the environment variable. In Rational Application Developer, you can define the environment variable for the MDB on the Bean tab of the EJB project deployment descriptor editor, by entering the appropriate name and value of the environment variable in the Environment Variables area. In our example, the environment variable name is Default_URI_Root.

An example
Listing 9 shows a POST request generated by a non-SOAP HTTP requester that happens to use an XML body. Note that the root URL of the service provider is /XMLHTTP/XMLHTTP2SIB. Therefore, there is an HTTP InfoPath that equals dofuss. There are also two HTTP parameters and several headers, one specifically introduced by the requester (A-FAKE-HEADER).

Listing 10 shows the request sent to the default target identified in the MDB environment. You can see the new root, /FakeXMLHTTPService/FakeService, defined by the EJB environment variable (which also contains the host name and port information). You can also see the InfoPath and HTTP parameters are included, though the syntax is a bit different, as the parameters are out of order. You can see that all the original headers appear in the new request, but again, the syntax is a bit different in that the headers are in a different order. Finally the body appears in the new request identical to the original body. Thus, even though the new request syntax is a bit different, the semantics of the original request are preserved.