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
