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


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]