| Author |
Message
|
| mathew78 |
 Posted: Wed Nov 23, 2005 10:58 pm Post subject: When to Use Server - Server Communication in MQ Series |
 |
|
Newbie
Joined: 23 Nov 2005
Posts: 2
|
Hi all,
I have a basic question in Websphere MQ/MQ Series. I know MQ Series can be used in client - server communication i.e a client in Java or C can talk to a MQServer residing in a different server and in Server to Server commnuication i.e MQ Series Server to MQ Series Server.
My question is when do we need Server - Server communication? Why not two application talk to each other using one MQ Series Server..
Thanks
Mathew |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Nov 24, 2005 6:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Becuase you have two apps that need to run on different machines that need to talk to each other. Suppose for instance one is a COBOL app running a mainframe and the other is a Java app running on a linux machine.
Then either one app needs to use the client (which isn't available on the mainframe!), or they both need qmgrs.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jsware |
| Posted: Thu Nov 24, 2005 7:09 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
This is a question with a thoughsand variables that affect the answer. Try searching this site for all the terms: advantages server client
This might help you determine what you requirements are.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| fschofer |
| Posted: Thu Nov 24, 2005 7:33 am Post subject: |
|
|
Knight
Joined: 02 Jul 2001
Posts: 524
Location: Mainz, Germany
|
WebSphere MQ V6 Fundamentals
http://www.redbooks.ibm.com/redpieces/abstracts/sg247128.html
3.3.3 Hub and spoke WebSphere MQ architectures
| Quote: |
Connecting to a WebSphere MQ queue manager as a client has limitations. A
network connection is placed between the application and the queue manager,
which has performance implications, especially over longer distances. This also
requires that a network connection is available in order for the application to
operate. The interaction between the application and the queue manager over
that network connection is synchronous, although WebSphere MQ manages that
connection for the application.
This single queue manager approach can be scaled, without alteration to the
application, to include multiple queue managers.
Applications accessing a service can have a queue manager hosted on the same
machine, providing a fast connection to the infrastructure, and gain
asynchronous communication with the service hosted on another queue
manager.
Alternatively applications accessing a service can connect as clients over a fast
network to a queue manager, for example, all applications accessing a service in
a branch office. Asynchronous communication occurs through this queue
manager to the services hosted on another hub queue manager.
These applications themselves can be implemented to provide an external
interface into the service, for example, by providing an interface over the Internet
through a Web browser.
The queue managers through which the services provided by the hub are
accessed are called the spokes of a hub and spoke WebSphere MQ architecture.
A machine, such as a mainframe or server hardware, can host the applications
providing the service. This machine hosts a hub queue manager, holding the
queue from which these applications process messages. This same machine
can host other resources required by those applications, such as a database.
Many instances of the applications providing the service can process requests
from the same queue, depending on the implementation of the applications
providing the service.
This type of architecture is developed by manually defining the routes from the
spoke queue managers to the hub queue managers hosting individual services.
Multiple services provided by the infrastructure can be hosted on different hub
queue managers, or through multiple queues on the same hub queue manager. |
Greetings
Frank |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Nov 24, 2005 7:40 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Aside from mainframes which must have their own queue managers, we prefer to provide centralised, highly available, shared-use queue managers and app servers use a MQ client to connect to them.
MQ clients are free, which is one very good reason to use them. I prefer to separate queue managers from application servers when possible. Also multiple app servers can access the same queues which is not possible if each have their own queue manager.
You can therefore have very efficient and simple to operate load balancing and app failover (several app server clients "pulling" messages from the same queue).
You can also connect MQ client to a mainframe queue manager. |
|
| Back to top |
|
|
| mathew78 |
| Posted: Mon Nov 28, 2005 9:13 pm Post subject: When to Use Server - Server Communication in MQ Series |
|
|
Newbie
Joined: 23 Nov 2005
Posts: 2
|
Thanks every one. I am clear now on when to use client to server or sever to server connection.
Thanks
Mathew |
|
| Back to top |
|
|
| hopsala |
| Posted: Tue Nov 29, 2005 7:59 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
|
| Back to top |
|
|
| gorilla |
| Posted: Wed Nov 30, 2005 9:57 pm Post subject: |
|
|
Novice
Joined: 17 Nov 2005
Posts: 16
|
FWIW, here's my short list of differences between client-server vs server-server with an app which connects directly to one of the servers:
Client to server is a synchronous connection - no connection, no MQ calls. This is ok in a highly reliable environment, but otherwise you (may) have to code for temporararily saving "Work In Progress" instead of delegating that to the MQ server.
Clients can't do a 2-phase commit (eg global transaction for input message + DB updates + output message).
If you need this you probably shouldn't build the reliability in by hand - it's a lot of work to build and maintain, you need to be *very* sure your coders know how to do it properly. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 01, 2005 4:35 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| gorilla wrote: |
Clients can't do a 2-phase commit (eg global transaction for input message + DB updates + output message).
If you need this you probably shouldn't build the reliability in by hand - it's a lot of work to build and maintain, you need to be *very* sure your coders know how to do it properly. |
The Extended Transactional Client can do this, but it costs as much as a full QM, but then there is less administration overhead without a QM on each client server.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
