Well yes, if the purpose of the abstract was to define the protocol. But
I thought it was
accepted that there are other purposes for abstract.
But suppose there are abstract BPEL definitions that define
customer:retailer protocol A, and
retailer:supplier protocol B, but the purpose of this abstract
definition is to be a
template for a retailer's process that can handle a defined subset of A
and may use any of B
but must use some particular parts (e.g. must check availability on
premium orders, but need not on others).
Concretization of this ought not to add things to the A link, but could
on the B link. The same
concretization would of course correspond to BOTH the A and B
protocol-defining abstract BPELs.
Hmm, I'm not sure that's an easily identifiable profile.
Peter
> -----Original Message-----
> From: Satish Thatte [mailto:]
> Sent: 13 December 2004 18:18
> To:
> Cc: ; ; Furniss,
> Peter;
> Subject: RE: [wsbpel] Issue 82 - Proposal to resolve 82 and
> other abstract process issues
>
>
> Abdrew's interpretation is correct. I think he meant
>
> Consequently one is not allowed to write a derivative
> concrete BPEL process that adds, omits, or changes the order
> of [interactions using] partnerlinks defined in the abstract
> process since this changes the protocol.
>
>
>
> -----Original Message-----
> From:
> [mailto:]
> Sent: Monday, December 13, 2004 10:04 AM
> To: Satish Thatte
> Cc: ; ;
> ;
> Subject: RE: [wsbpel] Issue 82 - Proposal to resolve 82 and
> other abstract process issues
>
> Hello:
>
> > I believe the distinction is not so much between wide and narrow as
> > between a completely vs incompletely defined notion of abstract
> > process, either singular, as you seem to prefer, or plural.
>
> [from archives/wsbpel/200412/msg00023.html]
>
> >If an abstract process is meant to fully represent the
> >>externally observable behavior of a complete executable
> >process along a set of partnerLinks, then the permitted
> >>executable completions of this abstract process cannot>allow the
> addition of web services interactions using the
> >partnerLinks mentioned in the abstract process, even as
> >>replacements for opaque activities.
> I believe an important point missing, or not stressed
> in Peter's proposal is that an abstract process defines
> an important invariant: the protocol. The protocol
> controls the public visible behaviour (i.e., traces).
>
> If my interpretation of Satishe's passage is correct,
> the abstract process (more specifically its control
> flow constructs) defines the contract for the invocation
> order of invoke, receive, and reply activities. Since
> partnerlink is required on invoke, receive, and reply are
> required attributes, this is tantamount to saying that the
> abstract process defines the invocations order of partnerlinks.
>
> Consequently one is not allowed to write a derivative
> concrete BPEL process that adds, omits, or changes the order
> of partnerlinks defined in the abstract process since
> this changes the protocol.
>
>
> Cheers,
> Andrew
>
>
>
>
>
>
>
>
>
>
>
>
Choreology Anti virus scan completed
