CONNECTORS

1. CONNECTORS Ryan McAlister

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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. Connectors In Action

10. 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

11. 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

12. Connector Foundations Framework Explantiation 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

13. 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

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

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

16. 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

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

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

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

20. Selecting Appropriate Connectors • 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.

21. 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

22. Detecting Mismatches

23. Detecting Mismatches • Four rules for combining connector dimensions • Requires • Cautions • Restricts • Prohibits

24. 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

25. 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.

26. 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

27. 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

28. 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.