It is true that EJB 1.1 does not provide the facilities needed to
implement a long running business process as an EJB. One of the goals of
EJB 2.0 is to address this by providing a specification for message
driven beans.
A typical scenario would be that a long lived business process
coordinates lower level business functions with a combination of sync
and async commands (EJB method calls and JMS messages).
The business process would typically be implemented as an entity bean
that manages the process's persistent state (one entity instance per
business process instance) and a 'stateless' message driven bean that
acts as a handler for progress/status messages (each message processed
by an instance of the bean from a 'stateless' instance pool). As
progress/status messages arrive, the container, within a container
managed transaction, activates an instance of the message driven EJB and
passes it the message. The bean's only job is to translate this message
into a method call on a specific instance of the business process EJB.
In this industrial strength business process implementation, the
container handles all the threading/activation and the developer just
implements the logic of a business process instance and the message
translation logic of a message handler instance. Messages don't get
'lost' due to JMS or EJB failures so the developer does not need to code
complex recovery logic to deal with this.
I realize this is a sketchy scenario; however, further info will have to
wait until the EJB 2.0 expert group produces its public draft.
You should note that simply providing threading within an EJB is not
sufficient to implement such a business process. While it might provide
a very primitive way of adding asynchrony it does not provide the basic
foundation needed to support the implementation of reliable, long lived
business processes. For instance, a failure would typically result in
the failure of the whole business process and the loss or corruption of
its state.
-- Mark
Aravind Naidu wrote:
>
> My sympathies are with you. I am glad someone else is in the same position
> as an application architect.
>
> The short answer is that if you want to be a good EJB 1.0 or 1.1 citizen,
> and then do it all in pure EJB, the only option is the one you outlined
> below, (ie) threading in the client.
> SUN's and many other's standard answer will be to use JMS to accomplish
> this. Which would mean that with the current state of specification and
> implementation, certain aspects of this 'workflow' application cannot be
> implemented in EJB (the reciever part). Until I think spec v2.0 (fingers
> crossed) when they hopefully have a message consumer bean and JMS is in the
> container.
>
> Which means that one of my customers has sort of headed towards a different
> product, (Domino) to accomplish such a workflow model, but alas the rest of
> the application is in EJB for their regular stuff and we are looking at
> their integeration, and it all boils down to the solution you outlined below
> :- Domino Java agents calling EJBs, which is client calling EJBs (aargh !!!)
>
> The other option is to implement the application in pure JMS, throwing away
> EJBs out altogether, which the PHBs are questioning as they made a strategic
> decision to go all EJBs (double aargh !!!)
>
> -- Aravind
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Laird Nelson
> > Sent: Friday, 25 February 2000 01:41
> > To: [EMAIL PROTECTED]
> > Subject: Threads and workflow
> >
> >
> > Grant for the moment that I understand all the issues around why you
> > can't create threads and run them inside enterprise beans, whether
> > session or entity.
> >
> > One of the things I need to be able to do is construct "workflows" (ugh;
> > I hate that term) that are parallelized to some degree. For example, in
> > order to decide whether to order a bucket of widgets, a company first
> > has to make sure that the project for which the widgets are needed is on
> > schedule, has enough inventory to justify the bucket-sized order (I'm
> > making all this up from whole cloth in case it wasn't obvious), that the
> > warehouse is, uh, empty enough to hold the bucket of widgets, and that
> > the, uh, distribution network of trucks and things is available for the
> > length of time it would take to deliver the widgets. Only then can the
> > order go through.
> >
> > Nevertheless, this can be seen as one big task, with all of the bizarre
> > checks as preconditions. There's nothing that prevents most of those
> > preconditions from occurring in parallel--then once they all complete
> > (or a sufficient number of them completes) the order can be placed. If
> > they complete badly, or there are errors, then of course the order is
> > not placed.
> >
> > Ideally I'd love to be able to encapsulate this in a session bean. But
> > of course I can't (<vendor>except in WebLogic, thank God; yet another
> > reason I'm personally leaning that way</vendor>) start a raft of threads
> > working on these precondition tasks, join up with them when they're
> > done, and test their results. (Note that of course the creation of many
> > threads that perform what are essentially read-only checks and then join
> > up with the main one does not result in any transactional no-nos,
> > providing a nice counterexample to the "the EJB server must control all
> > threads" dogma.)
> >
> > How then should I accomplish this task if I'm going to be specification
> > compliant? It looks like if I wanted to be a good EJB1.1 citizen, I'd
> > have to move each precondition step into its own session bean (eeeYUCK)
> > and call them all from a multithreaded client (double eeeYUCK)--the
> > client now becomes the place where the *real* workflow occurs (triple
> > eeeYUCK), not the session bean. This seems faintly or strongly wrong to
> > me (depending on how ornery I'm feeling at the moment). Comments?
> > Surely the EJB specification should allow for "workflows" like this.
> >
> > 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".
===========================================================================
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".
