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".
