[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 82 - Proposal for Vote
Not really. It depends on the use case one have in mind. Regards, Ivana > -----Original Message----- > From: Martin Chapman [mailto:martin.chapman@oracle.com] > Sent: Mittwoch, 13. Oktober 2004 12:13 > To: Trickovic, Ivana; '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 > > > one could say exactly the same for abstract/not absrtact. > > >-----Original Message----- > >From: Trickovic, Ivana [mailto:ivana.trickovic@sap.com] > >Sent: 13 October 2004 10:37 > >To: 'Martin Chapman'; '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 > > > > > >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. > >> > > > >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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]