• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

handling synchronous/asynchnronous modes

 
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi there,

I would want to know your viewpoint on this design. There are two modes of triggering an application.
In asynch we are planning to have an MDB which consumes message from the queue and invokes a sessionBean which in turn calls the core java biz application.
The second (synch) mode (web app - jsp/servlet) talks directly to the aforementioned sessionBean.
We need to respond back to the calling app in both the cases. So with the asynch mode we are thinking on the lines of having another (outbound) queue which will have the resultant message pushed by the sessionBean.
Is it a good idea to have the sessionBean discern its caller (MDB or servlet) and handle the response mechanism accordingly.
Or is there a better way of handling the same inside the SessionBean.

Do let me know your thoughts on the same.

-Manish
 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I understood correctly, onMessge() method of your MDB invokes the sessioBean method and it returns the response back. Now what you have to do is push the response into the outbound queue. In order to do this you don�t need a session bean because of you are not going to expose a method (entry point) to outside the container here. Push the message to outbound queue directly by your onMessage().
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, your session bean should definitely *not* know about its caller, as that would be tight coupling, leading to rigidity of the system - everytime a caller changes, or a new caller gets added, there is a likelihood that you also need to change the session bean. It's also hard to reuse the session bean in a different context. Not good.

What you could do - if this needs to be done by the session bean at all - , is using the Strategy design pattern: create an interface for handling the message, for example called MessageReceiver, with a single method that simply gets a message. Have to implementations, one for synchronous, one for the asynchronous case. Pass in the right implementation when you call the session bean. The session bean then just needs to delegate to the receiver, without knowing at all what happens to the message after that.
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The business logic of the application should be coded in a Session EJB or POJO class. Coding business logic in a Message-Driven Bean is a bad practice. The only code that should be in the MDB is code that handles processing of a message, and in this case, handling the response.

MDB receives message and invokes business logic in Session EJB.

Servlet receives request from user and invokes business logic in Session EJB.

Code in both servlet and MDB should handle response from Session EJB accordingly.
[ October 22, 2008: Message edited by: James Clark ]
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic