[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 82 - Proposal to resolve 82 and other abstract process issues
I persoanlly see nothing wrong with Peter's defintions, and seems to suit all the use cases discussed in the past. I also see no reason to create a tower of babel of abstract bpel dialects. Martin. >-----Original Message----- >From: rkhalaf [mailto:rkhalaf@watson.ibm.com] >Sent: 02 December 2004 17:32 >To: Danny van der Rijn >Cc: Furniss, Peter; wsbpel@lists.oasis-open.org >Subject: Re: [wsbpel] Issue 82 - Proposal to resolve 82 and >other abstract process issues > > >Hi, > >I like this proposal as a base for abstract processes and >would like to >add a few more points that would make it more workable. The >semantics of >the base is taken from the semantics of executable plus >"opaque". As you >increase opacity, those semantics become unclear for the general case >(easy example: source/target of link w/ opaque name). From the TC we >saw that for a particular use case or application area one can >converge >on what how the semantics of a construct are affected by the >opacity and >what possible constraints one could add to exec bpel, but when >discussing all possible use cases this discussion goes haywire. > >Instead of arguing about what can and cannot be opaque and the effects >of cutting all of abstract process 1.1 from the spec, we could use >Peter's proposal as a base for abstract BPEL. Using this base >people can >create types or dialects that at a minimum state where they >allow/disallow opacity and its effects on semantics (as a delta from >exec bpel). An abstract process would use a URI to denote its >dialect/type. This approach also lets people who have use cases that >have other requirements define their own dialects/types in any forum. > >Also, it lets us grandfather the abstract bpel we had in spec 1.1 (w/ >minor mods to be in synch with 2.0) by including it in the >spec as one >such dialect. > >This would give a clean solution that can be done quickly. > >Regards, >Rania > >Danny van der Rijn wrote: >> agreed. >> >> 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 <http://www.choreology.com/> >>>> email: peter.furniss@choreology.com >>>> <mailto: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/lea ve_wor >> kgroup.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_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/leave_workgr oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]