[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: No Subject
Rationale 1: "compensating a process as a whole" introduces uncertainties into the specification. These uncertainties leaves the feature hardly usable in my opinion.
Uncertainty 1: how to request compensating a completed process
instance is undefined.
Uncertainty 2: how long a process instance remains
"compensatable" is undefined. It should be natural to expect
that after some time the data of a completed process is
removed from the system (to save disk space, etc). Thereafter
compensation cannot be performed.
Rationale 2: There already is an easier and clearer way of achieving the same effect without incurring the uncertainties
described in Rationale 1. By cofiguring a process as follows, you can clearly express:
* how to initiate compensation of the process "body", and
* the deadline of initiating compensation after the completion
of the process "body".
if a certain message is received, compensate.
... compensation handler ...
... the "body" of the process ...
Merits:
* Clearer and more flexible semantics.
* An execution engine can immediately remove data for a
completed process instance.
Assaf Arkin:
6/19:
The event handler is enabled for the lifetime of the process before you reach a point where compensation is possible.
However, you can replace the wait with a pick that either waits for a compensation request (received only once) or gives
up after some time-out. That's consistent with your suggestion for writing a compensation handler using the available
set of constructs.
But there two issues that would arise as per the current specification:
1. Currently the specification does not allow you to perform compensation from outside a compensation handler, so you
can't invoke compensation on enclosed scopes. Clearly you would want to do that from the compensating activity that
follows the base activity.
Yuzo rewrote the example as: I've rewritten the example as follows. It should work now.
catch compensationRequested fault and compensate.
... compensation handler ...
... the "body" of the process ...
** this needs tested **
2. For management purposes there's a value in determining that the process has reach the 'completed' case after which it
can only be compensated or discarded. Structuring activities in this manner would work, but would not give a management
tool visibility into the process state.
Yuzo:
To solve the problem, we may need to formalize the concept of "body" of the process such that a process instance can be
in state "process as a whole=running, body=completed". I don't like this idea very much, but nonetheless present it
here to hopefully promote the discussion.
Bernd:
6/20:
I just wanted to contribute some experiences from implementing the spec. And in my experience it was additional work to
support the sequence activity. It was not much, so we could easyly keep that construct, but in that case I would vote
for a rationale in the spec, describing, that sequence has no sematic differences too a sequentially linked flow, just
to asure everybody who is reading the spec did understand it correctly and is not left wondering what he has missed.
David RR Webber:
6/20:
Message text written by "Yuzo Fujishima"
>
> Rationale 1: "compensating a process as a whole" introduces uncertainties into the specification. These uncertainties
> leaves the feature hardly usable in my opinion.
Also - without clear use cases to back up the need for this, it will just be an opened source of continued frustration
into the future.
I also see - once we have the use case work done, and once we have the liaisons in place - we can suggest some other
means to solve the extended picture - especially when the use case need is to coordinate across the architecture to
achieve the desired functionality.
Other teams have done this with Technical Notes and Adjuncts to the main spec' - and it works very well.
Means you can focus on the core aspects and get those really done well - and not sweat trying to have the whole kitchen
sink in there in the first release.
Satish:
6/20:
Consider also the BA protocol in WS-Transaction which shows how the compensation of a subordinate instance would be
invoked by a controlling instance, if we were to specify such a subordinate-controller relationship in BPEL, effectively
"remoting" a scope as a separate instance (without implicit state sharing). The BA protocol messages could be handled
by implicit event handlers that maintain the BA protocol semantics.
I am not saying yet that we should actually do this, just throwing out some interesting possibilities to think about.
Edwin:
6/20:
It would be very useful to have a session focused on compensation, scope state and WS-C/WS-T. We talked about that at
the F2F and in the following email exchanges.
Edwin:
6/20:
I suggest that we take one of the examples used by Satish in the F2F (travel procurement) and try to get down into the
details of how exception management and compensation management would be implemented. This will help us flush out the
details of how BPEL and WS-Transaction (BA) work together.
If we decide that this is valuable, I volunteer to implement the BPEL processes once the use case has been agreed on.
Assaaf Arkin:
6/20:
Suppose you have some process A that performs some operation and supports compensation through its process-level
compensation handler. (The topic of discussion is process-level compensation handlers, not scope-level compensation
handlers, which are covered in the appendix)
You have some process B that performs an activity called X. Activity X invokes process A and so process B may later on
decide to invoke A's compensation handler. Assume you would want to use WS-TX to do that. Interoperability means that
two systems would understand how it works and do it in the same manner (barring any other differences).
What would the compensation handler for activity X look like?
Let's say A is never compensated unless there is a compensation handler for activity X. The compensation handler for
activity X does not need to do anything, so it contains an activity. According to the current spec, if the
compensation handler includes an activity then nothing would happen. So there needs to be a clarification that
some work would indeed happen and that this compensation handler may actually throw a fault (if A returns 'faulted').
Another implementation may decide that to compensate A you need to invoke the default compensation handler for X. So if
X has a compensation handler containing it would not invoke A's compensation handler, but if it has no
compensation handler then A gets compensated using WS-TX. You can use the activity to prevent A from being
compensated (a good thing), but you can't interact with A within X's compensation handler, which violates the need to
pass data to a compensation handler.
Another possibility is for X's compensation handler to explicitly send a compensation message to A. Unfortunately, X
doesn't know the participant or coordination addresses and so can't pass them to A's WS-TX implementation.
Considering the lack of clarification in the specification I am very curious to see what such an example would look
like.
Edwin Response:
I think that we all agree that although this might be clear in a few people's mind, there is room for interpretation and
for the sake of interoperability the spec needs further clarification on that specific subject.
I am suggesting that we start by defining a simple example as a way to identifying the areas that need further
clarification within the spec.
Assaf:
6/20:
I think what we lack here is coherence. If we are not striving for a minimal feature set than there are others features
we should entertain that would simplify some definitions especially from the perspective of modeling and/or XML
authoring. If we are looking for a minimal feature set what are our criteria? Is that strictly to address execution or
do we need to look at a larger scope?
Assaf:
6/20:
The abstract as I understand it, is used to define the business protocol. I'm not sure what other purposes it serves,
the only one I can think of is to constrain the process definition. Which means you need to check for interface
compliance, again in terms of implementation a doesn't give you much unless we have a profile in which
is not supported.
As for modifying by humans, again we have to look at how often/how much. If it's frequent then you add a requirement to
support XML authoring and add more constructs to the syntax to make life easier. If it's less frequent, then you try to
be as easy to use as XML Schema, WSDL and other related specifications.
--0-265799556-1058574871=:85590
Content-Type: text/html; charset=us-ascii
<DIV><BR><BR><B><I>Sazi Temel <sazi@bea.com></I></B> wrote:
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid; WIDTH: 100%">Subject: FW: [wsbpel-uc] Proposed Use Case Conf Call: 7/21 @ 1 PM PT / 4 PM ET<BR>Date: Fri, 18 Jul 2003 19:59:37 -0400<BR>From: "Sazi Temel" <SAZI@BEA.COM><BR>To: <SALLYSTAMAND@YAHOO.COM><BR><BR>
<META content="MSHTML 6.00.2800.1141" name=GENERATOR>
<STYLE>v\:* {
BEHAVIOR: url(#default#VML)
}
o\:* {
BEHAVIOR: url(#default#VML)
}
w\:* {
BEHAVIOR: url(#default#VML)
}
.shape {
BEHAVIOR: url(#default#VML)
}
</STYLE>
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:SmartTagType name="mswterms" namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><o:SmartTagType name="time" namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><o:SmartTagType name="date" namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType>
<STYLE>st1\:* {
BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<STYLE>@font-face {
font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
page: Section1
}
OL {
MARGIN-BOTTOM: 0in
}
UL {
MARGIN-BOTTOM: 0in
}
</STYLE>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<DIV><SPAN class=074345923-18072003><FONT face=Arial color=#0000ff size=2>Hi Sally,</FONT></SPAN></DIV>
<DIV><SPAN class=074345923-18072003><FONT face=Arial color=#0000ff size=2>It looks like I am having problems to send e-mmail to the group (working on to fix it..) mean while would you please relay may message to the group.. thanks.</FONT></SPAN></DIV>
<DIV><SPAN class=074345923-18072003><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=074345923-18072003><FONT face=Arial color=#0000ff size=2>Monday, 7/21 at 4pm est for conf call opk for me.</FONT></SPAN></DIV>
<DIV><SPAN class=074345923-18072003><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=074345923-18072003><FONT face=Arial color=#0000ff size=2>thanks again.</FONT></SPAN></DIV>
<DIV><SPAN class=074345923-18072003><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=074345923-18072003><FONT face=Arial color=#0000ff size=2>.Sazi</FONT></SPAN></DIV>
<DIV><SPAN class=074345923-18072003></SPAN> </DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> John Evdemon [mailto:jevdemon@microsoft.com]<BR><B>Sent:</B> Friday, July 18, 2003 4:31 AM<BR><B>To:</B> wsbpel-uc@lists.oasis-open.org<BR><B>Subject:</B> [wsbpel-uc] Proposed Use Case Conf Call: 7/21 @ 1 PM PT / 4 PM ET<BR><BR></FONT></DIV>
<DIV class=Section1>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hello all,<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Please accept my apologies for the delayed follow-up. I am on the road this week with limited email access. <o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I would like to arrange a Use Case Conf Call for next Monday at <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:time Minute="00" Hour="13" w:st="on">1 PM</st1:time> PT (4 PM ET). Please let me know if this time will be feasible.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">A draft agenda appears below (I will finalize this agenda later tomorrow):<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN style="mso-list: Ignore">1)<FONT face="Times New Roman" size=1><SPAN style="FONT: 7pt 'Times New Roman'"> </SPAN></FONT></SPAN></SPAN></FONT><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Review of current status<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN style="mso-list: Ignore">2)<FONT face="Times New Roman" size=1><SPAN style="FONT: 7pt 'Times New Roman'"> </SPAN></FONT></SPAN></SPAN></FONT><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Review of Use Case candidates<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal style="MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in; mso-list: l0 level2 lfo1"><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN style="mso-list: Ignore">a.<FONT face="Times New Roman" size=1><SPAN style="FONT: 7pt 'Times New Roman'"> </SPAN></FONT></SPAN></SPAN></FONT><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I have compiled a document (attached) summarizing selected posts from the mailing list. Many of these posts could be considered for one or more Use Cases<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal style="MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in; mso-list: l0 level2 lfo1"><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN style="mso-list: Ignore">b.<FONT face="Times New Roman" size=1><SPAN style="FONT: 7pt 'Times New Roman'"> </SPAN></FONT></SPAN></SPAN></FONT><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Simpl EB<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal style="MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in; mso-list: l0 level2 lfo1"><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN style="mso-list: Ignore">c.<FONT face="Times New Roman" size=1><SPAN style="FONT: 7pt 'Times New Roman'"> </SPAN></FONT></SPAN></SPAN></FONT><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">CPFR (One of the nine steps)<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal style="MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in; mso-list: l0 level2 lfo1"><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN style="mso-list: Ignore">d.<FONT face="Times New Roman" size=1><SPAN style="FONT: 7pt 'Times New Roman'"> </SPAN></FONT></SPAN></SPAN></FONT><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Other candidates?<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN style="mso-list: Ignore">3)<FONT face="Times New Roman" size=1><SPAN style="FONT: 7pt 'Times New Roman'"> </SPAN></FONT></SPAN></SPAN></FONT><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Vote on which Use Case candidates will be presented to the TC at our next conf call<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN style="mso-list: Ignore">4)<FONT face="Times New Roman" size=1><SPAN style="FONT: 7pt 'Times New Roman'"> </SPAN></FONT></SPAN></SPAN></FONT><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Assign “owners” to each Use Case<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN style="mso-list: Ignore">5)<FONT face="Times New Roman" size=1><SPAN style="FONT: 7pt 'Times New Roman'"> </SPAN></FONT></SPAN></SPAN></FONT><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Next steps<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Again, this is a draft agenda that will be finalized tomorrow (I will also send out the call-in information). <o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I will send out some “reading assignments” for people that may be unfamiliar with Simpl EB or CPFR.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Please let me know if 7/21 at <st1:time Minute="00" Hour="13" w:st="on">1 PM</st1:time> PT/4 PM ET will work for you. <o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Thanks for your time – sorry again about the delay in getting this conf call scheduled.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Sincerely,<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">John Evdemon<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
<DIV>
<DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
<HR tabIndex=-1 align=center width="100%" SIZE=2>
</SPAN></FONT></DIV>
<P class=MsoNormal><B><FONT face=Tahoma size=2><SPAN style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> Sally St. Amand [mailto:sallystamand@<st1:mswterms w:st="on">yahoo</st1:mswterms>.com] <BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, <st1:date w:st="on" Year="2003" Day="10" Month="7" ls="trans">July 10, 2003</st1:date> <st1:time Minute="21" Hour="10" w:st="on">10:21 AM</st1:time><BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> Sazi Temel<BR><B><SPAN style="FONT-WEIGHT: bold">Cc:</SPAN></B> wsbpel-uc@lists.oasis-open.org<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [wsbpel-uc] When is the next call?</SPAN></FONT><o:p></o:p></P></DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P>
<DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">Sazi-<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">There has not been a conference call since 6/23. On yesterdays general conference call JohnE said he was going to schedule a use case conf call late this week or early next week. Since you were gone I put out a doc Voting on Use Cases that is a proposal we need to talk about and Ben Block put out some info and proposals relating to the template. Check the website for this stuff.<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">Personally I can do a conf call next Mon (7/14), not Tues, and Wed is a maybe. If we all let John know our availability it might be helpful to get something set up.<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">Hope your vacation was fun.<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">Sally<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV></DIV></DIV></DIV>Satish:<BR><BR>6/15:<BR>The "multi-start activities" example is one kind of use case, where rendezvous occurs at activation hence before the<BR>creation of any instance ID. Consider also multiway conversations, especially those where A-->B-->C-->A types of<BR>communication loops occur. What these need are mechanisms for carrying context and "infecting" the right instances with<BR>the context -- WS-Coordination has this as a general mechanism. The scope of such a coordination does not in general<BR>coincide with the lifetime of a process instance. You can think of correlation sets as a "poor man's context" mechanism.<BR>But I agree with the goal of reducing the scope of explicit correlation if possible, but that would mean dependency on<BR>some specific context mechanisms for two-way conversations and multi-way coordination. I would
hate to see us create<BR>some sort of meta model for context that has to be mapped to concr ete coordination layers. Too much complexity.<BR><BR>6/16:<BR>I believe a <SEQUENCE>activity can be replaced with a <FLOW suppressJoinFailure="false">activity with a few more<BR>caveats, to produce equivalent control sequencing behavior.<BR><BR>Assaf Arkin:<BR>6/16:<BR>What if a <SEQUENCE>was properly rewritten as a <FLOW>? My question again, is there a proper way to rewrite a sequence<BR>as a flow so you preserve the semantics of the execution but only use the flow activity? If so, what are the pros/cons of<BR>doing that?<BR><BR><BR>Bernd (responding to Satish):<BR>>>I honestly don't think <SEQUENCE>needs to justify its existence.<BR>>>Concurrency with synchronization can emulate sequentiality but that is <BR>>>clearly a convoluted and expensive way to do the simplest kind of <BR>>>orchestration.<BR>>> <BR>>><BR>><BR>This may be true from the standpoint
of writing bpel by hand, but for sure it is a non issue for implementation.<BR>Depending on your internal runtime data model, a sequence is only an additional complication, provided the fact, that you<BR>need to offer a implementation for flow, anyway. And since a sequence does not forbid to have links in and out, it also<BR>means your engine has to support the notion of synchronisation, anyway.<BR><BR>So we should make clear in the spec, that it is only a shortcut, for skipping those links inside a sequential flow, but<BR>all other properties will apply, anyway.<BR><BR>Ron Ten-Hove:<BR>6/17:<BR>If BPEL were to be strictly a modelling language, then the inclusion of both <SEQUENCE>and <FLOW>would be<BR>justifiable from the modelling perspective. Perhaps we can make this claim for abstract BPEL?<BR><BR>On the other hand, "concrete" BPEL has a different purpose: it is an executable description of a process. It may be<BR>appropriate for the TC to create a formal semantics for the
execution of each BPEL element, in order that we may<BR>analyse and better understand what we are creating. Even if we don't go as far as formalising the semantics, it is<BR>true that the simpler the language, the easier it is to reason about. From this perspective, it is entirely<BR>appropriate for Arkin to ask that the <SEQUENCE>activity justify its existence, when equivalent structures exist<BR>elsewhere.<BR><BR>So what is our rational moving forward? Is this (primarily) a modelling language, or an executable artifact? Or are<BR>there better criteria for resolving these issues?<BR><BR><BR>Ron Ten-Hove:<BR>6/17:<BR>this brings us back to the "how do we author BPEL documents?" question again. I would submit that if the process author<BR>has no more sophisticated an authoring tool than vi or emacs, wizardry will be required regardless. Managing information<BR>from assorted WSDL documents, complying to one or more abstract BPEL processes, and sorting through a relatively
complex<BR>syntax (XML serialization being what it is), we have already restricted the pool of authors to a relatively small one<BR>(with all the right skill sets). Even hello world, aided by syntactic sweeteners, becomes a headache.<BR><BR>On the other hand, if the process author is aided by auitably helpful tools, then the amount of detail he/she need<BR>manage can be reduced. If they are faced with authoring process graphs, suitably annotated, and BPEL exists safely<BR>behind the scence, then the BPEL language can be optimized to improve important aspects of a process language, rather<BR>than raw-text authoring.<BR><BR>A high-level process graph is typically not directly executed, but rather converted / compiled to be executed atop a<BR>purpose-built infrastructure. Human-friendly structures are converted into ones amenable to execution by machine.<BR><BR>The question is -- where does BPEL fit in this? Is it a high-level representation, suitable for modelling processes in
a<BR>fashion that a business analyst (or other such domain expert) want? Or is it an intermediate form, with well understood<BR>execution semantics? Or is it a little of both? If the last choice is correct, then what principles will be used to<BR>choose between the dual poles of representing high-level domain concepts, and simple executable semantics?<BR><BR>Assaf Arkin:<BR>6/17:<BR>Hello world does require a 2-star wizard. You need to define your message using XML Schema, strap a WSDL operation onto<BR>that, add the protocol bindings so you can define an endpoint. When you link that to the BPEL make sure to use the<BR>proper references to the proper definitions disperesed throughout these documents, or it will not validate. And don't<BR>forget the deployment descriptor -- you won't be able to send/receive messages without it.<BR><BR>We can make BPEL as easy as HTML, you still won't be able to deploy it without tooling support. So if you look at the<BR>whole mix of specifications
you have to deal with just to say "hello world", it really makes no difference. For the<BR>tools both options are the same, and for the vi user both options are impossible.<BR><BR>You need to build support for serializing activities that synchronize through links. It's not an easy task, but you'll<BR>have to do it anyway. If you already spent the time making flows work properly, might as well use that piece of code in<BR>all cases. If you write it once and use it all over the place then there's a good ROI argument in favor of using <FLOW><BR>as much as possible. Less code to develop, less test cases, etc. At least from an execution perspective.<BR><BR><BR>Jim Webber:<BR>6/18:<BR>After having hand written BPEL scripts, and intending to do so in future (because sometimes you just have to do things<BR>for yourself), I would plead the case for keeping useful bits of syntactic sugar like <FLOW>. For those of us who will<BR>be writing BPEL by hand (and I might be a minority of one here)
other constructs like <MACRO>or <PROCEDURE>would be<BR>very welcome too.<BR><BR>The point is, although I can see that tools are really useful in this arena, there will always be cases where tools<BR>aren't applicable. Given that BPEL hasn't been used much so far, it is premature to start optimising away features that<BR>I (for one) might rely on!<BR><BR>Maciej:<BR>6/18:<BR>BPEL is an abstract virtual machine, it should have the minimum constructs necessary to express the universe of<BR>supported programs; if there is no "if-then-else" because "switch" has all the expressive power (and then some) of "if-<BR>then-else", then there should not be a "sequenence" by the same reasoning.<BR><BR><BR>Satish:<BR>6/19:<BR>if a sequence has incoming and outgoing links, and is now replaced with a flow with links itself, I submit that<BR>recovering the original pattern and its simple inexpensive implementation would be challenging.<BR><BR>In other words, we would be raising the bar for
implementers of both tools and runtime engines, especially if we expect<BR>them to cater to the prejudices of those who prefer the "block structured" approach rather than the "linking activities"<BR>approach that Assaf seems to like these days.<BR><BR><BR>Yuzo:<BR>6/19:<BR>I would like to propose that we remove the concept of "compensating a process as a whole".<BR><BR>From 6.4: <BR>If a compensation handler is specified for the business<BR>process as a whole (see Compensation Handlers), a business<BR>process instance can be compensated after normal completion by<BR>platform-specific means. This functionality is enabled by<BR>setting the enableInstanceCompensation attribute of the<BR>process to "yes".<BR><BR>Rationale 1: "compensating a process as a whole" introduces uncertainties into the specification. These uncertainties leaves the feature hardly usable in my opinion.<BR><BR>Uncertainty 1: how to request compensating a completed process<BR>instance is
undefined.<BR><BR>Uncertainty 2: how long a process instance remains<BR>"compensatable" is undefined. It should be natural to expect<BR>that after some time the data of a completed process is<BR>removed from the system (to save disk space, etc). Thereafter<BR>compensation cannot be performed.<BR><BR>Rationale 2: There already is an easier and clearer way of achieving the same effect without incurring the uncertainties<BR>described in Rationale 1. By cofiguring a process as follows, you can clearly express:<BR>* how to initiate compensation of the process "body", and<BR>* the deadline of initiating compensation after the completion<BR>of the process "body".<BR><BR><PROCESS><BR><EVENTHANDLERS><BR>if a certain message is received, compensate.<BR></EVENTHANDLERS><BR><SEQUENCE><BR><SCOPE><BR>... compensation handler ...<BR>... the "body" of the process ...<BR></SCOPE><BR><WAIT ... time desired some until /><BR></SEQUENCE><BR></PROCESS><BR><BR>Merits:<BR>* Clearer and more flexible
semantics.<BR>* An execution engine can immediately remove data for a<BR>completed process instance.<BR><BR><BR>Assaf Arkin:<BR>6/19:<BR>The event handler is enabled for the lifetime of the process before you reach a point where compensation is possible.<BR>However, you can replace the wait with a pick that either waits for a compensation request (received only once) or gives<BR>up after some time-out. That's consistent with your suggestion for writing a compensation handler using the available<BR>set of constructs.<BR><BR>But there two issues that would arise as per the current specification:<BR><BR>1. Currently the specification does not allow you to perform compensation from outside a compensation handler, so you<BR>can't invoke compensation on enclosed scopes. Clearly you would want to do that from the compensating activity that<BR>follows the base activity.<BR><BR>Yuzo rewrote the example as: I've rewritten the example as follows. It should work
now.<BR><BR><PROCESS><BR><FAULTHANDLERS><BR>catch compensationRequested fault and compensate.<BR></FAULTHANDLERS><BR><SEQUENCE><BR><SCOPE><BR>... compensation handler ...<BR>... the "body" of the process ...<BR></SCOPE><BR><PICK><BR><ONMESSAGE...FOR request... compensation><BR><THROW faultName="compensationRequested" /><BR></ONMESSAGE><BR></PICK><BR></SEQUENCE><BR></PROCESS><BR><BR>** this needs tested **<BR><BR><BR>2. For management purposes there's a value in determining that the process has reach the 'completed' case after which it<BR>can only be compensated or discarded. Structuring activities in this manner would work, but would not give a management<BR>tool visibility into the process state.<BR><BR>Yuzo:<BR>To solve the problem, we may need to formalize the concept of "body" of the process such that a process instance can be<BR>in state "process as a whole=running, body=completed". I don't like this idea very much, but nonetheless present it<BR>here to hopefully promote the
discussion.<BR><BR><BR>Bernd: <BR>6/20:<BR>I just wanted to contribute some experiences from implementing the spec. And in my experience it was additional work to<BR>support the sequence activity. It was not much, so we could easyly keep that construct, but in that case I would vote<BR>for a rationale in the spec, describing, that sequence has no sematic differences too a sequentially linked flow, just<BR>to asure everybody who is reading the spec did understand it correctly and is not left wondering what he has missed.<BR><BR><BR>David RR Webber:<BR>6/20:<BR>Message text written by "Yuzo Fujishima"<BR>><BR>> Rationale 1: "compensating a process as a whole" introduces uncertainties into the specification. These uncertainties<BR>> leaves the feature hardly usable in my opinion.<BR><BR><BR>Also - without clear use cases to back up the need for this, it will just be an opened source of continued frustration<BR>into the future.<BR><BR>I also see - once we have the use case work
done, and once we have the liaisons in place - we can suggest some other<BR>means to solve the extended picture - especially when the use case need is to coordinate across the architecture to<BR>achieve the desired functionality.<BR><BR>Other teams have done this with Technical Notes and Adjuncts to the main spec' - and it works very well.<BR><BR>Means you can focus on the core aspects and get those really done well - and not sweat trying to have the whole kitchen<BR>sink in there in the first release.<BR><BR><BR>Satish:<BR>6/20:<BR>Consider also the BA protocol in WS-Transaction which shows how the compensation of a subordinate instance would be<BR>invoked by a controlling instance, if we were to specify such a subordinate-controller relationship in BPEL, effectively<BR>"remoting" a scope as a separate instance (without implicit state sharing). The BA protocol messages could be handled<BR>by implicit event handlers that maintain the BA protocol semantics.<BR><BR>I am not saying yet
that we should actually do this, just throwing out some interesting possibilities to think about.<BR><BR><BR>Edwin:<BR>6/20:<BR>It would be very useful to have a session focused on compensation, scope state and WS-C/WS-T. We talked about that at<BR>the F2F and in the following email exchanges.<BR><BR><BR>Edwin:<BR>6/20:<BR>I suggest that we take one of the examples used by Satish in the F2F (travel procurement) and try to get down into the<BR>details of how exception management and compensation management would be implemented. This will help us flush out the<BR>details of how BPEL and WS-Transaction (BA) work together.<BR><BR>If we decide that this is valuable, I volunteer to implement the BPEL processes once the use case has been agreed on.<BR><BR>Assaaf Arkin:<BR>6/20:<BR>Suppose you have some process A that performs some operation and supports compensation through its process-level<BR>compensation handler. (The topic of discussion is process-level compensation handlers, not
scope-level compensation<BR>handlers, which are covered in the appendix)<BR><BR>You have some process B that performs an activity called X. Activity X invokes process A and so process B may later on<BR>decide to invoke A's compensation handler. Assume you would want to use WS-TX to do that. Interoperability means that<BR>two systems would understand how it works and do it in the same manner (barring any other differences).<BR><BR>What would the compensation handler for activity X look like?<BR><BR>Let's say A is never compensated unless there is a compensation handler for activity X. The compensation handler for<BR>activity X does not need to do anything, so it contains an <EMPTY>activity. According to the current spec, if the<BR>compensation handler includes an <EMPTY>activity then nothing would happen. So there needs to be a clarification that<BR>some work would indeed happen and that this compensation handler may actually throw a fault (if A returns 'faulted').<BR><BR>Another
implementation may decide that to compensate A you need to invoke the default compensation handler for X. So if<BR>X has a compensation handler containing <EMPTY>it would not invoke A's compensation handler, but if it has no<BR>compensation handler then A gets compensated using WS-TX. You can use the <EMPTY>activity to prevent A from being<BR>compensated (a good thing), but you can't interact with A within X's compensation handler, which violates the need to<BR>pass data to a compensation handler.<BR><BR>Another possibility is for X's compensation handler to explicitly send a compensation message to A. Unfortunately, X<BR>doesn't know the participant or coordination addresses and so can't pass them to A's WS-TX implementation.<BR><BR>Considering the lack of clarification in the specification I am very curious to see what such an example would look<BR>like.<BR><BR>Edwin Response:<BR><BR>I think that we all agree that although this might be clear in a few people's mind, there is room
for interpretation and<BR>for the sake of interoperability the spec needs further clarification on that specific subject.<BR><BR>I am suggesting that we start by defining a simple example as a way to identifying the areas that need further<BR>clarification within the spec.<BR><BR>Assaf:<BR>6/20:<BR>I think what we lack here is coherence. If we are not striving for a minimal feature set than there are others features<BR>we should entertain that would simplify some definitions especially from the perspective of modeling and/or XML<BR>authoring. If we are looking for a minimal feature set what are our criteria? Is that strictly to address execution or<BR>do we need to look at a larger scope?<BR><BR><BR>Assaf:<BR>6/20:<BR>The abstract as I understand it, is used to define the business protocol. I'm not sure what other purposes it serves,<BR>the only one I can think of is to constrain the process definition. Which means you need to check for interface<BR>compliance, again in terms of
implementation a <SEQUENCE>doesn't give you much unless we have a profile in which <FLOW><BR>is not supported.<BR><BR>As for modifying by humans, again we have to look at how often/how much. If it's frequent then you add a requirement to<BR>support XML authoring and add more constructs to the syntax to make life easier. If it's less frequent, then you try to<BR>be as easy to use as XML Schema, WSDL and other related specifications.<BR><BR></BLOCKQUOTE></DIV>
--0-265799556-1058574871=:85590--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]