[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Vrs-development] Re: [DotGNU]Add Dynamic DNS to DotGNU
From: |
Chris Smith |
Subject: |
[Vrs-development] Re: [DotGNU]Add Dynamic DNS to DotGNU |
Date: |
Fri, 3 May 2002 17:25:28 +0100 |
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