[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Vrs-development] VRS and SEE/DEE goals

From: Chris Smith
Subject: Re: [Vrs-development] VRS and SEE/DEE goals
Date: Sun, 24 Mar 2002 12:21:15 +0000

On Saturday 23 March 2002 14:43, Tim Terlegård wrote:
> Howdy!
> I'm still fumbling a bit. The goals of the SEE/DEE and VRS are not that
> well explained, IMHO. It's hard to tell whether they should be the same
> project or in what way they overlap.

Well in my mind SEE/DEE and VRS do overlap.
A VRS is merely a collection of LDS.  One of these LDSs will be, say, my home 
server.  If I send a request for a webservice that is available in the VRS I 
do so to via my LDS because that is the nearest VRS component geographically 
to me.  So it is ON my home server that the webservice that I requested will 

Now isn't this the same as the SEE/DEE idea?

An LDS will execute a webservice within a secure sandbox because anyone who 
allows thier prized home/company server to run an LDS and become part of one 
or more VRSs will NOT want webservices deployed into the VRS to be able to 
access their raw filesystem or resources!!!!

So the LDS embodies a SEE by default.

I also see the need for 'public access' to webservices within the VRS.  In 
this case some of the LDS's need to open themselves up to public requests by 
offering a SOAP server etc to the internet at large.  The webservice would 
then run on the LDS that the public client sent the webservice request to.

We definately need a UDDI of some sort in this case so these public 
non-LDS/VRS 'clients' can find what webservices are available where and what 
LDS 'gateways' are available to serve the webservice.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]