Introduction

This article provides an overview of the IBM® Message Service API, which is known informally as XMS. By the end of this article, you should understand what XMS is, what it can do for you, and when it is appropriate to use XMS for your messaging projects.

You should have some familiarity with message-oriented middleware concepts such as point-to-point and publish/subscribe (pub/sub) messaging. For a good introduction to some of these concepts see J2EE pathfinder: Enterprise messaging with JMS.

Back to top

XMS Features

XMS is a programming API available in several languages that provides simple and consistent access to IBM messaging servers. These servers include WebSphere® MQ, WebSphere Business Integration Message Broker, and the default messaging provider in WebSphere Application Server V6. XMS offers the following features:

Point-to-point and pub/sub messaging

Like JMS, XMS provides integral support for point-to-point and pub/sub messaging, the two generally recognised messaging styles in the enterprise messaging arena.

In point-to-point messaging, applications communicate by putting messages out to queues and receiving messages from queues. A message is typically delivered only once.

In pub/sub messaging, publishing applications publish messages on topics, and subscriber applications receive those messages after registering an interest in the topic. An intermediary broker ensures that all subscribers to a topic receive the messages published on that topic.

XMS and JMS reduce the complexity of pub/sub messaging by hiding the way that the underlying messaging provider makes publications or registers subscriptions. An application programmer need not learn the inner workings of different messaging providers, but instead simply sends or receives messages to or from topics.

Cross-language programming API

The XMS API provides a consistent programming model across multiple languages by offering a common set of high-level classes to perform messaging operations. The programming model is based closely on the "unified domain" defined in the JMS 1.1 API Specification.

The blue boxes in Figure 1 below show the main classes or entities that are implemented by the XMS API interface. The grey boxes represent the domain specific classes in JMS 1.02 that are not implemented by XMS.

Synchronous/asynchronous delivery

XMS offers a choice of synchronous and asynchronous styles for receiving messages.

To get a message synchronously, an application calls the receive() verb, which returns a message if one is available.

To get messages asynchronously, an application registers a MessageListener object (or callback function in C) with a MessageConsumer. When a MessageListener object has been registered, XMS starts a thread (one thread per session) to listen in the background for new messages. Each time a message needs to be delivered to the MessageConsumer, the registered MessageListener's onMessage() method (or C callback function) is called on the background thread.

Message selectors

Both JMS and XMS let you filter messages using SQL92 selection criteria defined when a MessageConsumer is created. Message selection is performed based on header property values that are set in messages.

For example, in the following code fragment, an XMS application written in C sets a string property named Postcode in a message. The property value is SO21 2JN (the postcode for the IBM Hursley lab).

rc = xmsSetStringProperty((hObj)msg, 	 // Message handle
      “Postcode”, 			                          // Property name
      “SO21 2JN”,                                     // Property value
      length,                                             // 
      errorBlock);

In the fragment shown below, a receiving application creates a MessageConsumer that filters for postcodes beginning with SO21. This matches the postcode property set in the message, so the message is delivered to this MessageConsumer.

xmsSessCreateConsumerSelector(session, 
     destination,
     "Postcode LIKE 'SO21%' ", 
     selectorLength,
     &consumer, 
     errorBlock);

Decoupled administration

XMS and JMS applications use a number of resources (including message servers, queues, and topics), and have a facility to loosely couple the applications to the resources by looking up JMS resource definitions in a directory at run time. In JMS, this facility is implemented using the Java™ Naming and Directory Interface (JNDI).

JMS resource definitions are stored in either LDAP, file system based, or COS naming JNDI directories, and are configured using either the JMSAdmin tool (in WebSphere MQ), or the WebSphere Administration Console.

The main advantage of configuring resource definitions independently from an application is that the application can be targeted at a different server or destination simply by altering a resource definition. You do not need to change, rebuild, and redeploy the application.

XMS emulates the Java JNDI lookup capability by providing methods to look up objects in LDAP and file system based directories. The lookup can refer to exactly the same administered objects as a Java application, so you do not need to administer separate sets of resources for XMS and JMS. Resources can be defined once, then used at run time by a system consisting of a mixture of JMS and XMS applications.

Back to top

Sample Code

The following code sample shows a C++ program written using the XMS API. This program connects to a WebSphere MQ Queue Manager as a WebSphere MQ client over port 1414, opens a queue called AQ, and produces a Hello World text message (for more complete code, see the sample applications supplied with XMS).

#include <iostream>
#include <xms.hpp>
#include <windows.h>
using namespace std;

int main(int argc, char ** argv)
{
    try
    {
        xms::ConnectionFactory * pConnFact = NULL;
        xms::Connection          conn;
        xms::Session             sess;
        xms::Destination         dest;
        xms::MessageProducer     producer;
        //
        //  Create ConnectionFactory and set client connection details
        //
        pConnFact = new xms::ConnectionFactory();
        pConnFact->setIntProperty(XMSC_CONNECTION_TYPE, XMSC_CT_WMQ); 
        pConnFact->setIntProperty(XMSC_WMQ_CONNECTION_MODE, 
                                  XMSC_WMQ_CM_CLIENT);
        pConnFact->setStringProperty(XMSC_WMQ_HOST_NAME, "localhost");
        pConnFact->setIntProperty(XMSC_WMQ_PORT, 1414);
        //
        //  Create connection & session
        //
        conn = pConnFact->createConnection();
        cout << "Connected" << endl;
        sess = conn.createSession(xmsFALSE, XMSC_AUTO_ACKNOWLEDGE);
        dest = xms::Destination( "queue://AQ");
        producer = sess.createProducer(dest);
        cout << "Starting Connection..." << endl;
        //
        //  Start connection & send message
        //
        conn.start();
        xms::TextMessage textMsg = 
            sess.createTextMessage("Hello World, this is XMS");
        producer.send(textMsg);
        cout << "Successfully sent message:" << endl;
        delete pConnFact;
    }
    catch(xms::Exception & ex)
    {
        cout << "Unable to connect and send ..." << endl;
        cerr << ex <<  endl;
    }
    return(0);
}

Back to top

XMS connectivity

IBM offers three main messaging products, each with a set of distinct messaging capabilities implemented by different transports. Each transport has its own wire protocol and is particularly suited to a specific task.

XMS offers a single API that complements JMS by allowing C, C++, and .NET applications to make direct connections to all of these messaging servers (see Figure 2 below). The messaging servers are:

WebSphere MQ

WebSphere MQ provides enterprise standard messaging and queuing. WebSphere MQ's traditional strength lies in reliable point-to-point messaging. Since Fix Pack 8 on WebSphere MQ V5.3, a pub/sub broker (formerly SupportPac MA0C) has been included in the base product.

WebSphere Business Integration brokers

The WebSphere Business Integration Event Broker and Message Broker exploit and extend WebSphere MQ by adding message routing, transformation, and more sophisticated pub/sub capabilities. The WebSphere Business Integration brokers also add two message transport options in addition to WebSphere MQ:

• Real-Time Transport (RTT) is a very fast, lightweight, non-persistent (non-queued), pub/sub protocol. As its name suggests, RTT is most useful when data is required in real-time.
• Multicast Transport is an optimised non-persistent pub/sub protocol that takes advantage of the multicast facilities built into the network card hardware.

WebSphere Application Server V6 default message provider

WebSphere Application Server V6 introduces a new, pure Java message provider that runs in the application server process and takes advantage of application server clustering and administration.

Back to top

When to use XMS

When applications need to be loosely coupled to servers or destinations

As discussed in the "XMS Features" section above, XMS enables an application to be loosely coupled to the resources it uses. Loose coupling provides the flexibility to target an application at a different messaging server, destination, or even transport without the need to recompile and redeploy it.

When Java and non-Java environments need to be integrated

XMS is a good API choice when integrating Java and non-Java environments via the WebSphere family of messaging servers, because:

• XMS offers JMS compatibility and the potential for reuse of JMS design and programming skills.
• XMS simplifies application management in mixed Java and non-Java messaging applications, because JMS and XMS applications can share the same resources. Changes to an administered object will automatically be reflected for both the Java JMS and non-Java XMS applications that use it.
• XMS is the only non-Java API that provides access to the WebSphere Platform Messaging server and to WebSphere Business Integration Broker Real-Time and Multicast transports.

To access strategic assets from a managed .NET environment

XMS provides the ideal bridge for integrating .NET applications with applications using the WebSphere family of messaging servers. .NET client applications can be developed and deployed into the managed .NET environment, and can then use XMS to leverage the enterprise-level reliability and scalability of WebSphere servers – for example to access applications running on a mainframe.

To simplify WMQ pub/sub applications

XMS makes it simple to write pub/sub applications using WebSphere MQ Brokers in non-Java environments, because XMS automatically adds RFH(2) headers to messages, and sends the appropriate command messages to register subscriptions and make publications.

Back to top

...and when not to use XMS

When using WebSphere MQ and maximum performance is required

XMS provides a wrapper on top of the native WebSphere MQ programming verbs (MQI), which means that an XMS application may not perform as well as a well-written MQI application.

When using WebSphere MQ and maximum platform coverage is required

The native WebSphere MQ interface (MQI) offers a consistent API on every platform on which WebSphere MQ runs. XMS will probably not be provided on as many platforms, so you need to use MQI to get the widest possible range of languages and platforms.

Back to top

How to get XMS

The C and C++ implementations of XMS are available on Windows and Linux as Category 2 SupportPac IA94. Download C and C++ implementations of XMS from WebSphere MQ SupportPac page.

The .NET (C#) implementation of XMS is available as beta code. Download .NET (C#) implementation of XMS.

Back to top

Conclusion

This article has explained the features of XMS, and shown how on-the-wire compatibility with JMS and connectivity to the range of IBM messaging servers makes XMS an ideal choice for integrating C, C++, and .NET applications with WebSphere MQ and J2EE infrastructures.

Resources

• JMS 1.1 simplifies messaging with unified domains. This article by IBM WebSphere consultant Bobby Woolf shows you how the new API will help you write more reusable JMS clients.
  
  
• Write a JMS pub/sub application using WebSphere Business Integration Event Broker and WebSphere MQ Real-Time Transport. This article shows you how to set up and run a simple JMS pub/sub application using WebSphere Business Integration Event Broker with the WebSphere MQ Real-Time Transport.
  
  
• Setting up a multicast broker. This section of the WebSphere Business Integration Information Center shows you how to set up a multicast broker for pub/sub applications.
  
  
• Building an enterprise service bus with WebSphere Application Server V6. Part 3 of this series on using the new messaging engine in WebSphere Application Server V6 to build an ESB shows you how to set up a message-driven bean to listen to messages on a JMS queue, and how to set up a J2EE client application to send a message to that JMS queue.
  
  
• WebSphere MQ product page. Product descriptions, product news, trial downloads, training information, and more.
  
  
• developerWorks WebSphere Business Integration zone. Access to WebSphere Business Integration how-to articles, downloads, tutorials, education, product information, and more.
  
  
• Trial downloads for IBM software products. No-charge trial downloads for selected IBM DB2, Lotus, Rational, Tivoli, and WebSphere products.
  
  
• Most popular WebSphere trial downloads. No-charge trial downloads for key WebSphere products.
  
  
• Safari Bookshelf: e-library designed for developers. Complete search and download access to thousands of technical books for a one-time subscription fee. Free trial for new subscribers.
  
  
• WebSphere forums. Product-specific forums where you can ask questions and share your opinions with other WebSphere users.
  
  
• developerWorks blogs. Ongoing, free-form columns by software experts, to which you can add your comments. Check out Grady Booch's blog on Software architecture and engineering.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• XMS Features
• Sample Code
• XMS connectivity
• When to use XMS
• ...and when not to use XMS
• How to get XMS
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Webcast: Using Rational Application Developer with WebSphere Application Server to increase productivity
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers