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


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]