October 02, 2003
When MDBs aren't enough
J2EE 1.3 added support for J2EE applications statically declaring they needed to process incoming JMS messages arriving on a predeclared JMS topic or queue. This works well for a variety of applications but has problems with some advanced scenarios.
The topic/queue for the incoming message is not known when the application is deployed.
Here, MDBs don't work. They require this information to be known in advance. There is no way to do this in the spec. Some people think servlets can spawn threads in a J2EE application but this is false. The J2EE spec clearly says that this behaviour may not be supported in J2EE servers and hence shouldn't be relied on.
An environment where queues/topics are added and removed frequently.
Here even if they were known up front, it's difficult to remove a queue/topic or add one without redeploying the application. MDBs don't support dynamic messaging environments.
MDBs only work for JMS messages.
There are a lot of legacy messaging transports which need to be integrated and wrapping them with a JMS adapter or installing a gateway to bridge between the native and JMS transport may be undesirable. JCA 1.5 which is part of J2EE 1.4 addresses this aspect but doesn't help with the other issues.
The threading model isn't suitable for the application.
JMS internalizes the threading model used by the JMS client and then the MDB container further add its threading model on top of this. This means that if that model doesn't match what you need then it won't be good enough. The principle scenarios here deal with message ordering and when messages from a single queue/topic can and cannot be processed in parallel. Some other non JMS messaging products have more flexible APIs in this regard.
So, given these problems, there are two choices for a vendor trying to help here. Support generically all of the above features which is a lot of work but would be simpler for customers or provide enough flexibility so that the small percentage of customers that have these requirements can build a solution using the toolkit/APIs provided with the application server. The latter is the approach that works with WAS 5.0E.
The async beans capability which allows J2EE applications to take advantage of managed daemon threads as well as pooled threads, transient fast timers and managed callbacks/observers allows these solution to be implemented by 'advanced' customers using WAS-E 5.0.
Such applications can take full advantage of the J2EE programming model as well as run in a managed environment where as in the past, such applications were forced to run in a J2SE JVM managed by the customer.
October 2, 2003 in J2EE | Permalink
I would appreciate if you could give me the name/pointers to the good books/articles/docs on High Availablility.
Thanks in advance
Posted by: Khajjal | Aug 23, 2004 10:35:40 PM