ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: Partner Links in simBPEL
Date Tue, 11 Dec 2007 15:45:55 GMT
On Dec 11, 2007 2:15 AM, Tammo van Lessen <tvanlessen@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
>
>
>

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