Re: [DotGNU]Add Dynamic DNS to DotGNU

[Jonathan P Springer]

On Fri, May 03, 2002 at 03:52:59PM +0100, Chris Smith wrote:
> On Thursday 02 May 2002 21:12, Jonathan P Springer wrote:
> 
> > The key point that I hope all will remember is that we MUST separate
> > service names from physical addressing.  Perhaps its obvious to others,
> > but it wasn't until I saw Seth's memo that I realized the danger.
> 
> I've always seen this as a problem.
> The VRS kind-of addresses the problem by having services deployed across a 
> cluster of machines.  Each machine in the cluster may serve a service, but 
> it's not the only one.
> 
> So we end up with the situation of a call for service:
> 
> reference.of.a.vrs/which/service/to/request
> 

I think that we're falling into a trap laid by HTTP-based web services.

Let's posit multiple servers (server1.dotgnu.org, server2.dotgnu.org,
etc.).  Now let's say I create a service: "Jonathan's Bond Ladder".  
For the sake of the example, the service is a simple calculation.  No
persistent data needs to be stored.

So far so good?  Now how does invokation work?

Let me define some terms as I will use them.  Please correct me if I'm
off-standard:

   Application:   Some local program that wants to use a service.
   Client:   The actually program/library that calls a service.
   Server:   A machine on which services (and DotGNU core software)
             executes.
   Service:   A remote, public resource which accepts input and gives
              defined results.
   Cluster:   A collection of mutually aware servers.

What follows is my ideal world.

My application (let's say it's personal accounting software) wants
to execute the service "Jonathan's Bond Ladder".  In order to so it
tells the local DotGNU client (Portable.NET?) what service it wants to
execute and what the arguments are.  The DotGNU client has been
configured (or blindly pings or...) with server(s) to contact whenever a
WebService is requested.  This configuration can locally be as simple as
"use server1 for everything" or could be a local mapping of services to
servers.

Let's presume the former configuration.  The client connects to the
server (HTTP, Jabber, punchcards and pneumatic pipes, whatever) and
requests "Jonathan's Bond Ladder".  The server replies, "I don't know
that service, but server3 does."  The client repeats the process with
server3 to get its results (or downloads the service executable to a
secure local server instance).

The key is that the physical location of the server never enters into
the logical name of the service.

-js


-- 
-Jonathan P Springer <address@hidden>
------------------------------------------------------------------------------
"A standard is an arbitrary solution to a recurring problem." - Joe Hazen