[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]