[graap-wg] minutes from 4/5 telecon

[Asit Dan]

Karl,
   It is understood that receiving a termination message (and upon 
provider acknowledgement),  i) an agreement state transitions from a 
"Pending" to "PendingAndTerminating", and ii) the termination of 
service/agreement is not instantaneous (as you have elaborated). 

What we are trying to resolve here are the semantics of the states 
"PendingAndTerminating"  and "ObservedAndTerminating", i.e., what are the 
obligations in delivering (service and) service quality, while an 
agreement is being terminated.   Clearly, the options are 

                     a) No further obligations in delivering service 
quality (these states explicitly capture start of termination process, and 
the only difference between the above two states are historical, i.e., the 
state at which the termination message is received).
                     b) Degraded quality of service (what are "observing"? 
Just how bad is it during termination process? Does client still expects 
any service quality? Are the BV specifications, i.e.,  penalties or 
preferences the same? Obvioulsy, further semantics has to be defined for 
specific domains for this to be meaningful.)
         and,   c)  Full quality of service, i.e., acknowledges start of 
termination process, but remains undefined when  this will terminate, and 
service quality is fully observed. Again, we need more detailed 
specification to make sure there is a limit to this termination process, 
and/or, different BV assertions during this process. 

I think the simplest semantics (that doesn't require any further 
specification) is to assume upon starting the termination process the 
service quality obligations are no longer valid and observed.  There is no 
easy way to have a consistent  state across multi-tier services, i.e., 
where a service may depend on other autonomous services (as defined by its 
own set of agreements).  Many years   back, in the transaction 
community(HPTS), I argued for  COYOTE (Cover Yourself Transaction 
Environment) principles,  where service implementation and management 
issues are hidden from a client, even when a service is dependent on other 
services.  The attached paper illustrates these principles. 
As a matter of fact, to further simplify the agreement states according to 
the above principles, we should assume termination of agreement (and not 
necessarily provider cleaning up and bookkeeping) is instantaneous, i.e., 
receiving the termination message takes the agreement state from "Pending" 
or "Observed" to "Terminated" state.

In any case, if we choose the other two options, we have to specify 
further details in WS-Agreement specification for this transition to be 
meaningful.

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



Karl Czajkowski <karlcz at univa.com> 
Sent by: owner-graap-wg at ggf.org
04/06/2006 12:29 AM

To
Jim Pruyne <jim_pruyne at hp.com>
cc
GRAAP-WG <graap-wg at gridforum.org>
Subject
Re: [graap-wg] minutes from 4/5 telecon






On Apr 05, Jim Pruyne modulated:
> - On updated termination diagram:
>   * Asit to send a note on the mailing list to verify that we really
>     have a transition from PendingAndTerminating to
>     ObservedAndTerminating.  None of us seem to be able to come up with
>     a message sequence that would cause that to happen.

I think this transition is implied by Toshi's "broker" example, unless
we assert that there is some sort of transactional semantics in the
protocol?

If you make an offer to a broker, and it is pending in the broker
because he has started to make offers to other service managers, your
terminate request MAY arrive during the hazard window where the broker
has started making commitments but has not received accepts from the
subsidiary services yet.

The client-to-broker agreement changes state to pending-terminating,
and the broker can attempt to terminate the subsidiary
agreements. However, depending on whether they terminate before or
after they are accepted, the broker may want to communicate this
"distributed acceptance" transition that occurred during the
termination phase.

I assume this has impact and is important to model in the event that
the "penalties" are different depending on whether termination occurs
before or after acceptance.  The fundamental issue is that with
pending agreements, the initiator has already committed in his offer
message and he is at the mercy of the responder to decide if a
termination request occurs before or after acceptance.

Because of these hierarchical and asynchronous agreement scenarios, I
think we have to make the termination request interaction also be
asynchronous.  Just as with the acceptance/rejection window, there is
a window between when the termination request is received and the
outcome is known.  We can either delay the response, or model the
uncertain intermediate state in the agreement state.  I think we
should do the latter to be consistent with how we have handled the
acceptance/rejection window.

For consistency, perhaps we should even go so far as to introduce two
terminate request variants?  One that is synchronous and delays the
response, and one that responds early but leaves the agreement in an
uncertain state?


karl

-- 
Karl Czajkowski
karlcz at univa.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/graap-wg/attachments/20060406/e6b3566c/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hpts97.pdf
Type: application/octet-stream
Size: 1076364 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060406/e6b3566c/attachment.obj