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


Yaron,

I do not believe that #4 makes sense: some details, e.g. input/output variables, are mandatory for executable processes and are optional for abstract processes. So, using the schema of executable processes for syntactic validation would not work.

Regards,

Ivana

> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Mittwoch, 13. Oktober 2004 05:04
> To: Martin Chapman
> Cc: rkhalaf@watson.ibm.com; wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 82 - Proposal for Vote
> 
> 
> I think Martin's thinking is exactly right. If we are to 
> remove features 
> from Abstract processes then we can only do so if we have use cases 
> which clearly define why these features MUST NOT be 
> available. However 
> such use cases will inevitably mean enabling one set of use 
> cases at the 
> cost of disabling another set. We have already tried going down that 
> road and it ended up leading no where.
> 
> I believe we should adopt Peter's proposal. My understanding of his 
> proposal is that an abstract process is a process that is:
> 
> 1) Superset - a superset of executable processes, that is, 
> all features 
> and functionality available in executable processes are available in 
> abstract processes.
> 
> 2) Abstract - marked as an abstract process. The act of marking the 
> process indicates that the process semantics are not intended to be 
> considered 'complete' in terms of being a self contained executable 
> program. Exactly how far from 'complete' the semantics are is 
> decided on 
> a case-by-case basis and out of scope for BPEL.
> 
> 3) Opaque - allowed to contain opaque elements/attributes.
> 
> 4) Complete - required to be syntactically valid using the executable 
> schema extended with the opaque element/attribute.
> 
> 	Yaron
> 
> 
> 
> Martin Chapman wrote:
> > 
> > 
> > During the Abstract BPEL Sub group meetings I noted that 
> what might be
> > excluded to support one
> > use case might not be excluded for another, and that defining that
> > single dividing line that makes sense to all use cases 
> might take us for
> > ever to define and not really result in much!
> > 
> > Martin.
> > 
> >  >-----Original Message-----
> >  >From: Yaron Y. Goland [mailto:ygoland@bea.com]
> >  >Sent: 11 October 2004 23:59
> >  >To: rkhalaf@watson.ibm.com
> >  >Cc: wsbpel@lists.oasis-open.org
> >  >Subject: Re: [wsbpel] Issue - 82 - Proposal for Vote
> >  >
> >  >
> >  >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/lea
> > ve_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/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_workgroup.php.
> 


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