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.170.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; 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=Ig9zUqWf+dt94m57p9xhB4NO/P+xJbJt9EPpqm0Bi2SwUozN221RbwrDBFdTQ31RSteX0rsNCP6q+S2K24vht7Y7LA7Y7GNiVPgfvY6UB8efnIc6UrmBdCsMjcXCUh0yoGhqRI64VjZCkdFi20Yj3UwJEA3u6TEVHOj7eMfjzZs
Message-ID: <fbdc6a970410210141514e8b5c@mail.gmail.com>
Date: Thu, 21 Oct 2004 10:41:53 +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: <02e401c4b6e0$ae419680$56a13109@LANKABOOK>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <fbdc6a97041020055227d9ae0f@mail.gmail.com>
	 <DFA5323D-229A-11D9-8468-000A95D41A40@4quarters.com>
	 <02e401c4b6e0$ae419680$56a13109@LANKABOOK>

I think that I have to agree with Sanjiva, a BPEL engine has to be
pretty tightly integrated with the web service layer. Mechanisms like
correlation and assignment force you to handle XML messages and data
at the lowest levels of implementation.

In short a correlation in BPEL is a unique way to identify an
execution and is specific to each partner. For a given execution, you
may have 4 correlations, each handling the exchanges with a given
partner. For example if you have a process managing an order and its
shippment, you will have to handle order specific information that
will only interest your billing department and shippment specific
information only interesting the shipper. Both have a specific way to
identify their interaction, a specific correlation. And correlation is
initiated at an activity level.

The execution model in Twister is the same as the one you implemented
Geir. An activity can either execute and terminate, or execute and
wait for a message before termination depending on its type. We only
had to create specific activity types.

Actually the main difference between Twister's execution model and
yours is that Twister's execution doesn't use any "manager" class like
your engine, the execution is carried on from activities to activities
by activities. The basic use case is the following:

1. Web service layer receives a message.
2. Message is parsed and analyzed to extract the targeted partner,
port and operation and eventually a correlation.
3. The Message Controller uses the data extracted from the message to
see which current execution it is targeted at or if it has to start a
new execution.
4. The message is forwarded to the right activity execution that was
waiting for this message.
5. The activity terminate executions and forwards execution to the
next activity.
5. Next activity executes and (eventually) forwards execution to next
activity and so on...

Now I'm cheating a bit here. In Twister we have two main types of
activities: basic activity and activity container (coming from BPEL).
The container is the one controlling which activity has to execute
next in its domain. Once a controller has finish executing its
activities, it surrenders execution to it's parent container. And so
on... Right now the containers we implemented are Sequence, Pick,
Switch and While. The Flow is not finished yet. So we don't have any
notion of "link" between two activities, the container implementation
is the one deciding.

For more about Twister's architecture, there's a document here:

http://smartcomps.org/confluence/display/twister/Architecture+Guide

I didn't have enough time to finish all yet but there still might be
some helpful stuff. Actually a BPEL engine is somewhat different to a
workflow engine. The execution core may have similarities but all the
"wrapping around" is quite different.

So I would say that beside the fact that Twister is a bit more
"wrapped" (and therefore also more "heavyweight") the main differences
are:

1. Containment execution vs. "link-based" execution
2. Peer-to-peer execution vs. managed execution

Geir, what is your opinion on all this? Did you have time to check
Twister? Tell me if you need more information or anything else from
me.

Thanks,

Matthieu.

On Thu, 21 Oct 2004 02:09:17 +0600, Sanjiva Weerawarana
<sanjiva@opensource.lk> wrote:
> +1 for merging in BPEL support using Twister.
> 
> Geir, I'd like to understand the BPEL plans for Agila a bit
> more. I'm a co-author of the BPEL spec and have done an impl
> of it in IBM (BPWS4J- which was released via alphaworks a while
> back). My intuition is that a solid impl of BPEL needs to work
> very closely with the Web service layer. AFAIK there hasn't been
> that kind of interaction between Agila and the Axis community
> yet. Dims and I can easily support/facilitate that!
> 
> Matthieu- how does Twister do its SOAP, WSDL etc. stuff? Do
> you support non-SOAP bindings? (BPWS4J used WSIF, for example.)
> 
> Sanjiva.
> 
> 
> 
> ----- Original Message -----
> From: "Geir Magnusson Jr" <geir@4quarters.com>
> To: <general@incubator.apache.org>
> Sent: Wednesday, October 20, 2004 7:20 PM
> Subject: Re: Proposition: Twister WS-BPEL engine and Apache Agila
> 
> > This is great.  We're really interested in getting BPEL into Agila.
> > I'll take a look.
> >
> > We originally decided to not go w/ BPEL as the core language, as we
> > wanted to support all kinds of activities in a workflow, being able to
> > make a workflow that mixes them.  So it was planned that we'd get BPEL
> > support, and allow you to incorporate BPEL into a regular Agila
> > workflow using a namespace or something.  Of course, we can decide if
> > we want to change that plan here, but I think there are some compelling
> > arguments for that kind of approach...
> >
> > geir
> >
> > On Oct 20, 2004, at 5:52 AM, Matthieu Riou wrote:
> >
> > > Hello,
> > >
> > > I'm the project leader of Twister, an open source WS-BPEL engine. More
> > > can be found about Twister here:
> > >
> > > http://www.smartcomps.org/twister
> > >
> > > I'm sending this e-mail to suggest a donation of Twister to the Apache
> > > Group and a merge with the incubated Apache Agila project. I believe
> > > that Twister and the Gluecode engine could be assembled to a better
> > > solution, using the strengths of both implementations. This would also
> > > be beneficial for the BPM Open Source community and would bring more
> > > users and contributors to Agila.
> > >
> > > Regards,
> > >
> > > Matthieu Riou
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
> 
> ---------------------------------------------------------------------
> 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