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 plugEuropean 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

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 3 rd 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 Eric M Dashofy 1977 Mark Susan Computer Scientist UC Irvine 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” 2 nd Generation Middleware Which is largely geared toward interoperability between 1 st generation middleware packages Enterprise Application Integration (EAI) A whole market driven by people with experience making systems interoperate