• 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
  • Bear Bibeault
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • salvin francis
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Frits Walraven
  • Jj Roberts
  • Carey Brown
  • Scott Selikoff

Goal of MDB

Ranch Hand
Posts: 110
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,
I referred the specification of EJB3 which says

"The goal of the message-driven bean model is to make developing an enterprise bean that is asynchronously
invoked to handle the processing of incoming messages as simple as developing the same functionality
in any other message listener".

Can anyone please explain me the concept of above?

Amarshi mohanty
Ranch Hand
Posts: 110
Google Web Toolkit Java Google App Engine
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

That's a good question! The message driven beans are often used when you want to add some asynchronous feature to your software, they're built on top of JMS that's a message-oriented middleware and add a third guy on your app that helps a lot.

This third guy is often called broker, he is responsible to deliver the message sent to a given queue or to every subscribers of a given topic. The main advantage of using it is that you can send a message and trust that your message will be delivered in an arbitrary moment, but it will, unless that message triggers an error every time making it impossible to proccess it (it's called poisoned message).

E.g.: I've a real high rate of registers on my application at 2pm, I don't have a need to proccess them right the way, to ensure consistency I would have to ensure the necessary concurrency policies, the memory footprint of the registrations at that moment would be huge and probably even crash my app (if it isn't part of a cluster, what could be unnecessary to a simple register scenario). I could use a JMS producer to send the registration messages to a queue and configure that queue to a max proccessing rate of 4 registration/second and then turning my register implementation a litle bit more linear. (This isn't any kind of 2+2 solution that will work for every case in every scenario, but it's a good approach)

Another use could be if you want to notify a third party application but you don't want to worry if it's working or not, you just want to ensure it will be delivered whenever possible. You could send a message to it and let the broker deal with the many redelivers needed. Or better, you could want to notify a lot of other applications about something and don't want to worry with the when it will be delivered just if it will, and the broker will ensure you that he will deliver that. These techniques are often used as somekind of event bus to notify parts of a application that something happened and to trigger a callback whenever it happen in one or more locations of your app.

That's it .. hope it helps .. feel free to ask and let us know if it helped you!
Whatever you say buddy! And I believe this tiny ad too:
the value of filler advertising in 2020
    Bookmark Topic Watch Topic
  • New Topic