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

[Chris Smith]

On Monday 25 March 2002 10:34, Tim Terlegård wrote:

> > 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? Actually, in my design/programming tasks during the
> years at school, making the design flexible (even if it's not needed) has
> always resulted in much nicer OO. Often one also thinks "wow, because I did
> like that I can also do like this". It's so cool with design  :-)
> And one might regret doing a non-flexible design. One might figure out
> later that "aaaah, stupid me, I didn't think of that, I must be able to do
> this and this as well". But of course, one can't make a design that suits
> everywhere, then one would only need one design for all projects in the
> world  :-)

In the VRS webservices are passed whatever request payload came in with the 
request.  This is currently assumed to be XML.

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.

Services that don't want to receive XML don't have to.  The request payload 
is arbitary!  However, we WILL need some mechanism to identify the payload 
type and to verify that the webservice being requested can accept data 
encoding of that type.

> Authentication will prevent anyone from running executable code on another
> machine. 

Any code deployed into the VRS will run on *any* LDS.
However, LDS's do not have to release their services to the VRS propper.  
They may announce that they are available, but keep them private.  Anyone 
requesting these services will see them being run on the owners LDS.
This is important for several reasons:
1. The service requires a huge dataset/DB which is only available on the
   owners LDS.
2. The service really does contain sensitive information and the owner really
   would rather it be held locally (though this goes against the whole VRS
   philosophy.
3. The web service(s) form a 'dynamic' web-site with context etc.  This is not
   suitable for distribution.  (Actually with carefull design, most of the web
   site may be deployed over the VRS, and the sensitive/resource heavy/dynamic
   components run on the owners LDS.  REMEMBER that a web service may call
   another web service, so distributed services may call-back to the owners
   LDS for stuff which can't be distributed).

> 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.

Authentication IS necessary.  However, I'm still not sure whether webservices 
would be the most appropriate way of adminstering the LDS as the 
administrator would have access to the LDS directly.  Web services make 
resources publically available. Why would you want to make all administration 
services publicly available?

The functions JoinVRS and LeaveVRS are 'services' which may be viewed as 
being public web-services exported by a LDS.  However if these were web 
service calls, then they'd invoke internal functions within the LDS 
implementation (the Cluster Manager) to do the hookup.

> 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.

Now I think you've hit upon something I raised with Bill a while back - but 
not very eligently I admit.  I think that *some* VRS's will NOT accept 
unsolicited join requests.  That is, if the VRS doesn't know who you (the 
LDS) are in advance, you can't join.

> Maybe it's not one of the goals of the VRS to be totally secure. In that
> case, why is that so?

A VRS may be deemed secure if only ratified LDS's are allowed to form the 
cluster.

As far as the security of a particular LDS goes.... does someone have root 
access on this LDS?  Of course someone does, so most LDS's will not be 
trusted - unless you trust the owner of the root password etc.

Oh complicated!

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