[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 82 - Proposal for Vote
Yaron, I do not believe that #4 makes sense: some details, e.g. input/output variables, are mandatory for executable processes and are optional for abstract processes. So, using the schema of executable processes for syntactic validation would not work. Regards, Ivana > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Mittwoch, 13. Oktober 2004 05:04 > To: Martin Chapman > Cc: rkhalaf@watson.ibm.com; wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue - 82 - Proposal for Vote > > > 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/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_workgroup.php. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]