| Author |
Message
|
| murdeep |
 Posted: Mon Oct 05, 2015 9:26 am Post subject: IIB V10 Client MQInput |
 |
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| In IIB V10 MQInput nodes can connect as MQ client and consume messages from queues. So pre V10 in a hub and spoke topology with IIB running at the hub and spokes clustered via MQ messages would be sent to cluster queues exposed by the IIB broker qmgr where a flow would consume them. In V10 I can now configure my flow's MQInput node to client connect directly to a local queue at the spoke qmgr and consume the messages. What would I use as a criteria to choose the pre V10 configuration versus the V10 client configuration? Is one any better than the other? If I wanted transactional support would we need to pay extra for the transaction client at the IIB hub? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Oct 05, 2015 9:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The MQ Transactional client is no longer an extra charge.
You would choose between client to several qmgrs and client to a single qmgr based on the MQ topology.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| murdeep |
| Posted: Mon Oct 05, 2015 12:42 pm Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| mqjeff wrote: |
The MQ Transactional client is no longer an extra charge.
You would choose between client to several qmgrs and client to a single qmgr based on the MQ topology. |
Ok so now in V10 say I have an IIB flow that is a simple MQInput->Compute->MQOutput. The MQInput client connects to qmgr A to get the message to process and needs to send it to a queue at qmgr B. I gather that the MQOutput node would also client connect to qmgr B. My concern is how is the UOW now managed? Thinking back to my days as a programmer the MQConn to qmgr A gives me a hconn and the MQConn to qmgr B gives me an hconn. How would the UOW be managed to ensure that a single commit point commits both the get and put? |
|
| Back to top |
|
|
| vennela |
| Posted: Mon Oct 05, 2015 8:45 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| I think the criteria should be between synchronous vs asynchronous when you use MQCleint vs MQ Bindings mode |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 06, 2015 5:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| vennela wrote: |
| I think the criteria should be between synchronous vs asynchronous when you use MQCleint vs MQ Bindings mode |
Ok. But if I was an overall MQ admin, and someone started making MQ client connections to all of my "spoke" qmgrs, rather than to my Hub queue manager or the specific spoke assigned for their use... I think I would not be too happy.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| timber |
| Posted: Tue Oct 06, 2015 5:50 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1280
|
Correct me if I'm wrong, but I think murdeep's question could be rephrased like this:
'In v10 Ãs there any reason to create a queue manager for IIB to use. Or is it always OK for the IIB instance to read and write directly from/to the gateway queue managers?' |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 06, 2015 6:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Murdeep mentions both hub and spoke and clustering.
Which are kind of the opposite things, topology wise. But that's besides the point, I think.
Given an IIB v10 installation, and the need/requirement to process MQ messages, then the IIB v10 installation will need to connect to an MQ queue manager. This qmgr can either be local or remote.
The temptation, I think, using MQ Client connections from IIB is that one would use different qmgrs for different MQ nodes. This is what I was addressing about an MQ Admin's feelings.
If one ensures that IIB only talks to a single qmgr, then I agree with venella - one needs to evaluate the tradeoffs of client vs bindings.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 06, 2015 8:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| timber wrote: |
Correct me if I'm wrong, but I think murdeep's question could be rephrased like this:
'In v10 Ãs there any reason to create a queue manager for IIB to use. Or is it always OK for the IIB instance to read and write directly from/to the gateway queue managers?' |
I think the question, which covers the valid issue raised by my most worthy associate, is better phrased as:
"If I read from a hub with an MQInput using a client connection, and write a reply with an MQOutput to the same hub (potentially using a separate connection), is that in a single UoW?"
IMHO the answer is "yes", because the flow is a single thread and a single thread only ever has a single "HConn" to a single queue manager.
If you're bridging from spoke queue manager A to spoke queue manager B in a single flow in a single UoW, I'm with my most worthy associate.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| murdeep |
| Posted: Tue Oct 06, 2015 2:12 pm Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| mqjeff wrote: |
Murdeep mentions both hub and spoke and clustering.
Which are kind of the opposite things, topology wise. But that's besides the point, I think.
Given an IIB v10 installation, and the need/requirement to process MQ messages, then the IIB v10 installation will need to connect to an MQ queue manager. This qmgr can either be local or remote.
The temptation, I think, using MQ Client connections from IIB is that one would use different qmgrs for different MQ nodes. This is what I was addressing about an MQ Admin's feelings.
If one ensures that IIB only talks to a single qmgr, then I agree with venella - one needs to evaluate the tradeoffs of client vs bindings. |
We have a hub and spoke topology implemented with MQ clustering. We ensure that the spokes can only communicate with the hub where our full repositories reside along with our IIB Integration nodes. Spokes do not communicate directly since we want everything flowing through IIB for event management, logging etc. So I wouldn't say MQ clustering and hub and spoke are necessarily opposites in this design but rather complimentary.
Now with V10 IIB we can now client connect so in my environment it is possible to route from spoke or qmgr A to say spoke or qmgr B by doing a MQInput(Client to A)->Compute->MQOutput(Client to B) no messages need to flow to my hub qmgr in order to go from qmgr A to qmgr B. From an MQ admin view it's simpler since I don't have to concern myself with full repositories, partial repositories, clusters, namelists, clussdr/clusrcvr channels etc.
Now note I am not saying it is a better solution than server to server but nonetheless it is now an option. Now if it is an option I must weigh the pros and cons and the first con I see is UOW. A MQ server can be a resource co-ordinator but if it is I do not believe another MQ server may be a participant. So I am wondering how the IIB and WMQ architects will view the MQInput(Client to A)->Compute->MQOutput(Client to B) paradigm. I see this as having hole where you can have duplicate messages if the MQOutput commits but then you fail before the MQInput commits. I am curious if other SMEs on the board have considered this now with V10 being available. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Oct 06, 2015 10:37 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The Remote QM 1--> IIB --> Remote QM 2 scenario is certainly possible.
However a good number of sites use MQ for other things. Things such as Monitoring Events, HTTPNodes and other nodes (at the moment) that use MQ under the hood, and for us, Logging.
We send Log/Audit/Error messages using MQ. so for us Not having an associated QMGR with an IIB Instance is just not a choice.
Sure we could modify it to use a remote connection to an specific QMGR but honestly, it is far too much Faff to be bothered with. IMHO, it is far better to just drop a committed message onot a local queue from the message flow and let MQ handle it from there on. Classic 'Fire and forget' IMHO.
Just my 2p worth so it can be ignored.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 07, 2015 4:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| murdeep wrote: |
| From an MQ admin view it's simpler since I don't have to concern myself with full repositories, partial repositories, clusters, namelists, clussdr/clusrcvr channels etc. |
From this MQ Admin's point of view it's a nightmare. What you're describing is a series of unconnected queue managers with the only links being the IIB flows. You've clearly elected not to do that with your existing topology (because IIBv10 now acts like your existing client apps) for good and sufficient reason, and that still holds.
As an admin, I don't want a web of SVRCONN channels. I want some control over message flow, message priority, the ability to use pub/sub and the decoupled joy that only an XMITQ can bring. I don't want every single application (especially every single application all running under mqbrkrs) authorized to every single queue manager. I want my controlled topology, where it's easy to see when some application is being a jackass, where sanction is available and multiple routes can be defined for those 25Mb Java-Classes-Serialized-As-XML messages can lumber between queue managers and not spook the herd of tiny SOAP-over-JMS messages trying to meet their sub second SLA.
Other opinions are equally valid, may be more valid and are almost certainly less crazy in a variety of cases.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Oct 07, 2015 4:57 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
I can see the IIB v10 MQ client connection being a bit of a nightmare to control.
With v9 - I know which QM the flow connects to. Simple.
With V10 - it could be trying to connect anywhere - how do I even know what they have coded?
Also IBM are using MQ policies and not configurable services which is confusing.
The risk of environment pollution (Prod accessing non-prod queues because the promotion has not correctly updated the connection details) will be high.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 07, 2015 5:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| With V10 - it could be trying to connect anywhere - how do I even know what they have coded? |
Insist on the use of an MQ Service, and enforce it like any other coding standard. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Oct 07, 2015 6:24 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Which planet are you on? 
We need runtime enforcement capability - aside from the impossibility of enforcing development standards on people 5000 miles away, there is also the issue of accidental deployment of the wrong MQ configuration in a bar file.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 07, 2015 6:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| Which planet are you on? |
I've been asked that a few times. The sky is an interesting shade of purple, but I'm not sure if it's that color or just looks like it to me.
| zpat wrote: |
| We need runtime enforcement capability - aside from the impossibility of enforcing development standards on people 5000 miles away, there is also the issue of accidental deployment of the wrong MQ configuration in a bar file. |
I can enforce development standards from any distance but I was referring not to a local configuration but a service stored in the broker thus. If the service is stored and published, you maintain administrative control.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
