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

2. Bonn // 6.11.03NEFIS - Arch & Interop2 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)

3. Bonn // 6.11.03NEFIS - Arch & Interop3 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?

4. Bonn // 6.11.03NEFIS - Arch & Interop4 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

5. Bonn // 6.11.03NEFIS - Arch & Interop5 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…

6. Bonn // 6.11.03NEFIS - Arch & Interop6 Brief History: Distributed Systems IRBrowse …. Collaborative Dist processing…. Range Reach Dept Intra-Enterprise Anyone, anywhere … Inter-Enterprise Open Systems Which…???

7. Bonn // 6.11.03NEFIS - Arch & Interop7 (I) An Introduction to Software Architecture Moh Ibrahim, Alex Fedorec, Keith Rennolls University of Greenwich, London

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

9. Bonn // 6.11.03NEFIS - Arch & Interop9 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

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

11. Bonn // 6.11.03NEFIS - Arch & Interop11 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.

12. Bonn // 6.11.03NEFIS - Arch & Interop12 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.

13. Bonn // 6.11.03NEFIS - Arch & Interop13 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

14. Bonn // 6.11.03NEFIS - Arch & Interop14 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

15. Bonn // 6.11.03NEFIS - Arch & Interop15 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

16. Bonn // 6.11.03NEFIS - Arch & Interop16 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

17. Bonn // 6.11.03NEFIS - Arch & Interop17 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

18. Bonn // 6.11.03NEFIS - Arch & Interop18 Common Architecture Styles Virtual machines –Interpreters –Rule-based systems Data-centered systems – Databases – Hypertext systems – Blackboards Process-control paradigms

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

20. Bonn // 6.11.03NEFIS - Arch & Interop20 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??

21. Bonn // 6.11.03NEFIS - Arch & Interop21 Definitions Interoperability –The ability for two or more (independently-developed) (software) components to interact meaningfully Communicate meaningfully Exchange data or services

22. Bonn // 6.11.03NEFIS - Arch & Interop22 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

23. Bonn // 6.11.03NEFIS - Arch & Interop23 Why is Interoperability Important? One (perhaps the) dominant challenge in software engineering –We cant live without it Large systems are no longer built from first principles (nor can they be) - e.g. NEFIS, EFIS –We shouldnt live without it Component reuse has the potential for enormous cost savings –Cited by Brooks as a potential silver bullet

24. Bonn // 6.11.03NEFIS - Arch & Interop24 Is Interoperability the Problem? Interoperability is not a problem, its a software quality. The problem in achieving this quality is… Heterogeneity! Components are: –written in different programming languages –running on different hardware platforms

25. Bonn // 6.11.03NEFIS - Arch & Interop25 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

26. Bonn // 6.11.03NEFIS - Arch & Interop26 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 theyre 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)

27. Bonn // 6.11.03NEFIS - Arch & Interop27 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?

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

29. Bonn // 6.11.03NEFIS - Arch & Interop29 An example of an essential power problem American electrical plug Flintstones Power Source

30. Bonn // 6.11.03NEFIS - Arch & Interop30 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.

31. Bonn // 6.11.03NEFIS - Arch & Interop31 Shaws Taxonomy

32. Bonn // 6.11.03NEFIS - Arch & Interop32 Shaws Taxonomy, In Detail/1 Change As form to Bs form –Usually involves a complete rewrite –Expensive but do-able Publish an abstraction of As form –APIs (open or standardized) –Projections or Views (common in databases)

33. Bonn // 6.11.03NEFIS - Arch & Interop33 Shaws 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

34. Bonn // 6.11.03NEFIS - Arch & Interop34 Shaws 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 3 rd party –Classic example: word processors, Alchemy Mindworks Graphics Workshop

35. Bonn // 6.11.03NEFIS - Arch & Interop35 Shaws 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

36. Bonn // 6.11.03NEFIS - Arch & Interop36 Shaws 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

37. Bonn // 6.11.03NEFIS - Arch & Interop37 The (??)Solution (as offered by industry) Middleware –Buzz: Industry will build you a connector that makes interoperability magically appear –Right? Hint: Not Exactly

38. Bonn // 6.11.03NEFIS - Arch & Interop38 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?)

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

40. Bonn // 6.11.03NEFIS - Arch & Interop40 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?

41. Bonn // 6.11.03NEFIS - Arch & Interop41 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.

42. Bonn // 6.11.03NEFIS - Arch & Interop42 Example Component A Object B Public Interface of B How do we make this call (one way only, here)?

43. Bonn // 6.11.03NEFIS - Arch & Interop43 Example Component A Object B Public Interface of B First, we must turn this interface into something that is comprehensible in As world Solution: define the interface in a platform-neutral interface definition language (IDL) Why might this be harder than it looks?

44. Bonn // 6.11.03NEFIS - Arch & Interop44 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?

45. Bonn // 6.11.03NEFIS - Arch & Interop45 Example cont. Component A Object B Public Interface of B IDL Compiler for A-world IDL Compiler for B-world Are these the same?

46. Bonn // 6.11.03NEFIS - Arch & Interop46 Example cont. Component A Object B Public Interface of B Stub Compiler for A-world (or maybe…) Bs Stub for A-world Skeleton Compiler for B-world (or maybe…) Skeleton for B-world

47. Bonn // 6.11.03NEFIS - Arch & Interop47 Example cont. Component A Object B Public Interface of B Bs 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

48. Bonn // 6.11.03NEFIS - Arch & Interop48 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:

49. Bonn // 6.11.03NEFIS - Arch & Interop49 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 IIOPthe Internet Inter-Orb Protocol

50. Bonn // 6.11.03NEFIS - Arch & Interop50 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 Shaws taxonomy?

51. Bonn // 6.11.03NEFIS - Arch & Interop51 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)

52. Bonn // 6.11.03NEFIS - Arch & Interop52 Focus: XML XML: Extensible Markup Language –Buzz: Finally, a standard for encoding data! XML will solve your interoperability problems! –Right? Hint: Not exactly

53. Bonn // 6.11.03NEFIS - Arch & Interop53 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?

54. Bonn // 6.11.03NEFIS - Arch & Interop54 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

55. Bonn // 6.11.03NEFIS - Arch & Interop55 Example Erics 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.

56. Bonn // 6.11.03NEFIS - Arch & Interop56 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 couldnt 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?

57. Bonn // 6.11.03NEFIS - Arch & Interop57 Open Qs: 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 Shaws taxonomy?

58. Bonn // 6.11.03NEFIS - Arch & Interop58 So, onto NEFIS Relevance to NEFIS? Are they …. (A & I) – how, where, …? Yes – we suggest Can we build a future-proof, technology- independent, architecture-centric, model- driven architecture? We do not want to throw the baby with the bath water!! Leverage legacy Yes – –but perhaps not 100% - 80/20 will do

59. Bonn // 6.11.03NEFIS - Arch & Interop59 So, onto NEFIS Relevance to NEFIS? Are they …. (A & I) relevant – what, how, where, …? Yes – we suggest they are … Can we build a future-proof, technology-independent, architecture-centric, model-driven NEFIS/EFIS++?

60. Bonn // 6.11.03NEFIS - Arch & Interop60 Future Directions Interoperability over the Web –SOAP XML for control instead of data Solves, introduces same issues as XML –Web Services –The Semantic Web

61. Bonn // 6.11.03NEFIS - Arch & Interop61 Future Directions 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

62. Bonn // 6.11.03NEFIS - Arch & Interop62 Conclusions /1 NEFIS / EFIS ++ are ISs All ISs have architectures – by default, or by design Architecture need to be flexible, robust, resilient, extensible, …technology-proof, … to preserve legacy and enable progress / integration of future advance

63. Bonn // 6.11.03NEFIS - Arch & Interop63 Conclusions /2 100% Perfection is almost impossible 80/20 rule or better Achievable – but need planning & management & designed into NEFIS early; not bolted onto it at the middle/end

64. Bonn // 6.11.03NEFIS - Arch & Interop64 Conclusions /3 Many levels of interoperability, not just access, not just data – semantic interop not just syntax Design to an interface – not to an implementation Plan for change / preserve legacy / allow for future Hard work – but doable, the earlier in a product life-cycle the better Standards are CSF More study/research needed / team-work & collaboration &&&& more interoperability between partners !!

65. Bonn // 6.11.03NEFIS - Arch & Interop65 Thank you