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: domain of matthieu.riou@gmail.com
 designates 64.233.184.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=jEb2MWfveVeJoAPyaPyMWOv0L0lX4ruTRcFI4nFNhoGd9p59sKzsoUsvGxIXG91QgZmcdhXTzmDp2ChZlbaKEmXbhH+Ki7tBzAwoo3E7+JkPlzPT0jWUpZWjlv8gxtUZ5CRTGOBrGvXugeVhCPlOvPKe4lVQAVGxTNFGzKuZj5A=
Message-ID: <fbdc6a9704102600275620e2b6@mail.gmail.com>
Date: Tue, 26 Oct 2004 09:27:49 +0200
From: Matthieu Riou <matthieu.riou@gmail.com>
Reply-To: matthieu.riou@gmail.com
To: general@incubator.apache.org
Subject: Re: Proposition: Twister WS-BPEL engine and Apache Agila
In-Reply-To: <417A7FD5.1060708@cs.indiana.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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>

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

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