Skip to main content

Introducing XMS -- The IBM Message Service API

Mark Phillips (m8philli@uk.ibm.com), Software developer, IBM
Mark Phillips has worked as a software developer with the WebSphere MQ Development Team at the IBM Hursley UK Lab since 1995. He currently works on the WebSphere MQ Technical Strategy Team, with responsibility for Web services, messaging clients, and APIs. You can contact Mark at m8philli@uk.ibm.com.

Summary:  XMS (known officially as IBM Message Service Clients for C/C++ and .NET) is a collection of new messaging clients and APIs that render JMS in C, C++, and C#. They bring the benefits of JMS -- a standard, abstracted messaging API, pub/sub and point-to-point messaging, and externally administered objects -- to the non-Java world. XMS thus creates new integration possibilities by extending WebSphere messaging to customers who have, for example, standardised on .NET as their client platform, or who want to use messaging to integrate legacy C++ applications with new J2EE applications.

Date:  28 Sep 2005
Level:  Intermediate
Activity:  1208 views

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.


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.


Figure 1. Classes implemented by XMS
Figure 1. Classes 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.


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);
}


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.


Figure 2. Messaging portfolio: Servers, clients, and APIs
Figure 2. Messaging portfolio: Servers, clients, and APIs

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.


...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.


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.


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

About the author

Mark Phillips has worked as a software developer with the WebSphere MQ Development Team at the IBM Hursley UK Lab since 1995. He currently works on the WebSphere MQ Technical Strategy Team, with responsibility for Web services, messaging clients, and APIs. You can contact Mark at m8philli@uk.ibm.com.

Comments (Undergoing maintenance)



Trademarks  |  My developerWorks terms and conditions

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Architecture
ArticleID=94729
ArticleTitle=Introducing XMS -- The IBM Message Service API
publish-date=09282005
author1-email=m8philli@uk.ibm.com
author1-email-cc=

My developerWorks community

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).

My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Special offers