Presentation is loading. Please wait.

Presentation is loading. Please wait.

OD-1 CSE333 Architectural Specification and Optimal Deployment of Distributed Systems Profs. S. Demurjian and A. Shvartsman Computer Science & Engineering.

Similar presentations

Presentation on theme: "OD-1 CSE333 Architectural Specification and Optimal Deployment of Distributed Systems Profs. S. Demurjian and A. Shvartsman Computer Science & Engineering."— Presentation transcript:


2 OD-1 CSE333 Architectural Specification and Optimal Deployment of Distributed Systems Profs. S. Demurjian and A. Shvartsman Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT 06269-2155 (860) 486 - 4818 Prof. María Cecilia Bastarrica Department of Computer Science The University of Chile Santiago, Chile

3 OD-2 CSE333 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?

4 OD-3 CSE333  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 The Best Current Practice

5 OD-4 CSE333 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?

6 OD-5 CSE333 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.

7 OD-6 CSE333Network  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

8 OD-7 CSE333 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

9 OD-8 CSE333 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?

10 OD-9 CSE333 Software and Hardware Component Types

11 OD-10 CSE333 Software Component Classes

12 OD-11 CSE333 Hardware Component Classes

13 OD-12 CSE333 Relationship of Software and Hardware Classes

14 OD-13 CSE333 Instances of Software Classes

15 OD-14 CSE333 Instances of Hardware Classes

16 OD-15 CSE333 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

17 OD-16 CSE333 Objective Determine the Optimal Deployment?

18 OD-17 CSE333 software elements hardware elements protocols interfaces interaction patterns connectionsSpecification Distributed Systems Specification Combinations of Requirements

19 OD-18 CSE333 Performance algorithms middleware underlying network usage patterns deployment software architecture replication degree processing nodes Distributed System Optimal Deployment Influenced by Many Factors

20 OD-19 CSE333 Integrated Framework for Design and Deployment SOFTWAREHARDWARE Dependencies Deployment PERFORMANCE

21 OD-20 CSE333 Two-Fold Focus of the Work  I 5  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

22 OD-21 CSE333 Graphical Specification Textual Specification Extended Textual Specification Optimal Deployment Transformation Procedures Usage Patterns Information BIP Model The Complete Cycle

23 OD-22 CSE333 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 I 5 ’s Levels  Different Levels  Graphical and Textual Notations  Optimal Deployment  BIP Optimization  Parameters - Optimization Criteria  Conclusions and Future Work

24 OD-23 CSE333 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!

25 OD-24 CSE333 I 5 : Background and Sources I 5 : 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

26 OD-25 CSE333  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 new DL refine and expand DLs What is I 5 ?

27 OD-26 CSE333  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) The Five Levels of I 5

28 OD-27 CSE333  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 Levels of Specification in I 5

29 OD-28 CSE333UML  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.

30 OD-29 CSE333UML  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.

31 OD-30 CSE333 Pros and Cons of Graphical Modeling  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  Solution: Associate a Complete Textual Specification to Graphical Model that Contains the Necessary Details for Each Element

32 OD-31 CSE333 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

33 OD-32 CSE333 Design Concepts in UML Diagrams Component Types and Classes T1 T2 C1 C2.1 C2.2 I2 I4 types classes realization subtype subclass interface

34 OD-33 CSE333 The I 5 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

35 OD-34 CSE333 Interplay of Graphical and Textual Notations Well-formed Consistent graphical textual

36 OD-35 CSE333 Benefits of I 5  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 I 5 to Optimal Deployment!

37 OD-36 CSE333 Interface Implementation Integration Instantiation Installation Abstraction Detail The Five Levels of I 5

38 OD-37 CSE333 A First Look at the Interface Level  Component and Node Types Are Specified As Well As Their Connections. PNODE CITY PUZZLE SLIST PATH USERBASE TCP/IP types INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION

39 OD-38 CSE333 A First Look at the Inheritance Level  Two Types of Inheritance:  Implementation  Inheritance  Interface  Refinement WINDOW DIALOG BOX x_window x_dialog box w_window w_dialog box classes types INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION

40 OD-39 CSE333 A First Look at the Inheritance Level ComponentsNodes TypesInterfaces and semantics Role of the node Implementation Classes Implementation dependencies Architecture and/or OS of the role InstancesExecutable instance Instance computer INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION

41 OD-40 CSE333 A First Look at the Implementation Level  Implementation Constraints State the Class of Node Where Each Implementation Class of Component Should Run puzzleslistpath user > stereotypesclasses INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION

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

43 OD-42 CSE333 A First Look at the Instantiation Level  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 INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION

44 OD-43 CSE333 A First Look at the Installation Level  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 INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION

45 OD-44 CSE333 Installation Requirements  Types of Requirements:  Fix the Location of Certain Instance Components  Two or More Components Must Be Deployed Together user2:USER path: PATH puzzle: PUZZLE slist1: SLIST

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

47 OD-46 CSE333 Types Classes Instances Software Hardware Specification Elements

48 OD-47 CSE333 Dependencies Between Levels Component TypesNode Types INTERFACE IMPLEMENTATION INTEGRATION INSTANTIATION INSTALLATION Component ClassesNode Classes Implementation Dependencies Inst. ComponentsInst. Nodes Installation Req. (together,separated) Installation Req. (fix location) Complete Installation System Instantiation

49 OD-48 CSE333  Components Types   Type   Supertypes   Associated Interfaces   Calls  Properties   Types are Unique   Supertypes Must Be Part of I1S   Calls Must Be Satisfied in I1S Interface - Software: I1S

50 OD-49 CSE333 Client FrontEnd response request receive > Replica receive gossip > Interface - Software: I1S

51 OD-50 CSE333 [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 Interface - Software: I1S

52 OD-51 CSE333 I1_S comp_types : P Comp_Type  c,c’  comp_types  c.type = c’.type  c = c’  (ct  i)  comp_types.calls  ct  comp_types  i  ct.interfaces  ct  comp_types  ct.supertypes  comp_types Interface - Software: I1S

53 OD-52 CSE333 Interface - Hardware: I1H  Node Types  Connector Types  Connections  Properties   All Node Types Must Be Connected   Only Node and Connector Types Defined Take Part in the Connections SUN Intel Pentium MPI Sockets

54 OD-53 CSE333 [NODE_TYPE] Node_Type type: NODE_TYPE [CONN_TYPE] Conn_Type type: CONN_TYPE I1_H node_types : P Node_Type conn_types : P Conn_Type connects : Conn_Type  P Node_Type (dom connects) = conn_types  n_set  (ran connects)  n_set  node_types  nt  node_types   (ct  nt_set)  connects | nt  nt_set Interface - Hardware: I1H

55 OD-54 CSE333 Implementation - Software: I2S  Component Classes   Component Type   Class   Superclasses   Calls to Classes Interfaces  Properties:   Only Types in I1S are Allowed   Superclasses Are Realizations of the Supertypes   Calls & Inheritance are Satisfied Within I2S

56 OD-55 CSE333 XFrontEnd request receive PCCtrCl response XCtrCl response > Counter receive gossip > Implementation - Software: I2S

57 OD-56 CSE333 [COMP_CLASS] Comp_Class Comp_Type class : COMP_CLASS superclasses : P Comp_Class cl_call : Comp_Class  INTERFACE  cc  superclasses  cc.Comp_Type  supertypes  (cc  i)  cl_call   (ct  i)  calls | cc.Comp_Type = ct Implementation - Software: I2S

58 OD-57 CSE333 I2_S I1_S c_classes : P Comp_Class  cc,cc’  c_classes  cc.class = cc’.class  cc = cc’ c_classes.Comp_Type  comp_types  cc  c_classes  cc.superclasses  c_classes  (cc  i)  c_classes.cl_call  cc  c_classes Implementation - Software: I2S

59 OD-58 CSE333 Implementation - Hardware: I2H  Node Classes   Node Type   Class  Connector Classes   Type   Class  Connections Between Node Classes  Properties   Node and Connector Classes Refine the Types in I1H   Connections are With Connector Classes That Refine Connector Types in I1H

60 OD-59 CSE333 SUN Intel Pentium MPI Sockets SUN OS 4.1.4 Win95 MPI_Impl CSockets > Implementation - Hardware: I2H

61 OD-60 CSE333 [NODE_CLASS] Node_Class Node_Type class : NODE_CLASS [CONN_CLASS] Conn_Class Conn_Type class : CONN_CLASS I2_H I1_H node_classes : P Node_Class conn_classes : P Conn_Class connects_cl : Conn_Class  P Node_Class node_classes.Node_Type  node_types conn_classes.Conn_Type  conn_types  (cc  nc_set)  connects_cl   1 (ct  nt_set)  connects | cc.Conn_Type = ct  nc_set.NodeType  nt_set Implementation - Hardware: I2H

62 OD-61 CSE333 Software and Hardware Integration: I3  Relation >   Instances of the Component Class May Run on Instances of the Node Class   Important Step Since it Constrains Deployment Options  Properties   Only Node and Component Classes Defined in I2 Can Participate of the > Relation

63 OD-62 CSE333 XFrontEnd request PCCtrCl response XCtrCl response SUN OS 4.1.4 Win95 MPI_Impl CSockets receive gossip Counter > receive Software and Hardware Integration: I3

64 OD-63 CSE333 I3 I2 supports : Comp_Class  Node_Class (dom supports)  c_classes (ran supports)  node_classes Software and Hardware Integration: I3

65 OD-64 CSE333 Instantiation - Software: I4S  Component Instances   Class   Identification   Calls  Properties   Instance Calls Refine Class Calls   Only Classes in I2S May Be Instantiated

66 OD-65 CSE333 c4:XCtrCl c3:PCCtrCl c2:PCCtrCl c1:PCCtrCl ct1:Counter receive gossip ct2:Counter ct3:Counter ct4:Counter ct5:Counter receive gossip receive gossip receive gossip receive gossip ct6:Counter receive gossip response fe1:XFrontEnd receiverequest fe2:XFrontEnd receiverequest Instantiation - Software: I4S

67 OD-66 CSE333 [INST_COMP] Inst_Comp Comp_Class inst_id : INST_COMP inst_call : Inst_Comp  INTERFACE  (ic  i)  inst_call   (cc  i)  cl_call | ic.Comp_Class = cc I4_S I2_S i_comp : P Inst_Comp  ic,ic’  i_comp  ic.inst_id= ic’.inst_id  ic = ic’ i_comp.Comp_Class  c_classes (dom i_comp.inst_call)  i_comp.interface Instantiation - Software: I4S

68 OD-67 CSE333 Instantiation - Hardware: I4H  Node Instances   Class   Identification  Connector Instances   Class   Identification   Set of Connected Nodes  Properties   There are Only Instances of the Node & Connector Classes Defined in I2H   Connectors Refine I2H Connections

69 OD-68 CSE333 sun6: SunOS4.1.4 sun7: SunOS4.1.4 sun8: SunOS4.1.4 sun9: SunOS4.1.4 sun10: SunOS4.1.4 sun1: SunOS4.1.4 sun2: SunOS4.1.4 sun3: SunOS4.1.4 sun4: SunOS4.1.4 sun5: SunOS4.1.4 pc1:Win95pc2:Win95pc3:Win95pc4:Win95 sock1sock2sock3sock4 mpi1 Instantiation - Hardware: I4H

70 OD-69 CSE333 Inst_Node Node_Class int_id : INST_NODE Inst_Conn Conn_Class inst_id : INST_CONN inst_nodes : P Inst_Node I4_H I2_S nodes : P Inst_Node conns : P Inst_Conn nodes.Node_Class  node_classes conns.Conn_Class  conn_classes  ic  conns  ic.inst_nodes  nodes  in,in’  nodes  in.inst_id = in’.inst_id  in = in’  ic,ic’  conns  ic.inst_id = ic’.inst_id  ic = ic’  ci  conns   (cc  nc_set)  connects_cl | ci.Conn_Class = cc  (ci.inst_nodes).Node_Class  nc_set Instantiation - Hardware: I4H

71 OD-70 CSE333 I4 I3 I4_S I4_H  ic  i_comp   in  nodes | (ic.class  in.class)  supports Instantiation: I3 + Hardware + Software

72 OD-71 CSE333  A Set of Component Instances Must Be Deployed Together or Separated  Fix the Location of Some Component Instances  All Installation Requirements Must Be Consistent With the Requirements Imposed by All the Previous Specification Levels Installation Requirements

73 OD-72 CSE333 Installation - Requirements: I fix, I separated  Requirements   Together   Separated   Fix  Complete Deployment  Properties   All Component, Node and Connector Instances Identified in I4 Must Be Part of the Complete Deployment   Deployment is Consistent With All of Requirements   Nodes “Support” the Component Instances That are There Assigned

74 OD-73 CSE333 Installation - Requirements: I fix, I separated fe2:XFrontEnd receive request fe1:XFrontEnd receive request sun2:SunOS4.1.4sun3:SunOS4.1.4 separated = {ct1:Counter, ct2:Counter, ct3:Counter, ct4:Counter, ct5:Counter, ct6:Counter}

75 OD-74 CSE333 Complete Installation : I5  All Node and Component Instances Form the Complete Installation  Each Component Instance is Deployed to One and Only One Node in the Network  Node Classes Must Support the Class of Components It is Assigned  It Must Satisfy the Installation Requirements  (We Postpone the Graphical Representation Until We Calculate the Optimal Deployment)

76 OD-75 CSE333 I5 I4 together : P (P Inst_Comp) separated : P (P Inst_Comp) fix : Inst_Comp  Inst_Node deployment : Inst_Comp  Inst_Node (dom deployment) = i_comp (ran deployment)  nodes  (c  n)  deployment  (c.class  n.class)  supports fix  deployment  i_set  together  i_set  i_comp  i_set  separated  i_set  i_comp  i_set  together;  ic,ic’  i_set  deployment(ic) = deployment(ic’)  i_set  separated;  ic,ic’  i_set  deployment(ic)  deployment(ic’) Complete Installation : I5

77 OD-76 CSE333 Distributed Systems Deployment Goal  Premise:  Distributed Application Comprised of Multiple Interacting Components  Target Platform of Networked Computing Nodes  Problem:  Is it possible to Deploy Components Onto Targeted Platform in an Optimal Fashion?  Can Optimal Deployment that Satisfies Both Software Requirements and Hardware Limits be Attained?  Approach: Focus on Messages - Both Throughput and Frequency

78 OD-77 CSE333 Optimizing with the BIP Model  An Initial Deployment is Suggested by the Model  Optimization is Only With Respect to the Chosen Criterion  Complexity of the Algorithm Makes the Procedure Useful for Small Systems  Fixing the Location of Some Components Dramatically Reduces the Search Space  We Think That the Most Important Application for Our BIP Model is the Study of What If Cases

79 OD-78 CSE333 Two Optimization Models and Their Criteria

80 OD-79 CSE333 Model 1: Local vs. Remote Communication Local Less Expensive FasterSaferRemote More Expensive Slower Fault Prone But Distribution Improves the Opportunities for Parallelism and Availability of Resources Where They Are Necessary

81 OD-80 CSE333  Units Storage:  Communication Between Units:  Node Storage and Connector Capacity Model 1: Parameters Storage and Communication

82 OD-81 CSE333 Model 1: Deployment Constraints General:  Each Unit is Deployed to Only One Node  Storage for All Units Deployed to the Same Node Does Not Exceed the Node’s Available Storage  Communication Occurs Through Direct Connectors Between Nodes  No Connector’s Throughput Exceeds Its Capacity Particular:  Any Unit’s Location Can Be Fixed to a Certain Node (or a Set of Nodes)

83 OD-82 CSE333 Model 1: BIP Model for Optimal Deployment Decision Variables: x ij = 1 if component i is assigned to node j 0 otherwise 1 if component a is assigned to node i 1 if component a is assigned to node i y aibj = and component b is assigned to node j y aibj = and component b is assigned to node j 0 otherwise 0 otherwise Necessary Constraints: (y aibj = x ai * x bj ) y aibj  x ai y aibj  x ai y aibj  x bj y aibj  x bj 1 + y aibj  x ai + x bj 1 + y aibj  x ai + x bj { {

84 OD-83 CSE333 Model 1: BIP Model for Optimal Deployment Constraints:  Completeness  Storage  Communication

85 OD-84 CSE333 Model 1: Objective Function

86 OD-85 CSE333 Model 1: The Example 5000 3000 20000 2000 1000 9000 100 12000 100 5000 BASE1BASE2 USER1USER2 US COMM

87 OD-86 CSE333 Model 1: The Solution  X PATH,USER2 = 1 Z = 1200 + 8000 = 9200

88 OD-87 CSE333 Model 1: The Solution  PATH can be Located in Any Node Z = 8000

89 OD-88 CSE333 Optimization Criteria

90 OD-89 CSE333 Model 2: Parameters: Architecture + Usage Patterns  SUPP(C x N) - A Component is Supported by a Node  MSGS(C x C) - Number of Messages Between a Pair of Components  HOPS(N X N) - Hops Between a Pair of Nodes

91 OD-90 CSE333 Model 2: Decision Variables  C x N Primary Decision Variables  C 2 N 2 Auxiliary Decision Variables

92 OD-91 CSE333 Model 2: Derived Equations  X ij and Y aibj Are Related:  and This Relationship Can Be Restated Linearly As Follows:

93 OD-92 CSE333 Model 2: Equations: System’s Constraints  Completeness - All Instance Components Must Be Deployed & Only Over Instance Nodes  Supportability - Instance Nodes Must Support the Components Assigned  Requirements - Complete Deployment Must Satisfy the Fix, Separated & Together Installation Requirements

94 OD-93 CSE333 Model 2: Objective Function

95 OD-94 CSE333 A Second Example in I 5 Modeling a System  Conceptually Based on an Essentially Serializable Data Service (ESDS)  Demonstration of  Modeling Capabilities of I 5  Verification of Work Utilizing Genetic Algorithm  Joint Research with Bastarrica and Cabellero  Published in Software Engineering/Knowledge Engineering Conference 01  See Course web page for paper

96 OD-95 CSE333 What is ESDS?  ESDS is a Replicated Data Service Dealing with  Replicated Objects Allowing clients of Service to Relax Consistency Requirements for Improved Responsiveness  Simultaneously Provide Guarantees of Eventual Consistency of Replicated Data  ESDS Implementation Includes  Parameterizable Number of Client, Front-End, and Replicated Components  Each can have Different Communication Patterns  Each can be Individually Deployed in a Target Network

97 OD-96 CSE333 Modeling ESDS using I 5  ESDS Deals with Replicated Objects and Trades Short-Term Consistency (lack of) for Performance  ESDS Guarantees Eventual Consistency of Replicas  In ESDS Replicas  Keep Order of Known Data Operations  Implemented as Individually Deployable Components  Periodically Exchange Knowledge in Gossip Messages  Clients Interact with Users of the Service  Front-Ends Broker Communication Between Clients and Replicas

98 OD-97 CSE333 Software Interface : I1S comp_types = {Client, FrontEnd, Replica}

99 OD-98 CSE333 Hardware Interface : I1H node_types = {Sun, Intel Pentium} conn_types = {MPI, Sockets} connects = {(MPI  {Sun, Sun}), (Sockets  {Sun, Intel Pentium})}

100 OD-99 CSE333 Software Implementation :I2S c_classes = {PCCtrCl, XCtrCl, XFrontEnd, Counter} ---- Clients ----------FrontEnd--Replica

101 OD-100 CSE333 Hardware Implementation:I2H node_classes = {SUN OS 4.1.4, Win95} conn_classes = {MPI_Impl, CSockets} connects_cl = {(MPI_Impl  {SUN OS 4.1.4, SUN OS 4.1.4}), (CSockets  {SUN OS 4.1.4, Win95}}

102 OD-101 CSE333Integration:I3 supports = {(Counter  Sun OS 4.1.4), (XFrontEnd  Sun OS 4.1.4), (XCtrCl  Sun OS 4.1.4), (PCCtrCl  Win95)}

103 OD-102 CSE333 Software Instantiation: I4S i_comp ={c1:PCCtrCl, c2:PCCtrCl, c3:PCCtrCl, c4:PCCtrCl, fe1:XFrontEnd, fe2:XFrontEnd, ct1:Counter, ct2:Counter, ct3:Counter, ct4:Counter, ct5:Counter, ct6:Counter, }

104 OD-103 CSE333 Hardware Instantiation: I4H nodes = {pc1:Win95, pc2:Win95, pc3:Win95, pc4:Win95, sun1:SunOS4.1.4, sun2:SunOS4.1.4, sun3:SunOS4.1.4, sun4:SunOS4.1.4, sun5:SunOS4.1.4, sun6:SunOS4.1.4, sun7:SunOS4.1.4, sun8:SunOS4.1.4, sun9:SunOS4.1.4, sun10:SunOS4.1.4 } conns = {mpi, sock1, sock2, sock3, sock4}

105 OD-104 CSE333 Assumptions Assumptions  Communication Frequency Between Client and FrontEnd Components in ESDS  Components that Must be Separated and Fixed

106 OD-105 CSE333 SUPP Matrix  Matrix of Software Components Supported by Hardware Nodes

107 OD-106 CSE333 MSGS Matrix  Only One Types of Message Between Every Pair of Component Instances in ESDS  As a Consequence, the Value is the frequency of the Message

108 OD-107 CSE333 The HOPS Matrix  Contains the Minimum Number of Hops Between Every Pair of Modes by Examining the ESDS Hardware Instantiation Previously Shown

109 OD-108 CSE333 BIP Optimal Deployment  Given the Above Tables, we can Apply the Previously Described Model 2  BIP Performs Exhaustive Search  Utilizes Branch and Bound Algorithm  Complexity is O(N C ) - Exponential  Execution Time:  C Program Required 2 Hours of Computation Time for Optimal Solution on Model 2  GAMS Package Executed for Entire Day without Results  Even for “Small” Problem, Optimal Deployment is a Complex Task

110 OD-109 CSE333 Installation: I5 What is the Optimal Deployment?

111 OD-110 CSE333 Utilize Genetic Algorithm for Deployment  Genetic Algorithms (GAs) are Stochastic Search Techniques Inspired by Evolution  GAs Used to Find Global or Near Optimal Solution for Complex Multi-Dimensional Spaces  GA Utilizes Operations for: Selection, Crossover, and Mutation to Simulate the Evolutionary Process  Manipulate Individuals of Population  Each Generation of Population is Replaced via a Fitness Function  Fitness Function Evaluates Degree that Chromosome Meets Solution  In Our Case, Fitness Function Evaluates Optimal Deployment by Focusing on MSGSs/HOPS

112 OD-111 CSE333 Multiobjective Niching Genetic Algorithm (MNGA)  GA for Evaluating Optimal Deployment of Components on Nodes  Run Multiple Experiments, and For Each Run, May Identify Multiple Solutions  On Average, First Solution (194 messages) found in Generation 29  Same Solution as BIP  Due to Symmetry of Problem, GA found Many Other Solutions for 194 Messages  Why GA over BIP?  Performance, Performance, Performance  Ability to Work on Scaled up Problems

113 OD-112 CSE333 Performance of GA  Table Below Summarizes the Results of Multiple GA Experiments  Note that 13.1 Seconds (GA) vs. 2 hrs. (BIP)for Problem as Presented in this Paper  Other Case Increased Components and/or Increased Nodes  Notice that Increasing Nodes with 12 Components Doesn’t Alter Optimal Solution (194 messages)

114 OD-113 CSE333 Conclusion: Model 2 - BIP vs. GA  BIP vs. GA  BIP Yields Optimal Solutions at a Cost However, Problem is Intractable as System Grows in Terms of Components and/or Nodes  GA Doesn’t Guarantee Optimality However, Can Provide Solution in Reasonable Time for Larger Scale Problems  Moral  Optimal Deployment is an Important Problem for Distributed Applications  However, must use MNGA without Guarantee of Optimality  May be Only Choice as Complexity Grows

115 OD-114 CSE333 A Third Example in I 5 Modeling a System  Conceptually Based on the Virginia-class Submarine Data Distribution System  Composed of Several Subsystems  Consumers Are Decoupled From Suppliers Using a Typed Event Channel:  One Supplier Pushes Event Data to Multiple Consumers  Servers Use Typed Event Channels to Distribute Notifications of Changes to Available Data  Typed Event Channels Are Also Used to Deliver Signals and Distribute Periodic Updates

116 OD-115 CSE333 Software Interface : I1S SettCons SettEC SettSupp SettingsUpdate_ev SettingsSignal_ev SettingsUpdate_ev SettingsSignal_ev Settings_cs comp_types = {SettCons, SettEc, SettSupp}

117 OD-116 CSE333 Hardware Interface : I1H ConsNode EthernetHub ECNode ATMSwitch SuppNode 10BaseT Fiber node_types = {ConsNode, ECNode, EthernetHub, ATMSwitch, SuppNode} conn_types = {10BaseT, Fiber} connects = {(Fiber  {ConsNode, ATMSwitch}), (Fiber  {ECNode, ATMSwitch}), (Fiber  {SuppNode, ATMSwitch}), (Fiber  {ATMSwitch, EthernetHub}), (Fiber  {ATMSwitch}), (10BaseT  {ConsNode, EthernetHub})}

118 OD-117 CSE333 Software Implementation :I2S SettConsIC1SettConsIC2 SettECIC SettSuppIC SettingsUpdate_ev SettingsSignal_ev SettingsUpdate_ev SettingsSignal_ev SettingsUpdate_ev SettingsSignal_ev Settings_cs c_classes = {SettConsIC1, SettConsIC2, SettECIC, SettSuppIC}

119 OD-118 CSE333 Hardware Implementation:I2H ConsNodeIC2 EthernetHubIC ECNodeIC ATMSwitchIC SuppNodeIC 10BaseTICFiberIC ConsNodeIC1 node_classes = {ConsNodeIC1, ConsNodeIC2, ECNodeIC, EthernetHubIC, ATMSwitchICm SuppNodeIC} conn_classes = {10BaseTIC, FiberIC} connects_cl = {(10BaseTIC  ConsNodeIC2, EthernetHubIC}), (FiberIC  {ConsNodeIC1, ATMSwitchIC}), (FiberIC  {ECNodeIC, ATMSwitch}), (FiberIC  {EthernetHubIC, ATMSwitchIC}), (FiberIC  {ATMSwitch, SuppNodeIC}), (FiberIC  {ATMSwitch})}

120 OD-119 CSE333Integration:I3 ConsNodeIC2 EthernetHubIC ECNodeIC ATMSwitchIC SuppNodeIC 10BaseTICFiberIC ConsNodeIC1 SettConsIC2 SettConsIC1 SettECIC SettSuppIC > supports = {(SettConsIC1  ConsNodeIC1), (SettConsIC2  ConsNodeIC2), (SettECIC  ECNodeIC), (SettSuppIC  SuppNodeIC)}

121 OD-120 CSE333 Software Instantiation: I4S :SettConsIC1 host1 :SettConsIC2 host2 :SettConsIC2 :SettECIC :SettSuppIC i_comp = {:SettConsIC1, :SettECIC, host1:SettConsIC2, host2:SettConsIC2, :SettSuppIC}

122 OD-121 CSE333 Hardware Instantiation: I4H host1: ConsNodeIC2 :EthernetHubIC :ECNodeIC switch2 :ATMSwitchIC env: SuppNodeIC 10BaseTIC1FiberIC1FiberIC3 FiberIC2 FiberIC4 FiberIC5 :ConsNodeIC1 switch1 :ATMSwitchIC host2: ConsNodeIC2 sett: SuppNo deIC 10BaseTIC2 FiberIC6 nodes = {:ConsNodeIC1, :ECNodeIC, host1:ConsNodeIC2, :EthernetHubIC, host2:ConsNodeIC2, switch1:ATMSwitchIC, switch2:ATMSwitchIC, env:SuppNodeIC, sett:SuppNodeIC} conns = {10BaseTIC1, 10BaseTIC2, FiberIC1, FiberIC2, FiberIC3, FiberIC4, FiberIC5, FiberIC6}

123 OD-122 CSE333 Installation: I5 host1:ConsNodeIC2 :EthernetHubIC :ECNodeIC switch2 :ATMSwitchIC env: SuppNodeIC 10BaseTIC1FiberIC1FiberIC3 FiberIC2 FiberIC4 FiberIC5 :ConsNodeIC1 switch1 :ATMSwitchIC host2:ConsNodeIC2 sett:SuppNodeIC 10BaseTIC2 FiberIC6 host1: SettConsIC2 host2: SettConsIC2 :SettConsIC1:SettECIC :SettSuppIC Deployment = {(:SettConsIC1  :ConsNodeIC1), (host1:SettConsIC2  host1:ConsNodeIC2), (host2:SettConsIC2  host2:ConsNodeIC2), (:SettECIC  :ECNodeIC), (:SettSuppIC  sett:SuppNodeIC)}

124 OD-123 CSE333 Conclusions on this Example  The I 5 Textual Notation Was Used to Specify a Corba-based Distributed System  Documenting the Design of New and Existing Distributed Systems  Precision in Inheritance Hierarchy Specifications  Traceability -- Important for Maintenance  Configuration Management  Leveraging UML

125 OD-124 CSE333 Prototyping Example  Current UML Tools Have Weak Support for Diagrams Used for the I 5 Graphical Notation  Developed a Graphical Tool to Support I 5  Prototype Tool with Basic I 5 Capabilities  Revealed Limitations in the Ability of UML to Capture All Aspects of the Textual Notation  Work was Halted  Still Interested in Pursuing Given Current Capabilities of UML Tools and their Extensibility

126 OD-125 CSE333 Conclusions and Future Work  An Integrated Framework for Designing and Deploying Distributed Systems  A Consistent Methodology for Using UML’s Implementation Diagrams  A Concrete Measure of Performance for a Distributed System  Utilizing the Prediction of Performance of a Distributed System to Assist in its Deployment

Download ppt "OD-1 CSE333 Architectural Specification and Optimal Deployment of Distributed Systems Profs. S. Demurjian and A. Shvartsman Computer Science & Engineering."

Similar presentations

Ads by Google