| Author |
Message
|
| guogangli |
 Posted: Mon Mar 02, 2009 3:47 pm Post subject: WMQ Server/Client Applications |
 |
|
Novice
Joined: 02 Mar 2009
Posts: 15
|
Hi,
As I remember, a WMQ program can be either a server application or a client application, but can't be both.
Does anyone know how to find this in IBM's books? I need to convince my co-workers for an application design.
Thank you for your help.
Grant Li |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Mar 02, 2009 4:20 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It depends on what you mean.
An application can only create "bindings" connections to local queue managers, or "client" connections to queue managers over the network.
You can't mix and match these two connections within the same application, even in Java.
But an application making "client" connections can be acting as a server application processing requests from client applications (which can be using "bindings" connections). |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Mar 02, 2009 4:29 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
More specifically, client bindings means that the connection will take place across an MQ SVRCONN channel, while the non-client bindings means that the connection will take place cross-memory - the application executing in the same o/s instance.
A client-bindings application can run in the same o/s instance, but the connection will not be cross-memory.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Mar 02, 2009 5:43 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
bruce2359 and mqjeff referred to the methods of connecting a MQ application to a Queue Manager. Maybe guogangli was asking about Client vs Server as a general middleware paradigm.
An MQ application can be either or both, it all depends on how the messages are designed to flow. A Client would typically put a request message in MQ to be consumed by a Server. The Server may then respond back to the Client by putting a response mesage in MQ.
_________________
Glenn |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 02, 2009 6:50 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| And here I thought I'd referred to both. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 03, 2009 7:52 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| As I remember, a WMQ program can be either a server application or a client application, but can't be both. |
MQ imposes absolutely no restrictions on what kind of application you write.
So, your app can be the client kind, the server kind, or both client and server, or neither client nor server.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| guogangli |
| Posted: Tue Mar 03, 2009 9:54 am Post subject: |
|
|
Novice
Joined: 02 Mar 2009
Posts: 15
|
Thank you very much for your replies.
This is a C++ application with WMQ server binding. The application is linked in with WMQ server libraries. The application is running on multiple Solaris boxes, each connects to its local queue manger.
A new portion that added into the same application requires to send messages to a remote queue manager. Currently we are using sender/receiver channels.
The concern is the message orders. If one the channels goes down, the orders may break .
The thought is to change sender/receiver channels to client/server channels.
My impression is the two WMQ bingings, server and client, can not be mixed into one application (or executable).
Thanks again. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 03, 2009 9:58 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You're correct, you can't mix and match the two connection types in the same app, because you have to compile and link your C++ app against one of two different libraries.
You're correct that message ordering causes a lot of infrastructure concerns.
You're incorrect that the right way to solve the problem is to do anything other than eliminate the message ordering requirements. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Mar 03, 2009 6:39 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| mqjeff wrote: |
| And here I thought I'd referred to both. |
You did. I just thought I'd reinforce the concept without relating to connection sytle. 
_________________
Glenn |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Mar 03, 2009 6:42 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| guogangli wrote: |
...
The concern is the message orders. If one the channels goes down, the orders may break ... |
MQ does not guarantee message order, so applications should never be designed to rely on order of delivery. 
The applications should have some form of message marshalling, eg. temporary storage in a database with sorting on a key that indicates the processing order.
| Quote: |
| ...The thought is to change sender/receiver channels to client/server channels... |
That raises more issues than it solves.
_________________
Glenn |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 03, 2009 9:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
You're correct that message ordering causes a lot of infrastructure concerns.
You're incorrect that the right way to solve the problem is to do anything other than eliminate the message ordering requirements. |
 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gunter |
| Posted: Wed Mar 04, 2009 12:46 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2004
Posts: 307
Location: Germany, Frankfurt
|
| gbaddeley wrote: |
| MQ does not guarantee message order, so applications should never be designed to rely on order of delivery. |
Than it's not really a queuing system. It's a definition of a queue, first in - first out. Maybe there a a few exceptions in MQ, FAST channel and nonpersistence messages. Please point me to the disclaimer in the doc.
_________________
Gunter Jeschawitz
IBM Certified System Administrator - Websphere MQ, 5.3 |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 04, 2009 1:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gunter wrote: |
| Than it's not really a queuing system. It's a definition of a queue, first in - first out. |
So all the LIFO (Last in, First Out) systems are not really queues then? How would you describe them?
As to the link, any part of the docs describing priority will describe how messages may not be presented to a reading application in delivery sequence. Likewise the description of channels, and any part of the clustering manual.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Mar 04, 2009 1:22 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| gunter wrote: |
| Than it's not really a queuing system... |
A queue, by the Oxford English Dictionary definition, is:
| Quote: |
| • noun 1 a line of people or vehicles awaiting their turn to be attended to or to proceed. 2 Computing a list of data items, commands, etc., [b]stored so as to be retrievable in a definite order. |
So WMQ is a queuing system, and more flexible than the above definition allows for.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 04, 2009 7:33 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| MQ does not guarantee message order... |
Not quite accurate. MQ preserves message order under some conditions, but not all. This is well documented in the APG.
This is actually a discussion of message-affinity, where; somehow one message is related to the next - in this post, by time order.
Ignoring for a moment MessageGroups...
Message order will be preserved (for a local queue) if only one application is MQPUTting messages to a queue AND only one application is MQGETting messages from the same queue. If two applications are MQPUTting, then it is possible that messages will be interspersed. If two applications are MQGETting messages, then it is possible that one app may get a message belonging to the other app.
MQ cannot preserve message order where some messages are MQPUT or MQGET in syncpoint and some outside syncpoint.
MQ cannot preserve message order when messages flow across networks where one message may take an alternate path or end up in a dead-letter queue.
Message Groups (and GroupId in the MQMD) allow an application to preserve message order.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
