We discuss here new distributed computing technologies of relevance for building multi-user scalable televirtual (TVR) environments on the Internet such as: Java Shared Data API (JSDA) by JavaSoft, Common Object Request Broker Architecture (CORBA) by Object Management Group (OMG) or High Level Architecture (HLA) by Defence Modeling and Simulation Office (DMSO). We describe our early TVR prototype based on VRML2 front-end and JSDA back-end, and we summarize our ongoing work on exploring CORBA Events and HLA Dynamic Data Distribution technologies for building scalable collaboration servers for the Internet.
Java scripting support in VRML2-VRML97 set the stage for experimenting with multi-user distributed virtual environment on the Internet, hereafter referred to as televirtual, or TeleVR, or shortly TVR environments. A typical minimal configuration of such a system would include a few VRML2 browsers, downloading a common VRML world, opening Java node based connections to a collaboratory server which maps users mouse motions on the suitable movements of the corresponding avatars.
We developed a simple prototype TVR environment of this type at Syracuse
University within a joint project with IBM Watson using JSDA framework
for building Java collaboratory services.
Several other prototype TVR environments of similar type were developed
recently by various groups[Sony,Paragraph(Mitra),BlackSun, MERL etc.] and
a set of VRML SIGs was formed such as Universal Avatars, Humanoid Animation
or Living Words, focused on standardizing various aspects and software
layers of VRML based networked VR.
The detailed architecture of collaboratory servers is not being directly addressed by the VRML community. For example, Living Worlds encapsulates various multi-user technologies in terms of a "MuTech" node and focuses on its interactions with local/client side VRML nodes in the scene graph. There are some associated ongoing standard efforts in the MuTech domain such as Open Community led by Mitsubishi Electric Research Labs(MERL) but neither the full specification nor reference or even sample public implementations are available at the time of this writing.
In the VRML community framework, we can express our work and the content of this paper as research into promising MuTech technologies that are based on stable open standard and are capable to enable or facilitate the design or development of truly scalable TVR environments.
Below, we discuss the ongoing R&D activities at NPAC aimed at exploring the following collaboratory server technologies of relevance to TVR;
A simple implementation of this scenario would be a Server which waits
for connections from clients, and spawns threads (Dispatcher) to handle
any information received from the client regarding updates to position
and orientation. Besides this, the Server also could assign some sort of
identification to each of the clients and also the representation of avatars.
The clients would in turn spawn threads(Receivers) to handle the information
received from the thread on the Server side and call the appropriate method
in the Client side say updatePositions(..) to update their respective representations’
positions.Thus any change in the positions of one of the avatars is reflected
in all the other VRML scenes.
The current existing prototype works over both Script Node and EAI(External Authoring Interface) ways of Java-VRML interaction.
A brief note on the working of the Script Node is being provided here.
The essence of Scripting is to add dynamic behaviors to the VRML worlds.
The syntax of a Script Node is
Script {
url "Java filename.class "
EVENTIN eventType eventName
EVENTOUT eventType eventName
}
The url field provides the link between the node and the Java program
that will implement the required behavior to be inserted into the VRML
scene. VRML’97 specifications allow for the trapping of events in the scene
using various sensors like the TouchSensor, Position Sensor, Plane Sensor.
The event on being trapped will be routed as the EVENTIN or the input event
to the Script Node by making use of a ROUTE statement.
Any events arriving at an EVENTIN field automatically cause the browser
to pass the event to the program referred to in the url field of
the Script Node. The Java program performs some computation which will
add dynamics to the scene and then sends an EVENTOUT or an output event
which will then be routed to the required nodes in the scene graph again
through a ROUTE statement.
EAI version of the prototype was tested on SGI’s CosmoPlayer(1.0.2) version running as a plugin to Netscape 3.0 Web Browser on PC platform.Script Node version of the prototype was tested on Sony’s Community Place running as a plugin to Netscape 3.0 web browser and also SGI’s CosmoPlayer(1.0beta3a) running as a plugin to Netscape 3.0 web browser.
The front-end is designed to be a set of rooms to illustrate the correlation and corresponding visualization of Channel-Channel interaction in the current base networking engine-JSDA
Current works on the front-end include – development of realistic Human
avatars with custom behaviors fully confirming to the specifications of
the Humanoid Working Group Proposal including MPEG-4 compliant facial animation,
provision of audio-conferencing capability using open web-based API’s like
Microsoft NetMeeting.
JSDA allows to share objects using object serialization mechanisms since
it has a RMI(Remote Method Invocation) based implementation. JSDA also
has objects which encapsulate management policies for other given objects.
A classic example to this point is the Session Manager authenticating clients
to determine if they could join a session.
Currently JSDA is a research-oriented API at JavaSoft Corporation
and the TVR prototype is being packaged, as an effective demonstration
of JSDA’s capabilities, along with the main distribution.
The process is begun by implementing the VRServer program which establishes
the Multi-user VRSession and the Channel VRChannel which would be used
to route position updates to all the participating clients.
try {
/* Create a session, and publish it. */
VRSession = new SharedData.socket.socketSession(sessionName);
Naming.rebind(url, VRSession);
/* Get a client-side handle to the session and create a channel called
*"VRChannel". The clients would be using the VRChannel handles to
* pass information to various clients.. */
VRSession = SessionFactory.createSession(url);
VRSession.createChannel("VRChannel", true);
System.out.println("Setup and bound VR server.");
} catch (SharedDataException e) {
System.out.println("VRServer: main: shared data exception: " + e);
}
}
The Client – which is the Java Script Node for the World Scene in question
would get handles to the VRSession and the VRChannel besides getting references
to the translation and rotation fields of the avatar. This would be done
in the initialize() method.
for (int i=0; i < AVATARS; i++){
try {
avatar = (Node)((SFNode)getField("avatar" + i)).getValue();
avatarPosition[i] = (SFVec3f)avatar.getExposedField("translation");
avatarRotation[i] = (SFRotation)avatar.getExposedField("rotation");
} catch (Exception e) {
b.setDescription("can not get avatar");
return;
}
}
The VRConsumer receives any data that is sent on the VRChannel, this
data is received in the dataReceived(Data data) method and calls the performUpdate
method in the VRUser.
public synchronized void
dataReceived(Data data) {
String message;
int position = 0;
int priority = data.getPriority();
String senderName = data.getSenderName();
Channel channel = data.getChannel();
byte[] theData = data.getData();
message = new String(theData, 0);
vrUser.commandLine = message;
vrUser.performUpdate();
}
Besides this it would also get handles to the VRSession and the VRChannel
and set a Consumer the VRConsumer on that channel. The connect method would
be
String sessionType = "socket";
try {
String sessionName = "VRSession";
/* Create a VR client. */
client = new VRClient(name);
/* Resolve the VR session. */
try {
String url = "coll://" + hostname + ":" + hostport +
"/" + sessionType + "/Session/" + sessionName;
session = SessionFactory.createSession(url);
/* Join the session,channel set the channels data consumer. */
session.join(client);
channel = Channel.join(session, "VRChannel", client);
VRConsumer = new VRConsumer(client.getName(), this);
channel.setConsumer(client, VRConsumer);
} catch (Exception e) {
return(false);
}
} catch (Throwable th) {
return(true);
}
It is the VRConsumer which is responsible for calling the updatePositions
method in the VRUser Java client. The important point lies in updating
the references to the translation and rotation fields of all the avatars
in the World scene based on information sent on the VRChannel by the various
Clients.
public void updatePosition(int id, float x, float y, float z){
System.out.println("Avatar" + id +"on the move ....");
avatarPosition[id].setValue(x, y, z);
}
public void updateOrientation(int id, float x, float y, float z, float r){
avatarRotation[id].setValue(x, y, z, r);
}
public void performUpdate() {
StringTokenizer tok;
if(MuProtocol.MOVE == command){
updatePosition(idOfMove, x, y, z); // update position
}else{
r = Float.valueOf(tok.nextToken()).floatValue();
updateOrientation(id, x, y, z, r); // update orientation
}
}
}
The figure illustrates an avatar moving from room1 to room2. It detaches from room1 visual/sensory channel and attaches to room 2 visual/sensory channel and retains the radio
channel to listen news/ads/broadcast from room 1. JSDA Sessions are
mapped on "rooms" and JSDA Channels are assigned to individual avatars,
present in a given room. Only limited number of avatars per room is allowed,
and there is also a limit on number of Sessions per collaboratory server.
The simple model assures world-wide scalability, assuming that new rooms
join with their own session servers.
JSDA is a useful framework for prototyping simple collaboratory applications but it does not offer either a wire protocol or a high-level API for client-server communication - messages are typically passed as strings, custom encoded/decoded by JSDA clients/servers. The family of T12x protocols (which in fact influenced the JSDA design and was adopted by Microsoft's NetMeeting) could be a natural candidate for a TVR protocol. Another possibility is that such a protocol would be developed as in the course of current interactions between MPEG-4 and VRML Streaming groups. However, another tempting alternative is to select one universal wire protocol for the Internet that would be capable to support all required communication patterns in all relevant application domains.
At the moment, the most promising candidate for such 'lingua franca' on the Web is Internet Inter-ORB Operability Protocol (IIOP) by OMG that enables interoperation between ORBs from various vendors and is also frequently used as internal inter-ORB protocol between clients and servers within a single vendor CORBA environment. In the 100% pure Java sector, similar support is offered by RMI (in fact supported as one of the JSDA implementation modes), whereas CORBA offers both multi-platform and multi-language support in terms of the universal IDL interfaces/mappings and language-specific bindings. With the onset of ORBlets, dynamically downloadable or resident in Web browsers such as supported by Netscape/Visigenic, CORBA gets now in fact even more tightly integrated with Java towards a new powerful computing paradigm often referred to as Object Web.
Also it imperative that to operate in today’s heterogeneous computing environments, distributed applications must work on a plethora of hardware & software platforms. Suitability to business class applications calls for capabilities beyond conventional web based computing - scaleability, high availability, performance and data integrity. This is where Java & CORBA play a role which mutually complements each other, Java provides for easier distribution of CORBA-based applications with CORBA providing the where-with-all of a distributed infrastructure.
The ground work for this work was laid at the IBM T.J. Watson Research Facility and is being pursued further through a joint-project with the North-East Parallel Architectures Center, Syracuse University.
A prototype version of this API using CORBA objects as "shared data" and CORBA servers as "collaboratory servers" and Netscape/Visigenic based ORBlet front-ends has been developed at IBM We are currently extending this design and preparing for a refined implementation using CORBA Event Service that plays a similar event filtering role as the JSDA Channels.
The IIOP based collaborative API makes use of the CORBA Event Service which facilitates decoupled communication between objects via the abstraction of an Event Channel. Before we proceed further, a brief explaination of the abstractions used in the system has been provided.
The supplier sends a notification that an event has occured by invoking
a method on the target (i.e the Event Channel), which in turn invokes a
method on the consumer. The notification method doesn't use any new language
construct or programming syntax. Further every event has been made to have
a specific notification method associated with it, say a broadcast event
is different from a whisper. When an event occurs the Event Channel invokes
the corresponding method on all the consumers evincing an interest in consuming
that event. The event store is transactional in the sense that update/roll-backs
are contingent to the commit/abort of the event by all participating clients.
This is what adds the notion of What-You-See-Is-what-I-see in the system.
The factors of paramount importance in Collaborative Systems are Scalability and Fault-tolerance
Replication and LoadBalancing : Specifically this addresses the issue of replication of Servers accross different participating hosts in a
Collaborative environment, when the load (participating sessions) on a server crosses a certain threshold.
Solution : The API supports the notion of groups within a certain session, and since the Object-Implementations handling the groups can be
hosted on different machines, the problem of Scalability is addressed to a considerable extent.
Fault-tolerance : This concerns the problem of migrating sessions to a different participating host should the machine hosting the server crash - this with minimal or little disruption.
Solution :
(a)The ObjectServices agent which is a distributed directory service allows for migration of sessions to a different participating host in the case that a session terminates unexpectedly on one of the hosts
(b) The Events are persistently stored by the Event Channel to ensure that events are not lost on system failures.
These are the two most significant IDL definitions in the Collaborative System. The IDL definitions signify the operations a Client could invoke on a remote instance of these objects. Nevertheless, an invocation of any of these aforementioned operations should be preceeded by a successful reception of a remote handle to these objects. Acquisition of a handle to the PartyCoordinator, requires the client to invoke a bind to that Object. To digress on the semantics of the bind , it should be clear that in a HighAvailability scenario there would be multiple instances of the PartyScheduler with a static Hashtable containing the list of updated Parties i.e. Coordinator Objects.
interface Coordinator {
boolean setMaxClients(in long arg0);
long getMaxClients();
long numberOfMembers();
typedef sequence string sequence_of_string;
MultiCoordinator::Coordinator::sequence_of_string getClientNames();
boolean isEmpty();
long register(in long arg0, in string arg1, in Client::ClientControl arg2);
boolean deregister(in long arg0);
boolean broadcast(in string arg0);
boolean whisper(in string arg0, in long arg1);
};
interface PartyScheduler {
boolean createParty(in string arg0);
long getPartyID(in string arg0);
MultiCoordinator::Coordinator getPartyHandle(in long arg0);
};
The Client initiates a bind to the PartyScheduler Object. Given that this is successful, in the event that there is a Distributed Directory service and the Active Object server is in place, the Client is now ready to invoke the IDL-defined operations.
| [1] | It starts with the createParty(String partyName) function which would return a true in the event that a new Coordinator Object has been instantiated or a false to signify the prior existence of the desired party. It is the Scheduler's job to signal the appropriate notification to the Clients and perform appropriate house-keeping to reflect new instances of Coordinator's. All Coordinator objects scheduled by the PartyScheduler are identified by an ID. |
| [2] | The Client now has the option to decide wether he wishes to join an existing Party or initiate the existence of a new one. In the latter case Step[1] is repeated as mentioned earlier. Once the process is over, the Client gets a handle to the Coordinator Object by invoking long getPartyID(in string arg0); MultiCoordinator::Coordinator getPartyHandle(in long arg0); in succession. This is in keeping with the policy of the PartyScheduler to identify Coordinator's on the basis of the ID that it assigns during their instantiation. |
| [3] | Once Steps I and II are over and done with, the Client is in a Distributed Collaboration mode, and can invoke operations specified in IDL definitions for the Coordinator. These include boolean broadcast(in string arg0),boolean whisper(in string arg0, in long arg1); among other functionalities offered by the PartyCoordinator Object. |
This is just another demonstration of the complementary roles Java & CORBA play in a distributed environments. Java provides for easier distribution of CORBA-based applications with CORBA providing the where-with-all of a distributed infrastructure. In summary, CORBA offers both a potential candidate for universal wire protocol, IIOP, and a natural collaboratory framework based on shared CORBA objects and flexible message filtering mechanisms offered by the Event Service.
import java.rmi.*;
public interface PartyScheduler extends Remote {
boolean createParty(String PartyName) throws java.rmi.RemoteException;;
int getPartyID(String PartyName) throws java.rmi.RemoteException;;
MultiCoordinator.Coordinator getPartyHandle(int partyID) throws java.rmi.RemoteException;;
}
package MultiCoordinator;
import java.rmi.*;
public interface Coordinator extends Remote {
boolean setMaxClients(int _maxClients) throws java.rmi.RemoteException;
int getMaxClients()throws java.rmi.RemoteException;
int numberOfMembers() throws java.rmi.RemoteException;
String[] getClientNames() throws java.rmi.RemoteException;
boolean isEmpty() throws java.rmi.RemoteException;
int register( int clientHashCode, String ClientName,
String clientObjRef)
throws java.rmi.RemoteException;
boolean deregister(int clientID) throws java.rmi.RemoteException ;
boolean broadcast(String Message) throws java.rmi.RemoteException;
boolean whisper(String Message, int clientID)
throws java.rmi.RemoteException;
}
In summary, CORBA offers both a potential candidate for universal wire
protocol, IIOP, and a natural collaboratory framework based on shared CORBA
objects and flexible message filtering mechanisms offered by the Event
Service.
CORBA software bus seems to offer a convenient framework for scalable multi-user collaboratory environments, with the individual participants bringing their own resources (personal world servers) and plugging them into the bus.
However, scalability in such systems can be sustained only if some suitably defined communication locality is enforced. CORBA events discussed above offer one example of such a technique. Other examples of event filtering techniques include Zones in Living Words ot Domains in Open Community models.
The most elaborate support for communication channel based filtering is to be provided soon by the HLA technology and the associated Run-Time Infrastructure (RTI) software bus model under development and standardization by DMSO. Unlike VRML regions analized so far by VRML SIGs, the associated RTI service called Dynamic Data Distributions supports generic n-dimensional routing spaces suitable mapped on the simulation attributes (spacial, behavioral, parametric etc.) in the individual simulator nodes.
HLA builds on top of and extends DIS standards towards a truly interoperable simulation framework, including real-time and logical time simulations.
DIS is a standard[2] set of messages and rules, called Protocol Data Units (PDUs), used for sending and receiving information across a computer network. The most common message is the Entity State PDU(ESPDU) which represents all of the state information about a simulated entity that another simulator needs to know. DIS is strictly a peer-to-peer architecture, in which all data is transmitted to all simulators where it can be rejected or accepted depending on the receiver's needs. Because of the time lag(latency) problem, DIS is based on the peer-to-peer architecture.
The DIS allowed a certain number of people participate simultaneously in a distributed simulation. It used the planetary coordinate system, which permitted nearly everyone to play together simultaneously, and UDP-IP communication, which reduced the cost of participating the distributed simulation.
Using DIS protocol for a simulation of 100,000 entities, each node in a network will require 375 Mbps network connection.This results in a significant broadcasting bottleneck. The DoD then started to establish a common technical framework to facilitate both the interoperability between the wide spectrum of modeling and simulation applications and the reuse of the modeling and simulation components. As a result of this initiative, DIS community voted for the High Level Architecture(HLA) for the next generation of modeling and simulation software.
The High Level Architecture provides an architecture for modeling and simulation. The intent is to foster the interoperation of simulations(federation) and the re-use of simulation components. The HLA is composed of three concepts[7]:
A federation and its associated Federation Object Model(FOM)[4] should be defined and it defines
The RTI provides a set of common services[4] that are useful across multiple simulation domains. These services are
A federate tells the RTI to deliver only the data which fall within the extents of the region which it subscribe. By specifying an update region and associating it with a particular object, a federate promises that the attributes of the object instance or interaction will stay within the extents of the region. As the state of an object exhanges, the federate may need to change the associated region. The regions in a routing space are used by the DDM part of the RTI to determine the distribution of data. The RTI ensures that the attribute updates and interactions associated with an update region are routed to federates with subscription regions that overlap the sender's update region.
A lifecycle of a federation can be summarized as follows. A federation creates a federation execution and joins it. When it needs to create an object, it asks RTI to provide it an ID and then it instantiates the object with the given ID. Federate broadcast object state information through updating its attributes. For example, if the federate simulates a tank, the current position of the tank is the state of the object and it can be done through updating object attributes. If tank fires, then the federate sends an interaction. A federate will be destroyed through delete object message. Federation leaves the exercises by resigning and terminates by destroying the corresponding execution.
|
|
|
| FOM describes the objects and interactions | Standard PDU definitions[2] |
| Federate sends only changed attributes | DIS sends all of the object attributes(ESPDU) when any attribute changes |
| Federation gets object ID from RTI before instantiating the object | Specification[2] assigns the site number and the host number and they define the ID |
| RTI takes care of all communication needs | Simulation has to take care of communication requirements |
| DDM defines the data sharing | point-to-point communication |
| Dead-reckoning can be applied any object attribute | Dead-reckoning is applied only orientation and position of the object |
The DIS standards specify a fixed set of units for state variable,
a common coordinate system and a fixed resolution for representing each
variable. But some applications does not need to process and transmit that
much of entity state information. For example, an instrument might have
its own range coordinate system and set of units(resolution) then it needs
a coordinate conversion everytime it receives the ESPDU. Similarly, at
long distances, most simulations do not need the same degree of certainty
of state(uncertainty tolerances or data resolution) as they would for a
closer object since their sensor models are likely to discard much of the
information about far objects. Transmitting and processing of these information
put extra burden on communication bandwith and processing capacity.
The HLA concept of a Protocol Catalog contains an alternative data
representation formats for the attribute values associated with various
Object Interaction Protocols(OIP)[8], which specify what information must
be transferred among simulation under various conditions. A federation
of simulations selects which OIP is required for the purpose of the federation
and the corresponding data representations in the FOM so that simulation
developers can focus on the simulation problem instead of the communication
protocols.
The DIS standards require that all entity state information be transmitted
to all potential receivers whenever any of the state information changes
or whenever an agreed-upon timeout interval has elapsed. It has been proven
that grid-based update filtering and the use of an efficient consistency
protocol or heartbeat transmissions can significantly reduces the
traffic on the network. With the HLA framework, the transmission of only
attributes that have actually changed together with efficient subscription
and filtering mechanism(DDM) obviously will reduce the required transmission
on the network.
The DIS paradigm tried to use the dead reckoning to reduce the
required number of ESPDU on the network. But, these algorithms are only
extrapolates the orientation and position of the object. That kind of extrapolation
can be applied on any object state variables in the HLA framework.
Since FOM assumes the underlying RTI services, it can use a variety
of transport services and it can be re-used all HLA complaint platforms
independent from the RTI implementation details.
HLA facilitates the division of simulation responsibilities between
machines by manipulating attributes instead of entire objects.
At NPAC, we are currently exploring the HLA/RTI technologies within the DoD Modernization Program, aimed at integrating High Performance Computing into the DoD systems and products. We note several analogies between Object Web technologies and HLA/RTI and we develop an R&D plan and prototyping schedule for a high performance Web based HLA environment that would integrate HPCC and Java/CORBA technology support for advanced modeling and simulation systems.
More specifically, we are currently building a java based Web Object
Request Broker (WORB) that will offer integrated support for HTTPand IIOP
protocols and will be used for prototyping a WORB based RTI. This way,
we will be able to inherit our previous and current experience with Java/JSDA
and CORBA based TVR prototypes, and to explore additionally the advanced
DDM based multi-dimensional event filtering techniques and alogorithms
of RTI.
We are also monitoring the Java/VRML based DIS infrastructure development
activities by Don Brutzman group at NPS and we intend to plug and play
some of Web based NPS simulators in our WORB based WebHLA framework. We
expect early WebHLA demos to be available early next year and presented
during the VRML98 conference.
We discussed here a set of new promising distributed computing
frameworks (JSDA, CORBA, RTI) which offer open standards based support
for building scalable multi-user virtual environments on the Internet.
The essential feature of such environment - communication locality - is
enabled via event filtering in terms of JSDA channels, CORBA Event service
and RTI routing spaces.
So far, we acquired few early prototyping experience using JSDA and CORBA technologies and we are exploring the HLA/RTI environment. By the time of this conference, we expect to present all these protypes and their comperative analysis when employed for building scalable TVR environments.