Software Connectors

What is a Software Connector? 2 What is Connector? – Architectural element that models Interactions among components Rules that govern those interactions Connector offers – Simple interactions Procedure calls Shared variable access – Complex & semantically rich interactions Client-server protocols Database access protocols Asynchronous event multicast Connector provides – Interaction duct(s) – Transfer of control and/or data

Implemented vs. Conceptual Connectors 3 Connectors in software system implementations – Frequently no dedicated code – Frequently no identity – Typically do not correspond to compilation units – Distributed implementation Across multiple modules Across interaction mechanisms

Implemented vs. Conceptual Connectors (cont’d) 4 Connectors in software architectures – First-class entities – Have identity – Describe all system interaction – Entitled to their own specifications & abstractions

Reasons for Treating Connectors Independently 5 Connector  Component – Components provide application-specific functionality – Connectors provide application-independent interaction mechanisms Interaction abstraction and/or parameterization Specification of complex interactions – Binary vs. N-ary – Asymmetric vs. Symmetric – Interaction protocols

Treating Connectors Independently (cont’d) 6 Localization of interaction definition Extra-component system (interaction) information Component independence Component interaction flexibility

Software Connector Roles 7 Locus of interaction among set of components Protocol specification (sometimes implicit) that defines its properties – Types of interfaces it is able to mediate – Assurances about interaction properties – Rules about interaction ordering – Interaction commitments (e.g., performance) Roles – Communication – Coordination – Conversion – Facilitation

Connectors as Communicators 8 Main role associated with connectors Supports – Different communication mechanisms e.g. procedure call, RPC, shared data access, message passing – Constraints on communication structure/direction e.g. pipes – Constraints on quality of service e.g. persistence Separates communication from computation May influence non-functional system characteristics – e.g. performance, scalability, security

Connectors as Coordinators 9 Determine computation control Control delivery of data Separates control from computation Orthogonal to communication, conversion, and facilitation – Elements of control are in communication, conversion and facilitation

Connectors as Converters 10 Enable interaction of independently developed, mismatched components Mismatches based on interaction – Type – Number – Frequency – Order Examples of converters – Adaptors – Wrappers

Connectors as Facilitators 11 Enable interaction of components intended to interoperate – Mediate and streamline interaction Govern access to shared information Ensure proper performance profiles – e.g., load balancing Provide synchronization mechanisms – Critical sections – Monitors

Connector Types 12 Procedure call Data access Event Stream Linkage Distributor Arbitrator Adaptor

An Example of Connectors “Components A and B communicate via a Unix pipe” Pipe – unformatted byte stream Single interactional channel or duct - What does it mean? Unidirectional Data Transfer Cardinality- Single Sender & Single Receiver Low Coupling No Buffering 13

An Example of Connectors (cont’d) Change the nature of data from unformatted byte stream to discrete, typed packets. Event Bus connector Similar properties – loose component coupling, asynchronous communication EBC- on the fly establishment of ducts and single event sender, multiple observers 14

Benefits of First-Class Connectors 15 Separate computation from interaction Minimize component interdependencies Support software evolution – At component-, connector-, & system-level Potential for supporting dynamism Facilitate heterogeneity Become points of distribution Aid system analysis & testing

Framework for Connector Classification Each Connector is identified by a primary service category Common Characteristics – Top of the framework Variations – Lower Layers Service categories, Connector Types, Dimensions (Sub dimension) and values for dimensions Service Category – Broad interaction role Architecturally relevant detailscaptured through dimension Lowest Layer – set of values a dimension can take.

A Framework for Classifying Connectors 17

Procedure Call Connectors 18

Event Connectors 19

Stream Connectors 20

Data Access Connectors 21

Adaptor Connectors 22

Linkage Connectors 23

Distributor Connectors 24

Arbitrator Connectors 25

Connector Types - Summary Procedure Call – Enable the transfer of control and data through various forms of invocation Event - Support the transfer of data and control using an implicit mechanism, where the producer and consumer of an event are not aware of each other’s identity Stream - Support the exchange of a sequence of data between loosely coupled producer and consumer components Data Access - Used to access a data store, such as a SQL database, the file system, or a repository such as the Windows registry Adaptor - Retrofit components with different interfaces so that they can interact Linkage - Bind a name in one module to the implementation provided by another module Distributor - Identify paths between components and route communication along those paths Arbitrator - Provide services that coordinate and facilitate interactions among components. Examples of arbitrators include semaphores, locks, transactions, fault handling connectors with failover, and load balancing connectors

Event Connector Vs Procedure Call Event connector – Virtual connectors are formed between components interested in the same events – Connectors may appear or disappear dynamically depending on the component’s changing interests ProcedureCall–Codewrittentoinvoke the procedure so fixated connectors

Linkage Connector Vs Distributor Connector Linkage – Linkage connectors bind a name in one module to the implementation provided by another module – Examples of linkage connectors include imported names and references to names defined in other source files Distributor connectorsidentifypathsbetween androutecommunicationalong – Distributor components those paths – Provide routing services to other connectors

Discussion 29 Connectorsallowmodelingofarbitrarily complex interactions Connector flexibility aids system evolution – Componentaddition,removal,replacement, reconnection, migration Support for connector interchange is desired – Aids system evolution – May not affect system functionality

Discussion 30 Libraries of OTS connector implementations allow developers to focus on application- specific issues Difficulties – Rigid connectors – Connector “dispersion” in implementations Key issue – Performance vs. flexibility

References Aldrich,Jonathan,VibhaSazawal,Sazawal,CraigCraig Chambers, and David Notkin. "Language support for connector abstractions." In ECOOP 2003–Object-Oriented Programming, pp Springer Berlin Heidelberg, 2003