[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]