• 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

JMS Question

 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Guy's,
I've got a little problem on how to do something @ work.

Well, imagine that you've got a lot of people that can put message in a queue. But you want this queue to be read by more then one user but only 1 user at the time.
so ... you want that the next person that connect to the application read the first message on the queue.

For example :

User 1 : put message A in reception queue
User 2 : put message B in reception queue
User 3 : put message C in reception queue

After, this the user 4 is connecting to the application and when it connect on the home page, the user 4 read's the first message on the queue. So it read the message A.
The user 5 connect .. it reads the message B .. and guess what : user 6 read the message C.

My concern is how to do that with EJB3, without using for example the JBOSS toolkit that can give you how to do this by the @ Comsumer method.
My problems is that the EJB3 Message Driven Bean has the onMessage and it always listen on the Queue. So this scenario is not possible with that kind of
message.

Im a little confuse , can someone help me with that ?

Thanks.
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Christian, your concepts of "people" and "users" in regards to messaging are a bit awkward. Messaging is a communications mechanisim for an application to communicate with another application. For example, Application A sends a message to Application B instead of having a hard-coded dependency. This mechanism is a building block for distributed computing.

In regards to your example, having multiple applications posting messages to a message queue and having multiple applications reading from a message queue are not the same concept. Attempting to use the same message queue for both scenarios is not good. You should start to think about multiple queues for multiple applications. And stop thinking that humans are posting messages and humans are not reading messages.
 
christian leclerc
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, thanks.
Then my message driven bean will receive the information and put the information on database.
The messaging will keep my code with loose coupling though in case of having another application that can catch this request for another time.


 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Then my message driven bean will receive the information and put the information on database.



The Message-driven EJB will receive the message and extract data from the message. It should pass this
data to a Data Access Object (DAO). And code statements in the DAO will insert the data into the database tables.

The point being, the Message-driven EJB class should not contain business logic or data logic. It is only there to grab messages from a message queue.

If there is any business logic to be done with data contained in a message, then data is passed from Message-driven EJB to a business object which then does processing and calls the DAO to get data into database tables.

Hope this helps.
 
christian leclerc
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yeah indeed, when I saved item in database is always with DAO.
No logic in MDB, is a must but thanks for your help to solve my problem , you give me the hint that I wanted somebody to valid me ;)!

Have a nice morning,

Chris.

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

saving messages in a database has of many advantages with regard to safety, archiving, making statistics, etc. In a project I was working on, all incoming and outgoing messages were saved in a db and finally that db was the main tool for testing and for maintenance in production. For instance, when a customer complained about something we where able to look at the db and to prove that he had sent the wrong data. So I can highly recommend the db-solution.

Nevertheless let me describe a solution that solely uses the queue: Instead of using a MDB that reads the queue you can use a SLSB that's accessed by the users who want to read the messages. The invoked business method reads the message from the queue and returns the content to the user. Since the messages are read first-in-first-out from the queue (if configured accordingly) you get the behavoir you want. You could even replace the SLSB by a singleton bean in order to be completely sure about serialization.



 
christian leclerc
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, I had not clue about SLSB.
Well I use Message Driven bean to put data in my database. So in the worst case, if the database is down , the message will remain in the queue.
I've got the advantage of the 2 technologies !

But thanks for the SLSB information, I will read on that !

A+

Christian.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic