ICS 221 Winter 2001 Interoperability & Middleware Interoperability ! The ability of independently-developed Interoperability & Middleware components to interact and cooperate with each other ! The ability of components to exchange data and services David S. Rosenblum ! For example … ICS 221 Winter 2001 American electrical plug European electrical outlet Why Is Interoperability Interoperability and Important? Software Architecture ! Interoperability is becoming a dominant (if not the dominant) challenge for software AA ??BB engineering ! Component-based software engineering ! Connectors ! Increased levels of software reuse ! What kind of connector is needed to allow A to ! Exploiting legacy applications interoperate with B? ! The World Wide Web ! What are its properties? ! Distributed software engineering ! Engineering of distributed software ! Distributed engineering of software The connector must resolve ! Engineering of software for automated distribution and architectural mismatch between A & B deployment Architectural Mismatch Assumptions Leading to (Garlan, Allen, Ockerbloom 1995) Architectural Mismatch (I) ! Architectural mismatch refers to a ! Assumptions about the nature of the mismatch between assumptions made components by different components about the ! substrate on which component is built structure of the system and the nature ! control model ! data model of the environment in which they ! Assumptions about the nature of the operate connectors ! protocols ! data model © 2001 David S. Rosenblum 1 ICS 221 Winter 2001 Interoperability & Middleware Assumptions Leading to Syntactic and Semantic Architectural Mismatch (II) Interoperability ! Assumptions about the global configuration ! Syntactic compatibility only guarantees that ! topology data will pass through a connector properly ! presence of certain components or connectors ! Semantic compatibility is achieved only when components agree on the meaning of the ! absence of certain components or connectors data they exchange ! Assumptions about the system construction ! Example: American & European electricity process ! Example: UNIX pipes ! order in which elements are instantiated ! Syntactic compatibility established by making all ! order in which elements are combined data ASCII ! Semantic compatibility is not universal ! Line-oriented data? Field-oriented lines? Field separators? Approaches to Achieving Interoperability (Shaw) Approaches 1 & 2 1. Change A’s form to B’s form ! Complete rewrite of A or B ! Use standard architecture-specific frameworks ! Component & middleware standards (OLE, ActiveX, COM, DCOM, CORBA, JavaBeans, OpenDoc) ! Client/server builders (e.g., Powerbuilder) ! Class frameworks (MFC) ! UNIX pipes 2. Publish abstraction of A’s form ! Uniform distribution format ! Adobe Acrobat, MIME, Rich Text Format (RTF) ! Open interfaces ! Introspection/reflection ! Views and projections ! This is commonly found in databases form = representation, communication, packaging, semantics Approach 3 Approaches 4 & 5 3. Transform on the fly 4. Negotiate common form ! Data filters ! Modem protocol negotiation ! Convert big-endian to little-endian within communication protocol ! Mediators 5. Make B multilingual ! Encapsulate connection policies in separate integration components (Sullivan and Notkin) ! Parts capable of interacting in different forms ! Provide agents that synthesize information across ! Cross-platform parts heterogeneous data sources (Wiederhold) ! “Fat binaries” ! Scripts and other externally-imposed controls ! Portable UNIX code ! Event-based integration (SoftBench, ToolTalk, Castanet) ! Scripting languages: Tcl, Perl, Javascript ! Multimedia browsers (Mosaic, IE, Netscape) © 2001 David S. Rosenblum 2 ICS 221 Winter 2001 Interoperability & Middleware Approach 6 Approach 7 6. Provide import/export converters 7. Introduce intermediate form ! Standalone conversion tools ! Exchange representations ! Graphic format converters (GIF/JPG/PS/PBM/PCX/TIFF) ! Interface description language (IDL) ! Incoming/outgoing converters ! Standard distribution forms ! Conversion plug-ins (MS Word/WordPerfect, MS Powerpoint/Harvard Graphics) ! RTF, PDF, HTML, external data representation ! Procedure call conversions, Ada “pragma interface” ! Marshaling/unmarshaling of data ! Object serialization/deserialization Approaches 8 & 9 Approach 10 8. Use wrapper 10. Separate B’s essence from its ! Wrappers and filters packaging ! Adapters ! ! CORBA Basic Object Adapter (BOA) Separate decisions about internal ! Adapters and adapter classes in Java and JavaBeans functionality from decisions about ! Web browsers “packaging” or interaction style with rest ! Emulation of system ! WinTel emulators for Mac, SunOS ! Both these decisions are currently made by ! X Windows emulators for WinTel component provider 9. Parallel consistent versions ! Both these decisions must be currently ! Maintain two synchronized versions understood by system integrator ! Must constrain both A & B to match assumptions Example of Separating Distributed Object Technology Packaging from Essence and Middleware ! Component provider provides essence ! An layer of software that resides between ! compute the 200-day moving average of a stock applications and the network in order to price facilitate interoperability of distributed application components ! System integrator provides packaging ! An important enabling technology for ! synchronous procedural invocation interoperability in distributed software ! and/or asynchronous event-based update systems ! and/or ActiveX control ! Marriage of client/server technology with ! and/or CORBA IDL-based stub/skeleton interface object-oriented design and analysis ! … ! The “objects” can be anything from data structures to million-line legacy systems © 2001 David S. Rosenblum 3 ICS 221 Winter 2001 Interoperability & Middleware Middleware and Architecture Current Technology (I) ! CORBA ! Reconciling architectural models with ! COM+/DCOM and their ancestors component interoperability standards and standard design notations ! OpenDoc ! Explicit connectors ! SOM ! Architectural style ! ODP ! Research project: Architectural modeling ! Enterprise JavaBeans in UML ! MOM/Event Messaging Middleware ! Research project: ARABICA and ROBUSTA ! Publish/Subscribe Middleware beanboxes for JavaBeans Middleware and Architecture Middleware-Induced Styles (II) (Di Nitto & Rosenblum 1999) ! Reconciling architectural models with ! The choice of a specific middleware can middleware infrastructures have an impact on the architecture of ! Software engineering principle encourages the software system architects/designers to defer implementation decisions ! and vice versa ! But many design decisions constrain the ! An intuitive example choice of implementation technologies ! A three-tier client/server architecture ! Research project: Architectural support for implemented on top of an event-based middleware-induced styles middleware... Modeling Middleware-Induced Styles in ADLs Findings ! Focus of Paper ! We could not find a consensus on the semantics provided for ADLs ! Language constructs for defining styles ! None of the languages we studied suits our ! Language constructs for creating architectures starting from styles requirements ! Deficiencies in languages’ expressive power ! Why? Most ADL research has ignored ! Issues of implementation conformance ! Restrictions in the semantics ! Mapping to middleware technologies ! An exception is [Dashofy, Medvidovic, Taylor 99] © 2001 David S. Rosenblum 4 ICS 221 Winter 2001 Interoperability & Middleware Interoperability at Implications of Internet Scale Internet Scale on Event Notification ! Huge numbers of hosts and users ! Event interaction becomes too burdensome ! Vast numbers of events for applications to manage on their own ! Heterogeneity ! Increased importance of ! Thus, a separate event notification service is ! Network latency required ! Autonomy ! Resource accounting ! But, event technologies originally designed ! Security for LANs don’t scale ! Mobility SIENA SIENA Event Notification (Carzaniga, Rosenblum, Wolf 2000) Infrastructure Subscribe Interested Interested Interested Notify Interested PartyParty PartyParty Unsubscribe Advertise ObjectObject ofof ! Provides ObjectObject ofof InterestInterest ! Storage of advertisements Publish Interest Interest ! Storage of subscriptions ! Efficient delivery of notifications Unadvertise ! Research challenge: what is an appropriate architecture for this infrastructure? Architectural Advantages of Event-Based Interoperability ! Loose coupling between components ! Publishers need not know identity/location of subscribers ! Subscribers need not know identity/location of publishers ! Scalability ! Load on publishers and subscribers is constant as number of publishers and subscribers grows ! But the load on the pub/sub infrastructure grows … © 2001 David S. Rosenblum 5.