RE: [wsbpel] Issue 82 - Proposal to resolve 82 and other abstract process issues

["Furniss, Peter" <Peter.Furniss@choreology.com>]

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:satisht@microsoft.com] 
> Sent: 13 December 2004 18:18
> To: andrew.francis@mail.mcgill.ca
> Cc: charlton_b@mac.com; wsbpel@lists.oasis-open.org; Furniss, 
> Peter; dannyv@tibco.com
> 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: andrew.francis@mail.mcgill.ca 
> [mailto:andrew.francis@mail.mcgill.ca] 
> Sent: Monday, December 13, 2004 10:04 AM
> To: Satish Thatte
> Cc: charlton_b@mac.com; wsbpel@lists.oasis-open.org; 
> Peter.Furniss@choreology.com; dannyv@tibco.com
> 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