Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers

[Tammo van Lessen <tv...@gmail.com>]

Hi,

On Nov 27, 2007 11:41 PM, Assaf Arkin <ar...@intalio.com> wrote:
> But reading the process definition, plink.foo is confusing, I can't just by
> reading determing if it's invoking or receiving without also digging into
> the operation definition.  And me/partner is just another way of saying
> receive/invoke, so why not say it directly?
Ok, agreed :) The last one in Matthieu's mail look definitely
promising as it's pretty close to original BPEL look&feel (receive()
and invoke()).

What do you think about the partnerLink declaration? We thought about
something like that:

  partnerLink plink = [type = ns1::plType, myRole = rolea, partnerRole
= roleb, init = true]; // init defaults to false

Cheers,
  Tammo, Olly

-- 
Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de

Re: Partner Links in simBPEL

[Tammo van Lessen <tv...@gmail.com>]

Matthieu Riou wrote:
...
> But (BPEL, WSDL) isn't self-contained. You can't do anything with it outside
> of abstract definitions.
> 
> I think we don't agree here and won't go too far by trying to convince each
> other :) 

;) The valley is definitely too far away, otherwise this topic would be
a good reason for having some beers.

> So what about trying to find some middle ground and make this
> additional definition optional? We're still at an early stage, maybe
> practice and writing more processes will prove either of us wrong.
> 
> So what about something like this?
> 
> partnerLink somePL {me: ns::MyPortType, you: ns::PartnerPortType}

Great! Bought ;)

Cheers,
  Tammo

Re: Partner Links in simBPEL

[Matthieu Riou <ma...@offthelip.org>]

On Dec 11, 2007 2:15 AM, Tammo van Lessen <tv...@gmail.com> wrote:

> Matthieu Riou wrote:
> > For the particular case of partnerLinkTypes, they don't need to be in
> > the SimPEL document but could be extracted from deployment
> > information that associates partner links with an endpoint or a
> > portType. So you would have something like SimPEL+deploy <-> BPEL. I
> > think it's not an unreasonable requirement and saves us the pain of
> > explain why we have an unnecessary abstraction sitting there for no
> > real purpose.
>
> I think the deployment descriptor is not necessarily the proper place as
> it should IMHO contain only deployment, i.e. EPR related, details. The
> tuple (BPEL/simBPEL, WSDL) should be somehow self-contained. In our
> understanding a partnerLink defined the contract between two parties, so
> this information also belongs the definition of a process. When moving
> this contract binding into deployment descriptors, you could bind
> partner interfaces to service implementations that do not follow the
> contract as intended by the modeller. Therefore its important to
> reference the portType to be used. So it can be put to partnerLink
> definitions or referenced directly together with the operation. Our
> preference is still to stick close to the BPEL spec, so we would opt for
>  the partnerlink definition.
>

But (BPEL, WSDL) isn't self-contained. You can't do anything with it outside
of abstract definitions.

I think we don't agree here and won't go too far by trying to convince each
other :) So what about trying to find some middle ground and make this
additional definition optional? We're still at an early stage, maybe
practice and writing more processes will prove either of us wrong.

So what about something like this?

partnerLink somePL {me: ns::MyPortType, you: ns::PartnerPortType}

The colons might look a bit confusing but that's more in line with what
we've defined for correlation.

Cheers,
Matthieu


> Cheers,
>  Tammo, Olly
>
>
>

Re: Partner Links in simBPEL (was: Easy BPEL aka BPEL4Coders aka BPEL4Hackers)

[Assaf Arkin <ar...@intalio.com>]

Basically a partnerLinkType is an abstraction that names two related
portTypes, so you can then define two partnerLinks the represent each view (
i.e. roles reversed), and given two process definition somehow deduct (and
often be right) that they're related because they share a common
partnerLinkType.

But as far as execution is concerned, declaring a partnerLink directly
achieves the same thing.

Assaf



On 12/7/07, Matthieu Riou <ma...@offthelip.org> wrote:
>
> On Dec 7, 2007 9:03 AM, Oliver Kopp <ol...@iaas.uni-stuttgart.de>
> wrote:
>
> > Hi,
> >
> > > I question if we need to keep partnerLinkType alive?
> >
> > If we want to have a 1:1 relation of simBPEL to BPEL, then we really
> need
> > to
> > keep it.
> >
> > We think, it is good to have a more easy language, but this should be
> the
> > second step. First, there should be a bijective mapping between simBPEL
> > and
> > BPEL, so that one can freely choose the syntax one likes.
> >
> > We think that something like simBPEL+ should be born afterwards. There,
> > language extensions such as your security context and anonymous partner
> > links could be brought in. Then, the simple syntax is clearly
> > distinguished
> > from the extensions of BPEL.
> >
>
> I sympathize with the intent but don't agree that compatibility should be
> achieved at *all* cost. Although we should be able to reach a reasonable
> degree of compatibility between the formats. For the particular case of
> partnerLinkTypes, they don't need to be in the SimPEL document but could
> be
> extracted from deployment information that associates partner links with
> an
> endpoint or a portType. So you would have something like SimPEL+deploy <->
> BPEL. I think it's not an unreasonable requirement and saves us the pain
> of
> explain why we have an unnecessary abstraction sitting there for no real
> purpose.
>
> Cheers,
> Matthieu
>
>
> >
> > > It's a modeling artifact, but if we're not aiming for modeling,
> > > do we need the extra indirection?
> >
> > Isn't the introduction of anonymous partner links a new kind of
> modeling?
> > In
> > that case, the modeler has not to think about the concrete partner
> links.
> >
> > Cheers,
> >        Olly, Tammo
> >
> >
>

Re: Partner Links in simBPEL

[Tammo van Lessen <tv...@gmail.com>]

Matthieu Riou wrote:
> For the particular case of partnerLinkTypes, they don't need to be in
> the SimPEL document but could be extracted from deployment
> information that associates partner links with an endpoint or a
> portType. So you would have something like SimPEL+deploy <-> BPEL. I
> think it's not an unreasonable requirement and saves us the pain of 
> explain why we have an unnecessary abstraction sitting there for no
> real purpose.

I think the deployment descriptor is not necessarily the proper place as
it should IMHO contain only deployment, i.e. EPR related, details. The
tuple (BPEL/simBPEL, WSDL) should be somehow self-contained. In our
understanding a partnerLink defined the contract between two parties, so
this information also belongs the definition of a process. When moving
this contract binding into deployment descriptors, you could bind
partner interfaces to service implementations that do not follow the
contract as intended by the modeller. Therefore its important to
reference the portType to be used. So it can be put to partnerLink
definitions or referenced directly together with the operation. Our
preference is still to stick close to the BPEL spec, so we would opt for
 the partnerlink definition.

Cheers,
  Tammo, Olly

Re: Partner Links in simBPEL (was: Easy BPEL aka BPEL4Coders aka BPEL4Hackers)

[Matthieu Riou <ma...@offthelip.org>]

On Dec 7, 2007 9:03 AM, Oliver Kopp <ol...@iaas.uni-stuttgart.de>
wrote:

> Hi,
>
> > I question if we need to keep partnerLinkType alive?
>
> If we want to have a 1:1 relation of simBPEL to BPEL, then we really need
> to
> keep it.
>
> We think, it is good to have a more easy language, but this should be the
> second step. First, there should be a bijective mapping between simBPEL
> and
> BPEL, so that one can freely choose the syntax one likes.
>
> We think that something like simBPEL+ should be born afterwards. There,
> language extensions such as your security context and anonymous partner
> links could be brought in. Then, the simple syntax is clearly
> distinguished
> from the extensions of BPEL.
>

I sympathize with the intent but don't agree that compatibility should be
achieved at *all* cost. Although we should be able to reach a reasonable
degree of compatibility between the formats. For the particular case of
partnerLinkTypes, they don't need to be in the SimPEL document but could be
extracted from deployment information that associates partner links with an
endpoint or a portType. So you would have something like SimPEL+deploy <->
BPEL. I think it's not an unreasonable requirement and saves us the pain of
explain why we have an unnecessary abstraction sitting there for no real
purpose.

Cheers,
Matthieu


>
> > It's a modeling artifact, but if we're not aiming for modeling,
> > do we need the extra indirection?
>
> Isn't the introduction of anonymous partner links a new kind of modeling?
> In
> that case, the modeler has not to think about the concrete partner links.
>
> Cheers,
>        Olly, Tammo
>
>

Partner Links in simBPEL (was: Easy BPEL aka BPEL4Coders aka BPEL4Hackers)

[Oliver Kopp <ol...@iaas.uni-stuttgart.de>]

Hi,

> I question if we need to keep partnerLinkType alive?

If we want to have a 1:1 relation of simBPEL to BPEL, then we really need to
keep it.

We think, it is good to have a more easy language, but this should be the
second step. First, there should be a bijective mapping between simBPEL and
BPEL, so that one can freely choose the syntax one likes.

We think that something like simBPEL+ should be born afterwards. There,
language extensions such as your security context and anonymous partner
links could be brought in. Then, the simple syntax is clearly distinguished
from the extensions of BPEL.

> It's a modeling artifact, but if we're not aiming for modeling, 
> do we need the extra indirection?

Isn't the introduction of anonymous partner links a new kind of modeling? In
that case, the modeler has not to think about the concrete partner links.

Cheers,
	Olly, Tammo

Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers

[Paul Brown <pa...@gmail.com>]

On Dec 3, 2007, at 10:18 AM, Matthieu Riou wrote:
> I question whether we need partnerLink declarations at all. The  
> first time
> you use one in an invoke, you get a partnerRole, the first time you  
> use one
> in a receive, you get a myRole. Binding to a port, portType,  
> interface or
> whatever is out of SimPEL and more a deployment thing. What do you  
> think?

The only reasons I can think to retain the declaration (rather than  
having it be lazy) would be that (1) it's easier for a human to find  
the token and (2) it's easier to ensure that you're using the same  
token in all cases where you think you are.  (The compiler/parser/ 
translator can just make two passes...)

-- Paul

Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers

[Matthieu Riou <ma...@offthelip.org>]

On Dec 3, 2007 10:10 AM, Assaf Arkin <ar...@intalio.com> wrote:

> On 12/3/07, Tammo van Lessen <tv...@gmail.com> wrote:
> >
> > Hi,
> >
> > On Nov 27, 2007 11:41 PM, Assaf Arkin <ar...@intalio.com> wrote:
> > > But reading the process definition, plink.foo is confusing, I can't
> just
> > by
> > > reading determing if it's invoking or receiving without also digging
> > into
> > > the operation definition.  And me/partner is just another way of
> saying
> > > receive/invoke, so why not say it directly?
> > Ok, agreed :) The last one in Matthieu's mail look definitely
> > promising as it's pretty close to original BPEL look&feel (receive()
> > and invoke()).
> >
> > What do you think about the partnerLink declaration? We thought about
> > something like that:
> >
> >   partnerLink plink = [type = ns1::plType, myRole = rolea, partnerRole
> > = roleb, init = true]; // init defaults to false
>
>
> I question if we need to keep partnerLinkType alive?  It's a modeling
> artifact, but if we're not aiming for modeling, do we need the extra
> indirection?  What about specifying partner link directly as my and/or
> partner, and either one can be a port type or a port.
>

I question whether we need partnerLink declarations at all. The first time
you use one in an invoke, you get a partnerRole, the first time you use one
in a receive, you get a myRole. Binding to a port, portType, interface or
whatever is out of SimPEL and more a deployment thing. What do you think?

Matthieu


>
> Assaf
>
>
>
> Cheers,
> >   Tammo, Olly
> >
> > --
> > Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
> >
>
>
>
> --
> CTO, Intalio
> http://www.intalio.com
>

Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers

[Assaf Arkin <ar...@intalio.com>]

On 12/3/07, Tammo van Lessen <tv...@gmail.com> wrote:
>
> Hi,
>
> On Nov 27, 2007 11:41 PM, Assaf Arkin <ar...@intalio.com> wrote:
> > But reading the process definition, plink.foo is confusing, I can't just
> by
> > reading determing if it's invoking or receiving without also digging
> into
> > the operation definition.  And me/partner is just another way of saying
> > receive/invoke, so why not say it directly?
> Ok, agreed :) The last one in Matthieu's mail look definitely
> promising as it's pretty close to original BPEL look&feel (receive()
> and invoke()).
>
> What do you think about the partnerLink declaration? We thought about
> something like that:
>
>   partnerLink plink = [type = ns1::plType, myRole = rolea, partnerRole
> = roleb, init = true]; // init defaults to false


I question if we need to keep partnerLinkType alive?  It's a modeling
artifact, but if we're not aiming for modeling, do we need the extra
indirection?  What about specifying partner link directly as my and/or
partner, and either one can be a port type or a port.

Assaf



Cheers,
>   Tammo, Olly
>
> --
> Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
>



-- 
CTO, Intalio
http://www.intalio.com