vrs-development
[Top][All Lists]
Advanced

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

[Vrs-development] Design Tasks Proposal


From: Chris Smith
Subject: [Vrs-development] Design Tasks Proposal
Date: Tue, 26 Mar 2002 13:35:05 +0000

We're starting to go around in circles, as I don't think some
objectives are clearly understood, or some of the problems.

Bill: How about we start two design discussions :-
(These do cover the main issues that I see as needing to be
 addressed.  I'm NOT trying to suggest answers to the
 questions here by asking leading questions... :o) )


1) Distribution of Data/Services over the VRS
   This topic to specifically cover:
   a. The mechanism by which LDS's deploy data/services
      into the VRS.
   b. What happens to a LDS and the VRS when it (the LDS) 
      detaches from the VRS.
   c. Encryption and security of data/services held by
      an LDS.
   d. Recovery of data held by the VRS.


2) Clustering of LDS's into a VRS
   This topic to specifically cover:
   a. Organisation.
      a.1. VRS's as an unbounded set of LDS's or a 
           finite set of LDS's.  The management problems
           associated with these.
      a.2. Can VRS's interlink?
      a.3. Advantages/Disadvantages of clusters of 
           'VRSlets'.
   b. The scope of data/services within a VRS.  Is data
       shared across VRS boundaries (may be covered by
       a.2/a.3)
   c. Publically accessable LDS's.  Allowing arbitary
      clients to access services within the VRS.
      ( spans topic 3 ).
      c.1. VRS's having multiple public LDS's.
     

3) Discovery
   This topic to specifically cover:
   a. Identification of standard web service discovery
      specifications.
   b. Discovery server availability.
      b.1. Provided by the VRS itself?
      b.2. Provided by dedicated server, or clustered
           servers?
      b.3. Provided by a loosely coupled server cluster
           like the DNS model?
   c. Feedback from the VRS to the Discovery Servers.
      [May be important to quickly reflect the loss of
       an LDS to prevent clients accessing this LDS
       over the other LDS's which *are* still available].
   d. Interoperation with other webservice products
      (.net et al).      

Chris

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