| Author |
Message
|
| shehryar |
 Posted: Thu Mar 11, 2010 5:44 am Post subject: Recommendation for local WMQ installation vs. Remote Queue |
 |
|
Novice
Joined: 11 Mar 2010
Posts: 14
|
Hi,
Is there a recommendation on designing the landscape when a third party EAI system communicates with WMQ Server using the JMS adapter?
There is an ESB in place which connects with WMQ Server. On third party EAI side, does it make sense to install a local WMQ server hosting queue manager for local persistance? This local server then connects with WMQ connected with ESB.
Any landscape recommendations?
Regards. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Mar 11, 2010 6:51 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
It all depends on the way you plan to connect, whether or not you need multiphase commit, JCA etc...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Mar 11, 2010 7:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| It always makes sense to endpoint external MQ connections at a gateway qmgr. |
|
| Back to top |
|
|
| shehryar |
| Posted: Thu Mar 11, 2010 2:27 pm Post subject: |
|
|
Novice
Joined: 11 Mar 2010
Posts: 14
|
Thanks for the response. I am from the third party software side, trying to understand WMQ deployment options. So please bear with me.
I have looked at various redbooks and manuals for WMQ. And I have seen something along the lines of what mqjeff said on a previous project. The customer had a remote Q on sending system...connected to a gateway...which was further connected to queues on two message brokers (for HA I believe). Queues on gateway were clustered, if I remember correctly. The messages were sent to a mainframe with local queues. However, in this case, there was no additional middleware in between.
In case there is an additional middleware with two way communication with central WMQ server, does the same configuration apply? Or does it make sense to have a local WMQ installation on the same host as third party middleware, with clustering? I'd personally prefer the gateway option but still would like to understand the implications of both designs.
Thanks in advance for your time. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 11, 2010 9:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
MQ clustering does load balancing...
Hardware Clustering is for High Availability.
Two different concepts that can be mixed and matched...
You have to go with the costs and requirements
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| shehryar |
| Posted: Fri Mar 12, 2010 12:20 am Post subject: |
|
|
Novice
Joined: 11 Mar 2010
Posts: 14
|
Hi fjb_saper,
Thanks for the clarification. I mixed the two terms...my bad 
Keeping costs aside for the moment, the requirement is to have SAP PI deliver JMS messages to/receive JMS messages from central WMQ. I think it makes perfect sense to have a remote Q configured on PI to handover messages and forget about them. These will then be passed on to a gateway for further transmission to central WMQ. Similarly, a local Q can be configured on PI for receiving messages.
However, I am trying to understand the benefits to have a local WMQ Server with clustered queues? Does it really add any value or is it an overkill? |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Mar 12, 2010 1:16 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
I would find it surprising if an enterprise allowed a third party into their queue manager cluster(s). As mqjeff stated, better that you have a gateway queue manager that connects to 'their' gateway queue manager. Make your gateway hardware clustered and there should be no problem with availability.
As to whether you want to put additional queue manager behind your gateway is a design decision dependent on many factors, too many to go into here, but in general a gateway queue manager is just a routing mechanism and it's not usual for it to service applications, i.e. hold application QLOCAL's.
_________________
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 |
|
|
| shehryar |
| Posted: Fri Mar 12, 2010 4:18 am Post subject: |
|
|
Novice
Joined: 11 Mar 2010
Posts: 14
|
Thanks exerk. Just to clarify, by third party I meant non-WMQ system. The organization is using SAP PI for SAP-SAP integration and PI-WMQ for SAP-nonSAP integration based on JMS.
So the general recommendation would be...
1. SAP PI with local Queue Manager (configured for RemoteQ and LocalQ). Allows local persistance if network goes down. SAP PI will be Hardware clustered for HA.
2. Gateway Queue Manager (clustered queues, routes to Central WMQ)
3. Central WMQ (clustered queues, routes to desintation systems)
Do you see any pitfalls in this design? And does it still make sense to use a gateway if PI and WMQ are inside the same network?
Thanks again for your time. |
|
| Back to top |
|
|
| shehryar |
| Posted: Fri Mar 12, 2010 8:09 am Post subject: |
|
|
Novice
Joined: 11 Mar 2010
Posts: 14
|
Ok, just found out that if a local QM is configured on PI, and if it is not part of the cluster on central WMQ, then a gateway is required to connect local QM with QMs of centrally clustered queues.
So if the final configuration demands that the local QM on PI is made part of the cluster on central WMQ, then gateway isn't required. Otherwise, it is. Please correct me if I am wrong.... |
|
| Back to top |
|
|
| sumit |
| Posted: Fri Mar 12, 2010 8:46 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
A Gateway is required so that internal middleware config is not exposed to end site/3rd party qmgrs. At the same time, it's easy to manage.
If you still want your local QM to be part of cluster and you expect that the number of similar local qmgrs (spokes) can increase, then you can create a new cluster having end site and gateway as a part of it.
If there will be jst 1 local qm (as spoke), then instead of adding it to the main cluster, connect it with gateway using distributed queuing.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| shehryar |
| Posted: Sat Mar 13, 2010 7:37 pm Post subject: |
|
|
Novice
Joined: 11 Mar 2010
Posts: 14
|
Thanks Sumit. This makes perfect sense.
Regards. |
|
| Back to top |
|
|
|
|
