incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: Proposition: Twister WS-BPEL engine and Apache Agila
Date Sat, 23 Oct 2004 15:59:17 GMT
i agree that TLP is very important and very good for visibility that 
apache has now place for workflows but i look on it more like umbrella 
TLP with many subprojects? the reason for this is that i have a 
different opinion about BPEL.

i think there is a clear need *now* for apache-licensed BPEL specific 
engine (there is more than one LGPLed)

moreover building a complete BPEL engine is challenge enough - this 
observation is based on my own experience building BPEL-like engine but 
i think Mathieu and Sanjiva may agree based on their experience?

it seems to me that building BPEL engine on top of another workflow 
execution model (mappings!) that has no web services support looks like 
a very large task so the question really is: what is expected timeline?

should apache have BPEL engine implementation now or next year (or 
later...)?

just my .02c

thanks,

alek


Paul Russell wrote:

> Guys,
>
> 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" <geir@4quarters.com> 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



-- 
The best way to predict the future is to invent it - Alan Kay


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message