| Author |
Message
|
| treny_boy |
 Posted: Fri Oct 26, 2007 5:42 am Post subject: C#.NET - MQ API or XMS |
 |
|
Newbie
Joined: 25 Oct 2007
Posts: 8
|
Hi,
I'm fairly new to WebSphere MQ, and I need to integrate messaging into a .NET application which we need to use to send/receive data between a client.
From what I understand so far I have 2 options for .NET integration, and that is call the MQ API directly or using XMS. Are there any benefits of one approach over the other???
Basically what I need to achieve is to send a request to our client via MQ and wait for a response back from MQ. I've found a few samples using the MQ API and this approach looks pretty straight forward.
Thanks |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Oct 26, 2007 5:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
XMS is useful if you don't want to program to the MQ API directly, you want to be able to use a different messaging technology at some point.
It's also useful if you are doing pub/sub, because it provides a higher level abstraction that allows you to avoid things like building MQRFH2 headers by hand.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| treny_boy |
| Posted: Fri Oct 26, 2007 6:05 am Post subject: |
|
|
Newbie
Joined: 25 Oct 2007
Posts: 8
|
Programming the MQ API doesn't concern me too much, and I don't see us ever needing to use a different messaging technology...
What do you mean by pub/sub?
Basically I need to build something which will build the xml requests from a database table, and update the same table with the retrieved results. This will need to be asynchronous so I can send requests when available and process responses when they are retrieved from the queue. I don't want to be waiting for a response before sending another request.
I have prior C# and .NET experience, my only obstacle is time to get this running, which would be the quickest to pickup keeping in mind I know little about messaging?
Thanks |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 26, 2007 6:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Pub/Sub is "publish & subscribe"... it's a different way of building messaging applications, rather than "point to point" (request/response is a form of point-to-point).
You won't be concerned with it if you're doing request/response.
For what you need, the fastest and easiest thing is to use the MQ API and start from a sample. The nmqwld.cs sample may be reasonable to start with. You'll have to adjust properties on the message you put to make it a request, and save information before doing the GET. The sample doesn't cover that, but it's still pretty straight forward.
It sounds like you're going to want to use two threads... one for sending requests and one for processing responses.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| treny_boy |
| Posted: Fri Oct 26, 2007 6:29 am Post subject: |
|
|
Newbie
Joined: 25 Oct 2007
Posts: 8
|
Thanks Jeff, you've been really helpful!
Thats exactly what I was thinking, I'll check that sample out, is that something included with MQ installation or can I find the code sample somewhere on the forum?
Just out of curiosity, what is an example of a pub/sub application? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 26, 2007 6:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It is a sample included with the product - <MQ install root>/Tools/dotnet/samples/cs/
Pub/Sub is when you need to send one message to many receivers, and the sender needs to be logically isolated from the receiver.
A basic example would be a stock trading system - where the current price of a given stock changes frequently, and lots of people need to what the current price is.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| treny_boy |
| Posted: Sun Oct 28, 2007 4:02 am Post subject: |
|
|
Newbie
Joined: 25 Oct 2007
Posts: 8
|
Makes sense...and isn't what I need to do so API it is!
I'll install MQ on my dev box tomorrow and play around with some of the samples...
Are there any good API references/guides available? I've been through a few from the IBM site but haven't been able to find anything purely on the API...
Thanks for your assistance... |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sun Oct 28, 2007 4:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The MQ Info Center has two books - Using .NET and the Application Programming Guide - that would be directly applicable.
Almost every link you'll find in messages here goes to the MQ Info Center. Or at least a whole lot of them.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| treny_boy |
| Posted: Sun Oct 28, 2007 11:23 pm Post subject: |
|
|
Newbie
Joined: 25 Oct 2007
Posts: 8
|
Thanks Jeff, these books look very helpfull.
One thing I noticed in the Using .NET guide was a reference to the 3 connection types, client binding, server binding and managed client. It grabbed my attention as it states managed client connections do not support SSL, which is a requirement for me.
The application I am building will reside on the MQ Server, does this mean this will be a server binding connection therefore will not have the SSL limitation? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 29, 2007 2:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Um.
You code & configure your app to use whatever connection method you want it to use.
The only relationship this has to what machine you run your app on, is that there are different requirements for each connection. A bindings connection requires a local queue manager, a client connection requires an MQ client installation, and a managed connection requires a certain DLL to be packaged with your app.
So if you're running on a machine with a local qmgr, and you want to use bindings... then code & configure your app to use bindings.
And, bindings can't use SSL either. It doesn't use a channel, so there's no channel properties to set SSL parameters on...
But presumably the fact that you're running locally eliminates a lot of the requirements for SSL - no network traffic to be snooped, no issues with non-local user authentication, and etc.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
