An Internet-based workgroup application
The goal of the project described in this section was to develop a prototype for an Internet-based workgroup architecture using CORBA technology. CORBA provides a means for developing distributed object applications, while the Internet provides a standard and widely accessible network infrastructure. Users should not need special client software to use the system, other than a Java-enabled browser such as Netscape.The object model guiding the implementation is depicted in \sliref{object-model}. The most important notion in our system is that of an agent, which is defined as a representative of a user which can perform simple operations on the user's behalf, such as sending messages to and making appointments with other agents.
Each user participating is represented by a personal agent, which has an agenda and a message queue. Each agenda consists of several appointments. A workgroup has a membership list consisting of zero or more agents present in the system. An agent can be a member of zero or more workgroups. Possible operations on agents are sending messages to and making appointments with other agents, subscribing to a workgroup, making an appointment with a workgroup or sending a message to all workgroup members.
All interaction of the user with the system is done via Java applets, which combine a graphical user interface with Internet access and CORBA functionality. The server is implemented in C++. We used Visigenic's (formerly PostModern Computing) CORBA 2.0-compliant product ORBeline to implement the server and BlackWidow from the same vendor to implement the Java clients. The server can run on most UNIX platforms, as well as on Windows NT, while the Java applets, running on top of a Java Virtual Machine, can theoretically run on every platform that Java supports. In addition, a C++ browser/monitor was developed that can be used to interrogate agents and workgroups and to monitor message flows.
The Java client applets are first transferred to
the client by the HTTP server using a web page and then contact
the object server through IIOP, the Internet Inter-ORB Protocol.
The client applets run in Netscape or HotJava and contain the
CORBA client communications software as well as the client application
code. The object server can reside on a different machine than
the Web server and is running an IIOP gatekeeper, for instance
on {\sc tcp} port 15000, that is part of the ORB. All further communication
is done through this gatekeeper.
Discussion
The most important problem we faced was the distinction between clients and servers, where distributed objects can only reside on a server. If a client wants to make its objects available to other programs, it should be configured as a server as well, with an ORB running on the same host. This causes problems regarding overhead and licensing and is not a feasible situation for the distribution of (Java) clients over the Internet. The same architecture limitation prevents servers from notifying clients using callbacks. This feature makes it impossible for clients to pass distributed object references back to the server, forcing them to work with other identification mechanisms such as object IDs or human-readable strings.
Other minor problems we observed concern the lack of support for existing non-CORBA objects in a distributed environment. Possible solutions are converting existing classes to CORBA and making their interface available through IDL, or to write CORBA object wrappers around these objects.
Finally, not all parts of a CORBA system are compatible among ORBs at the source-code level. This problem should, however, be alleviated with the Portable Object Adapter (POA).
(C) Æliens 04/09/2009
You may not copy or print any of this material without explicit permission of the author or the publisher. In case of other copyright issues, contact the author.