OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]