[Vrs-development] Re: [DotGNU]The Worldwide Computer

[Chris Smith]

On Wednesday 13 February 2002 18:04, Bill wrote:

> We have touched on the Webservice component as a proxy
> once or twice already.   An Executable Object Dataset
> is created, registered and stored in the Cluster in
> the normal manner.  That components function, however,
> is limited to opening a link to another server outside
> of the Cluster and passing requests and responces back
> and forth with the general net.  The data remains
> private, and the real server is also masked.


Okay.  Are you suggesting :

Client -> VRS -> Private_LDS
       <-     <-------+

... in that the VRS that the client contacted directly for the 'non 
distributed resource' performs the request on the clients behalf?

If so, then the data has to go through two network hops.  It's better if the 
client makes the request directly to the Private_LDS for the resource (unless 
the resource is something that the VRS needs to satisfy the entire of the 
clients request, of course).  Getting the client to call the private_LDS can 
be done in several ways - the Discovery phase returns the address of the 
private_LDS for that resource, or a request for a resource gets a 'redirect' 
response.

The latter is not very nice if you're a client calling onto a webservice, and 
you're not an LDS.  IF you *are* and LDS, then redirects probably are 
possible and may even be helpful.  Goldwater Domains certainly used them to 
hide the fact that machines in a cluster have gone down.

> The other approach was also mentioned real early on.
> A service can be registered and flagged so that it can
> be requested only when the owners LDS is online.

Yeah - we've not talked about this recently.

> This may make sense for 'Passport' like things such as site
> passwords and credit card transactions. This creates
> the possibility that the data can then be drawn
> directly from the users node and not stored in the
> Cluster Repository, in effect a sole-source server
> connected directly to the Cluster, not a remote one
> like the first example.

Yeah, but there is a distinction here, in that availablility is transient and 
controlled from the Node Discovery Server - probably - as LDS's of this type 
come up and down they need to tell the NDS about this.  When clients (or 
other LDS's) fail to contact an LDS, then they too need to tell the NDS about 
this so the NDS can decide whether it wants to stop serving that LDS's 
service details - See post 
http://subscribe.dotgnu.org/pipermail/developers/2002-February/001985.html


> However, this opens a large breach in the sandbox.
> The LDS would need to be able to touch files other
> than the Repository archive and any configuration
> files we end up needing.

Unless they're files that are within the sandbox.
I think basically they'd all have to be within the Virtual Computer that 
we're effectively talking about.  If you put a file in the Virtual Computer's 
filespace, then there must be methods to access the file too.  Now these can 
be properties of the filespace itself as well as properties of the entity in 
question.

Chris

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