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 Y. Goland wrote:
> 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.
> 

-- This would have to be a separate issue. This issue deals with 
clarification not rearchitecture. If you want to bring this up, valid 
arguments should be made for all the cases in the fork, perhaps as each 
being its own issues. That way we can pull up only things that make 
sense. Either way, my proposal does not close doors for going up related 
venues syntactically. It explains about abstract processes so that we 
can have intelligent discussions in the other issues about the specifics 
such as syntax etc.

> 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.
> 

-- This is already in the proposal , that there is intent using the 
abstract process attribute.

> 3) Opaque - allowed to contain opaque elements/attributes.
> 

-- This is already in the proposal.

> 4) Complete - required to be syntactically valid using the executable 
> schema extended with the opaque element/attribute.
> 

This is depending on 1 and does not belong here. The proposal however 
says that they must be well-formed processes so they must be complete in 
that sense.. Currently there is no consensus on the superset idea so (4) 
  the way it is worded is a no-go.

>     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/leave_workgr
>> oup.php.
>>
>>




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