• Post Reply Bookmark Topic Watch Topic
  • New Topic

Question about two Design alternatives for using EJB and JMS in a specific scenario

 
Kai Wähner
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everybody,

we are discussing a question about the design of a JEE application which uses JEE 1.4 and EJBs (MDBs and Stateless Beans).

A stateless bean is already available which does some business logic. Also a MDB is available which receives a text message from a queue, calls the stateless bean and then sends the reply to another queue. This functionality must stay as it is and is already in production.

In the future, we will also receive other text messages, where the body / content must be manipulated, before we can use the stateless bean to do the business logic.

We are discussing two alternatives:

---------------------------------------------------------------------------------------------------------

1) Use a new MDB which does the manipulation and then send the manipulated message to the stateless bean.

Disadvantage: We need two extra queues. Is it bad design (and maybe performance) to use local queues, so we would misuse the MQ concept to send messages from one local queue to another local queue?

---------------------------------------------------------------------------------------------------------

2) Use the old MDB. We would add two methods to the stateless bean preProcess() and postProcess(), which are only executed if a text message of the new format arrives, not if an message of the old format arrives. Therefore we would add emtpy preProcess / postProcess methods. Then a bean - which extends from this bean - would implement these methods.

Disadvantage: We misuse the "extend"-functionality of Java because it is not the intention of "extends" to add empty methods and only implement them in a sub-class, isnt it?

---------------------------------------------------------------------------------------------------------

What alternative would you choose, or maybe you even have a better proposal?

Thank you a lot... Greetings Kai
 
ramprasad madathil
Ranch Hand
Posts: 489
Eclipse IDE Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The change is in the MDB which has to branch out and take two different actions based on the new kind of text messages? And there is no change to the SLSB which continues to receive a call from the mdb?

If that is correct, why not simply add a property to the messages which indicate the kind of text message it is?
Write a new MDB which has a MessageSelector that makes it receive the right type of message (the new message). The old MDB too should be slightly modified to add a MessageSelector so that it receives only the messages of the old type.

Is there something you have not mentioned in your post which makes this approach untenable?

ram.
 
Kai Wähner
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Ram,

a MessageSelector is a great idea (I never thought about this possibility before), but I forgot to mention: We will use different queues for the old and the new messages (I cannot tell you the reason at the moment, but this is a requirement). So I think, a selector does not make any sense, the request messages will be send to two different queues. Also I would have to check if we can change the old MDB and add a message selector to the old message - I dont think so :-(

We want to reuse as much code as possible (dont repeat yourself principle), otherwise we could simple write a new MDB which does everything the old MDB does plus the new pre- and postprocessing.

So we came to the ideas 1) and 2) described above. I think the most important design question is, if misusing MQ for messages which are send from one local queue to another local queue is bad for any reasons ?!
Otherwise I like the idea to use a new MDB for preprocessing, then forwarding the message to the old MDB, waiting for the response from the old MDB, doing postprocessing and then sending the response to the response queue.


Greetings Kai
 
ramprasad madathil
Ranch Hand
Posts: 489
Eclipse IDE Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
a MessageSelector is a great idea (I never thought about this possibility before), but I forgot to mention: We will use different queues for the old and the new messages (I cannot tell you the reason at the moment, but this is a requirement). So I think, a selector does not make any sense, the request messages will be send to two different queues. Also I would have to check if we can change the old MDB and add a message selector to the old message - I dont think so :-(


Ok that's out then.

We want to reuse as much code as possible (dont repeat yourself principle), otherwise we could simple write a new MDB which does everything the old MDB does plus the new pre- and postprocessing.


Why dont you simply write a pojo (backed by an interface to determine lifecycle methods) and pass the Message to the methods of these pojos to do the actual work? That way you would have common functionality abstracted out to methods of this pojo ensuring reusability.

We have in fact something similar in our application. We call them MessageProcessors and we invoke the lifecycle methods of these processors for different kind of messages. The MDBs then basically act as Controllers. They receive the messages and invoke the processors to do the actual work.

then forwarding the message to the old MDB, waiting for the response from the old MDB, doing postprocessing and then sending the response to the response queue.


That does sound like additional overhead. As far as I know, it is perfectly valid to use multiple queues to do part message processing - a process and forward paradigm. But forwarding to another MDB just for part processing may be bad from a performance point especially when you could just use plain old java abstraction.

ram.
 
Kai Wähner
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Why dont you simply write a pojo (backed by an interface to determine lifecycle methods) and pass the Message to the methods of these pojos to do the actual work? That way you would have common functionality abstracted out to methods of this pojo ensuring reusability.

We have in fact something similar in our application. We call them MessageProcessors and we invoke the lifecycle methods of these processors for different kind of messages. The MDBs then basically act as Controllers. They receive the messages and invoke the processors to do the actual work.


You mean: Write PreprocessorABC.java and PostProcessorXYZ.java which offer the needed methods with the message as parameter, and then simply call these methods within the onMessage() of the MDB?
This sounds good, but therefore the logic of the old MDB must also be move to such a POJO e.g. Calculator.java, right? (or alternatively copy&paste the logic) - I will check, if this is possible in our scenario.

Then old MDB would use only Calculator.java, the new MDB would use all three POJOs, right?


That does sound like additional overhead. As far as I know, it is perfectly valid to use multiple queues to do part message processing - a process and forward paradigm. But forwarding to another MDB just for part processing may be bad from a performance point especially when you could just use plain old java abstraction.


Well, how would you realize process and forward with multiple queues then? You either have to use a MDB or the JMS API with receive() or onMessage(), dont you?

In our case:
External System --> RequestQueue1 --> new MDB: do preprocessing --> RequestQueue2 --> old MDB: do some logic --> ReplyQueue1 --> new MDB: do postprocessing --> ReplyQueue2 --> External System
 
ramprasad madathil
Ranch Hand
Posts: 489
Eclipse IDE Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You mean: Write PreprocessorABC.java and PostProcessorXYZ.java which offer the needed methods with the message as parameter, and then simply call these methods within the onMessage() of the MDB?
This sounds good, but therefore the logic of the old MDB must also be move to such a POJO e.g. Calculator.java, right?


Exactly


Then old MDB would use only Calculator.java, the new MDB would use all three POJOs, right?


Yes


Well, how would you realize process and forward with multiple queues then? You either have to use a MDB or the JMS API with receive() or onMessage(), dont you?


The point I was making was that you do not need to use process and forward just to reuse mdb code. If you have logic where there is a need for asynchronous processing in multiple stages, that's where this is a candidate for.

Say for example, you have an MDB that processes a Purchasing Order (PO) and while doing this work, it detects that the inventory is low and spawns a messgae which triggers another MDB that does an Inventory replenish.
Also after finishing it's original work of Processing the PO, it can trigger off another message which sets into motion the approval (or invoicing) of the PO.

Dont just take my word as the approach I have outlined is how I would have gone about achieving the original objective. You should discuss with others in your team, other members of this/other forums

ram.
 
Kai Wähner
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, thank you for your comments. You helped me a lot thinking over the problem...
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!