incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Russell <>
Subject Re: Proposition: Twister WS-BPEL engine and Apache Agila
Date Fri, 22 Oct 2004 07:24:51 GMT

On 22 Oct 2004, at 02:13, Geir Magnusson Jr wrote:
> On Oct 21, 2004, at 4:20 PM, Sanjiva Weerawarana wrote:
>> "Geir Magnusson Jr" <> writes:
>>> I think that bringing the two concepts together - workflow and WS
>>> orchestration - would be a great goal :)
>> So as a co-author of BPEL I have to say that that was indeed
>> one of our objectives .. clearly we have failed at least by
>> you :).
> Yah, well, I've been clear that I don't know much :) so I'm doing a 
> bit more homework. I'll come back and apologize if I'm wrong, or else 
> clearly explain what I think it's missing.

I must confess, I've always had the impression that BPEL is /capable/ 
of participating in full BPM, but that it is only a /part/ of the 
solution. Gier: I'd be very interested to know what your perception of 
what's missing is -- it's funny, every time I talk to people about 
BPM/workflow, I get a different definition of what's in and what's out 
of scope ;) My perception is that BPEL is capable of handling 
everything except human interaction, but I treat (and so do IBM, as it 
happens) human interactions as 'just another ASYNC service call', so 
BPEL fits nicely into BPM provided you provide a staff resolution 
architecture (who can do this task?) and an interface to allow tasks to 
be allocated to people and processed etc.

That said, while I believe that BPEL is capable of acting as the 'core' 
of a BPM project, I'm all for a layered architecture. I've not had a 
chance to look at Agila yet, but I'm assuming it's based on petri-nets 
or similar, so it should be perfectly possible to implement BPEL over 
the top of this (hopefully by merging in Twister, but replacing its 
execution core with Agila), and this gives us the opportunity to 
implement other BPM/orchestration languages in the future when this 
becomes desirable.

>> So maybe the idea of a separate effort for BPEL is not a bad
>> idea. Dims, what do you think?

Personally, i would prefer the solutions to be merged -- my view is 
that they'll have such crossover functionally, it wouldn't make sense 
to treat them separately.

>> Geir, is the plan for Agila to go for a new TLP after incubation
>> or go to one of the existing projects?
> Right now, the Jakarta PMC has voted to accept us once we complete 
> incubation.
> However, I think that this would be a stronger community and better 
> software stack if we could bring all together into one project, and 
> then apply for TLP.  I'd really like to see Agila include BPEL, and 
> make it such that a pure BPEL workflow is just an agila workflow w/o 
> non-BPEL activities, if you get what I mean.  Make it so that people 
> who just want to write/use BPEL, people who want to mix, and people 
> who don't want BPEL can all use the same thing.  There's lots of 
> commonality - with a full system, we'll all need the reporting, 
> logging, administration, etc, and no need to duplicate...

I'm /so/ +1 for this (the TLP bit -- you /know/ I'm +1 the rest of it 
too!) it's making me late for work! My day job involves working for a 
large enterprise (the largest insurer in the UK). To large 
organisations like that, visibility is everything, and they would want 
to see that workflow is being taken very seriously by Apache before 
buying in (I know this is a bit of a stupid attitude, but such is the 
way with large companies). To give you an idea of how seriously /we/ 
take workflow, we currently spend several million pounds a year 
maintaining our own workflow system (developed before the rest of the 
world 'did' workflow). As you can imagine, we're currently looking to 
replace this. Right now, the likely candidates are commercial, but it'd 
be nice to have an alternative.

The other reason I'm for a TLP is that I can see a number of other 
projects that might spring up around this (an Agila plug-in for 
Eclipse, for example?), and it seems more cohesive to host these all 
under one well-focused TLP.

As ever, just my $0.10.

Paul Russell

View raw message