[comments inline. I'm quoting the original architecture on purpose]
> From: A mailing list for Enterprise JavaBeans development
> > 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.
>
> Hello,
>
> I agree with the responses of Bjarne Rasmussen on your
> different questions, however, about this last point, I've got
> a problem. In the EJB spec, it is said that a session bean
> always executes on behalf of a SINGLE client, i.e. it cannot
> be shared among several clients (as entity beans do). Handles
> on session beans may be used by a single client, when a client
> session needs to be temporarily suspended. I do not think that
> several clients may use a same session bean, and an EJB
> server will certainly not assume synchronisation of accesses to
> a session bean.
Good point. A workaround would be to post on the topic not the Handle of the
session bean but the JNDI name of a home capable of creating those SFSB. The
home should be smart enough to create SFSB fully initialized with the relevant
info (as opposed to initialized with default values).
Which makes me think it is beginning to look a lot like an Entity bean, now...
Is this indirection really worth it?
--
Cedric
===========================================================================
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".
