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

[Chris Smith]

On Monday 25 March 2002 19:27, Tim Terlegård wrote:
> > This request payload may have arrived at the VRS via SOAP over HTTP,
> > SMTP, FTP or XML-RPC or any other 'To Be Designed' protocol.
> > The PortManager -> request extraction part of the system is modular. 
> > Once the request payload has been extracted by the appropriate handler
> > and the recipient webservice identified, the webservice is invoked and
> > the request processed.
>
> Looks like a good plan!
>
> > > Authentication will prevent anyone from running executable code on
> > > another machine.
> >
> > Any code deployed into the VRS will run on *any* LDS.
>
> What do you mean by "deploying code into a VRS"?

An LDS makes a service available.  When it does that the code that makes up 
the service is sliced up and shared out and mirrored among the other LDS's in 
the VRS cluster.  Thus the code/service/whatever has been deployed into the 
VRS.

I couldn't think of a better term at the time, and it's kind of stuck in my 
head.

> Yes, but this is authentication, not non-repudiation. Authentication
> verifies that you are then one you say you are. Non-repudiation makes the
> authenticated person unable to deny transactions. It's like a digital
> receipt. If you go to the bank you authenticate yourself with your driving
> license (in Sweden anyway). When you withdraw money you sign a receipt. If
> you didn't have to sign that receipt, you could withdraw money without a
> trace. You have authenticated yourself, but you can deny the transaction
> ever taken place. This is probably desired for some greedy people, but
> non-repudiation is a nice feature I'd say.


True.

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