Daniel Dias, Geoffrey Fox, Wojtek Furmanski², Vishal Mehra¹ , Balaji Natarajan², H.Timucin Ozdemir²,

Shrideep Pallickara², Zeynep Ozdemir²

Submitted to the Workshop on OO and VRML in the VRML98 Conference to be held at Monterey, California on Feb 16-19,1998.

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. Recently, Open Community led by Mitsubishi Electric Research Labs (MERL) released the open standard proposal.

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.

We are exploring the following collaboratory server technologies of relevance to TVR with ongoing R&D activities at NPAC ;

1. JSDA from JavaSoft
2. CORBA objects and Event Services
3. HLA/RTI by DMSO

Here we focus on the CORBA domain and discuss relations between VRML and emergent distributed object technologies.

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.

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

We are trying to improve the front-end by development of realistic Human avatars with custom behaviors fully confirming to the specifications of the Humanoid Working Group Proposal and provision of audio-conferencing capability using open web-based API’s like Microsoft NetMeeting.

Java Shared Data Architecture (JSDA) provides a Shared Framework for Java at the data level. Data objects are shared over specific instances of Channels – communication paths – between two or more Clients – objects which are the source or destination of data – in a collaboration environment. Any Client object, which needs to register its interest in receiving messages sent over a channel, must implement the Channel Consumer. On similar lines if a client is interested in being notified about changes in state of some other object it should implement the Channel Observer interface. It should be noted that a Client which references a channel should operate on that channel, instinctively it’s clear that a Client could operate on multiple channels by referencing multiple channel at the same time. To register interest in a certain channel, a client first needs to join the session which the channel is a part of and then the channel. However, a client is not allowed to have more than one consumer on a channel, though replication of this behavior could be done in a roundabout way.

JSDA allows to share objects using object serialization mechanisms since it has the Remote Method Invocation (RMI) 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 following figure illustrates a more complex TVR World(currently under development at NPAC) including N avatars in M rooms where both N and M can be large(Internet Clubs, Malls etc). Rooms are mapped to sessions(1,2, etc…) running on individual servers. Each room/session publishes local sensory channel used to exchange coordinate/visual information between avatars in this room. Same rooms can also publish long range channels (e.g. audio) which are accessible from other rooms.

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 is 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 - scalability, 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.

• Java with its mobile code facility handles inter-object communications within its native environment.
• Only the Java Programming language has an inverse mapping to IDL, this allows the programmer to stay in the Java world during the developmental stage of distributed applications.

• Convergence of Object models
• Support for the notion of abstract interfaces distinct from implementations or classes.
• Interface inheritance mechanisms are mostly identical.

Because of their low-complexity and footprint, Java CORBA implementations can run on thin networks computers and low-end consumer devices.
• In the world of Web-based Distributed applications Java's multi-threading support builds the right scaffoldings for the Clients to have richer presentations and the Object-Implementation Servers to support more clients.
• Java-CORBA greatly simplifies software upgrades of Clients in large distributed systems, this is more so in Java because of the mobile byte codes and in CORBA due to the Dynamic Invocation Interface.
• The combination of Java's language features viz. platform-independence, strong security model etc and CORBA's well conceived approaches to static and dynamic, synchronous and asynchronous interfaces, and the rich and comprehensive set of CORBA Facilities and Services truly provide the right building blocks for a distributed computing paradigm.

These factors should allow the CORBA/IIOP-Java combination to assume a central role in shaping the Internet during the next phase of its evolution, besides having a profound impact on several areas of Web-Computing including multi-user collaboratory environments. Here we try to summarize the CORBA Event Service and the similarities between JSDA Channel and Event Channel is obvious.

8. CORBA Event Service

The Event Service (ES) allows decoupled communication between objects: instead of a client directly invoking operation on a target object, it can send an event that can be received by any number of objects. The sender of an event

is called supplier, and the receivers are called consumers. Suppliers and consumers are decoupled they do not know each other’s identities.

The Event Service introduces the notion of Event Channel. Suppliers send events to an Event Channel, and consumers receive these events. Each channel can have multiple consumers and suppliers, and all events sent by a supplier are made available to all consumers of that channel.

The ES supports four different modes of consumer-supplier interactions. The consumer could be push/pull-Consumer, and the supplier could be a pull/push Supplier. One of the advantage of using the EventChannel is that, the events can be buffered to accommodate consumers of differing speeds. The suppliers and the consumers both register with the EventChannel since otherwise its not possible to determine the source of the event in case of the supplier and also since its not possible to invoke the appropriate notification method on the consumer.

Supplier objects ask a proper ProxyConsumer object from the Event Channel’s ConsumerAdmin object. Whenever the supplier wants to send an object to the Event Channel, it uses its corresponding ProxyConsumer object. Similarly, consumer objects ask a proper ProxySupplier object from the Event Channel’s SupplierAdmin object. Whenever a channel receives an event, it informs all the ProxySupplier objects. Then, each proxy object notifies its consumer.

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 Northeast Parallel Architectures Center(NPAC), Syracuse University.

We developed an API for collaboration. The IDL definition of this API is given in the following section. 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 a refined implementation using CORBA Event Service that plays a similar event filtering role as the JSDA Channels.

Two important IDL definitions being used in the system along with the Event Service are given below.

IDL definition for the PartyHandler:

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);

};

IDL definition for the PartyCoordinator:

interface PartyCoordinator {

boolean createParty(in string arg0);

long getPartyID(in string arg0);

::MultiCoordinator::Coordinator getPartyHandle(in long arg0);

};

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.

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 :

(a) 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.

(b) Since one Event Channel can be a consumer/supplier of another Event Channel, it is possible to split the Event Channel if it exceeds the certain capacity and connect two Event Channels to each other as supplier and consumer.

Fault-tolerance : This concerns the problem of migrating sessions to a different participating host with minimal or little disruption whenever the machine hosting the server crashes.

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 can be stored persistently by the Event Channel to ensure that events are not lost on system failures.

We implemented the Event Service for omniORB2, which is a free C++ Object Request Broker by Olivetti Research Labs, in development phase and does not have Event Service. We wrote the standard Event Service with C++ and omniThread thread library. We tested this software with Chat program within the Netscape 3.0/OrbixWeb combination. With the same spirit, we started to use Event Service for Distributed Interactive Simulation (DIS) PDU broadcasting.

There are some differences with Event Service and what we want with the multi-user environment. Event Service does not care about the originator of the event. But for multi user environment we need to know who sent the message. DIS PDU format includes this information in its own body. The Event Service is central server based approach compared the peer-to-peer architectures. We can solve this problem by providing an Event Channel for each active object in the virtual environment.

One another intriguing option for message transfer is to use multicasting. This requires some changes in the Event Service implementation. For Push Consumer, instead of giving a separate Push Supplier for each consumer, it is possible to give one Push Supplier for each multicast group so that multicast Push Supplier can serve multiple consumers. This change also reduces the computation requirement on the Event Channel server.

HLA is a next generation framework for distributed simulation systems and promoted by DMSO to replace the current DIS standard. HLA’ enabling middleware is called as Runtime Infrastructure (RTI) which is based on distributed object technologies and DMSO is promoting HLA/RTI towards a Vertical CORBA Facility for the Interactive Modeling and Simulation.

We are working with DoD High Performance Modernization program on integrating advanced web/commodity technologies with large scale Forces Modeling and Simulation systems, being converted to or already based on HLA by DMSO and the enabling RTI middleware.

As part of this project, we are building an Object Web (i.e. Java/CORBA integrated) based implementation of IIOP and HTTP server called JWORB (Java Web Object Request Broker). For large geographically distributed M&S systems, middleware must be given by a mesh of scalable collaboratory servers running on heterogeneous platforms and supporting specific simulation components written in various languages.

A Java/CORBA based middleware with VRML front-end seems to be the most realistic architecture for such systems. Of a particular interest within DoD, is the Simulation Based Acquisition or Virtual Prototyping Environments. Where new systems are engineered and tested in the virtual space before the first real prototype is manufactured.

Figure illustrates a sample of such a system with middleware and a collection of front-ends, including (XML based) data analysis, (Java based) data flow visual authoring software and (VRML based) visual 3D display. Each of these activities can be made collaborative via CORBA Event Service and they all cooperate via the JWORB based componentware.

With the implementation of JWORB, clients can have their Event Channels running on their site and they can connect the other simulations’ Event Channel as a consumer. This also provides the necessary framework for creating an Event Channel for each active object in the virtual environment.

There is yet another pending CORBA Service called Notification Service extends the capabilities of Event Service with the following improvements:

• enables event filtering and interoperability with other standards.
• Enables to define events as objects.
• Time-stamping of event messages.
• Specifying delivery guarantees and other quality of service criteria ( prioritization, aging, retry, reconnect, persistent, and acknowledgement ).
• Allowing a consumer to suspend and reconnect their connections without losing their events.
• Support for assembling event channels into a network of various shapes.
• Allowing multiple event messages to be exchanged within a single unit-of-work to provide event atomicity with the help of CORBA Transaction Service.
• Enabling access to event messages to be controlled to authorized consumers with the help of CORBA Security Service.

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 prototypes and their comperative analysis when employed for building scalable TVR environments.

References