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 to resolve 82 and other abstract process issues

I persoanlly see nothing wrong with Peter's defintions, and seems to
suit all the use cases discussed in the past.
I also see no reason to create a tower of babel of abstract bpel


>-----Original Message-----
>From: rkhalaf [mailto:rkhalaf@watson.ibm.com] 
>Sent: 02 December 2004 17:32
>To: Danny van der Rijn
>Cc: Furniss, Peter; wsbpel@lists.oasis-open.org
>Subject: Re: [wsbpel] Issue 82 - Proposal to resolve 82 and 
>other abstract process issues
>I like this proposal as a base for abstract processes and 
>would like to 
>add a few more points that would make it more workable. The 
>semantics of 
>the base is taken from the semantics of executable plus 
>"opaque". As you 
>increase opacity, those semantics become unclear for the general case 
>(easy example: source/target of link w/ opaque name).  From the TC  we 
>saw that for a particular use case or application area one can 
>on what how the semantics of a construct are affected by the 
>opacity and 
>what possible constraints one could add to exec bpel, but when 
>discussing all possible use cases this discussion goes haywire.
>Instead of arguing about what can and cannot be opaque and the effects 
>of cutting all of abstract process 1.1 from the spec, we could use 
>Peter's proposal as a base for abstract BPEL. Using this base 
>people can 
>create types or dialects that at a minimum state where they 
>allow/disallow opacity and its effects on semantics (as a delta from 
>exec bpel). An abstract process would use a URI to denote its 
>dialect/type. This approach also lets people who have use cases that 
>have other requirements define their own dialects/types in any forum.
>Also, it lets us grandfather the abstract bpel we had in spec 1.1 (w/ 
>minor mods to be in synch with 2.0)  by including it in the 
>spec as one 
>such dialect.
>This would give a clean solution that can be done quickly.
>Danny van der Rijn wrote:
>> agreed.
>> Furniss, Peter wrote:
>>> It was my original thought that nothing is a valid replacement to
>>> opaque, though looking at the text, it doesn't read that way.
>>> Suggest adding, at the end of [4]:
>>> This includes the case where, if otherwise valid, an opaque entity
>>> is removed without replacement in a corresponding
>>> executable artifact)
>>> ([4] and [5] deliberately avoid the implication that the
>>> concretization is necessarily executable bpel, so 
>"syntactically" may
>>> be over-specific)
>>> Peter
>>> -----Original Message-----
>>> From: Danny van der Rijn [mailto:dannyv@tibco.com]
>>> Sent: 01 December 2004 17:59
>>> To: wsbpel@lists.oasis-open.org
>>> Subject: Re: [wsbpel] Issue 82 - Proposal to resolve 82 and other
>>> abstract process issues
>>>     i would explicitly add to your proposal that it is allowed that
>>>     "opaque" be removed completely in an executable realization, so
>>>     long as such removal is syntactically valid. in other words, my
>>>     current reading is that while <opaque> -> <empty> is valid,
>>>     <opaque> ->    <!-- removed opaque --> is not.  my 
>opinion is that
>>>     it should be.  same for attributes.
>>>     danny
>>>     Furniss, Peter wrote:
>>>>     Taking into account previous discussions and definitions, 
>>>>     including the Abstract BPEL
>>>>     sub-group work, the  following definition of Abstract BPEL is
>>>>     proposed as the  resolution
>>>>     of issue 82, to be included in WS-BPEL v2.0.  This definition
>>>>     would supercede the v1.1
>>>>     definition.
>>>>      A resolution in principle of issue 107 is also 
>proposed, in line
>>>>     with this defintion.
>>>>     The other abstract issues can then be rapidly resolved in line
>>>>     with these proposals:
>>>>      91, 97, 99 - abstract processes ARE allowed to omit/hide the
>>>>     features mentioned. The
>>>>     schema should make the  elements in question optional and, in
>>>>     line with 107, allow
>>>>     explicit <opaque> as an alternative.
>>>>      109 - close with no change, mark as revisitable
>>>>      (The existing proposals for some of these issues are 
>already in
>>>>     line with this
>>>>     proposal.)
>>>>      A corollary of [2] below is that the content of the  
>>>>     for executable
>>>>     processes" would become part of  the main body.
>>>>     Proposal for Issue 82:
>>>>     Abstract BPEL definition:
>>>>      A BPEL abstract process is a partially specified process that 
>>>>     is not intended to be
>>>>     executed. Executable and abstract BPEL  processes 
>share the same
>>>>     expressive power, while
>>>>     the latter  allows process definitions that are capable of
>>>>     abstracting  away operational
>>>>     details. Whereas executable processes are  fully 
>concretized and
>>>>     thus can be executed, an
>>>>     abstract  process lacks some of the required concrete
>>>>     operational  details expressed by or
>>>>     when mapping it to a fully executable  artifact. An 
>abstract BPEL
>>>>     process must be
>>>>     explicitly  declared as 'abstract'.
>>>>      Abstract processes serve a descriptive role. A BPEL abstract 
>>>>     process can define the
>>>>     publicly visible behavior of some or all of the services  it
>>>>     offers ("myRole" in its
>>>>     partnerLinks), which may include  its interactions along its
>>>>     partnerLinks with other
>>>>     services.  Alternatively, A BPEL abstract process can define a
>>>>     process  "template"
>>>>     embodying domain-specific best practices, encoded  in a
>>>>     platform-neutral and portable way
>>>>     by both enterprises  and vertical standards organizations. The
>>>>     process "template"
>>>>     captures some essential process logic while leaving out 
>>>>     operational details that will be
>>>>     concretized by the  enterprises and vertical standards
>>>>     organizations when mapping  the
>>>>     partial process specification to a fully executable artifact.
>>>>      Semantics of Abstract Processes:
>>>>      [1]  Although it might contain complete information that
>>>>      would render it executable as specified 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. 
>The  minimum
>>>>     criteria for an abstract
>>>>     process is defined in this  specification while completeness is
>>>>     left undefined.
>>>>      [2]  Abstract processes permit the use of all of the  
>>>>     of executable processes.
>>>>     Thus there is no  fundamental expressive power distinction
>>>>     between abstract and
>>>>     executable processes.
>>>>      [3]  An abstract process may omit operational details that are
>>>>     mandatory for BPEL executable
>>>>     processes either through the omission of specific BPEL elements
>>>>     or attributes listed
>>>>      in the specification, or through the use of "opaque" entities 
>>>>     of various types (i.e.
>>>>     elements, attributes, etc.).
>>>>      However, the semantics of the constructs used in such 
>a  process
>>>>     are exactly the same as
>>>>     their semantics in the  executable context. Addionally, an
>>>>     abstract process is  required
>>>>     to be syntactically valid using the executable  schema extended
>>>>     with the opaque entities.
>>>>      [4]  The omitted operational details may be added anywhere,
>>>>      by or when mapping an abstract process to a fully executable 
>>>>     artifact. In addition, if
>>>>     the points of the omitted  operational details are specified
>>>>     through the use of opaque
>>>>     entities, then these placeholders are replaced with other 
>>>>     concrete entities in any
>>>>     executable artifact that corresponds  to the abstract process
>>>>     using such opaque entities.
>>>>      [5]  Abstract processes say nothing about *how* concretized, 
>>>>     executable realizations of
>>>>     them should be implemented (ie:  language, platform, etc)
>>>>     (analogy to WSDL). Nor do they
>>>>     imply  a relationship(s) with any such realizations.
>>>>     Proposal for issue 107:
>>>>      Language extensions required for abstract processes
>>>>      The language extensions consist of opaque 'placeholders'
>>>>      whose functions are explained below:
>>>>      [1]  Opaque expressions- Needed in particular for opaque 
>>>>     assignment, opaque transition
>>>>     conditions, opaque query  expression. Opaque assignment is used
>>>>     for capturing variable
>>>>     creation/modification in a yet-to-be-concretized 
>>>> mechanism/fashion.
>>>>      [2]  Opaque activities- Hide a concrete BPEL activity, such
>>>>      as a structured activity, a lifecycle activity (ie.
>>>>      receive-start) or even just an "empty". They may also be used 
>>>>     as a source or a target of
>>>>     control links.
>>>>      [3]  Opaque attributes- Hide a concrete BPEL attribute. For 
>>>>     example in invoke, receive
>>>>     or reply activities opaque  attributes are specifying that
>>>>     variables need to be filled in
>>>>     by or when mapping the partial process specification to a fully
>>>>     executable artifact.
>>>>     Peter
>>>>     ------------------------------------------
>>>>     Peter Furniss
>>>>     Chief Scientist, Choreology Ltd
>>>>     web: http://www.choreology.com <http://www.choreology.com/>
>>>>     email: peter.furniss@choreology.com
>>>>     <mailto:peter.furniss@choreology.com>
>>>>     phone: +44 870 739 0066
>>>>     mobile: +44 7951 536168
>>>>Choreology Anti virus scan completed
>>>     To unsubscribe from this mailing list (and be removed from the
>>>     roster of the OASIS TC), go to
>> kgroup.php.
>>Choreology Anti virus scan completed
> To unsubscribe from this mailing list (and be removed from the roster 
> of
> the OASIS TC), go to 

To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

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