incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <>
Subject Re: Proposition: Twister WS-BPEL engine and Apache Agila
Date Tue, 26 Oct 2004 08:02:06 GMT

On Oct 26, 2004, at 3:27 AM, Matthieu Riou wrote:

> Very practically,  what is the conclusion of this discussion ? :)

Not sure if one is required.  I don't think solving the TLP problem is 
a good idea now because we're going to learn a lot more as time goes 
on.  I'm optimistic that we'll go that way at the end, but lets decide 
that later.  If we have enough size and strength to be a TLP, we do it. 
  If not, we don't. Until then, lets try and build some really great 
software and a great community.

I do think that working to have BPEL implementation at the ASF is a 
great idea, and while I'm 100% committed to seeing it a part of Agila, 
it doesn't have to only be in Agila.  For example, we could have a BPEL 
engine as part of the project that can be used standalone or inside 

I've been staring at the BPEL spec, on and off, and I have to admit, I 
just don't grok it beyond the fundamental motivation to define 
processes. My major stumbling point is why this was done in XML.  I'll 
start another thread so we can have a technical discussion.  I'll do my 
best to get the mail lists setup so we can have the discussion there, 
rather than here on the general list.


> Matthieu.
> On Sat, 23 Oct 2004 10:59:17 -0500, Aleksander Slominski
> <> wrote:
>> 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" <> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
Geir Magnusson Jr                                  +1-203-665-6437

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message