Architectural Specification and Optimal Deployment of Distributed Systems

1. Architectural Specification and Optimal Deployment of Distributed Systems Prof. María Cecilia Bastarrica Department of Computer Science The University of Chile Santiago, Chile cecilia@dcc.uchile.cl http://www.dcc.uchile.cl/~cecilia/ Profs. S. Demurjian and A. Shvartsman Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT 06269-2155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818

2. What are the Elements in a Distributed System? • Application Components • New Software • Legacy, COTS, Databases, etc. • Relationship Between Components • Different Implementations of “Same” Component on Different Hardware Platforms • Configuration • Node Types in the Network • Components’ Deployment • More?

3. The Best Current Practice • Graphical Modeling (Object-Oriented) • Manual Documentation of the Objects Interaction • Ad Hoc Specification of Types and Classes • Formal Specification of Interfaces • Description of Algorithms and Protocols • Specification of Configuration and Deployment

4. Problem and Issues • What is the Best Way of Deploying a Distributed Application? • Problems With the Problem • What is a Distributed Application ? • Where is This Application to Be Deployed? • What Do We Mean by Best Deployment? • How Do We Get the Best Deployment?

5. Distributed Application • A Distributed Application is a Set of Components Deployed Over a Network That Communicate. • Components May Be: • Data Types • Executable Programs • Legacy or COTS • Clients/Servers • Databases, Etc.

6. Network • A Network is a Set of Computers Connected So They Can Communicate • Computers & Connections May Have Different Characteristics That Affect Their Usage • Speed • Storage • Bandwidth

7. Best Deployment • A Distributed System is Optimally Deployed if it Yields the Best Performance • Performance: Efficient Use of Resources • Throughput • Response Time • Number of Messages

8. Understanding the Problem via UML • Consider an Application with a UML Design • Class Diagram and Object Diagram • Sequence Diagrams • Component Diagrams (Hardware & Software) • (see Next Three Slides) • Questions: • How do I Determine the Best Placements of the Components (Classes) on the Hardware? • How does the Object Interactions Influence the Placement? • Are any Instances Replicated? Fixed to Particular Hardware Locations? • How Do I Decide on Optimality?

9. Software and Hardware Component Types

10. Software Component Classes

11. Hardware Component Classes

12. Relationship of Software and Hardware Classes

13. Instances of Software Classes

14. Instances of Hardware Classes

15. Critical Step: Mapping Software Instances to Hardware Locations with Restrictions • Software (Left) and Hardware (Right) Instances • Restrictions on • Which Software Instance can be Deployed on Which Hardware Instance • Which Software Instances Deployed Together • Which Software Instances Must be Separate

16. Objective Determine the Optimal Deployment?

17. Distributed Systems SpecificationCombinations of Requirements interaction patterns hardware elements software elements Specification connections protocols interfaces

18. Distributed System Optimal DeploymentInfluenced by Many Factors replication degree algorithms usage patterns software architecture Performance middleware deployment underlying network processing nodes

19. Integrated Framework for Design and Deployment SOFTWARE HARDWARE Dependencies Deployment PERFORMANCE

20. Two-Fold Focus of the Work • I5 • An Architectural Specification Framework • Specifically for Distributed Systems • Including Software and Hardware Features • Textual and Graphical Notations. • Optimization Model • Binary Integer Programming Model • Architectural Information + Usage Patterns As Parameters • Possibility of Optimizing According to Different Criteria

21. The Complete Cycle Graphical Specification Transformation Procedures Textual Specification Usage Patterns Information Extended Textual Specification BIP Model Optimal Deployment

22. Outline or Remainder of Talk • Motivation and Background • Overview of Architectural Styles • OSF’s I4DL • UML and Design Concepts • The I5 Framework • A First Look at I5’s Levels • Different Levels • Graphical and Textual Notations • Optimal Deployment • BIP Optimization • Parameters - Optimization Criteria • Conclusions and Future Work

23. Overview of Architectural Styles • UML is Intended for Specifying OO and Component-based Systems • Define Business Processes (Use Cases) • Track Specification/Document • CORBA Assumes an OO Architectural Style • Other Architectural Styles Can Be Derived From the OO Style • Z Has Been Used to Specify Software Architectures • Formal Basis for Describing System • Mathematically Sound • We’ll Employ both UML and Z!

24. I5 : Background and Sources • OSF’s I4DL- Distributed Systems Defined With 4 Definition Languages (2 Pages): • Interface • Inheritance • Implementation • Instantiation • UML’s Implementation Diagrams: • Component Diagrams • Deployment Diagrams

25. What is I5? • Five Definition Languages • Interface • Inheritance • Implementation • Instantiation • Installation • Five Formal Integrated Graphical Languages Based on UML’s Implementation Diagrams • The Application, Network, Dependencies and the Deployment are Part of an Integrated Framework refine and expand DLs new DL

26. The Five Levels of I5 • Interface (I1) - Types of Components, Nodes and Connectors • Implementation (I2) - Classes of Components, Nodes and Connectors • Integration (I3) - Dependencies Between Component and Node Classes • Instantiation (I4) - Instances of Each Class Definition • Installation (I5) - Deployment of Each Instance (Requirements and Complete Deployment)

27. Levels of Specification in I5 • Types - Generic Definition of Components, Nodes, and Connectors According to Their Role • Defined in I1 • Used in I2 to Define Classes • Classes - Different Implementations of the Types • Defined in I2 • Used in I3 to Associate Software Components and Hardware Artifacts and I4 to Define Instances • Instances - Identical Copies of the Different Classes • Defined in I4 • Used in I5 to Deploy Instances Across Nodes

28. UML • UML is a Set of Graphical Specification Languages (OMG’s Standard Design Language Since November, 1997) • Implementation Diagrams • Component Diagrams: • Show the Physical Structure of the Code in Terms of Code Components and Their Dependencies • Deployment Diagrams: • Show the Physical Architecture of the Hardware and Software in the System. • They Have a Type and an Instance Version.

29. UML • When to Use Deployment Diagrams “… In practice, I haven’t seen this kind of diagram used much. Most people do draw diagrams to show this kind of information but they are informal cartoons. On the whole, I don’t have a problem with that since each system has its own physical characteristics that your want to emphasize. As we wrestle more and more with distributed systems, however, I’m sure we will require more formality as we understand better which issues need to be highlighted in deployment diagrams.” • From “UML Distilled. Applying the Standard Object Modeling Language”, by Martin Fowler. Addison-Wesley, Object Technology Series, 7th. Reprint June, 1998.

30. Advantages: Clear to Show Structure Excellent Communication Vehicle Addresses Different Aspects of Modeling in an Integrated Fashion Disadvantages: Shows Little (or No) Details There is a Big Gap Between Specification and Implementation Limited by Screen Size & Printable Page Pros and Cons ofGraphical Modeling • Solution: Associate a Complete Textual Specification to Graphical Model that Contains the Necessary Details for Each Element

31. Design Concepts • Interface Interaction With the Outer World Signature + Requested Services • Type: Abstract Entity - Interface + Semantics • Subtype: Inherits the Supertype Definition • Class: Implementation of a Type • Realization: Relation Between a Type and a Class That Implements It • Subclass: Inherits the Superclass Implementation • Instance: Element of a Class

32. Design Concepts in UML DiagramsComponent Types and Classes interface types I2 I2 T1 C1 realization subclass I2 I2 T2 C2.2 I4 I4 subtype I2 classes C2.1 I4

33. The I5 Framework • An Integrated Specification Framework for Distributed Systems • Support for the Architectural Specification of OO and Component Based Distributed Systems • Heterogeneous Network - Platforms • A Five Level Framework for Defining Software and Hardware (Platforms) With a Uniform Notation and With Different Levels of Abstraction • Specified Textually in Z or Graphically in UML • Emphasis on Implementation Diagrams • Please See http://www.engr.uconn.edu/~cecilia

34. Interplay ofGraphical and Textual Notations Well-formed graphical Consistent textual

35. Benefits of I5 • Organizes the Design of New Systems and the Documentation of Existing Distributed Systems • More Traceability, Important for Maintenance • Firm Base for Configuration Management • The Implicit Methodology Makes Use of the Knowledge Shared by the Trained UML Users Community • We’ll Transition from I5 to Optimal Deployment!

36. The Five Levels of I5 Interface Detail Implementation Integration Instantiation Abstraction Installation

37. A First Look at the Interface Level INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION • Component and Node Types Are Specified As Well As Their Connections. TCP/IP PUZZLE TCP/IP PNODE TCP/IP USER BASE SLIST CITY PATH types

38. A First Look at the Inheritance Level INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION • Two Types of Inheritance: • Implementation • Inheritance • Interface • Refinement x_window x_dialog box WINDOW classes w_window DIALOG BOX w_dialog box types

39. A First Look at the Inheritance Level INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION Components Nodes Types Interfaces and Role of the node semantics Implementation Implementation Architecture and/or Classes dependencies OS of the role Instances Executable Instance computer instance

40. A First Look at the Implementation Level INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION puzzle slist path <<supports>> <<supports>> <<supports>> user • Implementation Constraints State the Class of Node Where Each Implementation Class of Component Should Run classes stereotypes

41. A First Look at the Instantiation Level INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION puzzle: PUZZLE slist2: SLIST pnode: PNODE city: CITY slist1: SLIST path: PATH • Instantiation Identifies the Instance Components and Computers of Each Class That Form Part of the Actual System instances

42. A First Look at the Instantiation Level INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION • Only Instances of the Implementation Classes Already Identified Can Be Part of the System • Instances Must Preserve the Dependencies Specified in the Interface Level user1: USER user2: USER base1: BASE base2: BASE

43. A First Look at the Installation Level INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION • Deployment of the Instance Components Over the Instance Computers • Installation Has Two Facets: • Installation Requirements • Complete Installation • All Instances Identified in the Instantiation Level Must Be Part of the Complete Installation

44. Types of Requirements: Fix the Location of Certain Instance Components Two or More ComponentsMust Be Deployed Together Installation Requirements path: PATH puzzle: PUZZLE slist1: SLIST user2:USER

45. Complete Installation city: CITY pnode: PNODE puzzle: PUZZLE slist2: SLIST slist1: SLIST path: PATH user1: USER user2: USER base2: BASE base1: BASE

46. Specification Elements Types Hardware Software Classes Instances

47. Dependencies Between Levels Component Types Node Types Component Classes Node Classes Inst. Components Inst. Nodes Installation Req. (together,separated) Installation Req. (fix location) INTERFACE IMPLEMENTATION Implementation Dependencies INTEGRATION System Instantiation INSTANTIATION INSTALLATION Complete Installation

48. Interface - Software: I1S • Components Types • Type • Supertypes • Associated Interfaces • Calls • Properties • Types are Unique • Supertypes Must Be Part of I1S • Calls Must Be Satisfied in I1S

49. Interface - Software: I1S response Client <<call>> <<call>> request receive FrontEnd <<call>> <<call>> receive gossip Replica <<call>>

50. Interface - Software: I1S [COMP_TYPE][INTERFACE] Comp_Type type : COMP_TYPE supertypes : P Comp_Type local_int, interfaces : P INTERFACE local_calls, calls : Comp_Type  INTERFACE self supertypes interfaces = supertypes.interfaces  local_int calls = supertypes.calls  local_calls