ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Partner Links in simBPEL (was: Easy BPEL aka BPEL4Coders aka BPEL4Hackers)
Date Fri, 07 Dec 2007 20:31:02 GMT
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 <matthieu@offthelip.org> wrote:
>
> On Dec 7, 2007 9:03 AM, Oliver Kopp <oliver.kopp@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
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message