mq Authors: RealWire News Distribution, Charles Rich, Application Security, Daniel Thompson, Kevin Benedict

Related Topics: Java EE Journal, mq

J2EE Journal: Article

Implementing J2EE-.NET Interoperability Using WebSphere MQ

Implementing J2EE-.NET Interoperability Using WebSphere MQ

It is today's reality that most companies are using both J2EE and .NET environments for their software implementation. Until recently, the prevalent solution for integration of these two environments has been HTTP-based Web services.

Although this solution works well in many cases, it suffers from the following drawbacks:
1.  Most implementations today are synchronous and based on the synchronous nature of the underlying HTTP protocol.
2.  Reliable messaging is difficult to implement using HTTP.
3.  Load balancing in an HTTP-based environment requires a client-side load-balancing implementation, which is usually quite difficult when compared to server-side load balancing.
4.  Client and server application life cycles have to be synchronized in order for Web services-based communications to work.

Some of these problems can be easily alleviated by using messaging software that provides guaranteed message delivery, asynchronous communications, and ease of server-side load balancing.

So far, while the J2EE world has standardized on JMS, the .NET world usually relies on MSMQ and MSMQ bridges provided by third-party vendors. The release of the WebSphere MQ support for .NET - SupportPac MA7P ( supportpacs/individual/ma7p.html) - provides a new integration mechanism by using the same messaging middleware on both platforms.

We will discuss a simple interoperability example between a .NET client (via WebSphere MQ SupportPac MA7P) and a J2EE server (using WAS v5). Sample source code is provided for both environments.

Overall Implementation Architecture
The use of message queuing for communications between applications requires the introduction of additional components - queues (see the Queue Manager sidebar) - to serve as a main communication vehicle.

As shown in Figure 1, usage of queuing for application-to-application communication leads to a very loose coupling between applications. In this case applications don't talk to each other, but rather use intermediary queues. The consumer application puts a request message into the (request) queue, which is picked by the producer application actually fulfilling the request. When the request is processed, the producer application puts the result message into the (reply) queue, which is picked up by the consumer application.


Instead of depending on locations and interfaces of participating applications, queue-based communications are dependent only on the format of the messages and the queue names. In this approach, the producer does not need to know who and where the consumer is, and vice versa. It also allows unlimited scalability by providing the ability to add additional producers, all of which will listen on the same queue (see the Queue Clustering sidebar).

As stated above, the drawback of this otherwise very flexible architecture is the necessity for the consumer and producer to agree on the names of the queues they will use. In the simplest implementation, these queue names are hard-coded in both the consumer and producer; the more advanced implementations use configuration files. Although the notion of logical (or alias) queue names versus physical queue names, supported by WebSphere MQ, can further improve the solution by allowing the applications to use logical queue names that are mapped to different physical queue names, this approach still creates a fairly tight coupling between applications and queue names.

JMS, the Java implementation of messaging, overcomes this issue by introducing JNDI for storing information about queues and queue connection factories (queue managers), which allows for centralized control over queue topology. Instead of knowing the names of the queues, components need to know where in the JNDI tree this information is located. A centralized queue repository - usually LDAP based - becomes, in this case, a central point for the infrastructure configuration, allowing for queue topology changes without impacting code implementation.

Additionally, the message sender has the ability to take advantage of the notion - standardized by JMS (native to MQ) - of "Reply-to" queues, which allows it to specify the queue in which it wants to receive replies. This provides even more flexibility for overall queue-based communications.

Both JMS and WebSphere MQ provide support for two types of queues:

  • Permanent queues: Queues created as part of the infrastructure; these queues exist regardless of whether or not the application exists.
  • Temporary queues: Queues created by the application as part of its execution. Temporary queues can be either explicitly deleted by the application, or can be deleted by WebSphere MQ automatically when the application disconnects from the MQ server.

    Request queues are usually permanent queues because they are used for initializing communications and therefore have to be known by both parties. As for the reply queue, in this case either type can be used. When choosing permanent versus temporary queues, the following should be considered:

  • Temporary queues don't require infrastructure creation and maintenance for the applications to communicate correctly. Adding more client applications does not require any infrastructure activities.
  • Temporary queues require a better programming discipline from the client implementation; creation of temporary queues for each request may overwhelm the queue managers and lead to worse overall performance.
  • In the WebSphere MQ environment, the overall system health is often determined by monitoring the communication queue depth. It is usually much more difficult to monitor temporary queues than it is to monitor permanent queues.
  • Usage of temporary queues might not be applicable in the case of asynchronous communications because the queue could be destroyed before the reply comes back from the server. If the system needs to support both synchronous and asynchronous communications, usage of temporary queues will usually lead to duplication of the overall MQ infrastructure.

    Based upon the above considerations, we chose permanent queues for our implementation.

    Figure 2 shows multiple consumers, each of which can invoke any of the producers. The sequence of steps for the consumer application is as follows:


    1.  Query LDAP to retrieve reply queue (specific to the consumer application) information using, for example, the consumer name. This queue will be used by the consumer application to receive replies from all producers.
    2.  Query LDAP to retrieve request queue (specific to the producer application type) information using, for example, the producer name.
    3.  Place a request message on the request queue. If a reply is expected, the consumer's reply queue is placed in the "Reply-to" field of the message.
    4.  Retrieve the reply (if required) from the reply queue.

    The sequence of steps for the producer application is as follows:
    1.  Query LDAP to retrieve request queue (specific to the producer application type) information using, for example, the producer name.
    2.  Listen on the request queue for all incoming requests. In the case of "cloned" producers, all of them are competing for the message on the same queue.
    3.  Process the received message.
    4.  Check the "Reply-to" field of the request message and if a reply destination is specified, send a reply to the appropriate queue.

    The above architecture allows a very simple implementation for both failover and load balancing. It also allows consumers to define their own programming model (request/reply versus "fire and forget") without impacting the producer implementation. The producer implementation should always be prepared to send the reply back, whereas the consumer implementation dictates the actual interaction model.

    The last issue that must be resolved for queue-based communications is the format of the messages. WebSphere MQ supports a multiplicity of message formats, including object, binary, map, and text messages. For queue-based communications between applications implemented in different languages and different operating systems, text messages (the least common denominator) are usually used as the messaging format. Combined with XML, text messaging provides a very powerful mechanism for interapplication communications.

    For our example we used the architecture shown in Figure 3. We developed a request/reply consumer implementation in C# on the .NET platform, using IBM's SupportPac MA7P. The producer was implemented using message-driven beans (MDBs) in WebSphere Application Server 5. Both the consumer and the producer use IBM's Directory Server 5.1 to access queue/queue manager information. While our simple example uses text messaging, we recommend XML-based messaging for production implementations.


    Setting Up the Execution Environment
    When setting up a WebSphere MQ environment, we first decide on a client/server connection to the WebSphere MQ server. The client connection is implemented using TCP/IP-based communication with the WebSphere MQ server via a connection channel. The server connection directly binds executable code with the server software running on the same machine. Direct binding leads to better overall performance and transactional support but requires installation of the WebSphere MQ server on every machine participating in MQ interactions and thus usually leads to the use of MQ clustering. The client connection requires only WebSphere MQ client installation but leads to some performance degradation and worse overall quality of service due to additional TCP/IP communications with the server (sharing of the client connection channels leads to a further performance degradation).

    The three connection options supported by the .NET implementation are implicit server binding, implicit client binding, and explicit client binding. The type of implicit binding (client/server) depends on the software installed on the given machine as checked by the WebSphere MQ implementation. In the case of the client connection, at least an address and port of the server machine must be specified in the MQEnvironment class for the connection to work. Explicit client connection allows overwriting of default behavior by specifying a server connection string (machine name/port number pair) and channel name. When using the MQ connection API, if both parameters are null, an implicit connection takes place. In our implementation we use the explicit connection APIs, thus supporting all possible connection options controlled by the input parameters.

    J2EE supports the same three connection options, controlled by the definition of the queue factory object in the JNDI.

    For our simple example, we installed WebSphere MQ server, a .NET client, and WAS 5 on a single machine. This installation uses server bindings for both .NET and Java.

    Administrating the WebSphere MQ Objects
    For our example only a handful of WebSphere MQ objects in the LDAP tree need to be defined:

    • The queue manager that is shared between the consumer and provider applications
    • The provider queue (request queue)
    • The consumer queue (reply queue)
    The logical LDAP architecture shown in Figure 4 is designed to support both our and more complex deployments.

    As seen in Figure 4, the logical LDAP architecture allows for multiple consumers and producers. Each consumer/producer is defined by the queue (request for producers and reply for consumers) and queue manager it connects to. This allows every application in the system to bootstrap with the proper MQ information (as long as it knows its own name and functionality). This also allows consumer applications to refer to the required producer applications by their respective application names and resolve queue information using LDAP.


    The logical layout maps to our physical layout by mapping queue names onto two different physical queues (PRODUCER.IN and CONSUMER.IN) and mapping two logical queue managers into a single physical queue manager, QM1.

    WebSphere MQ object creation is done using the JMSAdmin tool. A full overview of this utility can be found in the WebSphere MQ manual, Using Java (

    References to WebSphere MQ objects (such as queue manager and queues) are stored in the directory as Java objects. Each object stores the information needed to locate and communicate with a specific WebSphere MQ element. The objects required for our application were defined through the following steps:
    1.  Define a JMSAdmin configuration file to point to the LDAP directory. A typical configuration file includes information related to the directory access method (file-based, LDAP-based, or WebSphere AppServer- based), the directory URL, and the credential. A sample JMSAdmin configuration file is presented in Listing 1.
    2.  Use a script (see Listing 2) to automate the object creation process. Although the same queue manager is used for both the consumer and producer, they are defined slightly differently:

    • Normal queue manager for consumer
    • Transactional queue manager for the producer (MDB requirement)
    Once the script is executed, the LDAP tree should look like the one shown in Figure 5.


    We have discussed the reasons for using WebSphere MQ for a J2EE-.NET interoperability overall implementation architecture and environment setup. In the second part of this series we will discuss implementation of the proposed architecture on both the J2EE and .NET platforms.

    Queue Managers
    WebSphere MQ introduces the notion of queue managers. Queue managers play a vital role in the WebSphere MQ framework, as they are not only responsible for the management of the queues but also for the routing of messages from consumers to providers. To use a queue, the consumer/ provider needs to connect to the queue manager first; it then is allowed access to the queue. In JMS, this is done by establishing a connection with a queue connection factory, which enables the creation of a sender/receiver and allows access to the queue. A full description of the queue manager responsibilities can be found at

    Queue Clustering
    The architecture described in this article can be further improved by the use of the queue-clustering capability provided by WebSphere MQ. Clustering enables the physical distribution of the providers by using the same queue name on clustered queue managers. WebSphere MQ is then responsible for handling the routing and load balancing of messages to instances of the queue. By default, the round-robin algorithm is used for load balancing.

  • More Stories By Boris Lublinsky

    Boris Lublinsky is an Enterprise Architect at CNA Insurance where he is involved in design and implementation of CNA’s integration strategy, building application frameworks and implementing service-oriented architecture for the company Prior to this he was Director of Technology at Inventa Technologies, where he was overseeing and actively participating in engagements in EAI and B2B integration implementations and development of large-scale web applications. While a Technical Architect at Platinum Technology and SSA, Boris was involved in component-based systems development and design and implementation of execution platforms for component-based systems. In all, he has over 25 years experience in software engineering and technical architecture.

    Comments (1)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.