[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Recommendations for BPEL4WS
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] Dear
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:
<onAlarm
for=”duration-expression”?
until=”deadline-expression”?> Code
C.1: Definition of a <onAlarm> element for an <eventHandlers> element. <onAlarm
(for=”duration-expression” |
until=”deadline-expression”)> 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.
<receive
partnerLink=”ncname” role=”(myRole|partnerRole)” 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:
I
hope to get a response on these recommendations before December 15th (day of my
final presentation). With
kind regards, Geert Zijlmans Location: Building: Hoofdgebouw Room: HG 5.41 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]