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

[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
>
>
>