Interoperability and Software Architecture

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

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)

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

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]

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 …