Karl,
   very interesting.  You are suggesting semantics of "PendingAndTerminating" and "ObservedAndTerminating" are identical to their counterparts (i.e., "Pending" and "Observed", respectively), in all aspects other than the acknowledgement of receiving a termination request.  As a matter of fact once the termination decision is reached by the provider, the agreement state will transition from either of these states to "Terminated" state  immediately (while internal clean up may be taking place).  This also means if the termination request is rejected, then the states revert back to their counterpart states.
       
With this interpretation, a transition is possible from  "PendingAndTerminating" to "ObservedAndTerminating" until the termination decision is reached.
Furthermore, in "ObservedAndTerminatating" state, the service quality must be observed just as in "Observed" state.

If we agree with this interpretation, I can add new transitions from "PendingAndTerminating" and "ObservedAndTerminating" to their counterparts.  We also need new text to clarify the transitions from these states to "Terminated"  -- triggered by  when termination decision is made, (and not when internal clean up may be taking place).


Karl Czajkowski <karlcz@univa.com> wrote on 04/06/2006 11:39:14 AM:
>
>
> I think there is another semantics of concern about the implied
> obligations, i.e. the "payment" or "penalties".  Let us assume in all
> cases that no service delivery guarantees will be expected once the
> client sends the terminate request.
>
> The issue I am trying to raise is that it is not just an atomic "state
> at which the termination is received".  If I, as a broker, am in the
> process of computing acceptance when the termination is received, I
> would like to reserve the right to decide LATER whether I had accepted
> or rejected the agreement.  I cannot make this decision
> instantaneously but must synchronize with a potentially complex
> brokering process.  If allowed to by the specification, I could return
> immediately with the state I know (PendingAndTerminating) and still
> would be able to enter other states to reflect what happened.
>
> So, PendingAndTerminating->ObservedAndTerminating->Terminated would
> mean that I have decided, due to the non-deterministic things I was
> doing as a broker, that I was not able to complete your terminate
> request before accepting.  I will bill you as having terminated an
> accepted agreement, i.e. in order to cover my own obligations with the
> services I was brokering (who may have accepted my offers before I
> could request termination).
>
> On the other hand, PendingAndTerminating->Terminated would mean that I
> have decided that I was able to complete your terminate request before
> accepting.  I will bill you as having terminated a pending agreement,
> i.e. I do not have to cover obligations with brokered services because
> I either terminated them early or never even got around to making
> offers.
>
> The issue is that at the time I, the broker, receive your terminate
> request I do not really know the distributed state of my own brokering
> process and I cannot tell you whether I will have to go into
> ObservedAndTerminating or not.  So, if we do not allow the
> PendingAndTerminating->ObservedAndTerminating transition, then I
> cannot respond to show any "terminating" state until I am able to
> synchronize my distributed process and make this determination.
>
> If you buy any of this, I think there is also an issue of having
> distinct final states (maybe sub-states?) for Terminated to encode the
> history of whether the agreement had been accepted or not.
>
>

Regards.
Asit Dan, Ph.D.
SWG SOA Design Requirements
Phone: (914) 766-1767  
Internet: asit@us.ibm.com
ICSOC 06 PC Chair (http://www.icsoc.org)