I find compelling Assaf Arkin's formulation of the problem: EJB
allows for synchronous processing; JMS allows for asynchronous
processing; neither allow for continous processing.
I wonder if parallel workflow requires continuous processing, as you
suggest. Consider a workflow with three parallel tasks
implemented on an EJB 2.0 server. A session bean implementing
this workflow would send a message to three "helper" session
beans and return. Each session bean would implement one task
(in parallel with the other two.) As each finished, they would send
a message to a "task completed" session bean, which would wait
until all three tasks had finished.
In fact, in my experience those workflows would frequently require
user interaction. A session bean implementing a task would insert
a record into a database, and/or notify a user via e-mail, and
disappear until the user responded. You certainly don't want a
thread hanging around until the user gets around to checking
his/her "to-do list."
You might want a "semi-continuous" process to check for those
instances where the user goes on vacation. But this can be a
database-scanning session bean triggered by JMS at a certain
interval. Again, you don't need to roll your own threading logic.
The lack of continuous processing may be a hole in the
specification if a complete enterprise platform is desired. But I
would need to see a more specific example to believe that EJB 2.0
(i.e. EJB + JMS) cannot handle the common business problem of
parallel workflow.
-Dan
On 28 Feb 00, at 15:00, Laird Nelson wrote:
> ----- Original Message -----
> From: Mark Hapner <[EMAIL PROTECTED]>
> > A major objective of EJB is to achieve the creation of a multi-user
> service by
> > implementing single threaded components.
>
> So EJB was never intended to handle parallel workflow, as occurs commonly in
> large business systems? Then what good is a session bean?
>
> > EJB 2.0 will significantly expand the EJB app domain by adding support
> > for asynchronous invocation (JMS integration).
>
> Which is only half of the problem. EJB will not be complete until it also
> specifies how to "create" threads within user beans in such a way that the
> container still has a handle on them. This is a very simple problem.
>
> > So, the question is not what you can do within your container it is what
> your
> > container can do for you :>). Why should you be worrying about creating
> threads if
> > you can get the container to handle all of that complexity?
>
> Because no container on the market will currently let me do parallel
> asynchronous workflow while still being strictly EJB 1.1 compliant. That
> says more about the specification than the container to me.
>
> 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".
>
===========================================================================
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".
