This document discusses interoperability between software components. It defines interoperability as the ability of independently developed components to interact meaningfully by communicating and exchanging data or services. Achieving interoperability is challenging due to heterogeneity between components in terms of programming languages, platforms, data formats, and assumptions. Common Object Request Broker Architecture (CORBA) and XML are examined as approaches to enabling interoperability, but both make assumptions that can limit their effectiveness and even introduce new interoperability issues in some cases. Shaw's taxonomy of interoperability solutions is also referenced.

1. Interoperability
Eric M. Dashofy*
ICS 221
November 12, 2002
*With special thanks to David Rosenblum from whom some of this material is blatantly stolen.

2. 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

3. Definitions
Interoperability
 The ability for two or more (independently-
developed) (software) components to
interact meaningfully
 Communicate meaningfully
 Exchange data or services

4. 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

5. 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

6. 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)

7. 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?

8. Classic Example
Enumerate the interoperability problems here
Are they essential or accidental?
Are they syntactic or semantic?
American electrical plug European electrical outlet

9. An example of an “essential”
power problem
American electrical plug
Flintstones Power Source

10. Achieving Interoperability
Component
A
Component
B
?
? ?
Given two components and an arbitrary connector
in between, how can we make them interoperate?
Give some examples of components for A and B.

11. Shaw’s Taxonomy
form = representation, communication, packaging, semantics

12. 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)

13. (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

14. (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

15. (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

16. (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

17. The “Solution”
(as offered by industry)
Middleware
 Buzz: Industry will build you a connector
that makes interoperability magically
appear
 Right?
Hint: Not Exactly 

18. 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?)

19. Focus: CORBA
Common Object Request Broker
Architecture
A middleware standard
 (not implementation)
 from the Object
Management Group
 Like the United Nations
of software organizations

20. 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?

21. 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.

22. Example
Component
A
Object
B
Public
Interface of B
How do we make this call (one
way only, here)?

23. Example
Component
A
Object
B
Public
Interface of 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?

24. Exercise: Convert this Java
signature to be called from C++
public int foo(int p1, Vector v);
public int start(Thread t);
What do we need to know about the source and
target language to do this effectively?
Can I do this for any arbitrary function?

25. Example cont.
Component
A
Object
B
Public
Interface of B
IDL
Compiler for A-world
IDL
Compiler for B-world
Are these the same?

26. Example cont.
Component
A
Object
B
Public
Interface of B
Stub
Compiler for A-world
(or maybe…)
B’s
Stub for
A-world
Skeleton
Compiler for B-world
(or maybe…)
Skeleton for
B-world

27. Example cont.
Component
A
Object
B
Public
Interface of B
B’s
Stub for
A-world
Skeleton for
B-world
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.
NB: B is often
called the “true
object”

28. 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.
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);
A snippet of the IDL for the Naming service:

29. 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

30. 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?

31. 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)

32. Focus: XML
XML: Extensible Markup Language
 Buzz: Finally, a standard for encoding
data! XML will solve your interoperability
problems!
 Right?
Hint: Not exactly 

33. 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?

34. 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

35. Example
Eric’s Personal Information,
unstructured.
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.

36. 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?

37. 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?

38. 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