| Author |
Message
|
| HenriqueS |
 Posted: Thu Jan 06, 2011 11:43 am Post subject: Triggering a Websphere transaction... |
 |
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Hello,
Whats the most appropriate way to trigger a WebSphere transaction from an MQ trigger?
As far I know there is no way I can create a Process definition object that points to a Websphere transaction (I´d love if IBM provided this, since it already exists for CICS).
Here at my job, people implemented a homemade (java) trigger monitor that checks our init queues, and when a notification message arrives, goes after the queue that originated it, and then starts a WebSphere transaction to get the incoming messages.
We would like to simplify this architecture, eliminating such homemade trigger monitor...it would be paradise if IBM provided direct start of WAS transactions...funny this is provided for CICS! |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Jan 06, 2011 11:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Using a Message Driven Bean? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 06, 2011 11:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
When in WAS you should be using the J2EE model and message driven beans... (see JMS)
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Thu Jan 06, 2011 12:44 pm Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
In the first research on our new messaging architecture we did check about the use of MDBs...
Back that time, our JE22 development and admin teams found the following cons (thanks we had this written down):
1) The J2EE standard specifies that every MDB has an unique link to a queue. So each MDB only serves one MQ file. With this limitation, our new messaging architecture would require the deployment of hundreds of almost identical MDBs mainly to because for every message partner we require four queues. Not only that, but we do today interact with more than one hundred partners.
2) Since each MDB allocates a respectable memory amount for the management of its resources, this solutions implies in intense and inefficient usage of system memory.
So folks, any light to the two arguments above? They still valid? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 06, 2011 1:02 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| 2) Since each MDB allocates a respectable memory amount for the management of its resources, this solutions implies in intense and inefficient usage of system memory. |
I'll wait a few moments for someone else to pick up on 1)...
The amount of memory required is sufficient and respectable, and is used as efficiently as Java does anything. With the price of RAM dropping like dead birds in the US mid-west, this is not really a consideration today.
_________________
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 |
|
|
| mqjeff |
| Posted: Thu Jan 06, 2011 1:24 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So at a minimum you could use an MDB as a Trigger Monitor, and do something to associate it the contents of the trigger message with the necessary information to start the necessary transaction.
This way at least you aren't writing a full blown "trigger monitor", just something that knows how to start the correct transaction based on a given trigger message.
And you're already inside WAS so you're not having to do anything too funny. |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Thu Jan 06, 2011 2:16 pm Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Let me see if I got it right...
1) Create an MDB for each of the init queues my partner queues point to. Simplify this by pointing several partners queues to one init queue.
2) WAS will be watching these init queues and start the onMessage() method for each notification message that arrives on the init queue.
3) Inside the onMessage() method, get the notification message and parse it to get the information that points the partner queue name, etc. (need to check how to parse the contents of this kind of message).
4) Forward this information to other method that will lookup for the message partner queue and retrieve the incoming message.
That´s it?
If this works, it will simplify thins here A LOT.  |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jan 06, 2011 2:24 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
That's about it, yeah.
You should be able to read the trigger message as a BytesMessage and then parse the contents based on the MQTMC structure - there aren't that many fields really. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 06, 2011 9:28 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
@HenriqueS
Additional simplification:
If the different partners all go through the same process, why have different MDBs servicing them?
One MDB per process should do. Use MQ as concentrator and have all partners' data endup in the same queues.
If you use a request/reply model (whether synchronous or asynchronous) the reply-to information (queue + qmgr) should be sufficient to distinguish between partners and allow for the right response to go to the right partner...
To scale just add more instances of the MDB ... (then scale by adding more instances of the processing app, then scale by load distribution across an MQ cluster etc...)
Yes you will need to plan for n+1 connections per MDB (with n instances). These will however be cached in the JMS connection pool.
You might need to plan for 2n+1 if you send a reply instead of just consuming...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 06, 2011 9:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| 1) The J2EE standard specifies that every MDB has an unique link to a queue. So each MDB only serves one MQ file. With this limitation, our new messaging architecture would require the deployment of hundreds of almost identical MDBs mainly to because for every message partner we require four queues. Not only that, but we do today interact with more than one hundred partners. |
Supposing that each partner sends the same 4 transactions, 4 MDBs should be enough to take care of all partners.... I don't see the need to keep the partner data isolated queue wise at the processing layer (MDB) as it would be isolated message wise... and the partners would not have access to this processing layer...
This also implies a strict error handling and poison message handling that allows you save the original message (including origin information).
You might want to double that (kind of probationary period for a new partner) until you know he is not going to throw a wrench into the well "oiled" system. However this gets usually weeded out by the passage through DEV and QA environments...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
