Programming Issues

With the increasing use of distributed systems, interoperability has emerged as a major issue for system developers. Of course, the problems of interoperability have actually been around for many years , and a number of standards and architectures have been developed to address some of these issues, with varying degrees of success. These issues can be generally classified into two broad categories: "programming in the small" and "programming in the large."

Programming in the Small

The "programming in the small" issues can be divided into three general domains: type system issues, metadata issues, and execution issues.

Type System Issues

Often what appears to be a simple objective ”for example, passing an integer from one program on one machine to another program on another machine ”turns out to be a complicated problem. Many languages have a different notion of what an integer is. Even if both programs are written in the same language, sometimes no accurate definition of what an integer is exists in that language. For example, the C++ language standard states that an integer ( int ) is equal to or greater than a short and is equal to or less than a long on any given platform. It does not define the size (and therefore the range) of the type, however. Thus, an integer may be 16 bits long on one machine, but 64 bits on a second machine. This choice, of course, says nothing about the endianness of either machine.

The situation becomes more complex when one attempts to pass types between different programming languages, even if they reside on the same machine. Some languages, such as C++, see an integer as a sequence of bits; other languages, such as SmallTalk, see an integer as an object; and still other languages, such as Java, allow integers to be either ( int or Integer ). The situation becomes even more complicated when you start to pass user -defined types between machines; passing the value of data members is far easier than passing the methods of the type.

Metadata Issues

A type's description is normally stored in a language-specific source file ”for example, a header file in C++. When the source file is compiled, many compilers remove a large amount of the type's metadata. As a consequence, little or no type information may remain in the executable file that other compilers can use to inspect the metadata of a type. Recently, the loss of metadata has become a more significant problem as languages and architectures add more support for dynamic type discovery and method invocation. C++ has added runtime type information (RTTI) to partially address this problem in a language-specific manner. COM and CORBA provide type libraries and interface repositories, respectively, as language-independent solutions. Maintaining consistency in this situation, where the type and its metadata are located in separate files and possibly generated at different times, is difficult and error prone.

Execution Issues

When a developer uses a type from another language, how does the run-time environment provide access to the type? Many architectures provide cross-language method invocation, but is this the best result that can be achieved? Certainly, cross-language method invocation is a significantly useful facility, but it is also a complicated scenario. For example, how are program constructs, such as exceptions, mapped from one language or machine to another? Add to the mix the fact that the programs may be executing on different hardware platforms with different operating systems, and the magnitude of the problem becomes evident.

True language interoperability should, in fact, offer more than cross-language method invocation. If a C++ programmer's classes can inherit from other C++ classes developed by other developers and then extend their functionality by overriding method bodies, then a C++ class should be able to inherit from a Python class. Today, however, the object and execution models provided by the languages are sufficiently different that a common execution system cannot be supported.

Programming in the Large

A number of "programming in the large" issues need to be addressed when taking software produced by a number of different developers using different languages, and then attempting to integrate these components into a coherent distributed system. Examples of these issues include, but are not limited to, the following:

• Naming. If developers from many sites plan to reuse one another's classes, how do you avoid name clashes ?

• Error handling. Some languages and architectures use return values to represent error conditions, whereas others use exceptions. What is required is a schema that allows translation while preserving semantics across languages/architectures.

• Security. Large distributed systems cross many language, architecture, organizational, and international boundaries. Ensuring that software is not used maliciously in such an environment can prove very difficult.

• Versioning. Anyone who has ever dealt with incompatible upgrades of system software, one form of which is commonly known as "DLL hell," understands that the evolution of system architectures is a major issue complicating component-based software development.

• Scalability. Scalability is probably the least known and most poorly understood of the issues associated with large distributed systems. What works well for 100 users on an intranet often proves completely inadequate for 1 million users on the Internet.

It can be argued that much of the recent evolution of programming languages and architectures has targeted "programming in the large" issues. Facilities added to C++ that are not found in C, such as namespaces and exceptions, address some of these issues. Likewise, the immutability of interfaces and the use of globally unique identifiers (GUIDs) as names in COM address some of these issues. One goal of the Portable Object Adapter (POA) in CORBA is to provide "scalable high-performance server applications." ^[1]

^[1] Michi Henning and Steve Vinoski (1999), Advanced CORBA Programming with C++ , Addison-Wesley.