1 Background

The focus of our long-term research program is summarized by the name of our research group - the Convergent Computing Systems Laboratory. The term convergent computing system is intended to denote any system that comprises features or components drawn from different computing domains (as, for example, a persistent programming language combines features from both the database and the programming language domains) or implemented using different technologies (as, for example, in the case of a software system consisting of modules written in two or more different languages). The group's long-range goal is to understand phenomena associated with convergence and to produce tools and techniques applicable to the development and maintenance of convergent computing systems. Since interoperability is perhaps the most important manifestation of convergence in contemporary computing practice, developing foundations for interoperability falls squarely within our purview.

Our research on interoperability began several years ago with an initial attempt to describe and categorize interoperability problems and approaches, coupled with an early effort at defining an architecture for automated interoperability support [WWRT91]. Since that time, our work on interoperability has been motivated by a primary concern for the impact of an interoperability approach on applications developers. In our view, among the most important objectives for any approach to interoperability are the following:

• Developers should have maximum freedom to define properties of objects that their programs manipulate. In particular, they should always be able to use the name management and type systems provided by the language(s) in which they are designing and developing components of their applications.
• Whether an entity is to be shared among an application's components should have minimal impact on the components' developers. In particular, making (or changing) a decision about whether, or with what other components, an entity may be shared should not affect the definition of, or interface to, the entity. As a corollary, interoperation should not result in an unnecessary reduction in the ways in which the (now shared) entities can be manipulated.

Given these objectives, we have been drawn to consideration of three major sets of issues regarding interoperability approaches. Briefly, these are:

Naming

How are entities accessed by components that wish to interoperate through sharing those entities? Currently, individual components typically rely on distinct and often incompatible name management mechanisms, with the result that their interactions are hampered by inconsistencies in the semantics of their respective name management capabilities [KW95]. At best, existing interoperability approaches generally provide only limited, non-native name management capabilities.

Timing

When is the decision to share entities among an application's components made? This question has a dramatic impact on the suitability of different approaches to interoperability. Three distinct timing scenarios for interoperability decisions can be characterized by the relationship among the relative times at which the sharing or shared components are developed and the decision to share them is made, as illustrated in Figure 1. The salient features of each scenario are:

Easiest case:

The decision to share is made before any components are developed. In this case, all points of potential interaction (e.g., names or types of shared objects) can, in principle, be identified and given special treatment (e.g., type definition via OMG's IDL), which may substantially facilitate interoperation.

Common case:

The decision to share is made after one of the sharing components is developed but before any others are. In this case, points of potential interaction in the existing component can, in principle, be identified and retroactively given special treatment (e.g., wrapped with interfaces defined via OMG's IDL) while points of potential interaction in the new components are given corresponding special treatment (e.g., matching IDL type definitions), which may somewhat facilitate interoperation.

Megaprogramming:

The decision to share is made after the sharing components are developed. In this case, retroactive special treatments (e.g., wrapping with interfaces defined via OMG's IDL) are unlikely to result in compatible interfaces, so achieving interoperation is facilitated little, if at all, by most existing techniques.

  

Figure 1: Interoperability Scenarios

Typing

How do developers determine whether entities that they wish to share are of compatible types? Most existing approaches to addressing this question have been based on use of a unifying type model [WWRT91], such as the OMG IDL or the ODMG ODL. While such approaches may suffice for the easiest and common interoperability scenarios, however, they are inadequate for the megaprogramming case.

Our recent interoperability-related research has been focused on the issues of naming and typing. Oue work has been oriented toward addressing the third of the interoperability scenarios listed above and toward adhering to our principles of maximum freedom for, and minimum impact on, software developers. In the area of name management, we have been particularly interested in the formation, manipulation and use of contexts, which determine the meanings associated with individual names at a given point in time. We have also investigated extended notions of closures, which associate contexts with particular objects in order to refine each object's control over the meanings of names that it uses. Our research in this area has produced models of names and their usage that are more general and broadly applicable than previous models [KW93,KW95,Kap96]. It has also led to the development of name management mechanisms providing more powerful and accurate control over, and analysis of, context definition and use than any existing mechanisms [KW94,KW95,Kap96]. Prototype implementations of these mechanisms have been developed as extensions to the TI/Arpa Open Object-Oriented Database (Open OODB) [WBT92], and some of our name management capabilities are included in the currently released version of Open OODB.

Our research on typing issues in interoperability has centered on problems impeding cooperation among software modules of different languages, or multi-language interoperability problems. These naturally arise for any number of reasons, such as a desire to reuse legacy components, or because particular languages facilitate development of particular kinds of applications. In addressing multi-language interoperability problems, we make several distinctions. First, we differentiate situations in which a component written in one language needs to access one or more components (subprograms, data objects, etc.) written in a single second language from those in which a component written in one language needs to uniformly interact with a set of components written in two or more different languages (which may or may not include the language of the first component). We refer to the former, more homogeneous situation as multilingual interoperability, and the latter, more heterogeneous situation, as polylingual interoperability. Second, we distinguish approaches by their level of transparency to software developers. Most current approaches force developers to be aware that multiple languages are involved and to build their modules to explicitly surmount the language boundaries. Multilingual interoperability may be achieved, for example, by using heterogeneous remote procedure calls, while polylingual interoperability can be realized by enforcing the use of a common, non-native type model among the modules (e.g., as in CORBA [BDE⁺95]). At the other end of the transparency spectrum, if developers of a multi-language software system need not be aware of language differences between the software modules then we call the interoperability approach seamless. Such seamlessness has long been a highly desirable property of interoperability, but it has rarely been achieved. As noted earlier, our work has always been motivated by a primary concern for the impact of an interoperability approach on applications developers, so we view seamlessness as an extremely important goal.

Existing approaches to interoperability, such as CORBA [BDE⁺95], ILU [JSS95], Concert [AR94], Microsoft's OLE [Bro94] or Apple's OpenDoc [App94], are generally not seamless because they typically involve use of a different invocation mechanism (e.g., low-level approaches and messaging systems) or a different type model (e.g., CORBA-style and database approaches) from those of the programming languages in which accessors are implemented. As a result, it is difficult to imagine how these approaches could be made transparent, even through automation. On the other hand, we have recently begun working on an approach that imposes neither different invocation mechanisms nor different type models and hence supports transparent, seamless interoperability. PolySPIN is an approach to Support for Persistence, Interoperability and Naming in POLYlingual systems [KW96]. The key component of PolySPIN is a language-neutral name management mechanism that allows for uniform name-based access to objects [Kap96]. This mechanism supports, but does not require, transparent polylingual interoperability. In the PolySPIN approach, a set of objects, implemented in diverse languages, can be transparently and automatically modified in such a way that they can be accessed seamlessly by software modules of different programming languages. That is, PolySPIN automates determination of type compatibility across language boundaries and implementation of cross-language access, thereby allowing a programmer to proceed as if the languages of the object and the accessor were the same. All software modules use only their native type systems to access these objects, not a common (but non-native) type system like CORBA's IDL, and existing modules need not be modified to do it. Hence PolySPIN meets our objective of minimizing the impact of an interoperability approach on applications developers. Our initial prototype implementations of PolySPIN and the PolySPINner toolset automating its use [BKW96] are based on the Open OODB. The way in which type compatibility is determined in these initial prototypes, however, lacks generalizable, formal foundations, does not address the polymorphism found in object-oriented programming languages, and does not assure type safety. Hence, we are currently developing a suitable formal foundation for polylingual type compatibility, based on concepts from signature matching [ZW95a] and object-oriented type theory [Bar97]. Our goal is to use this foundation to aid in reasoning about, and implementing support for, type safety in polymorphic, polylingual software systems [BRW97].

The various components of an approach to interoperability that we have developed to date have value in their own right, but we view them primarily as indicative that much more can and should be done. We believe that pursuing directions we have initiated, and exploring more rigorous and formal avenues, can lead to some suitable foundations for both theory and practice in the area of interoperability. In particular, we see an urgent need for a conceptual foundation for interoperation. It is our hope that participating in the workshop on Foundations of Component-Based Systems will contribute to developing an agenda for research that will lead us and others toward providing such a foundation. This in turn would contribute to our long-term goal of understanding convergence phenomena in computing systems.