Ryan McAlister CONNECTORS

Introduction Integration and interaction As important as developing functionality More challenging decisions Transfer control and data Can also provide services Persistence Invocation Messaging Transactions

Introduction Common misconception Just calls between two components Using large off-the-shelf components Connectors are used to communicate Wide range of connectors to use Service request to named recipients Broadcast to anyone listening Suspend current processing Allow component to continue processing

Introduction Different roles connectors play Different connector types available Roles each one can fulfill Variation points for each connector type Hints and guidelines about connector’s Applicablity Strengths Drawbacks

Connectors In Action Application independent elements How without the what Abstraction and separation of concerns New terminology showing up Pipe = type of connector Filter = component

Connectors In Action High level view Components A and B communicate via a Unix pipe Doesn’t give us all the properties of the pipe Pipe allows interaction of unformatted streams of data Single sender single receiver A’s task is to hand data to pipe Actual recipient is unimportant Send only once

Connectors In Action Change to where B can talk back to A Acknowledge data was received Add a pipe from B to A Keep trying until B receives the data Add data buffering to pipe Adding another component Even more pipes Causes substantial system downtime Not the most effective solution

Connectors In Action Change from unformatted byte stream to discrete, typed packets Pipes will not work Use an event bus connector Similar properties Loose component coupling Asynchronous communication Data buffering Differences Event bus is better suited for system adaptation

Connectors In Action

Connector Foundations Building blocks of connectors Managing the flow of control Changing the processor program counter Managing the flow of data Performing memory access Channels or ducts Link interacting components Ducts don’t provide additional interaction services Simple connectors just form ducts between components Others augment ducts

Connector Foundations Simple connectors Implemented in programming languages One type of interaction service Composite connectors Several connectors and possibly components Provided as libraries and frameworks Combine many kinds of interactions

Connector Foundations FrameworkExplantiation Category Broad interaction role Type How interaction services are realized Dimensions Architecturally relevant details Values Set of values dimensions can take Species Particular connector instance

Connector Roles Four general classes of services Communication Coordination Conversion Facilitation Connector will provide one or more of these services Category level of Figure 5-3

Connector Roles - Communcation Communication services Transmission of data among components Examples Pass messages Exchange data Communicate results

Connector Roles - Coordination Coordination Services Supports transfer of control among components Interact by passing the thread of execution Examples Function calls Method invocations

Connector Roles - Conversion Conversion Services Transform the interaction Takes information from one and formats it to where the other can use it Fixes mismatches caused by incompatible assumptions Type, number, frequency and order of interactions with other components Allow components that haven't been tailored for each other conduct interactions Examples Conversion of data formats Wrappers for legacy components

Connector Roles - Facilitation Facilitation services Mediate and streamline component interaction Reduces interdependences among interaction components Examples Load balancing Scheduling services Concurrency control

Selecting Appropriate Connectors Perform these steps 1. Select the specific set of interacting components Different sets can have different interaction needs Focus solely on the components needed for connector 2. Determine the interaction services needed Identify the precise characteristics of the components interaction Study the components architectural description

Selecting Appropriate Connectors 3. Determine 8 connector types that will provide services needed Based on identified interaction services 4. Evaluate each connector type Study these connectors dimensions, subdimensions, and values Eliminate any types that would be deemed suboptimal

Selecting Appropriate Connectors 5. For the remaining connector types Set the values for the necessary dimensions and subdimensions Identify the best or most natural connectors Perform a trade-off analysis Possibly choosing a composite connector.

Selecting Appropriate Connectors Using values of dimensions from different connector types leads to a composite connector species Creating unprecedented composite connectors is not easy Requires deep understanding of the connectors’ complementary, orthogonal, and incompatible characteristics Could become misguided, suboptimal or completely ineffective

Detecting Mismatches

Four rules for combining connector dimensions Requires Cautions Restricts Prohibits

Detecting Mismatches - Requires Requires states that the choice of one dimension in one connector species mandates that another dimension be selected in another connector species. For example if a distributor and an adaptor connector are composed Distributor’s delivery requires that the adaptor support presentation conversion Requires is a chaining rule and is used as a starting point. An event connector the require delivery semantics also needs a notification dimension, which in turn requires cardinality, synchronicity and mode. Mandatory dimensions are bold, optional dimensions are not

Detecting Mismatches - Cautions Cautions rule indicates that certain combinations of values for two connector dimensions that are required to be used in tandem, while valid, may result in an unstable or unreliable connector. For exam ple, a component being invoked implicitly should not have multiple entry points since an implicit invocation mechanism cannot choose among the entry points.

Detecting Mismatches – Restricts Restricts rule indicates that the two dimensions are not require to be used together at all times, and that there are certain combinations of their values that are invalid. For example, thread –specific data access cannot use heavy- weight concurrency

Detecting Mismatches - Prohibits Prohibits rule is used to exclude any combination of two dimensions from being used and indicates total incompatibility of the dimensions. For example, stream delivery cannot be built on transactional atomicity Relatively few instances of prohibits

Detecting Mismatches We’ve only discussed binary combinations of connector dimension, but the compatibility relations between dimensions are transitive. We could apply the rules to determine n-ary compatibility between dimensions.