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

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

11. Shaw’s Taxonomy

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 PublicInterface of B Component A Object B How do we make this call (one way only, here)?

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

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. PublicInterface of B Component A Object B IDL Compiler for A-world IDL Compiler for B-world Are these the same?

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

27. Example cont. PublicInterface of B Component A Object B Skeleton for B-world NB: B is oftencalled the “trueobject” B’s Stub forA-world Via proprietaryprotocol, probably TCP-basedif a network is involved, maybe through some more efficientOS-based mechanism likenamed-pipes if the call is allbeing made on one machine.

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

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 RPC with Services - DCE RPC - “Q” (U. Colorado) - Corba w/C binding Oneway Messages (low multicast) - JMS - MSMQ - MQ Series - SOAP (at core) - CORBA oneway calls 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 M. Dashofy, b. 1977 tofather Mark and motherSusan, currently acomputer scientist at UCIrvine, hobbies includeplaying guitar and making Star Wars fan-films. Eric’s Personal Information,unstructured.

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

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