Re: [DotGNU]Add Dynamic DNS to DotGNU

[Chris Smith]

On Friday 03 May 2002 16:52, Jonathan P Springer wrote:

> 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).

Okay, I'm with you on this.  I've assumed that the location of the service 
would be known through some sort of discovery lookup.  And now I think about 
it, it does hold true that more than one agent could register a service with 
the same name.  How do we stop this?

Is the proceedure for requesting a service (in .net or dontGNU speak) defined 
at all?  Or are we all continuing under our own assumptions?  I've been 
laying off this area of late, but it is an area of understanding that I need 
to get defined for the VRS project, otherwise we can't document how the thing 
can be used :o)

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

Is that absolute, or a goal that we'd like to achieve?  I still belive at 
this stage that there should be some sort of service resolution service.  In 
fact there has to be one really, else (as in your example) server1 would not 
know that server3 has the service it requires.

[In terms of the VRS, your example is exactly how that cluster works.  An 
external application may contact one of the nodes in the VRS for a service, 
but it may be another node in the cluster that is able to satisfy that 
request.  In quite a few cases the external application will only be 
interested in contacting a particular VRS cluster, as it knows that some 
server in the cluster is able to satisfy all of its needs.  However, in the 
case where there are many distinct and seperate VRS's available on the 
network, an application may require services that are provided by a 
collection of VRS's.  Each VRS does not know about the services available in 
another VRS.  In THIS case, the application needs some way of determining 
which VRS to contact for a particular service.

This may not be a scenario that is envisaged for the VRS at this point, but 
it should be.  The VRS provides location independance, security and 
resilience for services, and it shouldn't be the case that an application may 
only use the service provided by a single VRS cluster.

The above still holds true if you view a VRS as a single server.  Each of 
these 'single servers' do not know about any other servers - This saves you 
having to understand the VRS concept to see what I'm getting at.... :o) 
]

Got me thinking before the weekend! Damn!
Chris

-- 
Chris Smith
  Technical Architect - netFluid Technology Limited.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk