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_at_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_at_engr.uconn.edu http//www.engr.uconn.edu/st
eve (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
hardware elements
interaction patterns
software elements
connections
Specification
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
• OSFs I4DL
• UML and Design Concepts
• The I5 Framework
• A First Look at I5s 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
• Well Employ both UML and Z!

24
I5 Background and Sources

• OSFs I4DL- Distributed Systems Defined With 4
  Definition Languages (2 Pages)
• Interface
• Inheritance
• Implementation
• Instantiation
• UMLs 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 UMLs 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
  (OMGs 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 havent 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 dont 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, Im 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
Pros and Cons ofGraphical 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

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
• Well 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

• Implementation Constraints State the Class of
  Node Where Each Implementation Class of Component
  Should Run

stereotypes
classes
41
A First Look at the Instantiation Level
INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION
INSTALLATION

• 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
Installation Requirements

• Types of Requirements
• Fix the Location of Certain Instance
  Components
• Two or More ComponentsMust Be Deployed Together

puzzle PUZZLE
slist1 SLIST
user2USER
45
Complete Installation
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
INTERFACE
IMPLEMENTATION
Implementation Dependencies
INTEGRATION
INSTANTIATION
System 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
Client
response
ltltcallgtgt
ltltcallgtgt
request receive
FrontEnd
ltltcallgtgt
ltltcallgtgt
receive gossip
Replica
ltltcallgtgt
50
Interface - Software I1S
51
Interface - Software I1S
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
52
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

53
Interface - Hardware I1H
54
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

55
Implementation - Software I2S
ltltcallgtgt
ltltcallgtgt
ltltcallgtgt
receive gossip
Counter
ltltcallgtgt
56
Implementation - Software I2S
57
Implementation - Software I2S
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
58
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

59
Implementation - Hardware I2H
ltltrealizesgtgt
ltltrealizesgtgt
MPI_Impl
CSockets
SUN OS 4.1.4
Win95
60
Implementation - Hardware I2H
61
Software and HardwareIntegration I3

• Relation ltltsupportsgtgt
• 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 ltltsupportsgtgt Relation

62
Software and HardwareIntegration I3
ltltsupportsgtgt
ltltsupportsgtgt
MPI_Impl
request
Win95
SUN OS 4.1.4
CSockets
ltltsupportsgtgt
receive
ltltsupportsgtgt
Counter
63
Software and HardwareIntegration I3
64
Instantiation - Software I4S

• Component Instances
• Class
• Identification
• Calls

• Properties
• Instance Calls Refine Class Calls
• Only Classes in I2S May Be Instantiated

65
Instantiation - Software I4S
receive
receive
request
ct1Counter
gossip
receive
response
ct2Counter
c1PCCtrCl
gossip
fe1XFrontEnd
receive
response
ct3Counter
gossip
c2PCCtrCl
receive
ct4Counter
response
receive
request
gossip
c3PCCtrCl
receive
ct5Counter
response
gossip
c4XCtrCl
66
Instantiation - Software I4S
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
67
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

68
Instantiation - Hardware I4H
69
Instantiation - Hardware I4H
70
Instantiation I3 Hardware Software
71
Installation Requirements

• 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

72
Installation - Requirements Ifix, Iseparated

• 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

73
Installation - Requirements Ifix, Iseparated
receive
receive
fe2XFrontEnd
fe1XFrontEnd
request
request
sun2SunOS4.1.4
sun3SunOS4.1.4
separated ct1Counter, ct2Counter,
ct3Counter, ct4Counter, ct5Counter,
ct6Counter
74
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)

75
Complete Installation I5
76
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

77
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

78
Two Optimization Modelsand Their Criteria
79
Model 1 Local vs. Remote Communication

• Local
• Less Expensive
• Faster
• Safer

• Remote
• More Expensive
• Slower
• Fault Prone

But Distribution Improves the Opportunities for
Parallelism and Availability of Resources Where
They Are Necessary
80
Model 1 ParametersStorage and Communication

• Units Storage
• Communication Between Units
• Node Storage and Connector Capacity

81
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 Nodes Available Storage
• Communication Occurs Through Direct Connectors
  Between Nodes
• No Connectors Throughput Exceeds Its Capacity
• Particular
• Any Units Location Can Be Fixed to a Certain
  Node (or a Set of Nodes)

82
Model 1 BIP Model for Optimal Deployment

• Decision Variables
• xij 1 if component i is assigned to node j
• 0 otherwise
• 1 if component a is assigned to node i
• yaibj and component b is assigned to
  node j
• 0 otherwise
• Necessary Constraints (yaibj xai xbj)
• yaibj ? xai
• yaibj ? xbj
• 1 yaibj ? xai xbj

83
Model 1 BIP Model for Optimal Deployment

• Constraints
• Completeness
• Storage
• Communication

84
Model 1 Objective Function
85
Model 1 The Example
USER1
USER2
5000
100
100
1000
US
9000
3000
2000
BASE1
BASE2
20000
12000
5000
COMM
86
Model 1 The Solution

• XPATH,USER2 1

Z 1200 8000 9200
87
Model 1 The Solution

• PATH can be Located in Any Node

Z 8000
88
Optimization Criteria
89
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

90
Model 2 Decision Variables

• C x N Primary Decision Variables
• C2N2 Auxiliary Decision Variables

91
Model 2 Derived Equations

• Xij and Yaibj Are Related
• and This Relationship Can Be Restated Linearly As
  Follows

92
Model 2 Equations Systems 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

93
Model 2 Objective Function
94
A Second Example in I5 Modeling a System

• Conceptually Based on an Essentially Serializable
  Data Service (ESDS)
• Demonstration of
• Modeling Capabilities of I5
• 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

95
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

96
Modeling ESDS using I5

• 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

97
Software Interface I1S
comp_types Client, FrontEnd, Replica
98
Hardware Interface I1H
node_types Sun, Intel Pentium conn_types
MPI, Sockets connects (MPI ? Sun, Sun),
(Sockets ? Sun, Intel Pentium)
99
Software Implementation I2S
c_classes PCCtrCl, XCtrCl, XFrontEnd,
Counter ---- Clients
----------FrontEnd--Replica
100
Hardware ImplementationI2H
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
101
IntegrationI3
supports (Counter ? Sun OS 4.1.4), (XFrontEnd
? Sun OS 4.1.4), (XCtrCl ? Sun OS 4.1.4),
(PCCtrCl ? Win95)
102
Software Instantiation I4S
i_comp c1PCCtrCl, c2PCCtrCl, c3PCCtrCl,
c4PCCtrCl, fe1XFrontEnd, fe2XFrontEnd,
ct1Counter, ct2Counter, ct3Counter,
ct4Counter, ct5Counter, ct6Counter,
103
Hardware Instantiation I4H
nodes pc1Win95, pc2Win95, pc3Win95,
pc4Win95, sun1SunOS4.1.4, sun2SunOS4.1.4,
sun3SunOS4.1.4, sun4SunOS4.1.4,
sun5SunOS4.1.4, sun6SunOS4.1.4,
sun7SunOS4.1.4, sun8SunOS4.1.4,
sun9SunOS4.1.4, sun10SunOS4.1.4 conns mpi,
sock1, sock2, sock3, sock4
104
Assumptions

• Communication Frequency Between Client and
  FrontEnd Components in ESDS
• Components that Must be Separated and Fixed

105
SUPP Matrix

• Matrix of Software Components Supported by
  Hardware Nodes

106
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

107
The HOPS Matrix

• Contains the Minimum Number of Hops Between Every
  Pair of Modes by Examining the ESDS Hardware
  Instantiation Previously Shown

108
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(NC) - 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

109
Installation I5What is the Optimal Deployment?
110
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

111
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

112
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
  Doesnt Alter Optimal Solution (194 messages)

113
Conclusion Model 2 - BIP vs. GA

• BIP vs. GA
• BIP Yields Optimal Solutions at a CostHowever,
  Problem is Intractable as System Grows in Terms
  of Components and/or Nodes
• GA Doesnt 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

114
A Third Example in I5 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

115
Software Interface I1S
SettingsUpdate_ev
SettCons
SettingsSignal_ev
SettingsUpdate_ev
SettEC
SettingsSignal_ev
Settings_cs
SettSupp
comp_types SettCons, SettEc, SettSupp
116
Hardware Interface I1H
node_types ConsNode, ECNode, EthernetHub,
ATMSwitch, SuppNode conn_types 10BaseT,
Fiber connects (Fiber ? ConsNode,
ATMSwitch), (Fiber ? ECNode, ATMSwitch), (Fibe
r ? SuppNode, ATMSwitch), (Fiber ? ATMSwitch,
EthernetHub), (Fiber ? ATMSwitch), (10BaseT
? ConsNode, EthernetHub)
117
Software Implementation I2S
SettingsUpdate_ev
SettingsUpdate_ev
SettConsIC1
SettConsIC2
SettingsSignal_ev
SettingsSignal_ev
SettingsUpdate_ev
SettECIC
SettingsSignal_ev
SettSuppIC
Settings_cs
c_classes SettConsIC1, SettConsIC2, SettECIC,
SettSuppIC
118
Hardware ImplementationI2H
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)
119
IntegrationI3
supports (SettConsIC1 ? ConsNodeIC1),
(SettConsIC2 ? ConsNodeIC2), (SettECIC ?
ECNodeIC), (SettSuppIC ? SuppNodeIC)
120
Software Instantiation I4S
i_comp SettConsIC1, SettECIC, host1SettCons
IC2, host2SettConsIC2, SettSuppIC
121
Hardware Instantiation I4H
host1 ConsNodeIC2
host2 ConsNodeIC2
ECNodeIC
ConsNodeIC1
10BaseTIC1
FiberIC1
FiberIC3
10BaseTIC2
FiberIC2
FiberIC6
switch1 ATMSwitchIC
switch2 ATMSwitchIC
EthernetHubIC
nodes ConsNodeIC1, ECNodeIC, host1ConsNodeI
C2, EthernetHubIC, host2ConsNodeIC2,
switch1ATMSwitchIC,
switch2ATMSwitchIC, envSuppNodeIC,
settSuppNodeIC conns 10BaseTIC1, 10BaseTIC2,
FiberIC1, FiberIC2, FiberIC3, FiberIC4,
FiberIC5, FiberIC6
FiberIC4
FiberIC5
env SuppNodeIC
sett SuppNodeIC
122
Installation I5
host1ConsNodeIC2
Deployment (SettConsIC1 ? ConsNodeIC1),
(host1SettConsIC2 ? host1ConsNodeIC2),
(host2SettConsIC2 ? host2ConsNodeIC2),
(SettECIC ? ECNodeIC), (SettSuppIC ?
settSuppNodeIC)
123
Conclusions on this Example

• The I5 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

124
Prototyping Example

• Current UML Tools Have Weak Support for Diagrams
  Used for the I5 Graphical Notation
• Developed a Graphical Tool to Support I5
• Prototype Tool with Basic I5 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

125
Conclusions and Future Work

• An Integrated Framework for Designing and
  Deploying Distributed Systems
• A Consistent Methodology for Using UMLs
  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