[Top][All Lists]

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

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

From: Bill Lance
Subject: Re: [Vrs-development] VRS and SEE/DEE goals
Date: Mon, 25 Mar 2002 05:28:07 -0800 (PST)

--- Tim Terlegård <address@hidden> wrote:
> I now realized that SEE is just about securely
> running a web service on the 
> local host.

This is my understanding as well.

 I guess it's the DEE that does all the
> network job, making a 
> distributed system of SEEs.

As far as I know, DEE does not address distributed
precessing at all, except in the sense that a
procedure's code can be downloaded from the central
ASP server, as an explicir request, and locally

> If ASPs is possibly with p2p and p2p results in a
> _very_ distributed system, 
> which is very fault tolerant among other things.
> Then, why wouldn't DEE want 
> this? Are there any DotGNUers in here?

Perhaps they would.  It is my impression that no one
is currently working on DEE.

> <thinking_loud>
> Thinking peer-2-peer. A Virtual Remote Server could
> be a peer. An ASP could 
> be a VRS. All users that want to use the ASP is a
> part of a larger VRS (that 
> includes the ASP VRS) and think they contact a
> single ASP server, when they 
> matter a fact communicates with a cluster. Every VRS
> node runs a lookup 
> service, which enables anyone to browse the web
> services available on any 
> node or browse the complete VRS. A VRS node can also
> turn this off. This 
> allows a VRS cluster to have a single server as a
> lookup directory (although 
> this makes it less p2p, the webservices can still be
> requested in a pure p2p 
> manner.).
> </thinking_loud>

The above is consistant with our thinking so far.

> "calls like J2EE"? You mean RMI?
> Web in Web Services must mean that http is used and
> a web server is handling 
> the requests. Providing a service with RMI, Corba or
> just pure sockets, I 
> wouldn't call that a Web Service, just a service. As
> I'm a programmer I 
> myself think of a service as an object that exposes
> its methods to public 
> Internet users. This definition doesn't include any
> protocol information 
> whatsoever. But that's just my own definition...

The term 'webservices' does seem to imply an http
exclusive system.  That's one of the reason I find the
term a bit confusing in the context of VRS.  And I
think that other protocols are just, if not more
functional, for certain kinds of services, such as ftp
and smtp. 

> > That's exactly what I have in mind.  The protocols
> are
> > plugins that layer over the functional parts.  I
> think
> > this may be anohter area where VRS and SEE
> thinking
> > have differed.
> Hmm, sounds weird. Why not make the design in such a
> way that it'll be easy 
> to add new protocols?

Well, that's basically what we want to do.  Exactly
how this is done has not been nailed down yet.  If you
have some ideas, please throw them out.

> >
> > Humm ..  I'm not sure that we want to do that in
> the
> > infrastructure.  Although authintication services
> may
> > certainly be an offered service.
> Authentication will prevent anyone from running
> executable code on another 
> machine. I'm not sure if this is handled by Pnet
> though? Should all services 
> provided by VRS be accessable by anyone? Wouldn't it
> be neat to allow certain 
> services to be called by certain users? If an admin
> wants to adjust some 
> setting on a machine through a web service, anyone
> would be able to use that 
> service. There must be some authentication here.
> In the VRS docs it also says that administration of
> the LDS is done through 
> the use of web services. If there's no
> authentication needed, anyone will be 
> able to admin the LDS.
> Do you want for instance a bank to be able to use
> the VRS? If so, the bank 
> needs an assurance that the user can't deny it
> withdraw a certain amount of 
> money. They need the non-repudiation feature.
> Maybe it's not one of the goals of the VRS to be
> totally secure. In that 
> case, why is that so?

I'm sorry.  I think I misunderstood your original
question.  We intend to have strong authintication
within the VRS cluster of participating nodes.  A node
must first be subscribed to a specific VRS cluster. 
Then it is authinticated with openSSL when it logs in.

I was thinking of general webusers of the exposed
services.  And authentication for those is specific to
the service being requested.  They may or may not have
it, depending on the nature of the service.  And these
types of authentication must rely on methods other
than those built into the VRS itself.  

Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®

reply via email to

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