HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

This article proposes to reinvent select TCP based application layer Internet protocols and their client/server implementations in the framework of CORBA/IIOP [2]. Advantages of this approach will be exhibited from the perspectives of programming, deployment and protocol evolution. As an illustrative example, I will attempt a redefinition of the IRC protocol [1] in terms of OMG IDL (Interface Definition Language). I will implement its server object and client application in Java with Javasoft's JavaIDL [3] as the underlying ORB, paying attention to implementation issues different from those of its socket counterpart. I will then briefly go over various benefits the CORBA framework can bring to the deployment of the reinvented IRC 'protocol', with emphasis on the seamless incorporation of load balancing, security and transaction processing control.

CORBA has recently become the most talked-about distributed object framework for building client/server applications. However, few people have envisioned leveraging CORBA/IIOP on legacy client/server applications based on application layer Internet protocols such as SMTP, FTP, NNTP, IMAP, IRC, etc.

The unprecedented growth of the Internet as witnessed in recent years is mostly fueled by the widespread use of various Internet services, notable examples being e-mail and the World Wide Web. The underlying technology behind these Internet offerings is based on a client/server model with various application layer Internet protocols as the communication foundation. For years, these Internet protocols have been defined at the level of TCP socket streams.

The TCP socket framework, however, bears various inherent shortcomings. It turns out that CORBA offers a solution to remedy these shortcomings in an elegant manner.

The Socket Model
A TCP application layer Internet protocol engages two computer processes linked by a single or multiple (e.g., FTP) TCP connection(s), allowing one process (the client) to request services of a certain kind from the other (the server). The protocol governs the dialogs the client exchanges with the server over their TCP connection. The rule for the dialogs is usually expressed in Backus Naur Form (BNF), and serves as a contractual agreement for communication between the client and server implementations.

A TCP socket stream is a primitive communication infrastructure. Other than guaranteeing delivery of a sequence of bytes from one end of a TCP connection to the other in the same sequential order, it essentially offers no additional services. How a data object is marshaled for transportation over the wire is left as an exercise, often a tiresome one, to the design and implementation of the Internet protocol.

Real world deployment of an Internet protocol usually demands certain additional common functionality not related to the core application logic. For instance, a farm of Web servers is usually deployed to host a heavily hit Web site, giving rise to the need of uniformly brokering incoming HTTP requests among the HTTP servers, and for balancing their loads. E-commerce applications often necessitate encryption of network traffic, for instance, to prevent sensitive data from being eavesdropped.

Within the socket model, such additional requirements can only be tackled with ad hoc approaches. Load balancing of Web servers with identical content, for instance, is usually achieved through 'Round Robin DNS', in which the IP addresses of all participating Web servers are statically mapped to the hostname of the Web site. This ad hoc approach works because such HTTP servers seldom share state information among one another (cf. statelessness of HTTP), except possibly through a single backend DBMS. However, the Round Robin DNS approach is not robust, since the DNS server process has no way to find out the load of each participating Web server. It does not even have knowledge of whether a Web server is out of service or not. It is therefore not uncommon to come across popular Web pages with a certain percentage of broken in-line images, especially if the Web site is served from a lesser computing platform.

From time to time, an Internet protocol is due for upgrade to meet previously unanticipated demands, or to improve protocol performance. With a worldwide installed base, it is next to impossible to depreciate and retire implementations of the clients and servers conforming to an older version. Great care, therefore, must be taken in the design of the protocol upgrade to ensure that clients and servers of different versions are interoperable. This compatibility requirement imposes severe constraints in the design of the upgrade.

To summarize, the shortcomings of the socket model include:

  • Application developers need to marshal structured data for communication over TCP streams. The data marshaling and unmarshaling complicates the coding effort, introducing unnecessary digression on software developers from the main application logic.
  • Additional effort is required for load balancing, security and others. Usually ad hoc approaches result.
  • Upgrade of an Internet protocol is constrained by compatibility baggage.

The CORBA Framework
CORBA (Common Object Request Broker Architecture) [2] is a specification for creating and using distributed objects in a platform-independent and language-neutral manner. CORBA specification is written and maintained by the Object Management Group (OMG) [4], an industry consortium of all major software vendors with the exception of Microsoft.

Within the CORBA framework, the type of object is described by OMG IDL (Interface Definition Language). The IDL definition of an object publicly exposes its services to its potential clients. Well-defined mappings have been established for translating IDL definitions into common programming languages. As of this writing, the Java language mapping has just been approved by the OMG.

Besides allowing distributed objects to interoperate, CORBA defines a rich set of preexisting services and facilities. A CORBA object can seamlessly incorporate such commonly demanded functionality as transaction processing control and distributed object security.

In addition to CORBA, there are other competing architectures available including RMI (Remote Method Invocation), and Microsoft's DCOM (Distributed Component Object Model). RMI is closely tied with Java, allowing a client written in Java to invoke methods carried by a remote Java object. DCOM is the answer from Microsoft for communications among distributed objects living in the Win32 world. Since the Internet is a heterogeneous network linking up computers in diverse platforms, CORBA is currently the only architecture well suited for handling distributed objects over the Internet.

The recipe for putting a legacy Internet protocol into the CORBA framework is:

  1. Redefine the protocol in terms of OMG IDL.
  2. Construct server objects on your targeted platform by implementing various interfaces defined in the protocol IDL.
  3. Construct clients which interact with a server object by invoking its methods as defined in the protocol IDL.
Protocol upgrade is achieved through IDL inheritance. The upgraded server object will implement the inherited interfaces, which includes added attributes and methods pertaining to the newer protocol version. Appealing to the CORBA dynamic invocation interface, an upgraded client can determine at run-time which interfaces the server object exposes, thus ensuring interoperability with a server of older protocol version.

The advantages of the CORBA approach are:

  • Communications between client and server happen as method calls, hiding programmers from explicit data marshaling.
  • A rich set of preexisting CORBA object services and CORBA facilities can be utilized to seamlessly incorporate such commonly demanded functionality as load balancing, security and transaction processing monitoring.
  • Protocol upgrade is achieved through IDL inheritance. Clients of newer protocol versions can discover at runtime whether the server supports the newer interface. Clients and servers of different protocol versions are thus automatically interoperable. The design of the newer protocol version is therefore not constrained by compatibility baggage.
Example: Internet Relay Chat
To illustrate the various ideas introduced here, I will attempt to recast the IRC protocol [1] into the CORBA framework. IRC is a text-based protocol allowing teleconferencing among connecting clients in a chat room (channel). An IRC server can hold multiple channels, each of which is comprised of a group of participating users. A user's level of participation in a channel can be characterized by the user mode. A user of the SPECTATOR mode can observe the chat in progress but cannot broadcast a message to all channel users. A user of the PARTICIPANT mode has the capability to broadcast a message to all channel users. A user of the HOST mode is a PARTICIPANT with the added privilege of changing the modes of other channel users, as well as various channel properties.

From a functional point of view, the IRC protocol can be categorized into 2 parts:

  • Protocol governing interaction between an IRC server and its clients
  • Protocol governing interaction among IRC servers for content replication
My attempt at IRC redefinition will focus on the first part here. If there is sufficient interest from the Internet community, I will exert future effort on the second part to complete the whole CORBA-tization process.

Why pick IRC for an exercise of CORBA-tization? Why not HTTP, for instance, which is better known among Internet users? The reasoning is threefold. First, unlike HTTP, which in essence follows a simple request/response cycle, IRC is sufficiently complicated and feature rich to merit a CORBA approach. Second, unlike HTTP, IRC requires its server object to maintain certain state information for each client connection; namely, what channels (chat rooms) the client has joined and what user mode the client carries for each subscribed channel. It would be less trivial to CORBA-tize IRC than the stateless HTTP. Third, IRC is one of a few Internet protocols with asynchronous elements. An IRC client can, at any time, receive channel messages from other clients, as well as notification of a new user joining a subscribed channel, for instance. Such asynchronous elements present an opportunity to illustrate call back methods within the CORBA framework.

Listing 1 exhibits my attempt to redefine IRC in terms of OMG IDL. The Ircd interface describes a CORBA object a client will interact with in the beginning, to inquire about available channels and to log in. Upon a login invocation from a client, the server process will create a CORBA object implementing the UserSession interface, and pass a reference of that UserSession object back to the client. From the server's perspective, a UserSession object tracks various state information of its corresponding client. The client invokes methods of its UserSession object to perform various IRC activities.

The UserNotifier interface describes a CORBA call back object residing at an IRC client for receiving asynchronous events from the server. A UserNotifier object needs to be created at the IRC client side, and passed to the IRC server at login. The interface defines methods for an IRC client to receive channel message posting, notifications of user arrival and departure, notification of a user mode change and server pings.

The IRC server and client objects are then implemented in Java with JavaIDL as the underlying ORB. Without going into coding details, I will merely point out that porting the implementation for another Java ORB should be relatively easy.

Since Java does not allow parameter passing by reference, the CORBA language mapping stipulates that passing an inout or out parameter requires the use of the Holder class. The UserNotifier call back object needs to be passed as an inout parameter. Passing it as an input parameter will trigger a CORBA exception for unknown reasons. It is probably a bug of the JavaIDL early release.

Due to its length, the complete Java source code for both the IRC server and client implementations will not be listed here. Interested readers may download it along with setup information from http://www.unique.net/~lau/CORBAirc/.

Currently, the use of CORBA is mostly confined to the construction of n-tier client/server business applications. The forthcoming object Webs may bring CORBA closer to the mass. Much has been said in this article on the viability of leveraging CORBA on legacy Internet protocols. The Redmond school of thought has always proclaimed the installed base of COM/DCOM is an order of magnitude larger than that of CORBA. This claim may not be able to hold if CORBA-based Internet applications, such as IMAP-like e-mail clients/servers and NNTP-like Usenet news readers/servers are in widespread use.


  1. J. Oikarinen, D. Reed. Network Working Group RFC 1459 (Internet Relay Chat)
  2. CORBA/IIOP 2.1 Specification, http://www.omg.org/corba/corbiiop.htm
  3. JavaIDL, http://www.javasoft.com/products/jdk/idl/
  4. Object Management Group, http://www.omg.org/

About the Author
Kim M. Lau is a software engineer at Warner Bros. online. He holds a Ph.D. in Physics from UCLA. Kim can be reached at: lau@unique.net


Listing 1.
Redefinition of IRC in OMG IDL 

module CORBAirc { 

exception NickCollision {}; 
exception NickNotFound {}; 
exception ChannelNotFound {}; 

typedef sequence<string> StringSeq; 


interface UserSession { 
  readonly attribute string nick; 
  readonly attribute string realname; 

  boolean join (in string channel); 
  boolean part (in string channel); 
  StringSeq get_channel_users (in string channel); 
  UserMode get_my_usermode (in string channel) 
    raises (ChannelNotFound, NickNotFound); 
  UserMode get_usermode (in string channel, 
    in string nick 
  ) raises (NickNotFound, ChannelNotFound); 
  boolean set_moderated (in string channel, 
    in boolean moderated); 
  boolean set_topic_anyone (in string channel, 
    in boolean STA); 
  boolean set_topic (in string channel, 
    in string newTopic); 
  boolean set_usermode (in string channel, 
    in string nick, in UserMode mode); 
  void send_msg (in string channel, 
    in string msg); 
  void whisper (in string nick, 
    in string msg); 
  void quit(); 

interface UserNotifier { 
  void msg (in string channel, 
    in string sender, in string msg); 
  void whisper (in string sender, in string msg); 
  void new_user (in string channel, in string nick); 
  void user_left (in string channel, in string nick); 
  void usermode_changed (in string channel, 
    in string nick, in UserMode newMode); 
  void ping(); 

interface Ircd { 
  UserSession login(in string nick, 
    in string realName, 
    inout UserNotifier notifier 
  ) raises (NickCollision); 

  StringSeq list_channels(); 
  string get_realname (in string nick) 
    raises (NickNotFound); 
  string get_topic (in string channel) 
    raises (ChannelNotFound); 
  void get_channel_info (in string channel, 
    out boolean moderated, 
    out boolean setTopicAnyone 
  ) raises (ChannelNotFound); 


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: info@sys-con.com

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.