1. Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Connectors Infosys, Mysore December 19, 2009

2. Foundations, Theory, and Practice Software Architecture 2 Attach adapter to A Maintain multiple versions of A or B Make B multilingual Change A’s form to B’s form Provide B with import/export converter Separate B’s “essence” from its packaging Publish abstraction of A’s form Introduce intermediate form Transform on the fly What is the right answer? Negotiate to find common form for A and B How do we enable components A and B to interact?

3. Foundations, Theory, and Practice Software Architecture 3 What is a Software Connector? Architectural element that models u Interactions among components u Rules that govern those interactions Simple interactions u Procedure calls u Shared variable access Complex & semantically rich interactions u Client-server protocols u Database access protocols u Asynchronous event multicast Each connector provides u Interaction duct(s) u Transfer of control and/or data

4. Foundations, Theory, and Practice Software Architecture 4 Where 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.

5. Foundations, Theory, and Practice Software Architecture 5 Implemented vs. Conceptual Connectors Connectors in software system implementations u Frequently no dedicated code u Frequently no identity u Typically do not correspond to compilation units u Distributed implementation Across multiple modules Across interaction mechanisms

6. Foundations, Theory, and Practice Software Architecture 6 Implemented vs. Conceptual Connectors (cont’d) Connectors in software architectures u First-class entities u Have identity u Describe all system interaction u Entitled to their own specifications & abstractions

7. Foundations, Theory, and Practice Software Architecture 7 Reasons for Treating Connectors Independently Connector  Component u Components provide application-specific functionality u Connectors provide application-independent interaction mechanisms Interaction abstraction and/or parameterization Specification of complex interactions u Binary vs. N-ary u Asymmetric vs. Symmetric u Interaction protocols

8. Foundations, Theory, and Practice Software Architecture 8 Treating Connectors Independently (cont’d) Localization of interaction definition Extra-component system (interaction) information Component independence Component interaction flexibility

9. Foundations, Theory, and Practice Software Architecture 9 Benefits of First-Class Connectors Separate computation from interaction Minimize component interdependencies Support software evolution u At component-, connector-, & system-level Potential for supporting dynamism Facilitate heterogeneity Become points of distribution Aid system analysis & testing

10. Foundations, Theory, and Practice Software Architecture 10 An Example of Explicit Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

11. Foundations, Theory, and Practice Software Architecture 11 An 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.

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

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

14. Foundations, Theory, and Practice Software Architecture 14 Connectors as Coordinators Determine computation control Control delivery of data Separates control from computation Orthogonal to communication, conversion, and facilitation u Elements of control are in communication, conversion and facilitation

15. Foundations, Theory, and Practice Software Architecture 15 Connectors as Converters Enable interaction of independently developed, mismatched components Mismatches based on interaction u Type u Number u Frequency u Order Examples of converters u Adaptors u Wrappers

16. Foundations, Theory, and Practice Software Architecture 16 Connectors as Facilitators Enable interaction of components intended to interoperate u Mediate and streamline interaction Govern access to shared information Ensure proper performance profiles u e.g., load balancing Provide synchronization mechanisms u Critical sections u Monitors

17. Foundations, Theory, and Practice Software Architecture 17 Connector Types Procedure call Data access Event Stream Linkage Distributor Arbitrator Adaptor

18. Foundations, Theory, and Practice Software Architecture 18 A Framework for Classifying Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

19. Foundations, Theory, and Practice Software Architecture 19 Procedure Call Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

20. Foundations, Theory, and Practice Software Architecture 20 Event Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

21. Foundations, Theory, and Practice Software Architecture 21 Data Access Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

22. Foundations, Theory, and Practice Software Architecture 22 Linkage Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

23. Foundations, Theory, and Practice Software Architecture 23 Stream Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

24. Foundations, Theory, and Practice Software Architecture 24 Arbitrator Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

25. Foundations, Theory, and Practice Software Architecture 25 Adaptor Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

26. Foundations, Theory, and Practice Software Architecture 26 Distributor Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

27. Foundations, Theory, and Practice Software Architecture 27 Discussion Connectors allow modeling of arbitrarily complex interactions Connector flexibility aids system evolution u Component addition, removal, replacement, reconnection, migration Support for connector interchange is desired u Aids system evolution u May not affect system functionality

28. Foundations, Theory, and Practice Software Architecture 28 Discussion Libraries of OTS connector implementations allow developers to focus on application-specific issues Difficulties u Rigid connectors u Connector “dispersion” in implementations Key issue u Performance vs. flexibility

29. Foundations, Theory, and Practice Software Architecture 29 How Do You Select a Connector? Determine a system’s interconnection and interaction needs u Software interconnection models can help Determine roles to be fulfilled by the system’s connectors u Communication, coordination, conversion, facilitation For each connector u Determine its appropriate type(s) u Determine its dimensions of interest u Select appropriate values for each dimension For multi-type, i.e., composite connectors u Determine the atomic connector compatibilities

30. Foundations, Theory, and Practice Software Architecture 30 Simple Example System components will execute in two processes on the same host u Mostly intra-process u Occasionally inter-process The interaction among the components is synchronous The components are primarily computation-intensive u There are some data storage needs, but those are secondary

31. Foundations, Theory, and Practice Software Architecture 31 Simple Example (cont’d)  Select procedure call connectors for intra-process interaction  Combine procedure call connectors with distributor connectors for inter-process interaction  RPC  Select the values for the different connector dimensions  What are the appropriate values?  What values are imposed by your favorite programming language(s)?

32. Foundations, Theory, and Practice Software Architecture 32 Procedure Call Connectors Revisited Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

33. Foundations, Theory, and Practice Software Architecture 33 Distributor Connectors Revisited Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

34. Foundations, Theory, and Practice Software Architecture 34 Two Connector Types in Tandem Select the appropriate values for PC and RPC! Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

35. Foundations, Theory, and Practice Software Architecture 35 Software Interconnection Models Interconnection models (IM) as defined by Perry u Unit interconnection u Syntactic interconnection u Semantic interconnection All three are present in each system Are all equally appropriate at architectural level?

36. Foundations, Theory, and Practice Software Architecture 36 Unit Interconnection Defines relations between system’s units u Units are components (modules or files) u Basic unit relationship is dependency Unit-IM = ({units},{“depends on”}) Examples u Determining context of compilation e.g., C preprocessor IM = ({files},{“include”}) u Determining recompilation strategies e.g., Make facility IM = ({compile_units},{“depends on”,“has changed”}) u System modeling e.g., RCS, DVS, SVS, SCCS IM = ({systems, files},{“is composed of”})

37. Foundations, Theory, and Practice Software Architecture 37 Unit Interconnection Characteristics Coarse-grain interconnections u At level of entire components Interconnections are static Does not describe component interactions u Focus is exclusively on dependencies

38. Foundations, Theory, and Practice Software Architecture 38 Syntactic Interconnection Describes relations among syntactic elements of programming languages u Variable definition/use u Method definition/invocation IM = ({methods, types, variables, locations}, {“is def at”, “is set at”, “is used at”, “is del from”, “is changed to”, “is added to”}) Examples u Automated software change management e.g., Interlisp’s masterscope u Static analysis e.g., Detection of unreachable code by compilers u Smart recompilation Changes inside unit  recompilation of only the changes u System modeling Finer level of granularity than unit-IM

39. Foundations, Theory, and Practice Software Architecture 39 Syntactic Interconnection Characteristics Finer-grain interconnections u At level of individual syntactic objects Interconnections are static & dynamic Incomplete interconnection specification u Valid syntactic interconnections may not be allowed by semantics u Operation ordering, communication transactions e.g., Pop on an empty stack u Violation of (intended) operation semantics e.g., Trying to use calendar add operation to add integers

40. Foundations, Theory, and Practice Software Architecture 40 Semantic Interconnection Expresses how system components are meant to be used u Component designers’ intentions Captures how system components are actually used u Component users’ (i.e., system builders’) intention Interconnection semantics can be formally specified u Pre- & post-conditions u Dynamic interaction protocols (e.g. CSP, FSM) IM = ({methods, types, variables,..., predicates}, {“is set at”, “is used at”, “calls”, “called by”,..., “satisfies”})

41. Foundations, Theory, and Practice Software Architecture 41 Example of Semantic Interconnection connector Pipe = role Writer = write  Writer П close  role Reader = let ExitOnly = close  in let DoRead = (read  Reader read-eof  ExitOnly) in DoRead П ExitOnly glue = let ReadOnly = Reader.read  ReadOnly Reader.read-eof  Reader.close  Reader.close  in let WriteOnly = Writer.write  WriteOnly Writer.close  in Writer.write  glue Reader.read  glue Writer.close  ReadOnly Reader.close  WriteOnly Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

42. Foundations, Theory, and Practice Software Architecture 42 Semantic Interconnection Characteristics Builds on syntactic interconnections Interconnections are static & dynamic Complete interconnection specification u Specifies both syntactic & semantic interconnection validity Necessary at level of architectures u Large components u Complex interactions u Heterogeneity u Component reuse What about ensuring other properties of interaction? u Robustness, reliability, security, availability,...

43. Foundations, Theory, and Practice Software Architecture 43 Composing Basic Connectors In many systems a connector of multiple types may be required to service (a subset of) the components All connectors cannot be composed u Some are naturally interoperable u Some are incompatible u All are likely to require trade-offs The composition can be considered at the level of connector type dimensions and subdimensions

44. Foundations, Theory, and Practice Software Architecture 44 Connector Dimension Inter- Relationships Requires – u Choice of one dimension mandates the choice of another Prohibits – u Two dimensions can never be composed into a single connector Restricts – u Dimensions are not always required to be used together u Certain dimension combinations may be invalid Cautions – u Combinations may result in unstable or unreliable connectors

45. Foundations, Theory, and Practice Software Architecture 45 Dimension Inter-Relationships Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

46. Foundations, Theory, and Practice Software Architecture 46 Well Known Composite Connectors Grid connectors (e.g., Globus) u Procedure call u Data access u Stream u Distributor Peer-to-peer connectors (e.g., Bittorrent) u Arbitrator u Data access u Stream u Distributor Client-server connectors Event-based connectors

47. Foundations, Theory, and Practice Software Architecture More on the Grid A distributed systems technology that enables the sharing of resources across organizations scalably, efficiently, reliably, and securely Analogous to the electric grid

48. Foundations, Theory, and Practice Software Architecture Why Study the Grid? A highly successful technology Deficiencies in the existing guidance for building grids  More to come Grids are not easy to build u See CERN’s Large Hadron Collider Their architecture was published very early u “anatomy” and “physiology” Yet “What is (not) a grid?” is still a subject of debate

49. Foundations, Theory, and Practice Software Architecture The Architectural Perspective Grids are large, complex systems u Thousands of nodes or more u Span many agency boundaries Qualities of Service (QoS) are critical u Scalability u Security u Performance u Reliability... Software architecture is just what the doctor ordered  The set of principal design decisions about a software system [Taylor, Medvidovic, Dashofy 2009]

50. Foundations, Theory, and Practice Software Architecture Original grid reference architecture

51. Foundations, Theory, and Practice Software Architecture TechnologyPLKSLOC# Modules AlchemiC# (.NET)26.2186 Apache HadoopJava, C/C++66.51643 Apache HBaseJava, Ruby, Thrift14.1362 CondorJava, C/C++51.6962 DSpaceJava23.4217 GangliaC19.322 GLIDEJava257 Globus 4.0 (GT 4.0)Java, C/C++2218.72522 Grid DatafarmJava, C51.4220 Gridbus BrokerJava30.5566 JcgridJava6.7150 OODTJava14320 PegasusJava, C79659 SciFloPython18.5129 iRODSJava, C/C++84.1163 Sun Grid EngineJava, C/C++265.1572 UnicoreJava5713665 WingsJava8.897

52. Foundations, Theory, and Practice Software Architecture Architecture Recovery Technique - Focus - Establish idealized architecture and candidate architectural style(s) Identify data and processing components u Groups implementation modules according to a set of rules Map identified data and processing components onto an idealized architecture  Examine  Source code  Documentation  Runtime behavior  Tie to requirements satisfied by component

53. Foundations, Theory, and Practice Software Architecture Rules of Focus 1. Group based on isolated classes 2. Group based on generalization 3. Group based on aggregation 4. Group based on composition 5. Group based on two-way association 6. Identify domain classes 7. Merge classes with a single originating domain class association into domain class 8. Group classes along a domain class circular dependency path 9. Group classes along a path with a start node and end node that reference a domain class 10. Group classes along paths with the same end node, and whose start node references the same domain class

54. Foundations, Theory, and Practice Software Architecture Some Refinements to the Rules Domain class rules u Class with large majority of outgoing calls Exclusion rules u Class with large majority of incoming calls u Utility classes u Heavily passed data-structures u Benchmarking and test classes Additional groupings u By exception u By interface u By package if idealized architecture matches first-class component

55. Foundations, Theory, and Practice Software Architecture Focus Rules for Distributed Systems Infer distributor connectors from idealized architecture Classes with methods and names similar to first-class components are domain classes Classes importing network communication libraries are domain classes main() functions often identify first-class components Classes deployed onto different hosts must be grouped separately

56. Foundations, Theory, and Practice Software Architecture Discovered discrepancies Empty layers Skipped Layers Up-calls Multi-layer components

57. Foundations, Theory, and Practice Software Architecture Empty Layers Wings

58. Foundations, Theory, and Practice Software Architecture Skipped Layers Pegasus

59. Foundations, Theory, and Practice Software Architecture Upcalls Hadoop

60. Foundations, Theory, and Practice Software Architecture Multi- Layer Comps iRODS

61. Foundations, Theory, and Practice Software Architecture What about Globus?

62. Foundations, Theory, and Practice Software Architecture Two layer boundary AND Upcall Two layer boundary AND Upcall Two layer boundary AND Upcall Couldn’t determine right “layer” upcall What about Globus?

63. Foundations, Theory, and Practice Software Architecture Discrepancies Found

64. Foundations, Theory, and Practice Software Architecture Revised Grid Architecture The connectivity layer is eliminated Explicitly addressing deployment view Subsystem types rather than layer-oriented Four architectural styles comprise the grid u Client/server u Peer-to-peer u Layered u Event-based An improved classification of grid technologies

65. Foundations, Theory, and Practice Software Architecture Revised Grid Reference Architecture

66. Foundations, Theory, and Practice Software Architecture Grid Styles – C/S Application components are clients to Collective components u e.g., application components query for resource component locations from collective components Application components are clients to Resource components u e.g., direct job submission from application components to resource components Resource components can act as clients to Collective components u e.g., resource components may obtain locations of other resource components through collective components

67. Foundations, Theory, and Practice Software Architecture Grid Styles – p2p Resource components are peers u e.g., Grid Datafarm Filesystem Daemon (gfsd) instance makes requests for file data from other gfsds Collective components are peers u e.g., iRODS agents communicate with each other to exchange data to create replicas

68. Foundations, Theory, and Practice Software Architecture Grid Styles – Event-Based Resource components notify Collective components that monitor them u e.g., executors send heartbeats to managers

69. Foundations, Theory, and Practice Software Architecture Grid Architectural Styles – Layered Collective or Resource components request services from Fabric components u e.g., iRODS agent accesses a DBMS with metadata

70. Foundations, Theory, and Practice Software Architecture Correcting Violations in the Reference Architecture Why were there originally so many upcalls? u Legitimate client-server and event-based communication Why so many skipped layer calls? u The Fabric layer was at the wrong level of abstraction u Mostly utility classes that should be abstracted away Why so many multi-layer components? u Connectivity layer was at the wrong level of abstraction u Not a layer, but utility libraries to enable connector functionality u Also accounts for skipped layer calls Benefit of the deployment view u Essential for distributed systems u Helped to identify that the Fabric layer was not abstracted properly

71. Foundations, Theory, and Practice Software Architecture Where Are We Currently? There are remaining violations u Are they legitimate or a result of an improperly recast reference architecture? Original Focus is not ideal for recovering systems of these types u Distributed systems realized by a middleware A more automated approach that combines static and dynamic analysis would be preferable Use the recast reference architecture to build a new grid What are the overarching grid principles?

72. Foundations, Theory, and Practice Software Architecture Evolving Grid Principles 1. A grid is a collection of logical resources (computing and data) distributed across a wide-area network of physical resources (hosts). 2. In a single grid-based application, the logical resources are owned by a single agency, while the physical resources are owned by multiple agencies. 3. All resources in a grid are described using a common meta-resource language. 4. Atomic-level logical resources are defined independently of the atomic-level physical resources.

73. Foundations, Theory, and Practice Software Architecture Evolving Grid Principles 5. The allocation of the atomic-level logical resources to the atomic-level physical resources can be N:M. 6. All computation in a grid is initiated by a client, which is a physical resource. The client sends the logical resources to the servers, which are also physical resources. A server can, in turn, delegate the requested computation to other physical resources. 7. All agencies that own physical resources in a grid must be able to specify policies that enforce the manner in and extent to which their physical resources can be used in grid applications.