Software ConnectorsWhat is a Software Connector?Where are Connectors in Software Systems?Implemented vs. Conceptual ConnectorsImplemented vs. Conceptual Connectors (cont’d)Reasons for Treating Connectors IndependentlyTreating Connectors Independently (cont’d)Benefits of First-Class ConnectorsAn Example of Explicit ConnectorsAn Example of Explicit Connectors (cont’d)Software Connector RolesConnectors as CommunicatorsConnectors as CoordinatorsConnectors as ConvertersConnectors as FacilitatorsConnector TypesA Framework for Classifying ConnectorsProcedure Call ConnectorsEvent ConnectorsData Access ConnectorsLinkage ConnectorsStream ConnectorsArbitrator ConnectorsAdaptor ConnectorsDistributor ConnectorsDiscussionSlide 27Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.Software ConnectorsSoftware ArchitectureLecture 72Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureWhat is a Software Connector?Architectural element that modelsInteractions among componentsRules that govern those interactionsSimple interactionsProcedure callsShared variable accessComplex & semantically rich interactionsClient-server protocolsDatabase access protocolsAsynchronous event multicastEach connector providesInteraction duct(s)Transfer of control and/or data3Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureWhere are Connectors in Software Systems?Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.4Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureImplemented vs. Conceptual Connectors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 mechanisms5Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureImplemented vs. Conceptual Connectors (cont’d)Connectors in software architecturesFirst-class entitiesHave identityDescribe all system interactionEntitled to their own specifications & abstractions6Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureReasons for Treating Connectors Independently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 protocols7Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureTreating Connectors Independently (cont’d)Localization of interaction definitionExtra-component system (interaction) informationComponent independenceComponent interaction flexibility8Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureBenefits of First-Class Connectors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 & testing9Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureAn Example of Explicit ConnectorsSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.10Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureAn Example of Explicit Connectors (cont’d)??Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.11Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureSoftware Connector Roles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Facilitation12Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureConnectors as Communicators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, security13Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureConnectors as Coordinators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 facilitation14Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureConnectors as ConvertersEnable interaction of independently developed, mismatched componentsMismatches based on interactionTypeNumberFrequencyOrderExamples of convertersAdaptorsWrappers15Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureConnectors as Facilitators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Monitors16Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureConnector TypesProcedure callData accessEventStreamLinkageDistributorArbitratorAdaptor17Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureA Framework for Classifying ConnectorsSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.18Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureProcedure Call