[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 82 - Proposal for Vote
Whether a process definition is final(ized) or not is out of the scope of a process model - it is a tool/methodology isuse. Regards, Ivana > -----Original Message----- > From: Martin Chapman [mailto:martin.chapman@oracle.com] > Sent: Mittwoch, 13. Oktober 2004 11:29 > To: 'Furniss, Peter'; 'Satish Thatte'; 'Danny van der Rijn'; > ygoland@bea.com > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 82 - Proposal for Vote > > > Or we could go an alternive route and rather that say abstract of not, > we say whether it is final(ized) or not. > If its not final anything goes! > > Martin. > > >-----Original Message----- > >From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] > >Sent: 13 October 2004 10:05 > >To: Satish Thatte; Danny van der Rijn; ygoland@bea.com > >Cc: wsbpel@lists.oasis-open.org > >Subject: RE: [wsbpel] Issue - 82 - Proposal for Vote > > > > > >Well, it wasn't a question of asking for an opaque marker, as a > >question of what determined a bpel document as abstract. I was > >roughly summarising what I had heard suggested a while ago, > >rather than detailing. > > > >Compared to Yaron's summary, the thing I omitted was > >whether there was an explicit attribute that said "this is an > >abstract definition". If there isn't, then internal > >examination of the script can only say: > > a) this contains at least one "opaque" - it must be abstract > > b) this does not contain "opaque" - but it still might > >be an abstraction of deployed processes, with some aspects > >left unstated. > > > >I think I prefer Yaron's summary, where even if there is no > >explicit opaque, the process definition is marked as abstract. > >It would be imaginable to have an executable process > >definition which is used as if it were abstract, with > >additional stuff being put in. (analogous to extending a > >concrete java class as opposed to an abstract one). It would > >then be up to external information to determine what > >relationship the definition had to a deployment. Yaron's > >proposal would make the script self-documenting in this > >aspect, and if someone did want to extend a truly executable > >definition, but publish the base, they would just add the > >marker attribute. But then even exectuables may have aspects > >that are effectively hidden (as interactions with an internal > >service, as platform-specific decisions etc). I'm undecided on > >this specific. > > > > > > > >Peter > > > > > >> -----Original Message----- > >> From: Satish Thatte [mailto:satisht@microsoft.com] > >> Sent: 13 October 2004 06:41 > >> To: Danny van der Rijn; ygoland@bea.com > >> Cc: wsbpel@lists.oasis-open.org; Furniss, Peter > >> Subject: RE: [wsbpel] Issue - 82 - Proposal for Vote > >> > >> > >> When did Peter ask for "at least one opaque marker"? I must have > >> missed it .. > >> > >> Satish > >> > >> > >> -----Original Message----- > >> From: Danny van der Rijn [mailto:dannyv@tibco.com] > >> Sent: Monday, October 11, 2004 4:38 PM > >> To: ygoland@bea.com > >> Cc: wsbpel@lists.oasis-open.org > >> Subject: Re: [wsbpel] Issue - 82 - Proposal for Vote > >> > >> We're back to my objection of describing abstract > processes in terms > >> of conformance. You may not have intended to go there > Yaron, and I > >> apologize in advance if this is the case. > >> > >> My understanding of the current set of proposals, is that > the query > >> string would not affect conformance proofs at all, and > >therefore DOES > >> NOT BELONG in abstract processes. What you described would > >therefore > >> be termed an incompletely specified process, and one which > does not > >> meet the definition of abstract process. > >> > >> My preference, which I have (perhaps ineptly) stated in > >various ways, > >> coincides more with Peter's proposition that an abstract > process is > >> one with at least one "opaque" marker, for whatever value > of opaque > >> marker we decide upon. Note that this has nothing to do with > >> observable conformance, just with degree of specificity. > >> > >> I would also argue that an abstract process is defined by > >intent, and > >> not by syntax, e.g. an abstract process is one that is marked > >> abstract=true. > >> > >> I hesitate to go through my complete (but inept) arguments > >again, but > >> since it's been a while... > >> > >> It makes more sense to me that there will be multiple conflicting > >> definitions of abstract process: the observable > conformance flavor, > >> the proper superset which you describe, others. If we are > going to > >> preserve a notion of an abstract process that has any meaning to a > >> large number of the audience of our specification, one way > to do it > >> would be to mark the process with a string (perhaps a URI) that > >> selects some syntax/semantics/intentions of abstractness. I worry > >> that standardizing that portion of "abstractness" that aids > >> only in defining observable conformance will increase the > >> size and complexity of the BPEL spec without giving benefit > >> to a large portion of the community. Therefore I, for one, > >> can not support the current proposals. I would prefer the > >> absence of abstract processes to the current situation. > >> > >> One counter-argument is that while the use-case you provide is > >> ill-specified, the observable conformance use case can be > >nailed down > >> precisely. Using this as an argument for actually doing so, > >however, > >> and ignoring everything else, is specious. > >> > >> Yaron Y. Goland wrote: > >> > >> > 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/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_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_workgr > >> oup.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/le > ave_workgroup.php. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]