execution model (control) issues: How is the execution of the interoperating programs coordinated?
type model (data) issues: How are correspondences established among the ways interoperating programs manipulate a given shared entity?
Execution model issues become most problematic if the interoperating programs are based on very different underlying execution models, such as a dataflow model and a logic programming model.
This seems reasonable, since most existing approaches to support for interoperability have been based on the use of the remote procedure call (RPC) [7] for coordinating the execution of the interoperating programs.
That is, when two interoperating components are sharing or communicating via some data object, they must have consistent views of whatever properties they mutually rely upon that are associated with objects of that type.
An obvious approach to type compatibility in interoperating programs is to impose a single type model on all the languages in which interoperating programs are to be written.
Similarly, Emerald [8] is a language that supports multiple representations of objects across different machines, but again the assumption is that all interoperating programs are written in the same language, namely Emerald.
The earliest form of this approach involved interoperation through ASCII representation of data--where the data were communicated between the interoperating programs via files.
The Unix[TM] operating system supports interoperability via pipes (untyped byte streams) through which two interoperating programs can communicate.
In particular, RLI does not support abstract types, such as "stack" or "abstract" syntax tree." This not only makes RLI awkward to use in conjunction with modern languages having rich and extensible typing mechanisms (Ada, C ++, CLOS, etc.), but also leads to low-level dependencies on type representations between interoperating programs.
Furthermore, RLI limits the flexibility and extensibility available in interoperating systems.
In the Single Standardized Submodel approach, all interoperating programs must use a single type model, distinct from those found in the languages in which the programs are written, to describe any shared objects.
The SLI approach is motivated by our belief that developers of potentially interoperating programs should have the maximum possible flexibility, convenience and range of expressive power available when defining types for the objects their programs will manipulate.
The SLI approach thereby attains the benefits of abstraction and information hiding for interoperating programs, encouraging the use of entity descriptions (i.e., type definitions) that promote the overall organization of a software system.
A Unifying Type Model (UTM): A UTM is a notation for describing the types of entities that are to be shared by interoperating programs.
