aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes send directly a message or use a Queue and MDB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "send directly a message or use a Queue and MDB" Watch "send directly a message or use a Queue and MDB" New topic
Author

send directly a message or use a Queue and MDB

sioud abla
Greenhorn

Joined: Oct 09, 2004
Posts: 4
Hello,
Help me please,
in FBN when we want to send a message to a customer, we can use :
1. send the message directly from an EJBController or
2. send a message to a Queue and create a MDB to extract the message (Asynchrone)and send a message to the customer.
from performance point of view, it is necessary to use 2, although there does not exist much of treatment for the MDB, it only re-send the message?
Thank you
Ramon Gill
Ranch Hand

Joined: May 15, 2003
Posts: 344
Hi,
'2' is used because its asynchronous. You can send a message to a queue without having to wait for a response, therefore making the whole thing a lot quicker.

Ray
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
IMO, the queue and MDB is not necessary, saying you have a POJO using JavaMail to send emails called by EJBs, you just send the message to a nearest mail server and the mail server chain will help you to forward the email, you don't need to wait the whole process finished. So, it seems no waiting time observable. any other thoughts?
Udayan Patel
Ranch Hand

Joined: Oct 14, 2004
Posts: 94
Originally posted by Joseph Zhou:
IMO, the queue and MDB is not necessary, saying you have a POJO using JavaMail to send emails called by EJBs, you just send the message to a nearest mail server and the mail server chain will help you to forward the email, you don't need to wait the whole process finished. So, it seems no waiting time observable. any other thoughts?


What is the guarantee of delivery of message in this case? What if email server fails to send message? How you system will retry? is your application expects any recipt back from email server? if not, how the failed message will be handled?
Ramon Gill
Ranch Hand

Joined: May 15, 2003
Posts: 344
Hi,
Still use '2', but the MDB sends the email.
Ray
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
From the architecture discussion point of view, it is correct. Obviously, you do more, you get more. But for the reality, email server is much stable than an application server, if you don't trust your(uaually) email server, how can can you trust the email server chain over the Internet to delivery your message?
Udayan Patel
Ranch Hand

Joined: Oct 14, 2004
Posts: 94
Originally posted by Joseph Zhou:
From the architecture discussion point of view, it is correct. Obviously, you do more, you get more. But for the reality, email server is much stable than an application server, if you don't trust your(uaually) email server, how can can you trust the email server chain over the Internet to delivery your message?


First thing, I am not aware of this FBN problem atall. But here is my observations on MQ

I wouldn't buy much into scalability of email server or app server. A developer should be developing considering all scenario. And develop good solutions and not hacks.

MQ insures Guaranteed delivery of data. virtually no loss of data eventhough message goes to dead letter queue. You still can use JMX to retrive message and retry the delivery.

often, MQ is used in a distributed environment where you have a need to pass data somewhere once you receive it from client.

BTW Email is not an answer to anything other then sending a receipt to some operation.
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
Hi Udayan,
Let's away from detailed technology a little bit. As an architect, your resposibility is to design a system with 8 -ability etc.(based on SCEA) and satisfy client's functional requirement with a cost as low as possible.
So, if it is possible, make things simple. It's true MQ can make the message delivery more reliable, but if the current email delivery system already reliable enough, or only small part of the system got more reliable, we may don't need such a solution. BTW, MQ is just one example benifit from "save to disk" technology, shopping cart can also be persisted to DB to make it across server crash, but most time people just don't do it, why? cost/benefit. Anybody any comments?
Udayan Patel
Ranch Hand

Joined: Oct 14, 2004
Posts: 94
Originally posted by Joseph Zhou:
Hi Udayan,
Let's away from detailed technology a little bit. As an architect, your resposibility is to design a system with 8 -ability etc.(based on SCEA) and satisfy client's functional requirement with a cost as low as possible.
So, if it is possible, make things simple. It's true MQ can make the message delivery more reliable, but if the current email delivery system already reliable enough, or only small part of the system got more reliable, we may don't need such a solution. BTW, MQ is just one example benifit from "save to disk" technology, shopping cart can also be persisted to DB to make it across server crash, but most time people just don't do it, why? cost/benefit. Anybody any comments?


1. Cost is only one factor probably a major one. but, Client also exepcts reliability of the solution that you are to provide. Client also wants scalabillity and usability of the solution that you provide. Clients don't like when their customers complains about loosing data.

2. Saveing data in database and persist it for retries bugs me bacause, first you have to insert data into database, might have to query data numarous time untill message is delivered. once the messase is delivered what would you do with that row? delete or update some kind of status? another database call? Write your own schedular to keep query database every few minutes? thats why people don't do it. where as MQ does this all for you.

My argument to your initial answer was totally based on gurenteed delivery of message. You may have to go through an extra layer but still, a receipt to the customer is very important for a business. atleast from their customer service point of view(to me which counts for big to win the market).

SO, lets say if you have about 100,000 transactions a day and if you loose data for 5% of it, do you think that its ok? would you turn around and say its not that bad?
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
Hi Udayan,
Interesting discussion. What I want say is: for the specific email delivery issue we discussed here, even if you created guaranteed delivery form your side with a cost(You need a MQ and MDB implementation with re-try etc.), the benefit may be not worth your cost. Beause current email systems is not so bad(5% is not business acceptable, but this is not the current case).
Obviously, any 3rd integration you need some stategry for "Error Recovery". The MQ+MDB is one of them. Do we have any other alternatives with lower cost and make more business sense? I think we have. Ex: when the email server down the Travel System sending notification to admin, admin/agent/customer has the way to resend receipts...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: send directly a message or use a Queue and MDB