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] RE: Recommendations for BPEL4WS


Title: Recommendations for BPEL4WS

Dear Geert,

Thanks for contacting us to discuss these issues.

[1]
Your first bullet point is actually an old bug in BPEL 1.1 spec. The related syntax has been changed in BPEL 2.0 spec draft for a while. The current syntax of <onAlarm> within <pick> and <eventHandlers> are relatively consistent now:

Copied from BPEL 2.0 Draft:
======================
<pick createInstance="yes|no"? standard-attributes>
     standard-elements
    ...
    <onAlarm>*
      ( <for expressionLanguage="anyURI"?>duration-expr</for> |
        <until expressionLanguage="anyURI"?>deadline-expr</until> )

         activity
    </onAlarm>
</pick>

======================

======================
<eventHandlers>?
    ...
    <onAlarm>*
      ( <for expressionLanguage="anyURI"?>duration-expr</for> |
        <until expressionLanguage="anyURI"?>deadline-expr</until> )
        <repeatEvery expressionLanguage="anyURI"?>
              duration-expr
        </repeatEvery>?
          activity
    </onAlarm>
</eventHandlers>
======================

Yes, your assumption for C.2 is consistent with the BPEL 2.0 spec draft (“Exactly one of these two attributes must occur in any onAlarm event”).

Side note: Dieter Koenig has kindly pointed out there is another grammar mistake on the combination between the new feature <repeatEvery> and  (<for>|<until>): <repeatEvery> actually be used without (<for>|<until>).   When I grab the pen in the editor group next time, I would fix the syntax in spec text and XSD.

======================
<eventHandlers>?
    ...
    <onAlarm>*
      ( <for expressionLanguage="anyURI"?>duration-expr</for> |
        <until expressionLanguage="anyURI"?>deadline-expr</until> )?
        <repeatEvery expressionLanguage="anyURI"?>
              duration-expr
        </repeatEvery>?
          activity
    </onAlarm>
</eventHandlers>
======================


[2]
For your second bullet point, I would like to mentiont that portType attribute is now optional in BPEL 2.0. So, the redundancy between <receive> and <partnerLinkType> definition is no longer compulsory.
======================
<receive partnerLink="ncname" portType="qname"? operation="ncname"
    variable="ncname"? createInstance="yes|no"?
     messageExchange="ncname"?
    standard-attributes>
    standard-elements
    <correlations>?
    <correlation set="ncname" initiate="yes|join|no"?/>+
    </correlations>
    <fromPart part="ncname" toVariable="ncname"/>*
</receive>
======================

Another side note: you can get our latest spec document and XSD file from the following location:
http://cvs.sourceforge.net/viewcvs.py/wsbpeltc/specifications/


Thanks!


Regards,
Alex Yiu


Satish Thatte wrote:

Dear Geert,

 

Your first point looks like a “bug” in the schema description since both variants are equivalent.  I have copied Alex who is the keeper of the schema.

 

We did debate the second point quite a bit and decided to stay with the over-specified syntax for various reasons of clarity.

 

We also discussed the last point.  Management operations were deemed “out of scope” and sub-process control was postponed to a future version.

 

Hope that helps.  I have copied the TC and other people may have more comments.

 

Satish

 

 


From: Zijlmans, G. [mailto:G.Zijlmans@student.tue.nl]
Sent: Wednesday, November 30, 2005 4:23 AM
To: Satish Thatte
Cc: Zijlmans, G.
Subject: Recommendations for BPEL4WS

 

 

Dear Satish Thatte

I'm a graduate student at the Eindhoven University of Technology, Department of Mathematics and Computer Science (http://w3.win.tue.nl/en/).

As my graduate project I had to develop a High-Level Petri Nets (http://www.petrinets.info/docs/pnstd-4.7.1.pdf) based graphical modeling language for simple generation of BPEL4WS processes. In this project I had to study the syntax and semantics of the BPEL4WS specification thoroughly. This is why I have some recommendations for BPEL4WS.

In my thesis I make the following recommendations concerning BPEL4WS:

        • If one looks closely to the definitions of the <onAlarm> elements of the <eventHandlers> element and the <pick> element, then one difference between them can be noticed, which is that an <onAlarm> element of an <eventHandlers> element can contain both attributes as can be concluded from its definition (see code C.1) and an <onAlarm> element of an <pick> element can contain only one of the same attributes (see code C.2).

 

<onAlarm for=”duration-expression”? until=”deadline-expression”?>
        activity
</onAlarm>

Code C.1: Definition of a <onAlarm> element for an <eventHandlers> element.

<onAlarm (for=”duration-expression” | until=”deadline-expression”)>
        activity
</onAlarm>

Code C.2: Definition of a <onAlarm> element for an <pick> element.

Yet there is a catch, the semantics for an <onAlarm> element of an <eventHandlers> element in state that “Exactly one of these two attributes must occur in any onAlarm event” [BPEL4WS, 2003]. This is a little bit confusing, does it mean that still both attributes may be used or that only one may be used in its definition. In case of the first assumption I would suggest to remove this sentence from the semantics of this element, in the other case I would suggest that the definition becomes the same as that of the <onAlarm> element of a <pick> element.

Note: My GML uses the second assumption.

        • The communication with another process has been defined somewhat awkwardly in my opinion. One has to define a partner link, which involves the definition of a partner link type and the assignments of the roles of the partner link type inside the partner link. In the definition of a partner link type a role is associated with a particular port type that can be used in the communication with the process to which the role belongs. Yet in the definition of a communication activity one has to define a partner link, port type and operation. So what is the goal of defining partner links if they are not really used in the receiving and sending of messages? In my opinion the port type inside the communication activity should be replaced by the role to which this applies (e.g. for a <receive> activity element as shown in code C.3 below). In this way the <partnerLink> element is used to its full extent.

 

<receive partnerLink=”ncname” role=”(myRole|partnerRole)”
        operation=”” variable=”ncname”? createInstance=”yes|no”?
        standard-attributes>
        standard-elements
<correlations>
                <correlation set=”” initiate=””/>
        </correlations>
</receive>

Code C.3: Altered definition of a <receive> activity element.

Note: The use of the value partnerRole for the attribute role might seem a bit strange in the example above, but one can imagine that one has an asynchronous message exchange between two processes in which prior to the receiving communication activity an invocation of the other process has taken place. In that case one might expect an answer in an output communication port of that process.

Except for the ones in my thesis I have another one:

        • In WSFL there is something like a process manager for managing WSFL processes using a set of operations (e.g. spawn, call, resume, etc.). In BPEL4WS there are no means provided for managing BPEL4WS processes. In my opinion the BPEL4WS specification should be extended with a set of operations which can be used to create a BPEL4WS process manager.

 

I hope to get a response on these recommendations before December 15th (day of my final presentation).

With kind regards,
_____________________________________________________

Geert Zijlmans
Eindhoven University of Technology
Department of Mathematics and Computer Science
Den Dolech 2
Postbus 513
5600 MB Eindhoven
The Netherlands

Location: Building: Hoofdgebouw Room: HG 5.41
E-mail: g.zijlmans@student.tue.nl
__________________________________________________




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