Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <fbdc6a9704102600275620e2b6@mail.gmail.com>
References: <fbdc6a97041020055227d9ae0f@mail.gmail.com>
 <02e401c4b6e0$ae419680$56a13109@LANKABOOK> <4176C977.2090103@cs.indiana.edu>
 <299f30380410210259d8ea39e@mail.gmail.com>
 <fbdc6a97041021114813d86683@mail.gmail.com>
 <A2FDC1B6-2397-11D9-8BB8-000A95D41A40@4quarters.com>
 <056d01c4b7c4$8236d0c0$56a13109@LANKABOOK>
 <8D5024C6-23C7-11D9-889E-000A95D41A40@4quarters.com>
 <76A9EFB2-23FB-11D9-8A69-000393CC34EA@apache.org>
 <417A7FD5.1060708@cs.indiana.edu> <fbdc6a9704102600275620e2b6@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <541F4104-2725-11D9-9561-000A95D41A40@4quarters.com>
Content-Transfer-Encoding: 7bit
From: Geir Magnusson Jr <geir@4quarters.com>
Subject: Re: Proposition: Twister WS-BPEL engine and Apache Agila
Date: Tue, 26 Oct 2004 04:02:06 -0400
To: general@incubator.apache.org


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

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.

geir

>
> Matthieu.
>
> On Sat, 23 Oct 2004 10:59:17 -0500, Aleksander Slominski
> <aslom@cs.indiana.edu> 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" <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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@gluecode.com


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