We're perfectly willing to contribute ideas and even working code, if it
would help speed up the process.
arkin
MARK HAPNER wrote:
>
> Yes, I agree that some form of scheduled event service is needed to
> complete the picture. That is being investigated now.
>
> Assaf Arkin wrote:
> >
> > 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".
>
> ===========================================================================
> 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".
