Re: [wsbpel] Issue - 82 - Proposal for Vote

[rkhalaf <rkhalaf@watson.ibm.com>]

Furniss, Peter wrote:
> Well, it wasn't a question of asking for an opaque marker, as a 
> question of what determined a bpel document as abstract. I was roughly
> summarising what I had heard suggested a while ago, rather than
> detailing.
> 
> Compared to Yaron's summary, the thing I omitted was 
> whether there was an explicit attribute that said "this is an abstract
> definition". If there isn't, then internal examination of the script can
> only say:
> 	a) this contains at least one "opaque" - it must be abstract
> 	b) this does not contain "opaque" - but it still might be an
> abstraction of deployed processes, with some aspects left unstated.
> 


There is an explicit attribute saying it's abstract so there's no 
problem here :)

> I think I prefer Yaron's summary, where even if there is no explicit
> opaque, the process definition is marked as abstract. 

Yup, this is currently the case , in the spec, in my proposal and in 
Yaron's.

>It would be
> imaginable to have an executable process definition which is used as if
> it were abstract, with additional stuff being put in. (analogous to
> extending a concrete java class as opposed to an abstract one). It would
> then be up to external information to determine what relationship the
> definition had to a deployment.  Yaron's proposal would make the script
> self-documenting in this aspect, and if someone did want to extend a
> truly executable definition, but publish the base, they would just add
> the marker attribute.  But then even exectuables may have aspects that
> are effectively hidden (as interactions with an internal service, as
> platform-specific decisions etc). I'm undecided on this specific.
> 
> 


The abstract process says nothing about its relation to any executables, 
so this would come out of band (external information).

> 
> Peter
> 
> 
> 
>>-----Original Message-----
>>From: Satish Thatte [mailto:satisht@microsoft.com]
>>Sent: 13 October 2004 06:41
>>To: Danny van der Rijn; ygoland@bea.com
>>Cc: wsbpel@lists.oasis-open.org; Furniss, Peter
>>Subject: RE: [wsbpel] Issue - 82 - Proposal for Vote
>>
>>
>>When did Peter ask for "at least one opaque marker"?  I must
>>have missed it .. 
>>
>>Satish
>> 
>>
>>-----Original Message-----
>>From: Danny van der Rijn [mailto:dannyv@tibco.com]
>>Sent: Monday, October 11, 2004 4:38 PM
>>To: ygoland@bea.com
>>Cc: wsbpel@lists.oasis-open.org
>>Subject: Re: [wsbpel] Issue - 82 - Proposal for Vote
>>
>>We're back to my objection of describing abstract processes
>>in terms of conformance.  You may not have intended to go 
>>there Yaron, and I apologize in advance if this is the case. 
>>
>>My understanding of the current set of proposals, is that the
>>query string would not affect conformance proofs at all, and 
>>therefore DOES NOT BELONG in abstract processes.  What you 
>>described would therefore be termed an incompletely specified 
>>process, and one which does not meet the definition of 
>>abstract process.
>>
>>My preference, which I have (perhaps ineptly) stated in
>>various ways, coincides more with Peter's proposition that an 
>>abstract process is one with at least one "opaque" marker, 
>>for whatever value of opaque marker we decide upon.  Note 
>>that this has nothing to do with observable conformance, just 
>>with degree of specificity. 
>>
>>I would also argue that an abstract process is defined by
>>intent, and not by syntax, e.g. an abstract process is one 
>>that is marked abstract=true.
>>
>>I hesitate to go through my complete (but inept) arguments
>>again, but since it's been a while...
>>
>>It makes more sense to me that there will be multiple
>>conflicting definitions of abstract process:  the observable 
>>conformance flavor, the proper superset which you describe, 
>>others.  If we are going to preserve a notion of an abstract 
>>process that has any meaning to a large number of the 
>>audience of our specification, one way to do it would be to 
>>mark the process with a string (perhaps a URI) that selects 
>>some syntax/semantics/intentions of abstractness.  I worry 
>>that standardizing that portion of "abstractness" that aids 
>>only in defining observable conformance will increase the 
>>size and complexity of the BPEL spec without giving benefit 
>>to a large portion of the community.  Therefore I, for one, 
>>can not support the current proposals.  I would prefer the 
>>absence of abstract processes to the current situation.
>>
>>One counter-argument is that while the use-case you provide
>>is ill-specified, the observable conformance use case can be 
>>nailed down precisely.  Using this as an argument for 
>>actually doing so, however, and ignoring everything else, is specious.
>>
>>Yaron Y. Goland wrote:
>>
>>
>>>I like the general direction the text is going in but there is one 
>>>particular issue that still worries me - why are abstract processes 
>>>not a proper superset in functionality of executable processes?
>>>
>>>Imagine a company is using an abstract process as a
>>
>>template. Part of
>>
>>>the template is fully defined to provide a complete
>>
>>description of a
>>
>>>particular operation but the rest of the process is defined
>>
>>with less
>>
>>>detail. For the detailed section it is necessary to use a
>>
>>query string
>>
>>
>>>on a from to indicate exactly which part of a source variable should
>>
> 
>>>be assigned to a destination.
>>>
>>>Currently the previous use case is impossible in BPEL because query 
>>>strings on from-specs are reserved for executable
>>
>>processes. Therefore
>>
>>
>>>abstract processes do not have the same expressive power as
>>
>>executable
>>
>>
>>>processes.
>>>
>>>For issue 82 to be resolved it is necessary for abstract
>>
>>processes to
>>
>>>be well enough defined that it becomes obvious why
>>
>>limitations such as
>>
>>
>>>the query string restriction are necessary to meet the goals of 
>>>abstract processes. Yet no such description is provided
>>
>>below. Could
>>
>>>you please clarify this issue?
>>>
>>>    Thanks,
>>>
>>>        Yaron
>>>
>>>rkhalaf wrote:
>>>
>>>
>>>>
>>>>In this proposal, we clarify abstract processes as
>>>
>>requested by Issue
>>
>>
>>>>82. The spec should reflect these clarifications to abstract 
>>>>processes throughout its text.
>>>>
>>>>--------
>>>>
>>>>A BPEL abstract process defines the publicly visible
>>>
>>behavior of the
>>
>>>>services it offers (all "myRole" in its partnerLinks), of course
>>>>including its interactions along its partnerLinks with other
>>>
>>services.
>>
>>>>Abstract processes serve a descriptive role. They can be viewed as 
>>>>partially specified processes that are typically not
>>>
>>intended to be
>>
>>>>executed. They are partially specified in that they are capable of
>>>>abstracting away operational details. An abstract BPEL 
>>>
>>process must
>>
>>>>be declared abstract by setting the abstractProcess attribute to
>>>
>>"yes".
>>
>>>>Operational details may be abstracted away either through the 
>>>>omission of specific BPEL elements or attributes listed in the 
>>>>specification, or through the use of opaque tokens. Aside
>>>
>>from these
>>
>>>>factors, they are well-formed process following the structure and
>>>>restrictions in the specification regarding the process definition
>>>
>>and the constructs used.
>>
>>>>Semantics of Abstract Processes:
>>>>
>>>>A.       Although it might contain complete information that would 
>>>>render it
>>>>executable if the abstractProcess="yes" attribute were changed to
>>>
>>"no"
>>
>>>>for executable BPEL, its abstract status states that any concrete 
>>>>realizations of it may perform additional processing steps
>>>
>>that are
>>
>>>>not relevant to the audience to which it has been given.
>>>>
>>>>B.      Abstract processes permit the use of nearly all of the 
>>>>constructs of
>>>>executable processes.  Thus there is no fundamental
>>>
>>expressive power
>>
>>>>distinction between abstract and executable processes.
>>>>
>>>>C.      An abstract process may omit certain details that are 
>>>>mandatory for
>>>>BPEL executable processes. However, the semantics of the constructs
>>>
> 
>>>>used in such a process is exactly the same as their
>>>
>>semantics in the
>>
>>>>executable context. An abstract process must comply with
>>>
>>the syntax
>>
>>>>and semantics of the specification.  The syntactic
>>>
>>elements that can
>>
>>>>be omitted in abstract processes where this would not be
>>>
>>permitted in
>>
>>
>>>>executable processes are currently:
>>>>-       Those listed in the "extensions for executable processes" 
>>>>section of
>>>>the specification.
>>>>-       inputVariable/outputVariable/variable on invoke, receive, 
>>>>onMessage,
>>>>and reply.
>>>>-       An initiating receive activity (pending resolution of issue
>>>
>>99).
>>
>>>>D.      Abstract processes may include special syntactic 
>>>
>>extensions
>>
>>>>("opaque"
>>>>entities of various kinds) that should be replaced with concrete 
>>>>entities  in any executable artifact that complies with an
>>>
>>abstract
>>
>>>>process using such opaque entities. Which opaque entities are
>>>>permitted is the scope of issue 107.
>>>>
>>>>E. Abstract processes say nothing about *how* concrete, executable 
>>>>realizations of them should be implemented (ie: language,
>>>
>>platform,
>>
>>>>etc) . (analogy to WSDL).
>>>>
>>>>F. Multiple abstract processes together may be created to define a 
>>>>global view of a multi-party business protocol. However,
>>>
>>the way in
>>
>>>>which they may be wired together (connecting partnerLinks
>>>
>>a la WSFL
>>
>>>>global models) is out of scope of BPEL itself.
>>>>
>>>>
>>>>To unsubscribe from this mailing list (and be removed from
>>>
>>the roster
>>
>>
>>>>of the OASIS TC), go to
>>>>
>>>
>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
>>ave_workgr
>>oup.php.
>>
>>>>
>>>To unsubscribe from this mailing list (and be removed from
>>
>>the roster
>>
>>>of the OASIS TC), go to
>>>
>>
>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
>>ave_workgr
>>oup.php.
>>
>>>
>>>
>>To unsubscribe from this mailing list (and be removed from
>>the roster of the OASIS TC), go to 
>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
>>ave_workgr
>>oup.php.
>>
>>
> 
> 
> 
> Choreology Anti virus scan completed