Using Host Integration Server 2000

This chapter has described how both MSMQ and IBM WebSphere MQ can enable asynchronous interoperability between .NET Framework and Java clients and you can connect Java clients to MSMQ or .NET Framework clients to WebSphere MQ. However, there are several drawbacks to each technique such as the loss of reliable operations or transactional support.

An alternative way to implement asynchronous connectivity between .NET Framework and Java applications is by linking MSMQ and WebSphere MQ through the use of a bridge. In this approach, the .NET Framework application connects to MSMQ and the Java application connects to WebSphere MQ. You then use a bridge to connect the two queues. Figure 5.12 shows a high-level view of this approach using the MSMQ-MQSeries Bridge that is part of Microsoft Host Integration Server (HIS) 2000.

Figure 5.12: Using the MSMQ-MQSeries Bridge in HIS 2000 to enable asynchronous interoperability

HIS evolved from Microsoft SNA Server and enables organizations to connect Windows and LAN-based networking to host-based mainframe equipment. Most importantly from the interoperability perspective, HIS provides an MSMQ-MQSeries Bridge. By using the native message queue implementations, the bridge guarantees reliability and transactional message queue qualities.

For more information about HIS, see the Host Information Server Web site.

Bridging MSMQ and WebSphere MQ with HIS 2000

The MSMQ-MQSeries Bridge gives HIS the capacity to exchange messages in either direction between MSMQ and WebSphere MQ components. HIS can take messages from MSMQ queues and deliver them to WebSphere queues and back again.

Note

The MSMQ-MQSeries Bridge works with IBM WebSphere MQ, even though the bridge product name refers to MQSeries.

The MSMQ-MQSeries Bridge system contains two main components:

• MSMQ-MQSeries Bridge — Converts and transmits messages between the MSMQ and MQSeries environments.

• MSMQ-MQSeries Bridge Manager — Lets you configure, monitor, and control the messaging traffic through the MSMQ-MQSeries Bridge.

The MSMQ-MQSeries Bridge maps the fields or properties of a message to the corresponding fields or properties of the destination message queuing system. For example, if you send a message from WebSphere MQ to MSMQ, MSMQ-MQSeries Bridge analyzes the fields of the WebSphere MQ message and maps each value to its MSMQ counterpart.

In cases where one system needs an additional field that does not exist in the other, MSMQ-MQSeries Bridge provides the field during the conversion process. For example, suppose that a MSMQ message includes the PROPID_M_TIME_TO_BE_RECEIVED property with a specific value. The MSMQ MQSeries Bridge maps this property to the MQMD.Expiry WebSphere MQ property and multiplies the value by 10 to change the units from seconds to tenths of seconds.

Note

The MSMQ-MQSeries Bridge does not restrict the content of a message. The message body can contain its own internal structure, which only the sending and receiving applications recognize. The MSMQ-MQSeries Bridge does not interpret this structure in any way.

For detailed information about how the MSMQ-MQSeries Bridge maps and converts properties from Message Queuing to WebSphere MQ and from WebSphere MQ to Message Queuing, see the “Microsoft Host Integration Server 2000 Developer’s Guide” on MSDN.

Formatting Messages

The MSMQ-MQSeries Bridge in HIS 2000 enables you to exchange messages between MSMQ and WebSphere MQ. However, as Chapter 3, “Interoperability Fundamentals,” discusses at length, mere message exchange does not guarantee interoperability.

You now know that the MSMQ-MQSeries Bridge does not manipulate the contents of a message as it is passes between the two queuing systems. Hence it is up to you to ensure that messages are in a common format that both the .NET Framework and Java applications understand.

To ensure that messages exchanged through the MSMQ-MQSeries Bridge are in a common format, you need to understand how .NET Framework and Java applications send and receive messages to their respective queues, starting on the .NET Framework side.

When a .NET Framework client sends an object to a MSMQ queue, either a binary or XML formatter serializes the contents of the object. Likewise, when a .NET Framework client receives a message, it expects the message to be serialized in either binary or XML format.

Java handles sending and receiving messages to or from a queue differently from the .NET Framework. A Java client can send messages to a WebSphere MQ queue using either the native WebSphere MQ API or JMS. If the client uses the WebSphere MQ API, the object travels as a simple byte stream rather than in serialized form.

Note

JMS also sends the object as a byte stream, but wrapped with additional JMS header information.

Sending Messages from .NET Framework to Java Applications

You can choose whether a .NET Framework client uses a binary or XML serializer when sending messages to MSMQ. However, Chapter 3, “Interoperability Fundamentals,” described how the binary serializers in the .NET Framework and Java are incompatible. Therefore, when sending a complex data type object to MSMQ for transferring to WebSphere MQ and a Java client, the .NET Framework client should only use the XML formatter.

The message that the Java client receives from WebSphere MQ consists of a string object containing the serialized XML representation of the original .NET Framework object. Using the techniques described in Chapter 3, “Interoperability Fundamentals,” the Java client must then interpret this string as XML, and de-serialize it into a matching object in Java. This process assumes that the data type object that the .NET Framework client side passes derives from the same common XML Schema as the one in Java. It is up to you to de-serialize the received object in the Java client correctly, as described in Chapter 3, “Interoperability Fundamentals.”

Sending Messages from Java to .NET Framework Applications

As discussed earlier, messages sent to a WebSphere MQ queue using JMS include additional header information. Unfortunately, the .NET Framework does not understand this information. Therefore, if you want to send messages to a .NET Framework application, your Java client should use the native WebSphere MQ API or, if using JMS, set the target client to MQ.

In addition, because the WebSphere MQ API does not serialize messages that Java clients place into the queue, the Java client needs to serialize the object into XML format before sending it. You can accomplish this using the techniques in Chapter 3, “Interoperability Fundamentals.” This ensures that the .NET Framework client can de-serialize the XML formatted message it receives back into an object.

Implementing the MSMQ-MQSeries Bridge

There are several requirements for implementing the MSMQ-MQSeries Bridge. This section provides an overview of these requirements, and the architecture required to set up the bridge.

Note

For detailed instructions about setting up and configuring the bridge, consult the HIS 2000 product documentation.

The MSMQ-MQSeries Bridge requires an instance of Microsoft Active Directory to be in place to function properly. This dependency springs from how the MSMQ MQSeries Bridge works.

From MSMQ to WebSphere MQ, the MSMQ-MQSeries Bridge picks up messages from public queues published in Active Directory. These queues exist in a defined foreign site. The bridge then delivers the messages to a nominated queue on WebSphere MQ.

The reverse path involves the bridge picking up messages from the nominated WebSphere MQ queue and delivering them to a public MSMQ queue. Because you can only define foreign sites and public queues in Active Directory, operation of the bridge requires that you have Active Directory installed and configured.

You install the MSMQ-MQSeries Bridge on a computer running Windows 2000 or Windows Server 2003 that acts as a connection point between the networks. You must install a MSMQ routing server on the same computer as MSMQ-MQSeries Bridge, and this computer must be able to connect by a TCP/IP or LU 6.2 link to an MQSeries Queue Manager.

You must install WebSphere MQ on a Windows server to use the bridge to connect to MSMQ. This could be seen as a complicating factor if your existing WebSphere MQ implementation is on another operating system. One of the reasons for this requirement is to ensure that authentication works by enabling the computer hosting WebSphere MQ to participate in the same Active Directory forest. However, you can work around this issue by setting up a computer running Windows and WebSphere MQ, installing the bridge component, and configuring that computer to link automatically to the queues in your existing non-Windows environment.

In a test environment, you could run the MSMQ-MQSeries Bridge on the same computer as WebSphere MQ. However, this is not recommended in production. The computer running the bridge must either be a member server in an Active Directory domain (production environments) or a domain controller (test environments only).