----- Original Message -----
From: Aravind Naidu <[EMAIL PROTECTED]>
> 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.
Oh, BLAST. That was what I had come up with but hoped that the EJB spec.
writers weren't really that short sighted. Oh well.
> 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).
<rant>The more I work with EJB the less I like it. What on earth was the
problem they were trying to solve? Certainly not common large-scale
internet business applications.</rant>
> Until I think spec v2.0 (fingers
> crossed) when they hopefully have a message consumer bean and JMS is in
the
> container.
Which will only marginally improve things: there are times when you want to
use a message system, and there are times when you want something much less
"heavy", i.e. you want to kick off several threads, wait for them all to
complete in one fashion or another, rendezvous, and get on with the task.
Sigh.
> 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
!!!)
Good to know I'm not the only one.
> 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 !!!)
They would actually have good reason to question it: I've found from working
on a large messaging-system-only project that (a) it's impossibly difficult
to develop, (b) it's impossibly difficult to convey its complexities to the
people who need to implement it and (c) it's usually slow and involves way
too many network hits.
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".
