
		AT&T Laboratories Cambridge

Distributed Systems

Background

In our effort to engineer our research visions into real systems, a solid distributed system platform has always been an indispensible component in our toolbox. For over 10 years, we have built several generations of distributed systems middleware. Each middleware platform was built on the knowledge and experience gained from previous generations. Each has been put into use in real systems where robustness and high performance are of paramount importance.

Since 1997, our distributed systems research and deployment has been based upon CORBA, the industry standard specification for object-oriented middleware. We started our work with the development of omniORB, our own CORBA ORB.

CORBA is a very powerful technology, but with that power comes complexity, meaning that CORBA can be difficult to use. Our recent work has focussed on providing tools and other facilities to make CORBA easier to use and deploy. We have a four-pronged approach that helps us design new distributed applications:

Experience

Our distributed systems experience is both deep and broad because we develop and build distributed systems technologies and use them. This experience has given us special insights into thorny issues such as scalability, security, naming, and interface evolutions.

omniORB is an industrial strength implementation of the CORBA standard, for the C++ language. Not only have we put it into use in our systems, we have also made it publicly available since 1997 under open source (GPL and LGPL) licensing conditions, with great success. It is one of the most standard compliant ORBs, and was one of the first products to pass the Open Group's standard conformance tests.

omniORB for Python

Python is a high-level object-oriented interpreted language, renowned for its clear and concise syntax and its wide range of included library modules.

One of the most awkward aspects of using CORBA is the inconvenience and complexity of the standard language mappings to C++ and Java. omniORBpy brings the only complete Python binding to CORBA. The mapping is extremely simple -- the specification is only 16 pages long, compared to 130 for Java and 166 for C++. A simple CORBA interaction that would take 25 lines of C++ might take only 5 lines of Python code, for example.

Using Python dramatically simplifies CORBA programming. It has proved to be the ideal language to learn about CORBA, and it excels at programs used for testing and prototyping applications, as well as "glue" programs that tie other applications together. For some kinds and parts of applications, Python is a fine language for large-scale development too.

Like omniORB, omniORBpy is a successful open source project.

IDL Compiler

The interactions between elements of a CORBA application are specified using an Interface Definition Language, IDL. The IDL definitions are compiled by an IDL compiler into declarations to be used in the application programming language.

One way to provide assistance to CORBA application developers is to make use of the IDL definitions to generate additional output, effectively writing some of their program for them. omniidl is a compiler framework that makes it easy to write new code generators, without having to repeatedly implement the inconvenient task of reading in and parsing the IDL.

The code generators we have developed range from simple aids such as generating fill-in-the-blanks object implementations, through automatic test case generation, to some complex additional features provided by the Omni Object Services.

omniidl is publicly released as part of the omniORB distribution, and a number of outside projects make use of it. One notable use is within the Ethereal packet analyser, where omniidl is used to generate interface-specific packet decoders, so sniffed CORBA network traffic can be decoded.

Omni Object Services

The Omni Object Services are the final part of our work to make CORBA easier to use. The services stem from the realisation that many of the hard problems in distributed systems crop up again and again, in slightly different forms. Attempts to provide generic solutions to these problems lead to services that are extremely awkward to use, which greatly diminishes their worth. The Omni Object Services avoid this problem by extensive use of omniidl for code generation, so the services can be tailored for specific applications.

Examples of the services we have implemented are an attribute watching service, enabling interested clients to receive notifications whenever the state of an object's attribute changes, and a distributed state caching service that alleviates network load and performance bottlenecks. Both of these services rely on annotating the application's IDL definitions, to provide small extra hints to the omniidl code generation.