Interoperability
Eric M. Dashofy*
ICS 221
November 12, 2002
*With special thanks to David Rosenblum from whom some of this material is blatantly stolen.
Overview
Characterization of the Problem

With a small attempt to taxonomize
Taxonomy of Solutions
Investigation of Specific Solutions


CORBA, JMS, Siena, and other middleware
XML
Definitions
Interoperability

The ability for two or more (independentlydeveloped) (software) components to
interact meaningfully
 Communicate meaningfully
 Exchange data or services
Why is Interoperability Important?
One (perhaps the) dominant challenge in
software engineering

We can’t live without it
 Large systems are no longer built from first principles
(nor can they be)

We shouldn’t live without it
 Component reuse has the potential for enormous cost
savings


Cited by Brooks as a potential silver bullet
We need it to maintain the living we do now
 We are burdened with un-rebuildable legacy systems


cf. SAABRE, Air Traffic Control
It is induced by the state of computing now
 Increasing connectivity of computers through the
Internet
Is Interoperability the
Problem?
Interoperability is not a problem, it’s a software
quality. The problem in achieving this quality is…
Heterogeneity!








Components written in different programming languages
Components running on different hardware platforms
Components running on different operating systems
Components using different data representations
Components using different control models
Components implementing different semantics or semantic
interpretations
Components implementing duplicate functionality
Components implementing conflicting functionality
Another Characterization
Architectural Mismatch [GAO95]

Components have difficulty interoperating because
of mismatching assumptions
 About the world they run in
 About who is in control, and when
 About data formats and how they’re manipulated

Also assumptions about connectors
 About protocols (who says what when)
 About data models (what is said)


Also assumptions about the global configuration
(topology)
…and the construction process (mostly
instantiation)
Syntactic vs. Semantic
Syntactic compatibility only guarantees that
data will pass through a connector properly
Semantic compatibility is achieved only when
components agree on the meaning of the
data they exchange
Example: UNIX pipes


Syntactic compatibility established by making all
data ASCII
Semantic compatibility is not addressed
 Line-oriented data?
 Field-oriented lines?
 Field separators?
Classic Example
American electrical plug
European electrical outlet
Enumerate the interoperability problems here
Are they essential or accidental?
Are they syntactic or semantic?
An example of an “essential”
power problem
American electrical plug
Flintstones Power Source
Achieving Interoperability
Component ?
A
?
? Component
B
Give some examples of components for A and B.
Given two components and an arbitrary connector
in between, how can we make them interoperate?
Shaw’s Taxonomy
form = representation, communication, packaging, semantics
In Detail…
Change A’s form to B’s form


Usually involves a complete rewrite
Expensive but do-able
Publish an abstraction of A’s form


API’s (open or standardized)
Projections or Views (common in
databases)
(cont).
Transform on the fly


Big-endian to little-endian translations in
the connector
REST architectural style
Negotiate a common form


Requires that one or both components
support multiple forms
Classic example is modem protocol
negotiation
(cont).
Make B multilingual


Macintosh “fat binaries”
“Portable code” that uses #ifdefs
Import/Export Converters


May be part of A or B, may be developed
by a 3rd party
Classic example: word processors, Alchemy
Mindworks’ Graphics Workshop
(cont).
Intermediate form




Agree on a common form, usually involves some
sort of standardization
IDL data definitions
XML schema
RTF, PostScript, PDF
Wrap Component A

Machine emulator
 (cf. Playstation emulators, StellaX, SAABRE)

Piece of code that translates APIs
(cont).
Maintain parallel consistent versions



Constrain both A and B such that they have
matching assumptions
Whenever one changes assumptions, make the
corresponding change in the other component
Delicate, often impractical
Separate essence from packaging





Research topic
“A service without an interface”
Interfaces are provided by “system integrators”
Variant: exposing multiple interfaces from A
Variant: A generic interface that can be
transformed into many interfaces automatically
The “Solution”
(as offered by industry)
Middleware


Buzz: Industry will build you a connector
that makes interoperability magically
appear
Right?
Hint: Not Exactly 
Middleware
Popular middleware offerings









CORBA
COM
RMI
JMS
DCE RPC (aka Xerox Courier, SunRPC, ARPC)
Microsoft Message Queue
MQ Series
Siena
KnowNow SOAP Routing
 SOAP (is this middleware?)
Focus: CORBA
Common Object Request Broker
Architecture
A middleware standard


(not implementation)
from the Object
Management Group
 Like the United Nations
of software organizations
Focus: CORBA
From the spec:

Object Request Broker, which enables objects to transparently
make and receive requests and responses in a distributed
environment. It is the foundation for building applications from
distributed objects and for interoperability between applications in
hetero- and homogeneous environments. The architecture and
specifications of the Object Request Broker are described in this
manual.
Standard for middleware that enables interoperability
among components with different assumptions
about:


Platform
Language (type system)
What assumptions are implicit in the OMG
definition?
What is CORBA?
At its core:



It is RPC with objects
Along with a fairly competent IDL (interface
definition language)
Plus some pre-defined services provided by the
middleware and exposed through the
RPC+Objects mechanism (CORBAServices)




Naming
Trading
“Events”
Etc.
Example
Public
Interface of B
Component
A
Object
B
How do we make this call (one
way only, here)?
Example
Public
Interface of B
Component
A
Object
B
First, we must
turn this interface
into something that
is comprehensible in A’s world
Solution: define the interface in a platform-neutral
interface definition language (IDL)
Why might this be harder than it looks?
Exercise: Convert this Java
signature to be called from C++
public int foo(int p1, Vector v);
What do we need to know about the source and
target language to do this effectively?
public int start(Thread t);
Can I do this for any arbitrary function?
Example cont.
Public
Interface of B
Component
A
IDL
Compiler for A-world
Object
B
IDL
Compiler for B-world
Are these the same?
Example cont.
Public
Interface of B
Component
A
(or maybe…)
Stub
Compiler for A-world
B’s
Stub for
A-world
Object
B
(or maybe…)
Skeleton
Compiler for B-world
Skeleton for
B-world
Example cont.
Public
Interface of B
Component
A
Object
B
Skeleton for
B-world
B’s
Stub for
A-world
NB: B is often
called the “true
object”
Via proprietary
protocol, probably TCP-based
if a network is involved, maybe
through some more efficient
OS-based mechanism like
named-pipes if the call is all
being made on one machine.
Semantic Sugar:
CORBAservices
CORBAservices are basically standardized APIs for
doing common tasks.
The True Objects providing the services are usually
provided by your ORB vendor.
A snippet of the IDL for the Naming service:
void bind(in Name n, in Object obj)
raises(NotFound, CannotProceed, InvalidName,AlreadyBound);
void rebind(in Name n, in Object obj)
raises(NotFound, CannotProceed, InvalidName);
Funny Side-note: IIOP
It turns out that the proprietary
protocols between stubs and skeletons
caused interoperability problems
between ORBS

Solution: standardize yet another protocol
for Inter-ORB Interoperability
 This became IIOP—the Internet Inter-Orb
Protocol
For Discussion
What kinds of heterogeneity/interoperability
issues are solved by CORBA
Which are not?
Are the problems that are addressed syntactic
or semantic?
Does CORBA induce any additional
assumptions (i.e. does it worsen
interoperability)?


What assumptions?
How?
Where does CORBA fit in Shaw’s taxonomy?
Can we taxonomize middlewares?
RPC with Objects
- CORBA
- COM
- RMI
- SOAP-RPC
Oneway Messages
(low multicast)
- JMS
- MSMQ
- MQ Series
- SOAP (at core)
- CORBA oneway calls
RPC with Services
- DCE RPC
- “Q” (U. Colorado)
- Corba w/C binding
Oneway Messages
(high multicast)
- Siena
- KnowNow SOAP
routing
- Precache Secret Project
(presumably)
Focus: XML
XML: Extensible Markup Language


Buzz: Finally, a standard for encoding data!
XML will solve your interoperability
problems!
Right?
Hint: Not exactly 
What is XML?
From the spec:


Extensible Markup Language, abbreviated XML, describes a class of
data objects called XML documents and partially describes the
behavior of computer programs which process them. XML is an
application profile or restricted form of SGML, the Standard
Generalized Markup Language [ISO 8879]. By construction, XML
documents are conforming SGML documents.
XML documents are made up of storage units called entities, which
contain either parsed or unparsed data. Parsed data is made up of
characters, some of which form character data, and some of which
form markup. Markup encodes a description of the document's
storage layout and logical structure. XML provides a mechanism to
impose constraints on the storage layout and logical structure.
What assumptions are implicit in the W3C
discussion?
What is XML, really?
A way of organizing and decorating
textual data
Blatantly hierarchical, but works well in
the context of a running document
Supported by meta-languages that
define allowable constructs in the
hierarchy
Example
Eric M. Dashofy, b. 1977 to
father Mark and mother
Susan, currently a
computer scientist at UC
Irvine, hobbies include
playing guitar and making
Star Wars fan-films.
Eric’s Personal Information,
unstructured.
With XML
<person>
<name>
<first>Eric</first>
<mi>M</mi>
<last>Dashofy</last>
</name>
<dob>
<year>1977</year>
</dob>
<father>Mark</father>
<mother>Susan</mother>
<occupation>
<title>Computer Scientist</title>
<location>UC Irvine<location>
</occupation>
<hobby name=“guitar” />
<hobby name=“star-wars-fanfilms” />
</person>
Is this better or worse
than the bio on the
previous slide? Howso?
What can we do with this
bio that we couldn’t with
the previous one?
What assumptions are
being made in this
biography?
What agreement(s) do two
components have to come
to to make use of this bio?
For Discussion
What kinds of heterogeneity/interoperability
issues are solved by XML?
Which are not?
Are the problems that are addressed syntactic
or semantic?
Does XML induce any additional assumptions
(i.e. does it worsen interoperability)?


What assumptions?
How?
Where does XML fit in Shaw’s taxonomy?
Future Directions
Interoperability over the Web

SOAP
 “XML for control instead of data”
 Solves, introduces same issues as XML


Web Services
“The Semantic Web”
2nd Generation Middleware

Which is largely geared toward interoperability
between 1st generation middleware packages
Enterprise Application Integration (EAI)

A whole market driven by people with experience
making systems interoperate