Interoperability

PETER WEGNER
Brown University, Providence, Rhode Island ^pw@[Link]&

Interoperability is the ability of two or and floating-point numbers, can be han-

more software components to cooperate dled by polymorphism and coercion. Cli-
despite differences in language, inter- ents and servers from different software
face, and execution platform. It is a platforms or programming languages
scalable form of reusability, being con- can talk to each other through media-
cerned with the reuse of server re- tors that convert data formats. Media-
sources by clients whose accessing tion in information systems as an orga-
mechanisms may be plug-incompatible nizing principle for interoperation of
with sockets of the server. Plug compat- heterogeneous components is reviewed
ibility arises most literally with electri- in Wiederhold [1995]. Mediation may in
cal appliances that require both static turn be viewed as a form of coordina-
compatibility of shape and dynamic tion: the growing body of research on
compatibility of voltage and frequency. coordination languages [Ciancarini et
If there is no direct match, interoper- al. 1995] has interoperation of software
ability of electrical appliances can be components as one of its primary goals.
achieved by adapters and transformers. The use of “megaprogramming lan-
The client-server software paradigm is guages” to communicate among hetero-
a plug and socket paradigm with static geneous interfaces of large components
compatibility specified by types and dy- (like city transportation systems) is yet
namic compatibility by protocols. As another framework for interoperation
with electrical appliances, incompatibil- [Wiederhold et al. 1992].
ity of software plugs and sockets can be In focusing on client-server interoper-
mediated by adapters. ability, we exclude data interoperability
Static compatibility between calling at the level of raw legacy data. The
and called procedures in strongly typed problem of effectively querying and
languages can be determined by type mining (extracting the semantics of) the
checking. Type compatibility guaran- large volume of acquired signal process-
tees that the plug of the caller fits the ing data is of great practical importance
socket of the server but not that the but beyond the scope of this paper.
service provided is that expected by the The basic unit of interoperation in the
caller. But some of the most powerful client-server paradigm is the procedure.
systems of interoperation, like UNIX But procedure-level interoperation is
pipes and http World-Wide Web proto- not a sufficient condition, though it is a
cols, are typeless. Interface definition necessary one for interoperation of soft-
languages with static type-compatibility ware components [Nierstrasz and
protocols promote safety and efficiency, Tschichritzis 1996]. Software compo-
but the complexity and implementation nents may require larger-granularity
cost of typed systems for interoperation units of interoperation, since the corre-
is unacceptably high in today’s technol- spondence between client and server op-
ogy. erations may not be one to one. Moreover,
Type differences between data repre- interoperation may require preservation
sentations, like that between integers of temporal as well as functional proper-

Copyright © 1996, CRC Press.

ACM Computing Surveys, Vol. 28, No. 1, March 1996

286 • Peter Wegner

ties (order constraints on operations or serves as an adapter/transformer. The

coordination of inputs from multiple in- ORB handles communication among ap-
put streams). Such protocol constraints plication objects, object services (system
cannot be captured by functional corre- objects), and common facilities (library
spondences of individual operations. objects). Services provided by an object
Interoperability can be realized for a are specified in an interface definition
wide range of differences in data for- language (IDL) and stored in an inter-
mats and for recognized differences of face repository. The IDL specification
representation, like that between Carte- serves as a target for client requests
sian and polar coordinates of points. and a source for server requests.
But the general problem of reusing pro- CORBA provides half bridges from
cedure functionality is unsolvable, since clients to the ORB and from the ORB to
functional equivalence is undecidable. servers. Clients may invoke a service
The two major mechanisms for inter- through a static stub or through a dy-
operation are interface bridging and in- namic invocation created from the IDL
terface standardization: specification at run time. The ORB val-
idates client requests against the IDL
— Interface Standardization: Map cli- interface and dispatches them to the
ent and server interfaces to a com- server where arguments are unpacked
mon representation (unmarshalled), methods are executed,
— Interface Bridging: Two-way map be- and results are returned. Server-side
tween client and server software includes object adapters that
Interface standardization is more bind object interfaces and manage ob-
scalable because m client and n servers ject references, and a server skeleton
require only m 1 n maps to a standard that uses the output of object adapters
interface, compared with m p n maps for to map operators to the methods that
interface bridging. However, interface implement them.
bridging is more flexible, since it can be Microsoft’s Component Object Model
tailored to the requirements of particu- COM/OLE [Brockschmidt 1995] realizes
lar clients and servers. Interface stan- interoperability through a binary (ma-
dardization makes explicit the common chine language) standard that specifies
properties of interfaces, thereby reduc- multiple interfaces by a pointer to a
ing the mapping task, and it separates function table and objects by a principal
communication models of clients from interface I-unknown for accessing a di-
those of servers. But predefined stan- rectory of interfaces through a “queryin-
dard interfaces preclude supporting new terface” function. COM/OLE objects
language features not considered at the have multiple interfaces that share a
time of standardization (for example, common data structure. The multiple-
transactions). Standardized interface sys- interface model for objects is more scal-
tems are closed while interface bridging able than the hierarchical inheritance
systems are open. Architectures for stan- model of object-oriented programming,
dardized interfaces may be considered a providing greater flexibility for both in-
special case of interface-bridging architec- teroperation and extension of object
tures in which the bridge from clients to functionality. Class-based inheritance is
servers is replaced by two half bridges less scalable than multiple interfaces as
from clients to the standard interface, an organizing principle for interfaces,
and from the standard interface to the both because complex objects are natu-
servers. rally modeled by multiple interfaces
The common object request broker ar- and because hierarchies are too restric-
chitecture [Object Management Group tive a structuring principle. Use-case
1995] realizes interface standardization models [Jacobson 1991], as well as
by an object request broker (ORB) that COM/OLE, elevate collections of inter-

ACM Computing Surveys, Vol. 28, No. 1, March 1996

 Interoperability • 287

faces that share a state into a primary cesses are inherently less amenable to
structuring principle of software design. formal analysis than algorithms [Weg-
COM/CORBA interoperability, which ner 1995], heuristic methods of interop-
aims at a compatibility between Mi- eration will play an increasingly impor-
crosoft and CORBA-compliant compo- tant role in the software technology of
nents, is being pursued by a broad in- the 21st century.
dustry consortium under the auspices of
the object-management group (OMG). REFERENCES
Proposals for COM/CORBA interoper-
ability aim to realize interoperation by BROCKSCHMIDT, K. 1995. Inside OLE 2, 2nd ed.
interface bridging. Clients send a re- Microsoft Press.
quest via a surrogate object to a state OBJECT MANAGEMENT GROUP. 1995. CORBA:
Architecture and Specification, (July). Revi-
that marshals the arguments and sends sion 2.0. Object Management Group.
them across a bridge to a server skele- CIANCARINI, P., NIERSTRASZ, O., AND YONEZAWA,
ton that ummarshals the arguments A. 1995. In Proceedings of ECOOP ’94
and manages the implementation of op- Workshop on Coordination Languages. Lec-
erations by methods of the target object. ture Notes in Computer Science 924. Springer
Verlag, New York.
The combination of interface standard-
JACOBSON, I. 1991. Object-Oriented Software
ization within CORBA and interface Engineering. Addison-Wesley/ACM Press.
bridging to COM provides a balance be- NIERSTRASZ, O. AND TSICHRITZIS, D., EDS. 1996
tween closed efficiency and open exten- (especially Chapter 3 by Dimitri Konstantas)
sibility expressed by the metaphor of Object-Oriented Software Composition. Prentice
closed islands connected by bridges. Hall, Englewood Cliffs, NJ.
The paradigm shift from algorithms WEGNER, P. 1995. Interactive foundations of
in the 1960s and 1970s to interaction in object-based programming. IEEE Computer
(Oct.).
the 1990s is refocusing attention from
WIEDERHOLD, G. 1995. Mediation in informa-
inner processes of execution to interac- tion systems. ACM Comput. Surv. (June).
tive processes of mediation, coordina- WIEDERHOLD, G., WEGNER, P. AND CERI, S.
tion, and interoperation among software 1992. Towards megaprogramming. Com-
components. Though interactive pro- mun. ACM (Nov.).

ACM Computing Surveys, Vol. 28, No. 1, March 1996