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)