[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 82 - some slides
some slides for 82 Assaf Arkin wrote: > We see a clear need for abstract process definitions as per the original > spec (AP 1.1), and are concerned that the proposals to overload abstract > process definitions would interfere with their utility. > > I can imagine that during the lifecycle of a process definition, one > would want to exchange "incomplete" process definitions that do not > fully conform to BPEL semantics (executable or abstract). At the moment > the only technical requirement we have is satisfied by what XML defined > as "well-formed XML". But assume that we reach a point where we want > more specific restrictions and semantics, beyond "readable/writeable XML > document using BPEL elements". For example, creating a "template" > document type with specific semantics that could eventually be developed > into an executable or abstract. > > I would imagine that such a template document would be extended > syntactically, that any syntactical extension will be allowed (see > Peter's definition). On the other hand, the semantics of abstract > processes (AP 1.1) is such that not all syntactic extensions are allowed > (see Satish's definition). We are concerned that overloading abstracts > to support both cases would lead to confusion, unwanted restrictions on > future extensions, and difficulty in understanding AP 1.1. > > Further, it will be impossible to define a template for an abstract, if > such a template is called an abstract, as is the resulting abstract, as > is any template used to generate a process definition. Overloading is > not necessarily simplifying. > > I would like to propose that in allowing different profiles, we do not > overload existing BPEL semantics. Let abstracts be AP 1.1, let profiles > use their own set of semantics. For example, a profile for a template > could introduce the /template /attribute. The attribute will serve as a > marker for a BPEL processor that must understand the attribute, and can > use its value to understand the semantics associated with the document. > Further, it can be used in combination with the /abstract /attribute to > distinguish between templates for abstracts and templates for executables. > > Assaf > > > Charlton Barreto wrote: > >> Satish, >> >> I believe the distinctions are orthogonal to one another, and that we >> are looking at "wide" vs. "deep" vis-a-vis what can be accomplished >> completely per the level (high and abstract vs. low and detailed). By >> going "wide" and approaching the issue at a high enough level, as per >> Peter's proposal, we can provide a complete-enough abstract >> definition. Some tweaking of the definition for everyone's comfort >> level may be needed, but I feel that profiles takes us away from >> "wide" and abstract and introduces much complexity, which I feel to >> be more than necessary. I also feel that going too "deep" in the >> interpretation framework, and not sticking to the abstract level of >> Peter's proposal, will reintroduce the sort of issues that the SC >> wrestled with earlier this year. I agree with your point #1 (from >> http://lists.oasis-open.org/archives/wsbpel/200412/msg00023.html), >> but I feel that otherwise Peter's definition is generally complete >> to address absBPEL at the "wide", abstract level. I'm for avoiding >> profiles altogether, and sticking to an abstract level for the >> definition - if not Peter's proposal, then Peter's proposal as a base >> with some tweaking, >> >> -Charlton. >> >> On 12/12/2004, at 21:50, Satish Thatte wrote: >> >>> Charlton, >>> >>> 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. The >>> notion in BPEL4WS 1.1 is singular and Peter's proposal does not >>> actually capture it. I showed what needs to be added to Peter's >>> proposal to make it correspond to AP1.1. The only reason to >>> introduce profiles is to allow new interpretations such as templates >>> that are not present in the spec today. The TC should decide if we >>> want singular or plural interpretation of abstract processes. But >>> we do need an interpretation framework that is actually specified to >>> the point where the semantic interpretation is unambiguous. For >>> that Peter's proposal needs some additions, as I explained in my >>> mail http://lists.oasis-open.org/archives/wsbpel/200412/msg00023.html. >>> >>> Peter's proposal is indeed very close to what we need. I hope we >>> will have an amended proposal that fills the remaining gaps to >>> discuss during the face-to-face meeting. >>> >>> Satish >>> >>> >>> >>> -----Original Message----- >>> From: Charlton Barreto [mailto:charlton_b@mac.com] >>> Sent: Friday, December 10, 2004 5:11 PM >>> To: <wsbpel@lists.oasis-open.org> <wsbpel@lists.oasis-open.org> >>> Cc: Peter Furniss; Danny van der Rijn >>> Subject: Re: [wsbpel] Issue 82 - Proposal to resolve 82 and other >>> abstract process issues >>> >>> I agree with Peter's proposal as is and believe this is the better >>> route to resolving the outstanding absBPEL issues. I feel that it is >>> preferred to take a "wide", more abstract approach as opposed to a >>> "deep", more detailed one, especially given the difficult on agreeing >>> upon the details. >>> >>> Likewise, I feel that adding profiles/dialects to absBPEL would only >>> add complexity, impact interoperability, and take absBPEL "deeper" than >>> needed or is resolvable, and agree with Martin's point on the issue. >>> I'd prefer to stick to Peter's "wide" approach as it addresses the >>> issues well enough at a high level. >>> >>> On 02/12/2004, at 02:40, Furniss, Peter wrote: >>> >>>> It was my original thought that nothing is a valid replacement to >>>> opaque, though looking at the text, it doesn't read that way. >>>> >>>> Suggest adding, at the end of [4]: >>>> >>>> This includes the case where, if otherwise valid, an opaque entity >>>> is removed without replacement in a corresponding >>>> executable artifact) >>>> >>>> ([4] and [5] deliberately avoid the implication that the >>>> concretization is necessarily executable bpel, so "syntactically" may >>>> be over-specific) >>>> >>>> Peter >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Danny van der Rijn [mailto:dannyv@tibco.com] >>>> Sent: 01 December 2004 17:59 >>>> To: wsbpel@lists.oasis-open.org >>>> Subject: Re: [wsbpel] Issue 82 - Proposal to resolve 82 and other >>>> abstract process issues >>>> >>>> >>>> i would explicitly add to your proposal that it is allowed that >>>> "opaque" be removed completely in an executable realization, so long >>>> as such removal is syntactically valid. in other words, my current >>>> reading is that while <opaque> -> <empty> is valid, <opaque> -> >>>> <!-- removed opaque --> is not. my opinion is that it should be. >>>> same for attributes. >>>> >>>> danny >>>> >>>> Furniss, Peter wrote: >>>> Taking into account previous discussions and definitions, including >>>> the Abstract BPEL >>>> sub-group work, the following definition of Abstract BPEL is proposed >>>> as the resolution >>>> of issue 82, to be included in WS-BPEL v2.0. This definition would >>>> supercede the v1.1 >>>> definition. >>>> >>>> A resolution in principle of issue 107 is also proposed, in line with >>>> this defintion. >>>> >>>> The other abstract issues can then be rapidly resolved in line with >>>> these proposals: >>>> >>>> 91, 97, 99 - abstract processes ARE allowed to omit/hide the features >>>> mentioned. The >>>> schema should make the elements in question optional and, in line >>>> with 107, allow >>>> explicit <opaque> as an alternative. >>>> >>>> 109 - close with no change, mark as revisitable >>>> >>>> (The existing proposals for some of these issues are already in line >>>> with this >>>> proposal.) >>>> >>>> A corollary of [2] below is that the content of the "extensions for >>>> executable >>>> processes" would become part of the main body. >>>> >>>> >>>> >>>> Proposal for Issue 82: >>>> >>>> Abstract BPEL definition: >>>> >>>> A BPEL abstract process is a partially specified process that is not >>>> intended to be >>>> executed. Executable and abstract BPEL processes share the same >>>> expressive power, while >>>> the latter allows process definitions that are capable of >>>> abstracting away operational >>>> details. Whereas executable processes are fully concretized and thus >>>> can be executed, an >>>> abstract process lacks some of the required concrete operational >>>> details expressed by or >>>> when mapping it to a fully executable artifact. An abstract BPEL >>>> process must be >>>> explicitly declared as 'abstract'. >>>> >>>> Abstract processes serve a descriptive role. A BPEL abstract process >>>> can define the >>>> publicly visible behavior of some or all of the services it offers >>>> ("myRole" in its >>>> partnerLinks), which may include its interactions along its >>>> partnerLinks with other >>>> services. Alternatively, A BPEL abstract process can define a >>>> process "template" >>>> embodying domain-specific best practices, encoded in a >>>> platform-neutral and portable way >>>> by both enterprises and vertical standards organizations. The process >>>> "template" >>>> captures some essential process logic while leaving out operational >>>> details that will be >>>> concretized by the enterprises and vertical standards organizations >>>> when mapping the >>>> partial process specification to a fully executable artifact. >>>> >>>> >>>> Semantics of Abstract Processes: >>>> >>>> [1] Although it might contain complete information that >>>> would render it executable as specified 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. The minimum >>>> criteria for an abstract >>>> process is defined in this specification while completeness is left >>>> undefined. >>>> >>>> [2] Abstract processes permit the use of all of the constructs of >>>> executable processes. >>>> Thus there is no fundamental expressive power distinction between >>>> abstract and >>>> executable processes. >>>> >>>> [3] An abstract process may omit operational details that are >>>> mandatory for BPEL executable >>>> processes either through the omission of specific BPEL elements or >>>> attributes listed >>>> in the specification, or through the use of "opaque" entities of >>>> various types (i.e. >>>> elements, attributes, etc.). >>>> >>>> However, the semantics of the constructs used in such a process are >>>> exactly the same as >>>> their semantics in the executable context. Addionally, an abstract >>>> process is required >>>> to be syntactically valid using the executable schema extended with >>>> the opaque entities. >>>> >>>> [4] The omitted operational details may be added anywhere, >>>> by or when mapping an abstract process to a fully executable >>>> artifact. In addition, if >>>> the points of the omitted operational details are specified through >>>> the use of opaque >>>> entities, then these placeholders are replaced with other concrete >>>> entities in any >>>> executable artifact that corresponds to the abstract process using >>>> such opaque entities. >>>> >>>> [5] Abstract processes say nothing about *how* concretized, >>>> executable realizations of >>>> them should be implemented (ie: language, platform, etc) (analogy to >>>> WSDL). Nor do they >>>> imply a relationship(s) with any such realizations. >>>> >>>> >>>> >>>> Proposal for issue 107: >>>> >>>> Language extensions required for abstract processes >>>> >>>> The language extensions consist of opaque 'placeholders' >>>> whose functions are explained below: >>>> >>>> [1] Opaque expressions- Needed in particular for opaque assignment, >>>> opaque transition >>>> conditions, opaque query expression. Opaque assignment is used for >>>> capturing variable >>>> creation/modification in a yet-to-be-concretized mechanism/fashion. >>>> >>>> [2] Opaque activities- Hide a concrete BPEL activity, such >>>> as a structured activity, a lifecycle activity (ie. >>>> receive-start) or even just an "empty". They may also be used as a >>>> source or a target of >>>> control links. >>>> >>>> [3] Opaque attributes- Hide a concrete BPEL attribute. For example >>>> in invoke, receive >>>> or reply activities opaque attributes are specifying that variables >>>> need to be filled in >>>> by or when mapping the partial process specification to a fully >>>> executable artifact. >>>> >>>> >>>> >>>> >>>> Peter >>>> >>>> ------------------------------------------ >>>> Peter Furniss >>>> Chief Scientist, Choreology Ltd >>>> web: http://www.choreology.com >>>> email: peter.furniss@choreology.com >>>> phone: +44 870 739 0066 >>>> mobile: +44 7951 536168 >>>> >>>> Choreology Anti virus scan completed >>>> 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/ >>>> leave_workgroup.php. >>>> Choreology Anti virus scan completed >>> >>> >>> >>> >>> 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/ >>> leave_workgroup.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/ >>> leave_workgroup.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/leave_workgroup.php. >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]