All About Interop : MQ

Weblogic JMS with .NET

DotNetInterop — Thu, 09 Oct 2008 18:36:00 GMT

This came out last month, I just learned about it from an email from Jesus today.

WebLogic Server 10gR3 now has an officially-supported .NET client for its JMS provider. Very cool. Some of you might be wondering, just what does that mean? It means there is a queue mechanism in the WebLogic Server, for a long time this has been called "Weblogic JMS". And you can connect to that queue subsystem via .NET applications. James Bayer has a blog entry on it, which you should check out.

pet peeve alert! Calling a queue "JMS" is strange and confusing. It would be like calling the Oracle database "Oracle JDBC" or "Oracle ADO.NET". Oracle Database is not the same as JDBC. JDBC is an API. ADO.NET is the name for an API. The database is not the API. The database (whether Oracle, Microsoft SQL Server, IBM DB2, or something else) exposes mutliple API families - some for Java, some for .NET languages, some for C and C++. The programmatic interfaces are distinct from the implementation.

With JMS, Sun and the Java guys have confused the issue. Maybe even on purpose: remember back when JMS was conceived, Sun had aspirations to make Java itself a platform - everything contained within Java as other things like the operating system and the database itself, and to the point, a messaging subsystem, recede into the background. Well, that didn't really happen, despite the huge popularity of Java as a programming language. Operating systems still matter, databases still matter, message queues did not get subsumed into the programming language. Java is a language and a VM and a base class library, but not a platform. Regardless, the side effect of Sun's unfulfilled platform aspirations for Java is that today, people call message and queue subsystems "JMS." Developers speak of JMS topics, JMS queues, JMS messages. But it is clear: just as JDBC is a Sun/Java API for databases, JMS is a Java API for Messaging subsystems.

IBM has always been very clear about this with its MQ product, later called MQSeries and then changed to "WebSphere MQ".   (For this post I'll just call it MQ.)   MQ is the implementation, and MQ exposes a bunch of different APIs - for C, for .NET, for Java, and I'm sure, for other languages. In what looks like a bit of schizophrenia, IBM also has message service within WebSphere Application Server, which is called WebSphere JMS if I am not mistaken, and which... you guessed it, exposes more than just a JMS programming interface.

For some reason, the queue infrastructure for some products has been called "JMS" as if that is the only API that has ever mattered. Seems like a result of shortsighted and wrongheaded product planning to me. And it's darned confusing, to boot.

A separate issue is that JMS is not merely an API! JMS actually injects some message protocol behavior, specifically the RFH2 header formatting stuff, which makes for tricky interop with other, non-Java applications through queue subsystems. Designing JMS this way presented a big, unnecessary obstacle to interop, and I've blogged on it previously.   IBM has had to introduce new APIs for MQ and its other queue subsystems, specifically to work around this interop barrier. I don't know a better way to solve it, than the way IBM did. But make a note to yourself - if you ever design a queue system or queue API, keep the API separate from the application protocol and message formatting.

Check it out!

PowerShell CMDLets for WebSphere MQ - administer queues on Windows or Linux

DotNetInterop — Tue, 01 Jul 2008 00:27:00 GMT

Last year, I wrote about the idea of PowerShell CmdLets for WebSphere MQ. PowerShell is a beautiful scripting environment, you see, and it allows you to load any managed class library and then call into it. This is what allows me to, for example, create zip files within Powershell. But there are of course a zillion other possibilities. On the other hand if you are doing scripting, another opportunity for integration with PowerShell is CmdLets. CmdLets are little bits of function that get added to the Powershell base function. All the capabilities within PowerShell are exposed via commands that have a verb-noun structure, like Get-ChildItem. Or Write-Output. If you create a new cmdlet and add it to PowerShell , you've added to its vocabulary of functions. CmdLets offer better utility in a scripting environment, as compared to just loading an assembly and calling into the loaded class library.

It seems IBM have been busy doing CmdLets for MQ, and somehow this escaped my attention. Starting back in December 2007, Dale Lane at IBM published a series of posts about the topic of PowerShell CmdLets for MQ. There is also now an official SupportPac for this stuff, it goes by the catchy name of mo74. (direct FTP link here). In IBM-speak, a SupportPac is an add-on to the IBM product (in this case WMQ). Very good to see! Keep in mind that there are different categories of SupportPac and just because it says "support" in the name does not mean it is a "supported" part of the IBM product in the sense that you can call up their support engineers and ask for bugfix on it. mo74 is listed as Category 2, which means it is AS-IS software. SupportPacs can transition from "AS-IS" to a supported part of the product; this happens when customers demand it. Last updated April 16th, mo74 is currently at version 1.6.

One of the things you can do with the MQ cmdlets included in the mo74.zip SupportPac is administer queue managers on remote machines, including machines running MQ on Windows, Linux, or Unix. (If you know MQ, this shouldn't be too surprising, as you know that MQ can use the queue itself to send administrative commands.) IBM plans to add z/OS to the list of platforms that can be administered remotely using PowerShell. You can read about their plans and progress on integrating PowerShell with WMQ on the "Hursley on MQ" blog.

By the way, Dale also has a personal blog, where he writes about a bunch of stuff, some of which is related to PowerShell and WMQ.

It's good to see this integration.

JMS Adapters for .NET & BizTalk

DotNetInterop — Fri, 16 Nov 2007 19:12:00 GMT

Love it! I previously posted about a beta of the JNBridge JMS Adapters. I just got a form email from the company that they've publicly released their adapters.

There's a version of the adpater for .NET apps - this allows any .NET app to connect to any JMS resource. Think about that. It's really useful. If you have an IBM MQSeries queue, and you're using IBM's MQ JMS provider to get to it, you can use this new adapter to enable any .NET application to get to the same JMS resource. The thing is based on the WCF Line-of-Business Adapter SDK, which means any .NET application that can consume a WCF endpoint, can use the adapter.

There's a similar adapter that works for BizTalk Server applications, but it is not WCF-based.

These adapters work with any JMS server, and you don't have to change the JMS infrastructure to use them. They both use the .NET-to-Java bridging magic in JNBridgePro, so the .NET app actually connects into the JMS system via the JMS jars. That's why you don't have to change anything.

You can download a trial version on www.jnbridge.com.

The SOAP-over-JMS spec and interop

DotNetInterop — Tue, 24 Jul 2007 17:36:00 GMT

In a previous post, I wrote about a WCF Channel for MQ that IBM is building. Some customers had asked about this project and its implementation, specifically around the interop implications if other JMS providers, other than MQ that is, were used in an environment.

To be clear the WCF Channel for MQ is ... how can I put this? for MQ. It is not an approach that particularly facilitates interop among JMS providers. That would best be addressed by a spec that focuses at a different level, say AMQP. AMQP as I understand it, is a queue-to-queue protocol that would facilitate interop between queue providers, and I believe that would be true whether or not a JMS API was used to access it. In general the goals of AMQP are valuable when they are API-agnostic. Heterogeneity anyone?

The WCF Channel fo MQ does provide interop, but to a particular limited degree: it is interop between endpoints in a messaging network that all use MQ. .NET to CICS, .NET to WebSphere, C++-running-on-AIX to .NET-on-Windows, and so on. WCF isn't available on all the various IBM platforms, so how does the interop work? It happens because IBM is using the same message format on the queue, from all those endpoints. [added 30 July 2007 215pm Pacific] In fact as I understand it, that is the point of the WCF Channel for MQ: the programming model at the different endpoints varies, but interop among those endpoints is still possible.

There is a related spec effort in this space - the SOAP-over-JMS proposal. The message encoding IBM uses is NOT SOAP-over-JMS. Why? Because SOAP-over-JMS is an idea, not a real specification yet, let alone a standard one. Thinking a bit more about this, it doesn't matter very much that the WCF channel for MQ does not currently use a standard encoding, as long as the encoding is consistent across the endpoints that need to exchange messages. That is to say, consistent among CTS, a Websphere EJB (MDB), a Websphere JMS app, and the WCF app, etc.

If and when finalized and adopted, the SOAP-over-JMS spec aims to allow heterogeneous web services stacks (AXIS, Sun JWSDP, Websphere’s built-in, etc) to interop. But still, this assumes that there is a single JMS provider. The SOAP-over-JMS stack provides interop among web services stacks using a single JMS provider; it does not provide interop among JMS providers. For that you would be looking at something like a point-to-point bridge or to AMQP.

What are your thoughts on this? How much interest is there in AMQP? Drop me a line.

Custom WCF Channel for IBM MQ

DotNetInterop — Mon, 16 Jul 2007 21:06:00 GMT

IBM have shipped an early version of a Custom WCF Channel for MQ. The dev team in Hursley contacted me to solicit feedback. It's apparently pretty simple now, supporting only SOAP one-way messaging, but they say if there is sufficient interest and feedback, they will consider developing it further and perhaps adding it to the MQ product (as they did with the MQ Classes for .NET, and other stuff).

Out of the box, WCF includes support for queued transport, over MSMQ, which is the Microsoft Message Queue, built-into Windows. This is available in the NetMsmqBinding. You can read more about it here.

What our friends at IBM are doing is similar, but different in a very important way: In the IBM channel, messages are encoded and sent via the message queue, just as with the NetMsmqBinding. However, with the IBM channel, of course, the queue is WebSphere MQ v6.0, and not the built-in MSMQ. There is one other important difference though: Messages are encoded using the SOAP over JMS (Java™ Message Service) message format described in WebSphere MQ 6.0. Why is this important? This enables interoperability with services and clients hosted by other environments that can also read or generate SOAP-over-JMS. Examples are such as CICS (Customer Information Control System) and WebSphere Application Server.

So this channel has the possibility of opening up some new interop capabilities between .NET / WCF applications and apps that run in non-.NET environments, including Java applications running in WebSphere Application Server.

Please do have a look:
http://www.alphaworks.ibm.com/tech/mqwcf/

IBM's new MQ Blog includes some good .NET stuff

DotNetInterop — Fri, 16 Feb 2007 20:51:00 GMT

The MQ Engineers at IBM’s Hursley Lab (near Winchester, England) now have a blog. (By the way, the Hursley campus is just gorgeous.)

The blog is pretty new, started only last month, as far as I can tell, but it is already chock-full of interesting, high-content posts. I learned about it when Saket Rungta of IBM sent me an email.

I want to call your attention to a couple of entries in particular.

· “the Simplest MQ Publish/Subscribe Ever”, this one features IronPython, and XMS.NET.

The author shows how to build a publisher and a subscriber, in python running on .NET. The app uses the XMS.NET library to connect to the MQ Resource. Nifty!

http://hursleyonwmq.wordpress.com/2007/02/13/simplest-websphere-mq-publishsubscribeever/

· “WebSphere MQ Scripting using PowerShell”

http://hursleyonwmq.wordpress.com/2007/02/12/websphere-mq-scripting-using-powershell/

This is pretty cool. See, here's the thing about Powershell - it is a .NET-enabled scripting environment, so if you have a .NET class library (Such as IBM's MQ Classes for .NET), you can do pretty much anything that is enabled by that class library. Which means, from the script you can create queues, clear queues, delete queues, and so on. Anything you can do from the class library.

One editorial comment: One of the ideas embraced by PowerShell is that APIs are not the right level of abstraction for Administrators. PowerShell introduces the ideas of "Cmdlets" and "functions" - very small pieces of code focused on delivering the right user experience to admins and other people who would use scripts. It would be cool to have a powershell library for MQ - something with the right level of verb-noun abstractions. I imagine it would be a pretty thin layer. It's on my increasingly long list of things to investigate.

Kudos to IBM for the new blog!

.NET Logic triggered by IBM MQ Messages

DotNetInterop — Fri, 16 Feb 2007 19:09:00 GMT

I did not know about this.

With WebSphere MQ v6, IBM introduced something called the ".NET Monitor" feature. The .NET Monitor, in MQ, is similar to a WebSphere MQ "trigger monitor."

The doc says, developers can create .NET components and register them with the .NET Monitor. When a message is received on a monitored queue, The .NET Monitor will instantiate the component, and hand it the message, in the form of an MQMessage object.(The component also gets the MQQueueManager, and MQQueue) All the developer has to do is implement the IMQObjectTrigger interface, which is defined in the assembly <MQDIR>\bin\amqmdnm.dll. The interface has just one method:

void Execute(MQQueueManager qmgr, MQQueue queue, MQMessage message, string param);

The .NET Monitor feature of MQ v6 facilitates interop, because the incoming MQ Message can be sent by *anything*, including a CICS/COBOL program, a Java/WebSphere application, a C++ system, or whatever.

Good to know.

.NET integration with WebSphere Queues - Another Update

DotNetInterop — Tue, 22 Aug 2006 23:59:00 GMT

The IBM Message Service Client for .NET has been Updated

Part of an ongoing series on JMS and .NET interop

Another update on IBM SupportPac IA9H, the IBM Message Service Client for .NET, aka "XMS .NET".

First, it's supported! Woohoo! IA9H has graduated into a "category 3" SupportPac, which means if you use it with a licensed WebSphere queue product, IBM will support it. Good stuff. This is the same path the original MQ.NET library followed - it means IBM is seeing enough customer interest that they want to deliver something REAL, as opposed to sample code.

Second, it works with .NET v2.0 now. The assembly itself is built with .NET v1.1, but it will work with .NET 2.0.

Phil Willoughby at IBM also says there are some perf improvements.

If you use Websphere messaging products and need to connect .NET apps with Java/JMS apps through those messaging products, XMS .NET is worth checking out.

-Dino

[Update, 23 August 2006, 949am Pacific: I checked the readme and had some questions, which Saket Rungta at IBM (a colleague of Willoughby I take it) graciously answered via email this morning. first, the readme says:

In testing, we have found that XMS .NET applications sending messages through WebSphere Application Server Messaging Engines typically need to use a larger JVM heap than the default. Please see the Application Server documentation for details on changing heap configuration.

The obvious question is, whats up with that? Saket:

The additional heap requirement for WAS is independent of the clients, in other words, applies equally to .NET clients, Java clients and C/C++ clients. The root cause for this is perhaps a conservative choice for default heap size from our messaging perspective, but is likely to be appropriate default heap size for the common scenarios.

Ok, so if you use XMS.NET (or any XMS library, I guess, or in fact any JMS client) with the embedded messaging engine in WebSphere App Server or WebSphere Process Server, you will need to bump up the heap size. Clear enough.

Next question: the readme says that XA transactions are not supported with XMS.NET. I know that XMS.NET depends on the MQ Classes for .NET, which does support XA transactions. So, again, what's up with this? Saket:

We are evaluating customer requirements/need for this and may offer this functionality some time in the future, subject to resource availability, management approval and strategy recommendations.

Good clear answers. That's all for now... ]

IBM Message Service Client for .NET

DotNetInterop — Mon, 06 Mar 2006 20:29:00 GMT

IBM Message Service Client for .NET

Part of an ongoing series of posts on JMS-to-.NET interop

Philip Willoughby of IBM's Hursley Lab writes that IBM have released IBM Message Service Client for .NET (also known as XMS for .NET) as a category 2 SupportPac - IA9H is the moniker for the SupportPac tifosi out there.

IA9H joins other notable supportPacs like MA88, the "MQ Classes for Java", and MA7P, the progenitor of the "MQ Classes for .NET", a managed class library which is now supported as part of IBM MQ.

For IBM, MQ SupportPacs come in multiple flavors. The Category 1 SupportPac is a fee-based service. Category 2 SupportPracs are "freeware" - free as in puppies, and no support from IBM. Category 3 SupportPacs are supported as extensions of the MQ product. In some cases, as with MA88 and MA7P, Cat2 supportpacs graduate into the product. I suppose it depends on customer usage and interest?

The XMS.NET thing is a Category 2 SupportPac - free, but no support included. In general, that does not mean you won't get help from IBM. I don't speak for IBM, but I expect it means that support for IA9H is given on a best-effort basis. I'd bet if you had problems and rang them up on their newsgroups or email, you'd get a proper, helpful response, direct from the engineers.

The esteemed Mr. Willoughby goes on to say,

As with the beta release you can use XMS for .NET to connect your .NET applications to any or all of WebSphere MQ, WebSphere BI Brokers or WebSphere Application Server. XMS for .NET is compatible with IBM's JMS providers and XMS for C/C++. This release has some new features and a number of bug fixes as compared to the beta, so we advise everyone to upgrade.

I'm really glad to see this thing became real.

The IA9H Readme states that it requires Windows 2000, XP, or 2003, as well as .NET v1.1. I did not inquire with Philip Willoughby about .NET 2.0 support, but I will do so presently and keep you all apprised.

-Dino

.NET can connect to WebSphere's built-in JMS

DotNetInterop — Mon, 16 Jan 2006 16:36:00 GMT

Phil Willoughby of IBM dropped me a line. Phil apparently works on the XMS stuff, I'm guessing out of IBM's Hursley lab. Phil sez:

Re: http://blogs.msdn.com/dotnetinterop/archive/2005/11/04/488770.aspx

FYI, XMS can be used to connect directly to the WebSphere App Server embedded JMS system. There is no requirement to have WebSphere MQ, WebSphere Message Broker or WebSphere Business Integration Event Broker installed. Of course, if you're using another vendor's app server you would need to use WMQ or one of the brokers to bridge the gap.

Mark Phillips' developerworks article does a good job of explaining this:

http://www-128.ibm.com/developerworks/websphere/library/techarticles/0509_phillips/0509_phillips.html

Hey, that's good to know! One more way to connect...

PCF with IBM's MQ Classes for .NET

DotNetInterop — Fri, 02 Dec 2005 18:58:00 GMT

PCF with IBM's MQ Classes for .NET

For about 2 years IBM has been providing a supported class library that allows .NET apps to connect to MQSeries. There has always been PCF capability in the class library, but it's not documented and I suppose not supported either. (PCF is the Programmable Command Formats, and in a nutshell it defines a way you can administer MQSeries artifacts by sending and receiving messages to a queue. Rather than a separate admin API, MQ defines a set of message formats. When your app sends messages in the PCF format, you can query or update MQ resources, like queues, channels, queue managers, etc.)

If you are facile with Lutz Roeder's Reflector and have programmed PCF before using other environments (like Java or C or C++), then it's pretty straightforward to figure out how to use the PCF stuff in .NET. For those who don't fall under that category, here's an example of .NET PCF code using the MQ Classes for .NET that shipped in MQ v6.0.

private bool MqQueueExists(string queuename) {

PCFMessageAgent agent = new PCFMessageAgent(c.MQ_QueueManager);

PCFMessage request= new PCFMessage(CMQCFC.MQCMD_INQUIRE_Q_NAMES);

request.AddParameter (MQC.MQCA_Q_NAME, queuename);

request.AddParameter (MQC.MQIA_Q_TYPE, MQC.MQQT_LOCAL);

PCFMessage[] responses = agent.Send(request);

if (responses==null) throw new Exception("bogus response from MQ PCF.");

bool exists= (responses.Length!=1) || (responses[0].GetCompCode()!=0);

return exists;

}

private void MqCreateQueue(string queuename) {

PCFMessageAgent agent = new PCFMessageAgent(c.MQ_QueueManager);

PCFMessage request= new PCFMessage(CMQCFC.MQCMD_CREATE_Q);

request.AddParameter (MQC.MQCA_Q_NAME, queuename);

request.AddParameter (MQC.MQIA_Q_TYPE, MQC.MQQT_LOCAL);

request.AddParameter(MQC.MQCA_Q_DESC, "created by MQ.Create.exe on " + System.DateTime.Now.ToString("u"));

PCFMessage[] responses = agent.Send(request);

}

private void ClearQueue(string queuename) {

agent = new PCFMessageAgent(c.MQ_QueueManager);

PCFMessage request= new PCFMessage(CMQCFC.MQCMD_CLEAR_Q);

request.AddParameter (MQC.MQCA_Q_NAME, queuename);

PCFMessage[] responses = agent.Send(request);

}

There's lots more in PCF, not just creating queues or testing for their existence. Check the MQ header files and IBM's PCF docs for other platforms.

Disclaimer: I'd be wary of using this .NET PCF stuff in production. Since it is not documented, and probably not supported by IBM, you'd be out on a limb if something went bad with your mission-critical system. But, I found this PCF stuff to be really useful in test/development scenario, where I wanted to reset a queue to a known state, or create a queue, etc.

See the rest of the source code here

-Dino

JMS and RFH2 messages from .NET

DotNetInterop — Fri, 04 Nov 2005 15:59:00 GMT

My previous entry related to XMS, which is IBM's library for connecting .NET apps (and C++ apps) to its MQ Brokers.

If you don't have MQ, then how can you connect with JMS? The JMS interop issue is still a problem.

I found this link, to a solution posted a long while ago, by Rodrigo Salinas. Gracias, Amigo. It is sample code that allows you to generate RFH2 messages from a .NET app (including from VB.NET or C#).

Cheers!

XMS whitepaper from IBM

DotNetInterop — Thu, 03 Nov 2005 21:47:00 GMT

part of an ongoing series of posts on JMS and .NET interop.

I just saw this while looking around for something else - IBM published a paper in late September on the XMS client library for their MQ brokers. I posted about this previously. Essentially this is a .NET client for their MQ brokers, including an implementation of some stuff from JMS. That means publish/subscribe capability, partly. The new article offers some new info and clarifies a few things for me. Specifically, when IBM says "MQ Brokers", they include the regular MQSeries in that. Since CSD08 of MQ V5.3, IBM has offered a pub/sub capability in the base MQ. So this XMS stuff works with that. (IBM are now up to v6.0 of MQ.)

A nice interoperability option! This fixes the JMS-is-not-interoperable issue I had raised previously.

Remember, the .NET client library for plain-old-MQ is a separate thing - that has been a part of IBM's MQ product since MQ5.3 CSD05. But, what this XMS thing is, is a pub/sub client. Something a little different.

IBM and JMS-to-.NET interop

DotNetInterop — Wed, 03 Aug 2005 17:04:00 GMT

IBM's .NET Managed client for JMS

Today I received a comment on a prior entry of this blog. It is noteworthy so I thought I would re-post it here.

As previously mentioned in a previous blog entry (JMS Interop, revisited), there is a demand for .Net and JMS interop.

IBM Message Service Client for .NET (informally known as XMS) has now started an open Beta programme.

XMS is a non-Java implementation of the Java Message Service (JMS) API, currently implemented to work with the IBM WebSphere Messaging portfolio. Specifically, it is a fully managed .NET API that can be used by applications to send and receive JMS messages via IBM WebSphere Business Integration Brokers over Real-time Transport or via the default messaging provider within IBM WebSphere Application Server v6.

We welcome you to download XMS from: http://www14.software.ibm.com/webapp/download/search.jsp?go=y&rs=message,

Try it out, and give us your feedback via: news://news.software.ibm.com/ibm.software.websphere.mq.beta.

Cool!

First question I have is, does it work with plain old WebSphere MQ? I don't know what the term "WebSphere Business Integration Brokers" includes. I think there are some premium products like WBI Server, and WBI Message Broker and WBI Event Broker, and I guess all of those are included in "WBI Brokers". But what about just MQ? [ note added 4 Aug 2005 : The readme for this XMS.NET thing apparently states NB. Interaction with IBM WebSphere MQ is not supported in this release but is currently under development. So I think you need one of the higher-end MQ or WBI products, for now. ]

Anyone trying this out? I am interested in feedback, too! Comment on the blog or contact me privately. I'd love to hear if this thing is useful.

Setting up WinXPSP2 or WS2003 for XA transactions with MQ

DotNetInterop — Wed, 06 Jul 2005 21:14:00 GMT

In a previous post, I talked about transactions without components, spanning MQ and SQL Server. The hardest part in doing that was setting up the environment. For posterity, here's what I did:

Steps:

install Windows XPSP2 or WS2003
install the MQ Client or Server software.
install the MQ XA Client (aka "MQ Extended Transactional Client")
install the latest fixpack for WMQ. For Windows v5.3, As of May 2005, this is CSD10.
register the XA DLL in the registry.

for MQ, according to IBM, the DLL is <MQDIR>\bin\amqmtsxatm.dll but on a MQ client-only machine, it may be <MQDIR>\bin\amqmtsxatmc.dll

For MQ then, it is:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\XADLL]
Key name: amqmtsxatm.dll
Data: C:\progra~1\ibm\MQ\bin\amqmtsxatm.dll

If you are running the app from an MQ client node, get the interim fix from IBM; I don't know which fix this is. you have to request it. It is not included in CSD10. It may be included in CSD11. If you are running the app on a MQ server node, then you do not need the interim fix.
Turn on DTC in Windows. This is slightly different on XPSP2 and WS2003. On XPSP2, it is like this:
Control Panel--> Admin Tools --> Component Services --> My Computer --> Properties

select the MS DTC tab, click the "Security Configuration..." button.
Check the "Network DTC Access..." box.
Check the XA box.

allow the "network service" user to read the directory in which the XA DLL resides.

Use Explorer for this. For my install of MQ, this directory is
c:\progra~1\ibm\mq\bin\
add "network service" user to the MQM group (or other group authorized to "perform XA recovery" on MQ).
set the NMQ_MQ_LIB variable to c:\progra~1\ibm\mq\bin\mqic32xa.dll. This is from the "Using .NET" doc.)
Run the app

That's it.

[addendum, 13 October 2008: An attentive reader has pointed out that

the WebSphere MQ Solutions in a Microsoft .Net Environment (SG24-7012-00) states:

“WebSphere MQ applications can participate in transactions managed by Microsoft transaction managers. The application either has to be directly connected to a queue manager, or it has to use the extended transactional client function when running on a remote machine.”

So my assertion above, that you need the Extended Transactional Client, may not be appropriate in all cases. When in doubt, prefer the IBM documentation. Better yet, contact IBM for full details. I'm not even sure the Extended client still exists for MQ V6.0 and beyond.