TR: Part 2 On Architecture & Interoperability

1. TR: Part 2On Architecture& Interoperability Relevance to NEFIS: is there a need? Moh Ibrahim, Keith Rennolls & Alex Fedorec University of Greenwich NEFIS - Arch & Interop

2. Outline (plan?) • Brief History (Peter G. W. Keen – Range & Reach) • Architecture – superstructure, infrastructure • Quality of architecture - ODP • Kinds of architecture – s/w, h/w, web-services, …appl, b usiness, data, information, technology, • OR taxonomise as: Operation, development, execution • Enterprise, Information, etc (ODP) NEFIS - Arch & Interop

3. Outline (plan?) • Open systems: Interoperability & portability • Definitions of each • Portability – kinds of • Levels of interoperability • Examples from Andreas Schuck & Peter Holmgren talk in Quebec, other examples – from grids/e-science • Web services & Grids? NEFIS - Arch & Interop

4. Postulates (Axioms/assumptions) • Change & changeability - the norm • Diversity – everywhere • One problem : zero, one or many solutions • No one solution is perfect … For all seasons/situations • Perfection? 100% - impossible? • Heterogeneity galore NEFIS - Arch & Interop

5. Postulates (Axioms/assumptions) /cont • Functions – (more) stable than tools, techniques & technology (innovations) • Resources (EU,…) are scarce, limited • Hard but possible (?) to achieve a quality product, within budget, and on-time (e.g. Scottish parliament) • Add you own favourite… NEFIS - Arch & Interop

6. Reach Open Systems Anyone, anywhere … Which…??? Inter-Enterprise Intra-Enterprise Range Dept Brief History: Distributed Systems …. Collaborative Dist processing…. Browse IR NEFIS - Arch & Interop

7. (I) An Introduction to ‘Software’ Architecture Moh Ibrahim, Alex Fedorec, Keith Rennolls University of Greenwich, London NEFIS - Arch & Interop

8. Contents (I) • What is Architecture? • Current Practice in Software Architecture • Why Software Architecture? • Common Architecture Styles http://www.utdallas.edu/~chung/SA/contents.html NEFIS - Arch & Interop

9. What is Architecture? • Architecture: the underlying structure of things • An example of civil engineering • Customer engineer gets customer requirements • functional units: 3 bedrooms, 2+1/2 bathrooms, 1 living & 1 dining rooms, 2-car garage, kitchen, backyard, gardens • other considerations: cost, esthetics, workmanship, neighborhood, maintainability, economics NEFIS - Arch & Interop

10. What is Architecture? • Architect starts thinking about architectural styles • architectural styles: Victorian, Duplex, Condominium, Townhouse, Catheral, Pyramidal, floor plans & elevations for functional units NEFIS - Arch & Interop

11. What is Architecture? • Designers/Contractors think about detailed design considerations • electrical wiring, plumbing, heating, air-conditioning, carpeting, etc. • Sub-contractors/Construction Workers: • electricians, plumbers, CH installers, carpenters, locksmith,brick layers, bathtub technicians, etc. NEFIS - Arch & Interop

12. Current Practice in Software Architecture • Architecture Descriptions: • Many systems are based on the client-server model and use remote procedure calls  both locally and remotely to provide communication among client applications and servers. • use a distributed, object-oriented approach to managing information. NEFIS - Arch & Interop

13. Current Practice in Software Architecture • Observations: • software architectures are indeed used, very often but without even knowing it • A SA carries some, and more often than not a lot of, information • no explicit description of the structure NEFIS - Arch & Interop

14. Software Architecture Description • elements (components/parts): • from which systems are built,e.g., process, data, object, agent • interactions (connections/connectors/glues/relationships): • between the elements,e.g., PCs, RPCs, MOMs, events •  patterns: • describe layout of elements and interactions, guiding their composition, e.g., # of elements, # of connectors, order, topology, directionality NEFIS - Arch & Interop

15. Software Architecture Description • constraints: •  on the patterns (i.e., on components, connectors, layout),e.g., temporal, cardinality, concurrency, (a)synchronous, etc. •  styles: •  abstraction of architectural components from various specific architectures, (Sometimes interchangeably used with patterns,e.g., Unix OS, OSI protocol layer, Onion ring IS structure -> layering •  rationale: • describe why the particular architecture is chosen NEFIS - Arch & Interop

16. Why Software Architecture? • abstract solution to handle/conquer complexity (problem solving strategy) • supports reuse • facilitates (integration) testing • parallel development • system evolvability • … many other conceptual reasons NEFIS - Arch & Interop

17. Common Architecture Styles • Dataflow systems   • Batch sequential • Pipe & Filter • Call-and-return systems • Main program & subroutine • OO systems • Hierarchical layers •  Independent components • Communicating processes • Event systems NEFIS - Arch & Interop

18. Common Architecture Styles • Virtual machines • Interpreters • Rule-based systems • Data-centered systems • Databases • Hypertext systems • Blackboards • Process-control paradigms NEFIS - Arch & Interop

19. Interoperability *With special thanks to Eric M. Dashofy from whom some of this material is blatantly stolen. NEFIS - Arch & Interop

20. Contents (II) • Characterization of the Problem • With an attempt to taxonomize • Taxonomy of Solutions • Investigation of Specific Solutions • CORBA, J2EE, DCOM, .Net, and other middleware • UML, xUML, XML, … • Web services ?? • Grid Services?? NEFIS - Arch & Interop

21. Definitions • Interoperability • The ability for two or more (independently-developed) (software) components to interact meaningfully • Communicate meaningfully • Exchange data or services NEFIS - Arch & Interop

22. Why is Interoperability Important? • We need it to maintain the living we do now • We are burdened with un-rebuildable legacy systems • cf. SABRE, Air Traffic Control • It is induced by the state of computing now • Increasing connectivity of computers through the Internet NEFIS - Arch & Interop

23. 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) - e.g. NEFIS, EFIS • We shouldn’t live without it • Component reuse has the potential for enormous cost savings • Cited by Brooks as a potential silver bullet NEFIS - Arch & Interop

24. Is Interoperability the Problem? • Interoperability is not a problem, it’s a software quality. • The problem in achieving this quality is… • Heterogeneity! Components are: • written in different programming languages • running on different hardware platforms NEFIS - Arch & Interop

25. Is Interoperability the Problem? Heterogeneity! Components are /cont: • running on different operating systems • using different data representations • using different control models • implementing different semantics or semantic interpretations • implementing duplicate functionality • implementing conflicting functionality NEFIS - Arch & Interop

26. 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) NEFIS - Arch & Interop

27. 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? NEFIS - Arch & Interop

28. Classic Example Enumerate the interoperability problems here Are they essential or accidental? Are they syntactic or semantic? European electrical outlet American electrical plug NEFIS - Arch & Interop

29. An example of an “essential” power problem American electrical plug Flintstones Power Source NEFIS - Arch & Interop

30. Achieving Interoperability Component A Component B ? ? ? Give some examples of components for A and B. • Given two components and • an arbitrary connector in between, • how can we make them interoperate? NEFIS - Arch & Interop

31. Shaw’s Taxonomy NEFIS - Arch & Interop

32. Shaw’s Taxonomy, In Detail/1 • 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) NEFIS - Arch & Interop

33. Shaw’s Taxonomy, In Detail/2 • Transform on the fly • Big-endian to little-endian translations in the connector • Use an architectural style • Negotiate a common form • Requires that one or both components support multiple forms • Classic example is modem protocol negotiation NEFIS - Arch & Interop

34. Shaw’s Taxonomy, In Detail/3 • 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 NEFIS - Arch & Interop

35. Shaw’s Taxonomy, In Detail/4 • 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, SABRE) • Piece of code that translates APIs NEFIS - Arch & Interop

36. Shaw’s Taxonomy, In Detail /5 • 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 NEFIS - Arch & Interop

37. The (??)“Solution” (as offered by industry) • Middleware • Buzz: Industry will build you a connector that makes interoperability magically appear • Right? • Hint: Not Exactly  NEFIS - Arch & Interop

38. 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?) NEFIS - Arch & Interop

39. Focus: CORBA • Common Object Request Broker architecture • A middleware standard • (not implementation) • from the Object Management Group • Like the United Nations of software organizations NEFIS - Arch & Interop

40. 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? NEFIS - Arch & Interop

41. 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. NEFIS - Arch & Interop

42. Example Object B Component A PublicInterface of B How do we make this call (one way only, here)? NEFIS - Arch & Interop

43. 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? NEFIS - Arch & Interop

44. 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? NEFIS - Arch & Interop

45. Example cont. PublicInterface of B Component A Object B IDL Compiler for B-world IDL Compiler for A-world Are these the same? NEFIS - Arch & Interop

46. 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 NEFIS - Arch & Interop

47. Example cont. PublicInterface of B Component A Object B Skeleton for B-world NB: B is oftencalled the “trueobject” 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. B’s Stub forA-world NEFIS - Arch & Interop

48. 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); NEFIS - Arch & Interop

49. 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 NEFIS - Arch & Interop

50. 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? NEFIS - Arch & Interop