[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 82 - Proposal for Vote
That is the purpose of the opaque attributes. They would allow one to explicitly say "I'm not providing this information". Hence why I refer to the schema as an extension of the executable schema, it's not identical. Trickovic, Ivana wrote: > 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]