Javier Borrajo wrote:
> Then maybe implement a multithreaded service that talks to the EJB session
> bean ?
Right, which is a job that a session bean SHOULD be able to do, IMHO.
Why do you make something a session bean? You make it a session bean
because it encapsulates some complicated workflow behind a nice
transactional boundary and because you can reuse it easily. In lots of
cases, that session bean talks to entity beans that you've created. In
lots of THOSE cases, the workflow and the entities that it works on are
logically tightly bound together (it doesn't make sense to have an order
processing session bean if you don't have the orders to work on!).
Consequently, putting on my tech-lead-or-pointy-hair hat for a moment,
you want to manage the workflow with the things it works on so that
they're kept in sync. Hold that thought for a moment.
IMHO, if the workflow encapsulated by a session bean could be improved
or optimized to use parallel calls, that would be great. But because
EJBs can't create Threads, and because not every asynchronous problem
can be solved by hitting it with a JMS hammer, you can't encapsulate
some workflow in session beans. Consequently, you're right, you make
that workflow into a client object.
But now, returning to that thought you held for a moment :-), that
client object is not a bean, and so doesn't go into the deployment
bucket that all of the beans that it uses do. When you deploy the
beans, you are not (obviously) deploying the workflow that depends on
them with them. Now, instead, you're talking about maintaining workflow
that is logically tied to some beans in your server, but you have to
maintain it apart FROM those beans.
If instead you make a Session bean able to get threads in a simple and
safe manner, then that session bean can now:
(a) encapsulate just about any workflow you throw at it
(b) be managed with the beans that it itself is working with
(c) be reused easily because it will now be bundled up in the same jar
file as everything else
(d) shield clients from *implementation details* like whether the
workflow it encapsulates is being optimized through parallel calls or
not
Consider the following example, assuming for a moment that Threads are
allowed to be created inside an enterprise bean.
You, a bean developer, have just made a session bean, WorkProcessor,
that has one method on it, called doWork(). Your clients/callers, when
they have work to be done, will simply call your doWork() method. If it
works, then the work is done. Otherwise, an Exception is thrown.
Simple enough.
Inside that doWork() method, you've decided to farm out tasks that can
happen in parallel via multiple threads. At the end of firing off all
these asynchronous processes, you do a bunch of join() calls and wait
for the tasks to complete before determining whether to throw an
exception or not. Clients are happy because the API is simple. You're
happy because you have the freedom to optimize performance in your bean.
Now, back to the real world. You can't do this, because you can't
create threads in your session bean. So instead you create an EJB
client, that your callers will call. The first thing you do is you make
this non-EJB client have a doWork() method that either works or doesn't
(sound familiar? See two paragraphs above). In this non-EJB object,
you'll now kick off several parallel threads before working on your
entity beans. You'll wait for them to complete. Then you'll either
throw an exception or modify your entity beans.
IMHO you've just been forced to write a session bean, but without any of
the transaction/security perks. That's silly.
Nothing here is unworkable; it's just inconvenient, that's all. A
well-designed API makes things more convenient, not less.
> It's either that or wait for EJB 2.0, or use some propietary JMS-EJB mix
> such
> as Egipt, Voyager AppServer, WebLogic, ...
Yep.
Cheers,
Laird
===========================================================================
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".
