in an application in which every request involved with
a lot of ejb processing(sometimes involves more than one transaction)
like - storing data to db + sending email notifications + processing reports and creating ones etc ..
the dependency in other factors like the smtp server and the report processing objects have to be decoupled from the client..
is it wise to use JMS and an mdb that will consume every request as a message and will devide the work between the diffrent components ?
is using messaging between components or tiers in same application server a good solution?
It depends on how critical your application is and what the transaction volume is. Simply, can you make an justification in terms of development efforts and costs to use JMS versus a simple queue implemented as in memory or a database table? My opinion: if you have all the components running in the same server, JMS has no advantage over a database table solution.
well my friend in terms of costs (or network costs)
seems to me that messaging between components - is less consuming then db(remote) queries ?
and if u take into that the fact that it involves more than one processing tasks/components it will require more than one table,
moreover a DB queue is less flexible then messages - u can always add another property to a message ...
and implementing a DB queue will require a sort of a timed object to access the q ,refresh it and pass the data
i think the bottom line here is performance and cases of failures
the question is how in-server messaging perform vs a db implements a tasks's queue