Mark,
That is exactly the conclusion we've reached when developing the
workflow framework, and have been planning to use EJB and JMS in
precisely the same manner, with entity beans representing processes
(activities and transitions being dependent classes), session beans
representing activation of processes, and using JMS to coordinate
transitions.
But that wasn't enough. We needed some way to schedule operations to
occur at a given time, e.g. you can define that a certain process has to
complete by a given date, or be cancelled if it's still in progress. You
might want a transition to occur at the end of the day, etc.
The solution for that was to add a scheduling ability which relies on
JMS to deliver the messages, and entity beans to represent the scheduled
activities so you can add/remove/query them.
So far, works fine. But a scheduling engine must run as a separate
continueous thread. That thread can be managed in one of two ways:
1. It can be a connector plugged into the EJB server
2. It can be a thread-bean
Even though we plan to use solution no. 1 with the yet unspecified
connector API, I believe that many EJB application developers would
rather choose solution no. 2, which is more approachable to the EJB
application developer (as opposed to a connector developer).
Whether or not thread-beans can be supported is an open issue, but has
that approach been investigated with regard to EJB 2.0, and what was the
reason not to support it?
arkin
MARK HAPNER wrote:
>
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
