Application Management

Digg This!

Page 1 of 2   next page »

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.

IBM's WebSphere Application Server V6 (hereafter called Application Server) provides a platform for building an Enterprise Service Bus (ESB). Building an Enterprise Service Bus with WebSphere Application Server V6, Part 1: Introduction to WebSphere V6 Messaging Resources is the first part of a series that provides a wealth of information on WebSphere Messaging Resources, also known as the Service Integration Bus, or SIBus, available in Version 6. The SIBus supports many of the integration features required of an ESB. The SIBus ships with mechanisms to connect service requesters and providers that use SOAP/HTTP and Java^TM Messaging Service (JMS).

However, there are many sources of service requesters and providers that don't use SOAP/HTTP or JMS. In this article, we'll talk about requesters and providers that use HTTP as a transport, but don't use SOAP, and may not even use XML as the payload. In some cases, such requesters and providers were developed before SOAP became widespread; in other cases, even for recently developed applications, SOAP is considered too heavyweight. See the Resources section for links to XML-RPC, REST, eBay-REST, eBay-XML and Yahoo to get a look at some non-SOAP mechanisms and applications that use them. Non-SOAP HTTP requesters and providers can be an important part of a service-oriented environment. In this article, you'll learn how to connect such entities to the SIBus. This allows non-SOAP HTTP requesters and providers to benefit from the same integration logic available for SOAP/HTTP and JMS requesters and providers.

Our goal
Figure 1 shows a scenario in which a service requester interacts directly with service a provider via XML/HTTP. This means that the requester uses an XML-encoded payload for the request message sent to the provider and expects an XML-encoded payload as the response message. The requester uses HTTP to deliver the request and receive any response.

Figure 2 shows the scenario we want to achieve, where a requester interacts with a service provider through an ESB that can, for example, log requests, modify requests, or even route requests to a different provider. You'll see later that the payload does not have to be XML.

Figure 3 shows some additional scenarios possible with an ESB. Integration logic in the ESB can transform requests so that XML/HTTP requesters can interact with SOAP/HTTP providers and SOAP/HTTP requesters can interact with XML/HTTP providers. However, in this article, we'll only deal with the scenario shown in Figure 2.

An analysis of the XML/HTTP <==> XML/HTTP scenario shows that the ESB must do the following:

• Receive the XML/HTTP request from the XML/HTTP requester. (At this point, integration logic in a mediation can run to process the request.)
• Send the request to the XML/HTTP provider
• Receive the response from the XML/HTTP provider. (At this point, integration logic in a mediation can run to process the response.)
• Return the response to the XML/HTTP requester

Our solution
Figure 4 shows an ESB topology that performs the steps described above. The figure shows a servlet that acts as an XML/HTTP on-ramp for the SIBus, in a manner very similar to the SOAP/HTTP on-ramp for Web services, called the inbound Web service, that ships with the SIBus. The servlet inserts the request into the SIBus, via the JMS sender, where it can be mediated if necessary, and returns the response to the requester, via the JMS listener. A Message-Driven Bean (MDB) acts as an XML/HTTP off-ramp for the SIBus, in a manner very similar to the SOAP/HTTP off-ramp for Web services, called the outbound Web service, that ships with the SIBus. The MDB sends the request to the XML/HTTP provider, via the HTTP client and inserts the response into the SIBus, via the JMS sender, where it can be mediated if necessary.

Note that to support the spectrum of possible non-SOAP request types, the ESB must preserve the fidelity of the HTTP request and response. In particular, the servlet must deal specifically with the following HTTP methods:

• POST, where the requester sends body content in the request and expects body content in the response.
• GET, where the requester only expects body content in the response.
• PUT, where the requester sends body content in the request, but expects no body content in the response.
• DELETE, where the requester sends no body content in the request, and expects no body content in the response.

In addition, the servlet's JMS sender function inserts the HTTP method, the HTTP path info (part of the URL past the root), the HTTP parameters and the HTTP headers (including cookies) from the HTTP request into a JMS message inserted into the SIBus. For the POST and PUT methods, the JMS sender also inserts the request payload or body (which might be XML) into the JMS message. The JMS sender then sends the message to an SIBus queue destination (the yellow box labeled Request in Figure 4). The servlet then invokes its JMS listener to listen for the response.

The MDB listens for messages arriving on the Request queue. Upon receiving a message, the HTTP client function of the MDB constructs an HTTP request using all the information placed in the request JMS message by the servlet. There is one significant semantic difference between the newly constructed HTTP request and the original HTTP request received by the servlet: the root URL is different so that when the HTTP client sends the request, it goes to the expected provider. The MDB HTTP client waits for the synchronous HTTP response from the provider.

The MDB JMS sender inserts any response payload, the HTTP headers (including Set-Cookie headers) and status code from the HTTP response into a JMS message. The JMS sender also sets the correlation ID of the JMS response message to the message ID of the JMS request message, and then sends the JMS response message to an SIBus queue destination (the yellow box labeled Reply in Figure 4).

The servlet's JMS listener listens for an incoming message on the Reply queue with a JMS selector set to match a response correlated with the request; the correlation ID of the response must be equal to the JMS request message ID. Upon receiving the correlated response message, the JMS listener inserts only the response status code into the HTTP response if the response is not OK. If the response is OK, the JMS listener inserts the response (XML) payload and any headers from the JMS message into the HTTP response. The JMS listener then returns the HTTP response to the original requester.

Implementation
Listing 1 shows the servlet skeleton used for the on-ramp. The init() method gets the JMS connection factory and queues, and starts a connection. The connection is held open for the lifetime of the servlet, and is not closed until the servlet's destroy() method gets called. Configuration information, such as JNDI names, is described in detail in the next section.

Listing 1. Servlet skeleton

public class XMLHTTP2SIB extends javax.servlet.http.HttpServlet
implements javax.servlet.Servlet {

	// connection factory and queue resources
	private final static String

	JMSCF_JNDI_NAME = "java:comp/env/MDBCF";
 	private final static String JMSRequest_JNDI_NAME =

	"java:comp/env/MRequest";
 	private final static String

	JMSReply_JNDI_NAME = "java:comp/env/MReply";
	// session and connection
	private Session session = null;
	private Connection connection = null;
	// request and reply queues
	private Destination requestQueue = null;
	private Destination responseQueue = null;
 

	public void init() throws ServletException	{

	try {

	InitialContext context = new InitialContext();

	ConnectionFactory factory = (ConnectionFactory)

	context.lookup(JMSCF_JNDI_NAME);
	        	requestQueue = (Destination)

	context.lookup(JMSRequest_JNDI_NAME);
	       	responseQueue = (Destination)

	context.lookup(JMSReply_JNDI_NAME);

	connection = factory.createConnection();

	session = connection.createSession(

	false,

	Session.AUTO_ACKNOWLEDGE);


	connection.start();

	} catch (NamingException e) {

	...

	} catch (JMSException e) {

	...

	}
	}

	public void destroy() {

	try {

	connection.close();

	} catch (JMSException e) {
		...

	}
	}
}

Page 1 of 2   next page »