In this article we examine the CORBA domain and discuss the relationship between VRML and the emergent distributed object technologies.

TVR Front-End Description
Our current TVR prototype has two versions of the VRML plus Java front end: one is based on Script Nodes; the other, on the External Authoring Interface (EAI).

The EAI version of the prototype was tested on SGI's CosmoPlayer (version 1.0.2), running as a plug-in to the Netscape 3.0 Web browser on a PC platform. The Script Node version of the prototype was tested on Sony's Community Place, running as a plug-in to the Netscape 3.0 Web browser, and also SGI's CosmoPlayer (1.0 beta 3a), running as a plug-in to Netscape 3.0.

Our current "world" metaphor is given by a set of rooms with avatars represented by simple geometrical objects (such as colored cones). We've added realism in terms of more humanlike avatars with custom behaviors, conforming to the specifications of the Humanoid Working Group Proposal. We're also exploring add-on audio-conferencing capability using commodity APIs like Microsoft NetMeeting.

TVR Back-End Description
JSDA provides a shared framework for Java at the data level. Data objects are shared over specific instances of channels (broadcast communication paths) between two or more clients (objects that are the source or destination of data) in a collaborative environment. Any client object that needs to register its interest in receiving messages sent over a channel must implement the Channel Consumer. Similarly, if a client is interested in being notified about changes in the state of some other object, it should implement the Channel Observer interface. To register interest in a certain channel, a client first needs to join the session that hosts this channel and then can join the channel.

JSDA allows objects to be shared using object serialization mechanisms since it has RMI-based implementation. JSDA also has objects that encapsulate management policies for application objects. One example is the Session Manager, which authenticates clients to determine whether they can join a session. Currently, JSDA is a research-oriented API at JavaSoft Corporation and our TVR prototype is being packaged as an effective demonstration of JSDA's capabilities, along with the main distribution.

Toward Multiserver JSDA Environments
Figure 1 illustrates a more complex TVR world (currently under development at NPAC) that includes 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 channels used to exchange/coordinate visual information between avatars in this room. Some rooms can also publish long-range channels (e.g., audio) that are accessible from other rooms.

Figure 1 shows an avatar moving from room 1 to room 2. It detaches from the room 1 visual/sensory channel and attaches to the room 2 visual/sensory channel and retains the radio channel to listen to 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 a limited number of avatars are allowed per room, and the number of sessions per collaborative server is also limited. This simple model assures worldwide scalability, assuming that new rooms join with their own session servers and that most interactions are local.

Toward CORBA-Based Collaborative Environments
JSDA is a useful framework for prototyping simple collaborative applications, but it doesn't 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 in the course of current interactions between MPEG-4 (Moving Picture Experts Group) and VRML streaming groups. However, a tempting alternative would be to select one universal wire protocol for the Internet that would be capable of supporting all required communication patterns in all relevant application domains.

At the moment, the most promising candidate for such a lingua franca on the Web is the Internet interoperability 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, it is supported as one of the JSDA implementation modes), whereas CORBA offers both multiplatform and multilanguage 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 those supported by Netscape/Visigenic, CORBA now gets even more tightly integrated with Java toward a new, powerful computing paradigm often referred to as Object Web.

To operate in today's heterogeneous computing environments, distributed applications must work on a plethora of hardware and 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 and CORBA complement each other: Java provides for easier distribution of CORBA-based applications that have the wherewithal of a distributed infrastructure.

Java-CORBA Combination
Java's multithreading support encouraged developers to write Web-based distributed software based on proprietary server protocols. Each such server can be viewed as a specific remote computational object. On the other hand, CORBA offers generic support for such server objects based on distributed object technology. Instead of encoding low-level messages, sending them through the network and decoding them at the receiver side, the programmer just calls an appropriate high-level method on a distributed object without the need for any specific low-level network programming. This high-level abstraction capability is definitely a promising framework for future distributed solutions. The only two alternatives that can be viewed as competitive are Java RMI and Microsoft DCOM - but only CORBA is both language- and platform-independent.

However, rather than a competitor or alternative to CORBA, Java is now viewed by many as a complementary technology that forms a perfect match with CORBA within the emergent "Object Web" trends. In a nutshell, the master plan of the Object Web (supported by Netscape, Oracle, IBM, Sun and others) is to implement CORBA control; that is, the middleware layer (including ORBs and some core services) in Java.

Since Java has an inverse mapping to IDL, a programmer can stay in the Java environment during the software development. Java-CORBA implementations can run on thin network computers and low-end consumer devices because of their low complexity and footprint. Java's mobile byte code and CORBA's Dynamic Invocation Interface (DII) simplify upgrades of clients' software in large distributed systems. The Java-CORBA combination truly provide the right building blocks for distributed object computing: (1) platform independence, a strong security model, etc., in the Java language; and (2) static and dynamic interfaces, and synchronous and asynchronous method calls with the comprehensive set of facilities and services in CORBA.

These factors might result in the Java-CORBA combination's assuming a central role in shaping the Internet during the next phase of its evolution. Such emergent Object Webs could have impact in several areas, including multiuser collaborative environments.

In particular, the collaborative environments can be naturally addressed by CORBA in terms of the Event Service - one of the standard 15 services developed and sustained by OMG (together with Security, Persistence, Concurrency, Naming, LifeCycle, Relationships, Trading and other such fundamental object services). The following sections describe the CORBA Event Service, which offers functionality similar to the JSDA Channel discussed above.

CORBA Event Service
The Event Service (ES) (see Figure 2) allows for decoupled communication between objects. Instead of a client's 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 a supplier, and the receivers are called consumers. Suppliers and consumers are decoupled; that is, they don't know each other's identities.

The ES 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 a push/pull Consumer, and the supplier could be a pull/push Supplier. One advantage of using the Event Channel is that the events can be buffered to accommodate consumers of differing speeds. Suppliers and consumers both register with the Event Channel; otherwise it isn't possible to determine the source of the event should the supplier not be able to invoke the appropriate notification method onto the consumer.

Supplier objects request an appropriate ProxyConsumer object from the Event Channel's ConsumerAdmin object. Whenever the supplier wants to send an object to the Event Channel, it uses the corresponding ProxyConsumer object. Similarly, consumer objects request an appropriate ProxySupplier object from the Event Channel's SupplierAdmin object. Whenever a channel receives an event, it informs all the ProxySupplier objects. Each proxy object then notifies its consumer.

CORBA-Based Collaborations
So far, in our work, we have developed an initial API for CORBA-based 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 "collaborative 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, which plays an event-filtering role similar to that of the JSDA Channels (see Figure 3).These are the two most significant IDL definitions in the Collaborative System. The IDL definitions signify the operations a client can invoke on a remote instance of these objects. Nevertheless, invocation of any of these previously mentioned operations should be preceded by the 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 high-availability scenario there would be multiple instances of the PartyScheduler with a static hashtable containing the list of updated Parties; that is, Coordinator Objects (see Listing 1).

Elucidating further on the semantics of operations on these remote objects, the PartyScheduler is the one that schedules the appropriate instance of the Coordinator Object to coordinate clients logged onto a specific session (Party) composed of different possible applications. Basically, the PartyScheduler is responsible for spawning instances of the Coordinator, possibly across a different subnet, and also for returning a remote Coordinator handle to the client. A brief description of the sequence of operations in the Collaborative System follows.

The client initiates a bind to the PartyScheduler Object. If this is successful, and if 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.

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 to perform appropriate housekeeping to reflect new instances of Coordinators. All Coordinator objects scheduled by the PartyScheduler are identified by an ID.

The client now has the option of deciding whether to join an existing Party or to initiate a new one. In the latter case, the first step 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 Coordinators on the basis of the ID that it assigns during their instantiation.

Once the first two steps are over and done with, the client in a Distributed Collaboration mode can invoke operations specified in IDL definitions for the Coordinator. These include Boolean broadcast (in string arg0) and 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 and CORBA can play in distributed environments. Java provides for easier distribution of CORBA-based applications, with CORBA providing what is necessary for a distributed infrastructure. To summarize, CORBA offers both a potential candidate for universal wire protocol - IIOP - and a natural collaborative framework based on shared CORBA objects and flexible message-filtering mechanisms offered by the Event Service.

Scalability and Fault Tolerance in Collaborative Systems
Scalability and fault tolerance, the essential features required in Collaborative Systems, can be naturally addressed in the CORBA model. The replication of servers on different participating hosts in a collaborative environment answers the scalability problem when the load (participating sessions) on a server crosses a certain threshold. The current API supports two different approaches. The notion of groups within a certain session allows us to define one object for each group and easily place these objects on different machines. It is also possible to split the Event Channel if it exceeds a certain capacity and connect two Event Channels to each other as supplier and consumer since one Event Channel can be a consumer/supplier of another Event Channel.

Fault tolerance in Collaborative Systems can be solved by migrating sessions to a different participating host with minimal or little disruption whenever the machine hosting the server crashes. The ObjectServices agent, which is a Distributed Directory service, allows for migration of sessions to a different participating host in case a session terminates unexpectedly on one of the hosts. The events can be stored persistently by the Event Channel to ensure that they are not lost because of system failures.

Using CORBA Event Service for Message Broadcasting
At NPAC we implemented the Event Service for omniORB2, a free C++ Object Request Broker under development by Olivetti and Oracle Research Labs. We wrote the standard Event Service with C++ and the omniThread thread library. We tested this software with a chat program using Netscape 3.0 with OrbixWeb-based ORBlets.

We also started exploring the issues related to using CORBA Event Service for Distributed Interactive Simulation (DIS) PDU broadcasting and for HLA/RTI support. Some additional services are required to support event handling in a multiuser environment. For example, Event Service doesn't care about the originator of the event. But for a multiuser environment, we need to know who sent the message. DIS PDU format includes this information in its own body. The ES is a central server-based approach as compared to peer-to-peer architectures. We can solve this problem by providing an Event Channel for each active object in the virtual environment.

For large-scale interactive simulations, it is imperative that we support event filtering to adjust the frequency of events received from the supplier. The obvious choice is to make this decision a responsibility of Event Channel so the messages are handled before they are put on the network. Event filtering could be based on time stamping. However, this simple solution has a profound problem with synchronizing time values in distributed simulations. The best-known solution is to add the Global Virtual Time (GVT) calculation to the system so that messages that are out of order can be handled properly with the rollback mechanism. GVT calculation allows us to release the storage for the logged events since nobody expects to receive an event time-stamped earlier than the current GVT.

Another intriguing option for message transfer is to use multicasing. This requires some changes in the ES implementation. For PushConsumer, instead of giving a separate PushSupplier for each consumer, it is possible to give one PushSupplier for each multicast group so that multicast PushSupplier can serve multiple consumers. This change also reduces the computation requirement on the Event Channel server.

Several advanced event-handling features are currently in the OMG standardization pipeline in the form of the CORBA Notification Service. New capabilities include support for Quality of Service, integration with Transaction and Security Services and a more flexible user-adjustable format for event objects. Emerging Collaborative Server Technologies Based on Distributed Object Technology

Experiments with Java and CORBA-based collaborations previously described represent our first initial steps toward systematic Object Web support for HLA-based modeling and simulations.

HLA is a next-generation framework for distributed simulation systems promoted by DMSO to replace the current DIS standard. HLA's enabling middleware (RTI) is based on distributed object technologies. DMSO is promoting HLA/RTI within the OMG toward a vertical CORBA facility for interactive modeling and simulation.

At NPAC we have been working with the DOD's High Performance Modernization program to integrate 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-based implementation of IIOP and HTTP server called JWORB (Java Web Object Request Broker) and the Object Web-based RTI layer that will operate on top of JWORB to provide Web-based simulation support for HLA and a natural linkage to front-end technologies such as VRML. For large, geographically distributed M&S systems, middleware must be given by a mesh of scalable collaborative servers running on heterogeneous platforms and supporting specific simulation components written in various languages. A Java-CORBA-based RTI middleware such as JWORB with a VRML front end seems to offer an attractive pervasive architecture for such systems.

Of particular interest within the DOD M&S systems are the simulation-based acquisition or virtual prototyping environments in which new systems are engineered and tested in virtual space before the first real prototype is manufactured.

Figure 4 illustrates a sample of such a system with JWORB-based 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 the base RTI mechanism, CORBA Event Service or JSDA, and they can all cooperate via the JWORB-based componentware.Summary
We've discussed here a set of promising distributed computing frameworks - JSDA, CORBA, RTI - that offer open standards based on support for building scalable multiuser virtual environments on the Internet. The essential feature of such an environment - communication locality - is enabled via event filtering in terms of JSDA channels, CORBA Event Service and RTI routing spaces.

So far, we've acquired a few early prototyping experiences using JSDA and CORBA technologies, and are now exploring the HLA/RTI environment. In the JWORB middleware framework currently under development, we'll be able to integrate, experiment with and conduct comparative analysis of all three collaborative technologies discussed here: JSDA, CORBA and HLA/RTI.

References
Syracuse University/IBM Technical Report on Prototype for Scalable TeleVirtual Environments for the Web.
D. Harkey and R. Orfali (1997). Client/Server Programming in Java and CORBA. Wiley.
S. Baker (1997). CORBA Distributed Objects, Addison Wesley/ACM Press.
J.O. Calvin and R. Weatherly (1996). "An Introduction to the High Level Architecture (HLA) Runtime Infrastructure (RTI)." March, 14th DIS Workshop, 96-14-103.
D.C. Miller (1996). "The DOD High Level Architecture and the Next Generation of DIS." March, 14th DIS Workshop, 96-14-115.
K.L. Morse (1996). "Interest Management in Large-Scale Distributed Simulations." University of California, Irvine. Information and Computer Science Technical Report, ICS-TR-96-27.