| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message broker (split/aggregation) using J2EE |
« View previous topic :: View next topic » |
| Author |
Message
|
| czaszek |
 Posted: Fri Jan 26, 2007 11:10 am Post subject: Message broker (split/aggregation) using J2EE |
 |
|
Apprentice
Joined: 30 May 2006
Posts: 36
Location: Poland
|
Hi All
I am to help some people to make an architecture for new system and am not sure whether their approach is good.
The main idea of the system is to work as a broker, an example flow looks like that:
1. a message received from one client (read a request from MQ queue)
2. do a split of the message (request) to several small submessages (subrequests)
3. send them to few other clients (via other queues)
4. wait maximum 40sek. (for example) for responses from the clients (used in point 3)
5. aggregate all subresponses into one big response (if there was no answer from any client than generate a timeout subresponse instead)
6. send back one big answer to the client which sent the request in point 1.
Is it possible to implement the solution using standard J2EE EJBs (MDB, Session Bean)?
My question is because as I understand (I am not programmer) a MDB can not be connected in any way with a Session Bean which produces the requests (sends them in point 3) to make the communication synchronous (to implement the timeout, which is critical for us).
We will use MQ as transport and one of AppServers (WebSphere or WebLogic, not decided yet).
I know that we could use WebSphere Message Broker instead but it costs a lot and would like to be sure that there is no other way to implement it. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Jan 26, 2007 11:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The only difficulty you might doing this in J2EE is in managing your transactions.
You will have to either not use transactions at all, or manage them yourself in the code - so that you do not have the outbound subrequests waiting for the overall transaction to complete.
I am not aware of any restrictions for MDBs that would prevent them from calling a session bean. Except that the session might not be what you think it is.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| czaszek |
| Posted: Sat Jan 27, 2007 1:17 am Post subject: timeout |
|
|
Apprentice
Joined: 30 May 2006
Posts: 36
Location: Poland
|
I understand that the MDB can call session bean. The problem is that the MDB is asynchronous.
Imagine the simplest scenario without a split:
1. the first client sends a message containing only one submessage
2. session bean retrieves the submessage and send it to another client
3. the another client is not available and sends no replay
4. MDB does not find anything in the queue so can not call the session bean
Here are two problems:
1. MDB in point 4 does not know which session bean should call
2. Even if he knew he could not implement any timeout message generation after he did not receive any response for a perticular request (which in fact was sent by other bean without his assistance). MDB is stateless and asynchronous.
Correct me if I am wrong. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Jan 27, 2007 5:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I thought you meant the MDB was calling individual session beans to handle the submessage processing.
You don't want to do it the way you've laid out, that's correct. You could do something to embed the session bean ID in the message - but it's a lot easier to handle this as a strict chain of request/reply patterns.
user -> session bean ---request-->MDB
user -> session bean ---wait for reply
MDB --request --> subquery1
MDB -- request --> subquery2
MDB -- wait for replies
Subquery1 ---reply-->MDB
Subqery2 --- reply-->MDB
MDB ---reply--->session bean --> user
I know it's that last step you're confused about. But it's the same request/reply pattern as each of the subqueries, and so it's correlated in the same way, using messaging.
If you need to implement a single transaction across all of the subqueries... you are going to have some big fun. So I'd recommend steering your client away from that notion.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
