You are currently browsing the category archive for the ‘clients’ category.
We’ve just brought out a new SupportPac that allows access to WebSphere MQ using HTTP: MA0Y: IBM WebSphere MQ Bridge For HTTP.
There is no client involved here – just connect using whatever method you like Ajax, C++, Java, anything that can make a socket connection and send HTTP! This makes it the first zero-footprint client to WMQ.
We’ve defined a bunch of HTTP headers that encapsulate the message headers and the body of the message is sent as the HTTP body.
The support enables three of the standard HTTP verbs:
- GET – browse (get with browse) the currently highest message on the queue.
- DELETE – delete (destructive get) the currently highest message on the queue or topic.
- POST – post (put) a message to the queue or topic.
Emir Gaza (Consulting IT Specialist, Hursley Software Lab Services) and I are currently putting together a list of SSL gotchas based on our personal experiences and, of course, those of our customers. Our list covers many problems and solutions already well documented in the manuals (e.g. Error messages), but what we’re trying to do is compile a single list containing both common problems and those with sometimes cryptic solutions.
We aim to expand this list in future with more items and more detail, but for now, here’s the list we have compiled… Comments most welcome…
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
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.
- 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:
* 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).
An interesting discussion on the use of client connection wildcards came up on mqseries.net today. This is documented in the Application Programming Reference and Clients manuals, but I’ve not seen it used very often and it can help to see how it works with a practical example.
In this post, I’ll go through an example of why you might want to use a wildcard in an MQCONN call and show the effect that it has.