You are currently browsing the category archive for the ‘JMS’ category.

Ever puzzled by CCSIDs, Encoding or Data conversion issues? Here is an excellent document on this topic.

Data Conversion Under WebSphere MQ

Here are some simple sample applications for WebSphere MQ JMS that you may find useful. You may use them to verify your installation or to learn more about WebSphere MQ JMS semantics.

Both applications use client bindings rather than local bindings; and do not make use of JNDI for simplicity. They can be run as standalone J2SE/JSE programs.

Note: Applications need minor tweak in the config section and destination names according to your setup.

Author: Saket Rungta, wastedmonkeys.com

Read the rest of this entry »

Here is a minimalist cookbook for getting SSL working with XMS .NET client when communicating with WebSphere MQ*. Comments and suggestions are very welcome!

* Understanding of basic JMS and XMS concepts is assumed in this cookbook. For further information about JMS, see ‘Using Java’ book and for further information about XMS see ‘Message Service Clients for C/C++ and .NET’ book shipped with XMS.

Meta Notes

  • Currently, MQ SSL only applies to the unmanaged client*. This functionality is not available for the fully managed client (which is the default). This functionality is not applicable for the bindings mode, as there is no network communication in bindings.
  • The following only applies to MQ v6, as v5.3 has a different SSL story, at-least for Windows, I think.

So, in source code we must do the following:

myConnectionFactory.SetIntProperty(XMSC.WMQ_CONNECTION_MODE, XMSC.WMQ_CM_CLIENT_UNMANAGED);

* XMS .NET for WebSphere MQ delegates the security to lower layer of ‘MQ classes for .NET’. ‘MQ classes for .NET’ supports three connection modes – unmanaged client, fully managed client and bindings. XMS .NET transparently allows a selection between these three connection modes thru the XMSC.WMQ_CONNECTION_MODE property on a ConnectionFactory. For further information about these modes, see ‘Using .NET’ book. However, in a nutshell: unmanaged client is .NET wrapper with underlying C library, fully managed client is 100% pure .NET and bindings is (by definition) unmanaged, since it does IPC with the queue manager processes. (client modes communicate over network, bindings mode does IPC).

Read the rest of this entry »

I came across The Support Authority series of WAS related articles on developerWorks the other day, with their latest article on WAS trace released yesterday.

In this series a group of IBM’s technical support professionals are taking the time to explain the trace, and other RAS (reliability, availability and serviceability) features, of WebSphere Application Server and IBM’s JVM.

If you use WMQ as a messaging provider for WAS, or standalone WMQ JMS applications, I suggest taking a look.

Using IronPython and XMS .NET under-the-covers. Works like a charm for Point-to-point messaging and Publish/Subscribe messaging using WebSphere MQ.

And, you can change five lines and connect to WebSphere Platform Messaging (WebSphere Application Server, WebSphere ESB and WebSphere Process Server) or connect to WebSphere Brokers using the Real-time transport!

xmsconsumer xmsproducer

Read the rest of this entry »

With WMQ, an IBM Java environment is shipped with a number of platforms. If you’re developing JMS or WMQ Java Classes Client applications, it is well worth taking the time to scan the Diagnostics Guide that is available on developerWorks.

To give you an idea of the type of things this contains..

Java Heap Dumpsinformation on how to (a) produce one of these dumps yourself, and (b) how to understand the output. These can be very useful if you have a thread lock and need to work out what is locking what

Class Loading – Every wondered where that class was being (or not being) loaded from? Try this out.

Apologies for the slighly non-WMQ post.. but I thought this is very valuable information. Most WMQ users will be using a IBM JVM (or not?? please correct me!)

XMS is a non-Java implementation of the Java Message Service (JMS) API, currently implemented to work with the IBM WebSphere messaging portfolio.

XMS can connect to the following IBM messaging servers — WebSphere MQ; WebSphere Platform Messaging, for example, as embodied by the default messaging provider in WebSphere Application Server v6; and WebSphere Event/Message Brokers over Real-time transport.

An XMS application can exchange messages with any of the following types of application – An XMS application, a WebSphere MQ JMS application, a native WebSphere MQ application and a JMS application that is using the WebSphere Platform Messaging. XMS applications may use different IBM messaging servers with little or no change.

A C/C++ implementation of this technology is available as ‘IBM Message Service Client for C/C++’. This can be downloaded as a Cat3 SupportPac here.

Likewise, a .NET implementation of this technology is available as ‘IBM Message Service Client for .NET’. This can be downloaded as a Cat3 SupportPac here.