PROJECT PAPERS

• Introduction
• Background & Philosophy
• Technology
  3.1. AliceBot
  3.2. NeuroGrid
  3.3. JXTA
  3.4. JPos
  3.5. JBoss
  3.6. James
  3.7. Multimedia
  3.8. VRSpace
  3.9. Design Guidelines
  3.10. Implementation Technology
  3.10.1. VRSpace Plugin Schema
  3.10.2. VRObject Class Diagram
  3.10.3. VRSpace Server Class Diagram
  3.10.4. VRSpace Server Distribution
  3.10.5. Client's Scene Distribution
  3.10.6. Request Processin
• Possible applications
• Conclusion
  
  
  
  

DOWNLOAD

• VRSpace Presentation papers.doc (714 kb)
  
  

 

• main
  Presentation page

......

3.10. Implementation Technology

3.10.1. VRSpace Plugin Schema

Picture proposes "Duncan" - the ultimate VR Application Server.

VRSpace Server takes care of user authentication, maintenance of the scene, distribution of events to users, permanent storage, and in short, everything except presentation.

Client is responsible for data presentation and interaction with user. This is accomplished by connecting to the VR Application Server and reacting to the messages received by server.

Various plugins (JBoss, ALICE, NeuroGrid...) extend appropriate subclass of VRObject and thus add new features to VR Application Server. Architecture is designed in a way that adding new plugins is simple as much as possible.

3.10.2. VRObject Class Diagram

VRObject - Generic VRObject class. It extends Observable interface and notifies observers of any state changes. All changes are encapsulated inside Request object. Objects of subclasses of this class can't store state changes to DB and can't change its fields values, just exist in memory while Server is up and store those changes at Checkpoint time or when admin shutdown the Server.

DBObject - This class defines methods for database storage. Objects of subclasses of this class can be stored in underlying DB and set their fields' values. When processing a Request, objects first store changes in DB and then distribute Request.

There are 4 main types of VRObject and DBObject:

Clients are observers, and monitor VRObjects state changes.

Ownership is implemented by implementing Owner and Owned interface. Objects can be the owner and the owned at the same time, but ownership is not delegated: if object O1 is owner of object O2, and object O2 is owner of object O3, object O1 is not owner of object O3.

Classes that implement Owner interface:
- Client
- Robot

Classes that implement Owned interface:
- OwnedDBObject
- OwnedVRObject
- ObserverSensor
- Proximitysensor
- Robot

3.10.3. VRSpace Server Class Diagram

The Main server class, Server, looks up the configuration, connects to the database, and starts listening to a network socket. It should also start some daemons (services).

When something connects, it starts new Session. Session sends "login;" and reads response, than sends "password;" and reads the response.

Then, it asks the Dispatcher for Client with this login and user name. If Dispatcher returns the client, session starts. Now, this Dispatcher thing is big deal. It is responsible for client login and logout, data retrieval from the database, and dispatching of events - all the main server functionality. Dispatcher.login () looks for AuthInfo object having the appropriate login and password. If it does not exist, and vrspace.user.autocreate property is true, it will create new AuthInfo, and a new client object of class specified by vrspace.user.class property.

Authentication fails if:
- vrspace.user.autocreate is false and no AuthInfo has specified login
- AuthInfo with login exists but password is wrong
- client is already logged in and daemon parameter to login method is false

Daemon logins and sessions are intended for file transfer and other session types which are not interested in state of the world. When authentication passes, Dispatcher constructs new Scene for the client (if daemon is true, Scene is not constructed). Scene looks up the database, adding interesting object to the client's view (by calling Client.addObject(VRObject)) and removing object of no interest from the Client's view. This implementation uses client's current coordinates within the space to determine which objects are of interest.

Persistence implementation - database description:

The task of persistence layer is to store all VRSpace objects (objects of VRObject class and all subclasses of it) into database. This is accomplished through abstract DB class which serves as database interface. Storing and retrieving objects is simple through DB.put(Object) and DB.get(ObjectID) methods (actually DB has several put/get methods for various updates/queries). Database implementation is based on already known object-relational mapping (http://www.object-relational.com/), but the main difference from existing solutions is that there's no need to write any code (scripts, templates…) for new type of objects. When database determines object of new type, it processes class of that object in run-time, and creates all necessary updates. What is also accomplished is easiness of writing new DB adapters: all that a developer has to do is to subclass SQLDB class and write some constants and simple SQL queries.

Filters description:

3.10.4. VRSpace Server Distribution

- every Server contains some space (objects, information...)
- Server can have a part of the space that is already contained in some other Server
- space between servers doesn't have to be continuous e.g. there can be areas that don't exist on any server
- while moving through the space Client will change Server if he moves from area of space contained in one Server to area of space contained in another Server (this is transparent for a Client)
- Client can also enter in Gate object which serves as "teleport", so he can "teleport" himself into some other Gate which can be on the same or some other Server
- every Client can also be a Server - in that case Server creates its own space by creating cache of objects that Client sees by moving through the space
- that way we can say that in p2p environment the difference between Client and Server cannot be clearly distinguished - it's just a point of view.

3.10.5. Client's Scene Distribution

- every "real" user is represented by Client object (or any object whose class is subclass of Client class) in VRSpace
- every Client has his Scene e.g. part of space that he can see. Size of Scene depends on Client and Server properties
- Client as observer observes all objects inside his Scene
- if some object enters/exits from some Client's Scene (because Client is moving), Dispatcher takes care to add/remove that Client as observer for that object
- because Scenes for different Clients can be of different size, there are possible situations that the first Client can see objects from the second Client's Scene, but not the second Client himself or that the first Client can see the second Client, but the second Client can't see the first

3.10.6. Request Processing

Session accepts a request from a user (1), creates the Request object and calls client.request() method (2). Client asks the Scene for VRObject that is embedded in Request (3) and propagate Request to Dispatcher (4). If VRObject is null it means that it's not in client's Scene, so Dispatcher gets it from DB (5), and calls VRObject.sendEvent() method (6). VRObject.sendEvent () method tries to set its value according to Request and to notify registered Observers that it has changed (7). Those Observers are other Clients that propagate changes to their Sessions (8), and Sessions to users (9).