CSCE 5013 – Software Architecture Spring 2011
Chapter 5: Connectors
Introduction
· Designing and implementing large systems are hard.
· Software components integrating and designing proper interaction between them are very important.
· Software connectors perform transfer of control and data among components.
· Connectors can provide services as well.
· Recognizing connectors’ services helps to keep the components focus on domain-specific concerns, and helps to reuse them across applications and domains.
· Connectors help engineers to compose heterogeneous functionality.
· Connectors are not restricted to only functions calls.
· Software architect’s must:
o Understand the component interaction needs
o Identify the relevant attributes of the interaction
o Select the candidate connectors
o Asses any trade-offs with any connector
o Analyze the key properties of the resulting component-connector assemblies
5.1 Connectors in action: a motivating example
· Connectors are the most part application-independent architectural elements.
· Connectors support abstraction and separation of concerns.
· Different views of software connectors are useful for different tasks; however, more detailed lower-level view is needed to understand all the properties of the connectors.
5.2 Connectors foundations
· Flow of control is changing the processor program counter.
· Flow of data is performing memory access.
· Every connector maintains one or more channels called ducts.
· Ducts are used to link the interacting components and support the flow of data and control between them.
· Very Simple connectors form ducts between components, while complicated connectors use ducts with some combination of data and control flow to provide richer interaction.
· More complicated connectors can include computations and information storage such as load balancing connectors.
· Simple connectors are typically implemented in programming languages, while composite connectors use composition of several connectors.
· Connectors’ classification framework consists of: service categories, connector types, dimensions, and the value of the dimensions.
5.3 Connector roles
· Communication
o Provide communications services by transmitting data among components.
o Ex. results of computations communications.
· Coordination
o Provide coordination services by transferring control among components.
o Ex. Function calls.
· Conversion
o Allow components that have not been specifically tailored for each other to establish and conduct interaction.
o Ex. Conversions of data formats.
· Facilitation
o Mediate and streamline component interaction.
o Ex. Load balancing.
5.4 connector types and their variation dimensions
The four interaction categories of connectors listed (communication, coordination, conversion, and facilitation) is good, but it is more useful to break them into smaller categories based on how they perform interaction types:
· Procedure call
· Event
· Data Access
· Linkage
· Stream
· Arbitrator
· Adaptor
· Distributor
Connectors can (and often do) fall into multiple categories. Using these more fine-grained categories can make it easier for architects to select connectors needed for a given system.
5.4.1 Procedure Call Connectors
· Model flow of control among components
· Perform transfer of data to components through parameters/return values
· Usually both Coordination Connectors and Communication Connectors
· Examples include fork & exec in Unix systems, call-back invocation in event-based systems, and OS calls
5.4.2 Event Connectors
· Like Procedure Call Connectors, they affect flow control
· Generates messages (event notifications)
· Like Procedure Call Connectors, they are both Coordination Connectors and Communication Connectors
· Biggest difference is that the flow control and event notifications are precipitated by events (single event, or specified sequence of events)
· Another difference is that virtual connectors are formed between components interested in the same events, which can appear and disappear dynamically
· Examples include windowing systems such as X for Unix
5.4.3 Data Access Connectors
· Allow components to access data maintained by a data store component
· Often performs set-up and clean-up before and after data access
· May also perform translation of the information
· Fits into Communication, Facilitation and Conversion connectors
· Data accessed can be persistent or temporary
· Example of persistent storage connector includes SQL
· Example of temporary storage connector includes heap and stack memory access
5.4.4 Linkage Connectors
· Used to tie system components together, keep them in that state during operation
· Enable establishment of ducts (channels for communication/coordination)
· Falls into Facilitation, Communication and Coordination categories
· Examples include links between components and buses in a C2-style architecture (from chapter 4), and dependency relationships between software modules
5.4.5 Stream Connectors
· Streams used to perform transfers of large amounts of data between autonomous processes
· Used in client-server systems to deliver results of computation
· Communication Connector
· Can be combined with other connector types such as data access connectors to provide composite connectors used for database or file storage access, or event connectors to multiplex delivery of a large number of events
· Examples include Unix pipes, TCP/UDP communication sockets
5.4.6 Arbitrator Connectors
· Helps components resolve conflicts, and redirect flow of control between components that can see each other, but cannot make assumptions about their needs/state
· Acts as an arbitrator connector and facilitator connector
· Can also help negotiate service levels and mediate reliability and atomicity
· Provide scheduling and load balancing services
· Example: synchronization and concurrency control on a multithreaded system
5.4.7 Adaptor Connector
· Provide facilities to support interaction between components that have not been designed to interoperate
· They help match communication policies and interaction protocols among components
· These are Conversion Connectors
· Needed in heterogeneous environments
· Examples include virtual memory translation
5.4.8 Distributor Connector
· Perform identification of interaction paths, and routing of communication/coordination information between components
· Facilitation Connector
· Never exist by themselves, but provide assistance to other connectors like streams or procedure calls
· Examples include DNS, routing, switching
5.5 Example Connectors
Connectors can have multiple types in real world implementations and are often composed together to form composite connectors. There are many composite distribution connectors in use today which can be event-based, client-server-based and peer-to-peer based. These composite connectors typically include the data access, stream, and distributor connector types.
5.5.1 Example: Event-based Data distribution connector
Composition of 4 of the connector types: event, data access, stream, and distributor
Event: These connectors send and receive data through asynchronous notifications called events.
Data Access: Often employ an asynchronous best-effort delivery method for data
Streams: both structured and raw, can be identified via URIs
Distributor: Data streams are delivered as events using best-effort delivery and any combination of unicast, broadcast, and multicast delivery mechanisms.
5.5.4 Example: P2P-based Data distribution connector
composition of 4 of the connector types: arbitrator, data access, steram and distributor
Arbitrator: Doesn't rely upon traditional event-based or procedural invocation, instead relies upon arbitration for synchronization and invocation. Arbitration involves control flow redirection between networked peers, negotiating protocols, scheduling and timing issues.
Data Access: Access to both transient and persistent data, mostly transient due to nodes frequently connecting and disconnecting.
Streams: Uses best effort bounded mechanism. Organized into identifiable chunks that can be retransmitted and shared between peers handled by the connector. Streams are named URNS, typically identified by some hashing algorithm.
Distributor: Distributed by locating other peers that have pieces of the requested data. Tracking mechanisms allow location of chunks of data streams that need to be distributed or obtained in a P2P-based connector.
5.6 Using the connector framework
Selecting Appropriate Connectors
Different sets of components, even in the same system, may have different interaction needs.
Need to determine the interaction services the components need.
Determine a subset of the eight connector types that comprise the initial candidate set for providing those services. Choose most natural connector for these interactions, compositing as necessary in a way that will not lead to a suboptimal system.
Some combinations of connector types, dimensions and subdimensions result in incompatible or poorly performing systems. 4 types of relation: requires, cautions, restricts, and prohibits. Very little prohibits compositing.
Example (prohibits):
Stream delivery cannot be built on transactional atomicity.
Example (restricts):
In Procedure calls, there are restrictions between invocations and concurrency. This can be seen in the form of race conditions.
Example (requires):
Most procedure calls require well defined entry points, this is essential if parameters are specified.
1