Bill O'Brien's WebLog

MQ from .NET

I recently needed to research how to utilise MQ as a transport from .NET applications. The possible options are as follows:

1) Web Services

 

The integration strategy of choice these days. Easy from .NET, trouble is that I don’t believe there is an MQ http listener or Web Services infrastructure, if you know otherwise let me know.

 

2) IBM Websphere for Windows classes giving access to MQ directly. This is probably the simplest way. Dino has a great blog on this here.

 

3) HIS MSMQ/MQ bridge

If you already know and love MSMQ then this is the option for you. Otherwise bear in mind that it’s another moving part in your system.

 

4) Biztalk MQ adapter

If you are using Biztalk or considering as part of your solution then this is a great option.

 

5) Remoting - I put this in for completeness but I think it’s a non-runner. There is an MSMQ remoting channel that was developed but if you wanted to do this for MQ then you would need to reverse engineer the remoting infrastructure on the MQ side!

Bill

   

Published Wednesday, March 16, 2005 10:07 AM by bobrien

Comments

 

P said:

Hey there,
just spotted your post on MQ.

I hope you don't mind me pointing out that you loose the ability for Transactional support with some of those options and it might be something to note. After all the action of enquing or dequing message(s) from a message store may have a requirement to be a action in a group of actions (as a unit of work) and the sucess/coordination/*Commit* of the unit of work determines if the message gets send (and gives a "exactly once" semantic.

hope you don't mind the comment, from the "peanut throwing gallery".

Have a good Paddy's day.
March 16, 2005 9:48 PM
 

Bill said:

Good point, as you know MQ (and MSMQ) are transactional resources (can enlist in two phase commits etc.).
Unless the channel into MQ is transactional also then you dont have your transaction anymore.
Specifically the remoting and WS options fall into this category (the others are OK, assuming you code your direct access classes in option 2 correctly). Web svcs will be addressed with WS-* specs covering transactions but remoting does not flow transactional context.
March 16, 2005 9:56 PM
 

Rushi Desai said:

If your data resides in SQL Server and the purpose for using MQSeries/MSMQ is for the purpose of transactional reliable messaging between the databases, you may also want to consider Service Broker in SQL Server 2005. The biggest benefit of having a single connection and single transaction is not requiring to enlist in two phase commits. Besides you have a single failure/backup story and other benefits that Service Broker provides.
March 21, 2005 9:54 PM
 

.NETicated said:

Awhile back, I was building a .NET application which needed to do two-phase commit between MS SQL 2000

April 26, 2007 11:09 PM
 

.NETicated said:

Awhile back, I was building a .NET application which needed to do two-phase commit between MS SQL 2000

April 27, 2007 5:51 PM
 

Bill O Brien s WebLog MQ from NET | Paid Surveys said:

PingBack from http://paidsurveyshub.info/story.php?title=bill-o-brien-s-weblog-mq-from-net

May 29, 2009 3:55 PM
 

Bill O Brien s WebLog MQ from NET | internet marketing tools said:

PingBack from http://einternetmarketingtools.info/story.php?id=9592

June 16, 2009 1:16 AM
Anonymous comments are disabled

This Blog

Syndication

Tags

No tags have been created or used yet.

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker