Facilitating Busines Interoperability from the Semantic Web
Interoperability
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
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.
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?
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
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