[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 82 - Proposal for Vote
+1 Yaron Y. Goland wrote: > I think Martin's thinking is exactly right. If we are to remove > features from Abstract processes then we can only do so if we have use > cases which clearly define why these features MUST NOT be available. > However such use cases will inevitably mean enabling one set of use > cases at the cost of disabling another set. We have already tried > going down that road and it ended up leading no where. > > I believe we should adopt Peter's proposal. My understanding of his > proposal is that an abstract process is a process that is: > > 1) Superset - a superset of executable processes, that is, all > features and functionality available in executable processes are > available in abstract processes. > > 2) Abstract - marked as an abstract process. The act of marking the > process indicates that the process semantics are not intended to be > considered 'complete' in terms of being a self contained executable > program. Exactly how far from 'complete' the semantics are is decided > on a case-by-case basis and out of scope for BPEL. > > 3) Opaque - allowed to contain opaque elements/attributes. > > 4) Complete - required to be syntactically valid using the executable > schema extended with the opaque element/attribute. > > Yaron > > > > Martin Chapman wrote: > >> >> >> During the Abstract BPEL Sub group meetings I noted that what might be >> excluded to support one >> use case might not be excluded for another, and that defining that >> single dividing line that makes sense to all use cases might take us for >> ever to define and not really result in much! >> >> Martin. >> >> >-----Original Message----- >> >From: Yaron Y. Goland [mailto:ygoland@bea.com] >> >Sent: 11 October 2004 23:59 >> >To: rkhalaf@watson.ibm.com >> >Cc: wsbpel@lists.oasis-open.org >> >Subject: Re: [wsbpel] Issue - 82 - Proposal for Vote >> > >> > >> >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/lea >> ve_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_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_workgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]