[graap-wg] More async/asymmetry comments

[Karl Czajkowski]

I am sorry I missed the telecon.

I have been giving this asymmetry/asynchrony topic more thought and
discussing it with some WSRF/Web Service experts in the Globus
Alliance.  I still think that binding-level reliability can extend the
utility of the basic "synchronous" Agreement creation patters and that
we should repair the "initiator EPR" mess to render the peer-to-peer
asynchronous pattern proposal (with the accept/reject
operations).

Additionally, I am persuaded that as a practical matter, it may be
worth rendering the asymmetric (client-server) interface to support
asynchronous (post+poll) messaging because of limitations in the
binding and tooling world today.  However, I am uncomfortable with the
standing proposal and how it uses correlation IDs.  As was pointed out
to me, there is a related distributed systems management problem of
deciding how this ID "namespace" is managed and how information is
buffered, e.g. for how long.

The low-level binding solution that uses Message-ID has some
unaddressed quality of service issues pertaining to how long the IDs
are remembered in order to enforce idempotence.  It also has security
issues pertaining to whether one client can deny service to another by
anticipating and "polluting" IDs.  I think it would be unfortunate if
we replicated all of these flaws in the WS-Agreement WSDL interface.

The view I share w/ my Globus colleagues is that we should use WSRF
resources to model the buffering state and use those resource EPRs as
the correlation IDs, since we are already using WSRF.  This
alternative is what I was hinting at in an earlier message as "another
layer of resources".

There are really two reasonable variants to doing this, depending on
how we wish to think about the lifecycle of Agreement resources.

  1) Change the Agreement resource lifecycle to again capture
     "pre-agreement" and possibly "post-agreement" states.

     The pre-agreement state can be used to allow a simple low-latency
     Agreement creation step and then have the "responder agrees to
     offer" decision made asynchronously.  The initiator can poll or
     subscribe for notifications to learn what decision is made.

     The post-agreement state would capture the notion Heiko is
     arguing for that it is possible to "expire" or "cancel" an
     agreement without destroying the service interface. I mention
     this only to carry through the modelling approach; the pre and
     post states are really independent concepts.

  2) Introduce separate PreAgreement and PostAgreement resources that
     have lifetimes linked with the existing Agreement resource.

     The PreAgreement resource represents the messaging state for
     determining whether the responder will agree to the offer or
     not.  When he agrees, the initiator can invoke an operation on
     the PreAgreement to obtain the Agreement resource EPR.

     Similarly, the PostAgreement resource would represent the
     Agreement after it is "expired" or "canceled", obviating the need
     for an Agreement resource that exists after Heiko's agreement
     termination?

I suppose you could mix the two, using a PreAgreement resource and
having a post-agreement state on the Agreement resource, but I think
that is a bit strange.  I will try to start a separate thread about
the termination stuff again...

Personally, I prefer (1) as I think it sets us up with a better base
on which to integrate future negotiation mechanisms.  The Agreement
provides a generic introspection interface to present different
negotiation lifecycles.  Optional RPs could provide info on the
specific negotiation process, either as extended pre-agreement states
or as references to some other service domain where that info can be
found.  It was also argued by my WSRF colleagues that this would be
easier to implement in practice than a flurry of "smaller" resources,
although that might depend on implementation technology?


karl

-- 
Karl Czajkowski
karlcz at univa.com