CS 590 L Distributed Component Architecture Ch 10

CS 590 L Distributed Component Architecture (Ch 10 - 12 of UML) Yugi Lee STB #555 (816) 235 -5932 leeyu@umkc. edu www. sice. umkc. edu/~leeyu 1 CS 590 L - Lecture 8

2 CS 590 L - Lecture 8

Architecture: Component/Connector • Components, with connectors between their ports, provide – a powerful way to abstract larger grained structures of objects – the protocols of interactions between those objects. • Many kinds of architectural descriptions can be made clear and simple using these. – tend to be very symmetrical i. e. they make explicit both the services provided (abstracted into input ports), and the services required (abstracted into output ports). 3 CS 590 L - Lecture 8

Architecture: Component/Connector • Unix configuration of pipes + filters – the streaming/buffering semantics for each connection – working with a lower level protocol – the "pipe" connector to abstract away these details, specified clearly and precisely and only in one place the pipe/filter Architecture Type. filter 4 filter CS 590 L - Lecture 8

Evolution of Component Interactions • Mainframe (host) applications – quite unnatural, not designed for this screen scrapers, host terminal emulators host • O. S. , databases, inter-application communication o. s. services – essential support of “system services” • Unix pipes – effective but limited “connection” model • C++ objects (or Smalltalk, . . . ) – effective, limited scope, early OO mistakes filter m 1() obj • COM, Corba, Java. Beans, … – tackles broader scope and issues – interface-centric, distribution, services, discovery 5 CS 590 L - Lecture 8 filter m 2() obj m 3() obj

Architecture: Motivation of Connector • Composition of heterogeneous components that provides complex functionality and engage in complex interaction [N. Mehta, N. Medvidovic, S. Phadke, Towards a Taxonomy of Software Connectors, Technical Report, CS, USC] • Connector Roles – dependability constraints (performance, safety, security, scalability) – adaptable to changing environment, – concurrency control, transaction and reliability of component interaction 6 CS 590 L - Lecture 8

Architecture: Motivation of Connector • [Perry & Wolf, Shaw & Garlan] – Separate computation (components) from interaction (connectors) – Support for modeling or implementing certain class of connectors (emergence of Internet, distribution) – A first-class status (connectors) [Shaw & Garlan, Medvidovic & Taylor] – Procedure calls are the assembly language of software interconnection: connectors deserve first-class status [Shaw, 93] 7 CS 590 L - Lecture 8

Architecture: Motivation of Connector • Benefits of decoupling communication and interaction dependencies from the component implementation – higher flexibility and increased reusability – explicit configuration of the communication protocols being used – different interconnection topologies between the same set of components and the same connector – adaptability to different architectures and customized environments 8 CS 590 L - Lecture 8

Architecture: What’s Connector? • Mediate interactions (the transfer of control and data) among components – the rules that govern component interaction – specify any auxiliary mechanisms required [Shaw] • Provide services – persistent, invocation, messaging and transactions – facilities components in middleware standard – simplify an architecture and keep the architecture focus on domain-specific information – help their reuse across domains. 9 CS 590 L - Lecture 8

Architecture: Connector • Instances of Connector – Shared variable accesses, table entries, buffers, instructions to a linker, – procedure calls, networking protocols, pipes, event, property, method, replication, pipe, etc. – SQL links between a database and an application, – key determinants of system properties (performance, resource utilization, global rates of flow, scalability, reliability, security, evolvability, etc) 10 CS 590 L - Lecture 8

Architecture: Connector • Architectural Styles [Perry & Wolf, Shaw & Garlan] – define a set of rules that describes or constrains the structure of architectures and the way in which their components interact – allow considerable flexibility in the choice of implementation of the connectors (parameters of variation) • Protocol – – 11 property list (standard or specific attributes) symmetry/asymmetry relationship/role (export/import, provide/request) an associate set of rules or assumptions/constraints CS 590 L - Lecture 8

Architecture: Motivation of Component • A economically and technologically practical way to organize and package an object-oriented system • Developed, marketed, and maintained on a component basis • Support capabilities that are impractical for “small” objects – Interfaces accessed through different programming languages – Components interact transparently across networks – More cost-effective to maintain since they do more than “small” objects, and less than “monolithic” programs • Each component could itself be a candidate “product” • Component partitioning enables parallel development 12 CS 590 L - Lecture 8

Component “Events” e. g. Java Beans • An event is an interesting change you can subscribe to • Events grouped into event channels by Listener interfaces interface Balance. Listener extends java. util. Event. Listener { void overdrawn (Balance. Event); void balance. OK (Balance. Event); } • Bean may offer different event channels Usage Listener Usage event channel Account Bean Balance event channel • Standard convention for registering event listener: void add. Balance. Listener (Balance. Listener f); void remove. Balance. Listener (Balance. Listener f); 13 CS 590 L - Lecture 8 Balance Listener

Component-Based Modeling and Specs Abe’s Auto Rental Membership Program “Framework” Component Libraries Rentals Members customize: rent Cars Generic Models interfaces for customization • Build models, specs, and implementations from generic component libraries by customizing and composing 14 CS 590 L - Lecture 8

“Frameworks” as Components • A large-grain component designed with “plug-points” • Application will “plug” domain objects into plug-points • “Plug-in” based on interface, sub-class, delegation, etc. Shipper ship (shipment, receiver) product shipment plug in product customer (supply return) (vendor) receiver 15 Order Taker order (item, buyer) plug in (service) Customer buyer CS 590 L - Lecture 8 customer

Architecture: Application Components Application Server Sales Manager UI Sale. Item Inventory Manager Product Credit Authorizer Payment DB Server 1 Authorization Frequent Buyer Mgr DB Server 2 Customer • Application components partitioned and interactions designed – Partition based on ease of change, re-use, buy Vs. build, etc. • Original domain types split across components, some partly shared 16 CS 590 L - Lecture 8

Architecture: Infrastructure Components Application Server cross-component transactions Sales Manager Sale. Item Inventory Manager Product Credit Authorizer Payment DB Server 1 Authorization Frequent Buyer Mgr Customer Transaction Server • Infrastructure component added for transaction management – Appropriate application components “linked” to it 17 CS 590 L - Lecture 8 DB Server 2

Component Terminology • • Component: Software chunk that can be “plugged” together with others Connector: A coupling of a particular nature between ports of two components Port: The “plugs” and “sockets” of an individual component Component Architecture: (a) Standard port “connector” types and rules Component Infrastructure: (b) Standard services for components and connectors Component Kit: Components designed to work together with common architecture Packaging: Packaging of a component with associated specs, resources, tests, docs, . . . components connector types interface “ports” infrastructure services 18 CS 590 L - Lecture 8

Components generalize “Connectors” output event Button slider start position pressed start <<physical>> stop reactor input method COM, Java Beans 19 Thermometer value pressed Button property limit in Threshold out in Differentiator out gradient in 1 in 2 OR out in Alarm in Threshold – Events out of a component, or in to a component (triggering a method) – Input properties that are kept in sync with output properties – Workflow “transfers” where an object is transferred – Replication -- where information is copied and kept in sync – Standard objects and method invocation underlie all of the above CS 590 L - Lecture 8

Interfaces lead to Collaboration Design Collaboration 2 Collaboration 1 Passenger Guest Composition of 1+2 Passenger Guest • An object offers a different interface in each role it plays – Related objects talk through related interfaces • Interface-centric design makes us focus on collaborations – A collaboration defines related roles and interactions – Provides excellent basis for composing patterns / architectures 20 CS 590 L - Lecture 8

Collaborations as Architectural Units • A collaboration is an architectural package that contains: – a set of related interacting types – characterized by set of interfaces with behavior specifications Collaboration package patterns. Spell. Check; interface Spell. Checker { void attach ( target: Spell. Checkable); void spell. Check (); } interface Spell. Checkable { Word next. Word (); void replace. Word (replacement: Word); } 21 CS 590 L - Lecture 8

Composing Collaborations Spell. Checker Layout. Management Spell. Checkable Layout. Able Layout. Manager Editor-Structure Spell. Checker E-Core Layout. Manager the two collaborations work together through the Editor Defines effective ways of using and reverse-engineering patterns 22 CS 590 L - Lecture 8

Collaborations as Design Patterns observer-subject proxy-remote interface collaboration object • An object offers a different interface in each role it plays – Related objects talk through related interfaces • Generic collaborations often represent design patterns – Can be defined as sets of interfaces in a Java package – In Catalysis, augment with behavior model 23 CS 590 L - Lecture 8

Composing Collaborations Subject-Observer Subject Proxy-Remote Proxy Remote-Subject subject proxy Sub-Proxy Remote invariants relating two parent collaborations & models • Defines effective ways of using and reverse-engineering patterns • Can use Java packages for modularizing collaborations 24 CS 590 L - Lecture 8

Code-Level Collaboration Composition • We can carry role-structures into the implementation – A role-object for each role played – Design rules for dealing with (split) object-identity issues – Each role-object implements its part of its framework spec – A shared object for the “real” object – Uniform observation or notification mechanism between the two collaboration 25 shared state role objects implemented- (with local state) CS 590 L Lecture 8

Design Styles for Code Components methods properties events • Components can be composed together • Each component should define – Abstract attributes which can be read and set – Services which can be requested from that component – Services required from other connected components – Changes (“events”) that component is capable of notifying • The last two are problems – Traditional object descriptions only focus on services provided 26 CS 590 L - Lecture 8