Using the MSMQ-MQSeries Bridge


If you are familiar with code that writes messages from .NET Framework to MSMQ and have experience of writing JMS code to work with WebSphere MQ, enabling interoperability using the MSMQ-MQSeries Bridge is straightforward.

MSMQ-MQSeries Bridge requires two computers, the first with the following configuration:

  • Windows 2000 or Windows 2003

  • Active Directory

  • MSMQ-MQSeries Bridge

  • MSMQ (with routing support)

  • WebSphere MQ client

The second computer should have Windows 2000 installed as a member server and should be running WebSphere MQ.

You need to configure the computer running WebSphere MQ as the foreign computer in MSMQ. Do this by creating a foreign site under the Services/MsmqServices node in Active Directory Sites and Services, add a new MSMQ routing link to link the local site (usually Default-First-Site-Name) to the foreign site, add the MSMQ computer as the local site gate, and then add the MQ Series computer as a foreign computer to the foreign site.

For more information about the details of configuring MSMQ foreign sites, see “Configuring cross-platform messaging” on TechNet.

For more information about how to configure and use the MSMQ-MQSeries Bridge, see “Chapter 13 — MSMQ-MQSeries Bridge Configuration Guide” on TechNet.

Consider the scenario where you are reading WebSphere MQ messages using JMS. Originally, those messages came from MSMQ and passed over the bridge. In this case, there should be no message consumption problems providing you change the WebSphere MQ JMS configuration. To implement this interoperability scenario, set the Queue Configuration for WebSphere MQ’s targetClient to MQ, not JMS. If you do not make this change, WebSphere MQ expects a JMS headed message, which .NET Framework cannot generate.

Note

Do not configure targetClient on existing queues, because the change may cause existing JMS applications to fail. Always create a new message queue exclusively for interoperability purposes.

In the reverse direction, providing you change the targetClient to MQ, you can generate messages from JMS and then pass them over the bridge and consume them in a .NET Framework application.

Configuring the Message Queues

To enable interoperability through the MSMQ-MQSeries Bridge, you need to create two queues for each direction in which you want to send messages. You need to define local queues for receiving messages and remote queues for sending messages. You also have to configure the bridge correctly.

Figure 9.3 shows how you might set up two queues for each direction you want to send messages between .NET Framework and Java.

click to expand
Figure 9.3: Logical representation of the MSMQ-MQSeries Bridge connecting MSMQ and MQ Series

Start by defining the MSMQ queues. You add a local queue to the computer running the bridge and a remote queue on the foreign computer.

Next, using the MSMQ-MQSeries Bridge Manager, you add a MQI channel which points to the computer running WebSphere MQ. This creates four message pipes, two transactional and two non-transactional, that route messages between the two queuing systems. After you have created these, you need to export both the client and server definitions. Copy these files to the WebSphere MQ computer, and then import them using the runmqsc command. This command configures the transmission queues and keeps the channels synchronized across the bridge.

The next step is to create a local and remote queue in WebSphere MQ. Configure the remote queue to point to the MSMQ queue through the bridge. Do this by configuring the remote queue manager name and transmission queue name to point to the objects that the import created.

Finally, you need to copy the WebSphere MQ Client Channel Table file from the computer running WebSphere MQ to the MSMQ computer and configure the MQCHLLIB and MQCHLTAB environment variables to point to this file.

Selecting a Data Format

When sending messages on queues using the MSMQ-MQSeries Bridge, you must ensure that the receiving end can consume the message data. The only realistic way of sending complex data between J2EE and .NET Framework is to serialize the data into an XML-formatted string. Additionally, WebSphere MQ supports sending TextMessages, where you load up the body with a string containing the XML data you want to send. MSMQ also allows you to send simple messages containing an XML-formatted string.

Note

It is not feasible to use other data types because of binary serialization differences between .NET Framework and J2EE as discussed in Chapter 3, “Interoperability Fundamentals.”

Creating the Message Consumer

This guide has already covered how the Message Consumer is an application that you create to poll and read messages from a queue and place them into the resource fa ade. Because you are using the bridge, you work with XML-formatted strings. Therefore, you have to reconstruct the data from the XML string before you can use it to call methods on the resource fa ade. The next two sections consider how to do this on the two platforms.

Creating the .NET Framework Message Consumer

As described in Chapter 5, “Interoperability Technologies: Resource Tier “the .NET Framework message consumer reads from an MSMQ queue. After you read the contents of the message you must reconstruct the data. For techniques about how to do this, see the “Web Services” section of Chapter 7, “Integrating .NET in the Presentation Tier.”

The following code sample shows how to read a message from MSMQ and the data you use to build the correct .NET Framework data type.

 MessageQueue q = new MessageQueue(_queueName); q.Formatter = new XmlMessageFormatter( new Type[] {typeof(String)} ); Message order = q.Receive(0); string xml = (string) order.Body(); StringReader sr = new StringReader(xml); OrderData ds = new OrderData(); // Load result string back into an OrderData-typed DataSet ds.ReadXml(sr); 

Note

The preceding sample uses the OrderData custom data type from XBikes. However, the XBikes application does not implement this code.

Creating the J2EE Message Consumer

The J2EE message consumer reads from WebSphere MQ, which you can build using either the MQI Java classes or JMS. After you read the message, you have to reconstruct the Java data from the XML string. For techniques about how to do this, see the “Web Services” section of Chapter 8, “Integrating .NET in the Business Tier.”

The following code sample shows how you can read a message from WebSphere MQ and the data you use to build the correct J2EE data type.

 String connectionName = "XBikesQFC"; InitialContext ic = new InitialContext(); QueueConnectionFactory factory =        (QueueConnectionFactory) ic.lookup(connectionName); QueueConnection connection = factory.createQueueConnection(); QueueSession session = connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE); Queue queue = (Queue) ic.lookup(queueName); QueueReceiver receiver = session.createReceiver(queue); connection.start(); TextMessage message = (TextMessage) receiver.receive(); String orderXML = message.getText(); OrderData order = OrderConverter.stringtoOrderData(orderXML); DalServiceFacade facade = getFacadeHome().create(); return facade.saveOrder(order); 

Note

The preceding sample uses the OrderData custom data type, and the OrderConverter class from XBikes. However, the XBikes application does not implement this code.

Creating the Interoperability Adapter

Following the techniques already discussed in this guide, it is recommended that you create an asynchronous interoperability adapter to provide access to the asynchronous communication channel. This adapter serializes the data for the message into an XML formatted string.

Creating the .NET Framework Asynchronous Interoperability Adapter

The .NET Framework application sends a message to MSMQ, so you can use the .NET Framework classes to do this, as discussed in Chapter 5. Because the final destination of the message is to WebSphere MQ, you must write the message as a string.

If you are using datasets, you can extract the XML using the GetXml() method. You can then place the XML string in the MSMQ message queue as the following code example shows.

 string xml = order.GetXml(); MessageQueue q = new MessageQueue(_queueName); q.Send(xml); 
Note

The preceding sample uses the OrderData class from the order object that appears in the XBikes application. However the XBikes application does not implement this code.

Creating the J2EE Asynchronous Interoperability Adapter

The J2EE application sends a message to WebSphere MQ, so you can use the JMS classes (or MQI) to send the message. Again, because the final message destination is MSMQ, you must create a string message rather than writing an object.

For the background and code for serializing Java data to an XML string, see the “Web Services” section of Chapter 7. To send the message, you can use JMS code similar to the following example.

 InitialContext ic = new InitialContext(); QueueConnectionFactory factory =     (QueueConnectionFactory) ic.lookup("XBikesQCF"); QueueConnection connection = factory.createQueueConnection(); QueueSession session =     connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE); Queue queue = (Queue) ic.lookup("XBikesQ"); QueueSender sender = session.createSender(queue); sender.setDeliveryMode(DeliveryMode.NON_PERSISTENT); sender.setPriority(4); sender.setTimeToLive(0); connection.start(); // Use a text message TextMessage message = session.createTextMessage(); // Convert the order to a string String sorder = OrderConverter.orderListDataToString(orderObject); message.setText(sorder); sender.send(message); 

Note

The preceding sample uses the OrderData and OrderConverter classes from XBikes. However, the XBikes application does not implement this code.

Now that how to implement the MSMQ-MQSeries Bridge has been described, it is time to look at runtime bridges for asynchronous interoperability.




Application Interoperability. Microsoft. NET and J2EE
Application Interoperability: Microsoft .NET and J2EE: Microsoft(r) .Net and J2ee (Patterns & Practices)
ISBN: 073561847X
EAN: 2147483647
Year: 2003
Pages: 104

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net