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 <[EMAIL PROTECTED]> wrote: > > On Dec 7, 2007 9:03 AM, Oliver Kopp <[EMAIL PROTECTED]> > 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 > > > > >
