Re: [ogsi-wg] Reasons for the GSH/GSR split

[Guy Rixon <gtr@ast.cam.ac.uk>]

Thanks for the clarification, Ian.

I still think that this business of refreshing the GSR is a bit iffy from the
client-writer's point of view.

 - If a service instance adds a new binding but keeps its other, existing
   bindings unchanged, then why should a client using the old bindings
   have to get a new GSR to go on doing what it used to do?

 - If a service instance withdraws an old binding of a port, then
   a client that depends on that binding can't refresh the GSR usefully.

>From the point of view of someone writing a client in Java, if the old
bindings cease to operate, then I have to make code changes and recompile.
The new client then has to go and get a new GSH before it can re-resolve to a
GSR for a different binding.  From the client's point of view, a service
instance that changes its binding might as well be two separate instances.
Handling TTL on the GSR seems a lot of overhead for a simple client.


On Tue, 30 Jul 2002, Ian Foster wrote:

> Guy:
>
> Three comments:
>
> 1) One reason for a CSR changing is if a service instance adds a new
> protocol, say a high-speed transport protocol. Another might be a change in
> authentication scheme.
>
> 2) OGSA is being defined with a view to supporting large-scale software
> systems in which component evolution is a real concern. Here, the
> capabilities of entities may change over time. Perhaps not frequently, but
> if a service instance is running for years, it could well happen that the
> set of bindings that it supports changes.
>
> 3) While any network entity always has the option of stopping working
> unilaterally, the structured way of handling GSR evolution is to use
> time-to-live data associated with the GSR to signal when clients should
> refresh it.
>
> Ian.
>
>
> At 10:13 AM 7/30/2002 +0100, Guy Rixon wrote:
> >I'm having still having difficulty in understanding the usefulness of the
> >GSH/GSR split.  As I understand it, a client uses a dynamic service by:
> >
> >1. Calling a factory to create a service instance and receiving a GSH
> >from the factory.
> >
> >2. Calling a resolver service, passing the GSH and getting a GSR back.
> >
> >3. Calling the instance, using the address and binding information carried in
> >the GSR.
> >
> >The distinction I heard at GGF5 was "the difference between finding and
> >binding", which I take to mean that having a GSH locates an instance of a
> >service but you have to get a GSR to find out what binding it has (and hence
> >how to talk to it).  I have problems with this.
> >
> >Suppose I have a service with two bindings for the port of interest (HTTP and
> >SMTP, say) and I have a client that can talk to only one of these bindings.
> >The client wants to _select_ a binding for the instance that it gets from the
> >factory.  That is, the client needs the information that will eventually be
> >available through the GSR before it has a GSH; before there is even an
> >instance for the GSH and GSR to apply to.  When the client does get a GSH, it
> >needs to know that the GSH applies to an instance with the binding of choice.
> >This seems to make the GSH->GSR resolution redundant.
> >
> >I also understand that a GSR can become invalid and that this can happen while
> >its service instance is still running and the GSH is still valid.  Why should
> >this happen?  Does it mean that a service instance could unilaterally change
> >the binding it supports while running?  This would be a bizarrely disruptive
> >thing for it to do.  Presumably, if the service instance crashes or times out,
> >then the GSH is invalid too.  I.e. any GSRs resolved from that GSH would be
> >invalid from the start.  I can't see a case that requires that a client
> >renew a GSR from a given GSH.
> >
> >Apologies if the answers to this are well known; they're not obvious to me
> >from the available papers.  Something for the OGSA primer maybe?
> >
> >Guy Rixon                                       gtr@ast.cam.ac.uk
> >Institute of Astronomy                          Tel: +44-1223-337542
> >Madingley Road, Cambridge, UK, CB3 0HA          Fax: +44-1223-337523
>
> _______________________________________________________________
> Ian
> Foster                                      http://www.mcs.anl.gov/~foster
>
> Math & Computer Science Div.            Dept of Computer Science
> Argonne National Laboratory             The University of Chicago
> Argonne, IL 60439, U.S.A.               Chicago, IL 60637, U.S.A.
> 630 252 4619 (fax 5986)                  773 702 3487 (fax 8487)
>
>

Guy Rixon 				        gtr@ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523