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 SolutionsInvestigation of Specific Solutions CORBA, JMS, Siena, and other

middleware XML

Definitions

Interoperability The ability for two or more

(independently-developed) (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 CharacterizationArchitectural 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. SemanticSyntactic compatibility only guarantees that data will pass through a connector properlySemantic compatibility is achieved only when components agree on the meaning of the data they exchangeExample: 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

Enumerate the interoperability problems hereAre they essential or accidental?Are they syntactic or semantic?

American electrical plug European electrical outlet

An example of an “essential” power problem

American electrical plugFlintstones Power Source

Achieving Interoperability

ComponentA

ComponentB?

? ?

Given two components and an arbitrary connector

in between, how can we make them interoperate?

Give some examples of components for A and B.

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

MiddlewarePopular 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: CORBACommon Object Request Broker ArchitectureA middleware standard (not implementation) from the Object

Management Group Like the United Nations

of software organizations

Focus: CORBAFrom 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

ComponentA

ObjectB

PublicInterface of

B

How do we make this call (one way only, here)?

Example

ComponentA

ObjectB

PublicInterface of

B

First, we mustturn this interfaceinto something thatis comprehensible in A’s world

Solution: define the interface in a platform-neutralinterface 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);

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?

Example cont.

ComponentA

ObjectB

PublicInterface of

B

IDLCompiler for A-world

IDLCompiler for B-world

Are these the same?

Example cont.

ComponentA

ObjectB

PublicInterface of

B

StubCompiler for A-world

(or maybe…)

B’sStub forA-world

SkeletonCompiler for B-world

(or maybe…)

Skeleton forB-world

Example cont.

ComponentA

ObjectB

PublicInterface of

B

B’sStub forA-world

Skeleton forB-world

Via proprietaryprotocol, probably TCP-basedif a network is involved, maybethrough some more efficientOS-based mechanism likenamed-pipes if the call is allbeing made on one machine.

NB: B is oftencalled the “trueobject”

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:

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 DiscussionWhat kinds of heterogeneity/interoperability issues are solved by CORBAWhich 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 dataBlatantly hierarchical, but works well in the context of a running documentSupported by meta-languages that define allowable constructs in the hierarchy

Example

Eric’s Personal Information,unstructured.

Eric M. Dashofy, b. 1977 tofather Mark and motherSusan, currently acomputer scientist at UCIrvine, hobbies includeplaying guitar and makingStar Wars fan-films.

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 worsethan 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 DiscussionWhat 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 DirectionsInteroperability 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