Hi-
I have some design trade off questions open for discussion among the
interest groups in regards to Message Driven Beans. I've been through the
message archives and the most relevant messages on this topic are located at
the link below to avoid duplication:
http://archives.java.sun.com/cgi-bin/wa?A2=ind0009&L=ejb-interest&D=0&P=1172
18
I'm working on some draft materials for an EJB manuscript and I'm currently
working on the Message Driven Beans chapter. I have some questions that I
want to throw out for consideration. I believe I have solid answers, but it
never hurts to have a discussion.
1)
Since MDBs can be attached to a Topic or a Queue, do you foresee multiple
MDBs attaching to the same Topic to process a single request from a client
in parallel? This would be an alternative to having a client invoke
multiple asynchronous requests (still saving time versus doing multiple
synchronous requests on the client side). Essentially, if any parallel
logic has to be performed on the server or by a client (such as a branch in
a workflow engine), do you recommend having a client invoking multiple
asynchronous requests or attaching multiple MDBs to a single Topic?
2)
What are the tradeoffs between using MDBs and JMS server-side message
consumer pools? I think that using MDBs will decrease performance slightly
since you get the benefit of automatic transaction demarcation, support for
EJB security, and other EJB semantics. Besides performance, would there be
other reasons that you might select a JMS server-side message consumer pool
over an MDB?
3)
Consider the following scenario: An MDB creates an EJB instance and converts
the remote interface to its Handle equivalent. The MDB then sends a
response message to a Topic that contains the Handle of the newly created
EJB. The Topic has many consumers, some of them remote clients. I know
that this sounds ludicrous and is probably a very bad design, but I'm trying
to cover possible architecture ideas that may arise. Would this be a
scenario where an MDB does some business processing; At the completion of
the business processing, there is a large amount of in-memory data that a
variety of clients might like to view. Instead of sending the data back to
all interested clients via a JMS Topic message, might it be possible for a
bean to create a stateful Session Bean and send the remote Handle to the
Topic instead of the data? Granted, the clients will have to synchronize
access to the stateful bean, but they could access the data at their leisure
without using an entity bean. Ok, let me know if I'm off my rocker, but if
I'm crazy enough to think up this scenario, I'm sure someone else might be,
too.
Thanks all.
Tyler Jewell
Worldwide Education Strategist
BEA Systems, Inc.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
