PDSG - NYU 1
Partitionable Services Framework: Seamless access to distributed applications
deployed in heterogeneous environments
Anca-Andreea Ivan
Advisor: Vijay Karamcheti
Computer Science Department
New York University
PDSG - NYU 2
Motivation
Trends: Designing component-based applications (CORBA, .NET,
Globus) Deploying applications in heterogeneous environments
Heterogeneous environments: Environment composed of nodes and links organized in
multiple administrative domains Nodes and links exhibit diverse properties:
• Links – variable bandwidth, latency
• Nodes – variable CPU, memory, operating system
Nodes, links, and their properties change in time and space: e.g. mobility
PDSG - NYU 3
Problem: Seamless access to distributed applications
Hard to write and deploy distributed applications such that users seamlessly access services Seamless access i.e. the quality of service (QoS)
requirements specified by users are satisfied Current systems are very complex and provide only
partial solutions: e.g. CORBA, DCOM
Ideally, one would like to: Design flexible applications Automatically choose the appropriate application
deployment that ensures seamless access to services
PDSG - NYU 4
Our solution: Partitionable Services Framework
PSF uses the first trend (i.e. designing applications as sets of components) as a solution to these problems.
PSF facilitates seamless access to services by: Deploying services into the network Creating appropriate connections
Given: Current state of the network Application description User’s QoS requirements
PDSG - NYU 5
Roadmap
Motivation Problem: Seamless access to distributed applications Our solution: Partitionable Services Framework (PSF)
Architecture Modules Evaluation
Related work Contributions and future plans
PDSG - NYU 6
Example: Web-based mail application Components
QoS requirements: Qualitative: security, access to various services Quantitative: bandwidth, CPU,
minimum operation time (send/receive),
number of messages/time
CipherWeak Mail
Client
Mail ClientCache
Mail ServerMail Server
PDSG - NYU 7
Deploying the mail application into the network
Insecure, slow link
Secure, fast link
Secure, slow link
CipherWeak Mail
Client
ClientCache
Mail Server
Server
A
B
C
PDSG - NYU 8
Partitionable Services Framework (PSF) Architecture overview
Insecure, slow link
Secure, fast link
Wrapper
Wrapper Wrapper
Wrapper
Wrapper
Wrapper
PSF Manager
1. register
application
Service Description
2. m
ake
req
ues
t
3. find plan
4. deploy comp
5. connect
4. d
eplo
y co
mp
4. deploy comp
PDSG - NYU 9
Physiology of PSF
Basic functionality: Modeling application/network properties and behaviors
(qualitative and qualitative) Planning, i.e. finding valid applications deployments Securely deploying applications into the network
Extensions: Views = component customizations Increase the chances of successfully finding a plan Permit efficient maintenance of consistency between
components Provide flexible, fine-grain access control
PDSG - NYU 10
Problem 1:Describing the application and the network
Challenges: Describing application properties and behaviors Capturing the effects of the network on the application Extending CPU-like QoS requirements (e.g. security) Extracting information from the network
Our solution:
PSF application and network models (HPDC 2002)
PDSG - NYU 11
PSF application and network specification models
PSF models use general, quantitative and qualitative properties, belonging to different namespaces.
Network contains nodes and by links associated with properties: Nodes – e.g. OS, software version, CPU Links – e.g. security, bandwidth, latency
Applications are defined as set of components Linkage information Deployment requirements and effects Effects of the network over the application and vice-versa
PDSG - NYU 12
Component linkages are defined as: Implemented interfaces (i.e. component functionality) Required interfaces (i.e. services required for correct
execution)
PSF application model: Component linkages
MSIMSI
MSIe MSIMSIeMSI
MSI
MSI MCI
MSI MCI
PDSG - NYU 13
How to specify deployment requirements and effects?
Win XP
CPU = 100
Linux
CPU = 60 56Kbps, Secure = false
MSI
Secure = true
NumReq = 200
Deployment requirements:
Node.CPU > 50 units
Node.OS = Win XP
Win XP
CPU = 50
Deployment effects:
Node.CPU = 50 units
MSI.Secure = true
MSI.NumReq = 200
MSI.ReqSize = 1 Kb
PDSG - NYU 14
How to specify link crossing requirements and effects?
Linux
CPU = 60 56Kbps, Secure = false
MSI
Secure = true
NumReq = 200
MSI
Secure = false
NumReq = 56
Deployment requirements:
Node.CPU > 50 units
Node.OS = Win XP
Deployment effects:
Node.CPU = 50 units
MSI.Secure = true
MSI.NumReq = 200
MSI.ReqSize = 1 Kb
Win XP
CPU = 50
Link crossing requirements:
Link.BW > 2Mb/s
Link crossing effects:
Link.BW = MSI.NumReq * MSI.ReqSize
MSI.NumReq = min( MSI.NumReq,
Link.BW / MSI.ReqSize )
MSI.Secure = MSI.Secure & Link.Secure
MSI.ReqSize = MSI.ReqSize
0Kbps, Secure = false
PDSG - NYU 15
Problem 2: Finding a valid deployment plan
Challenges: Searching for valid component compositions Satisfying network and application resource constraints Scaling with size of network and size of application Expressing deployment requirements and effects
Our solution:
AI-based planning algorithm (IPDPS 2003)
(joint work with Tatiana Kichkaylo)
PDSG - NYU 16
Contributions of the planning algorithm
Deploys dynamically created DAGs of components Satisfies application requirements given the network state Guarantees minimum planning cost
Allows monotonic functions to express requirements and effects
Scales with: Network size (number of links and nodes) Size of the application (number of components) Number of relevant vs. irrelevant components
Reuses existing deployments
PDSG - NYU 17
Problem 3: Securely deploying applications
Challenges: Different domains → administrators → namespaces No centralized certification authority No total knowledge about all namespaces
Our solution:
PSF deployment infrastructure (HPDC 2003)
PDSG - NYU 18
Contributions of PSF deployment infrastructure
Authorizes entities across multiple domains Distributed role based access control system (dRBAC)
Securely downloads and connects components Communication abstraction to create secure channels:
Switchboard
Monitors trust relationships between domains Switchboard
Translates properties between namespaces Distributed trust management system (dRBAC)
PDSG - NYU 19
Translating properties between namespaces
Intel NYU
PDSG
OS
secure
system
trusted
softwaresecure
[Intel.OS→ NYU.system]NYU [NYU.system → PDGS.software]PDSG
PDSG - NYU 20
PSF: From basic to extended functionality
So far: Models application and network specification formats Finds valid deployments Securely deploys application into networks
Problems: Chances of successful planning depend on component set Multiple instances of the same components might require
that data be kept consistent Access control to services should be fine-grained
Our solution: Views
PDSG - NYU 21
View Definition
Component c is defined as a tuple (FC , VC), where FC is the set of implemented functions and VC is the set of declared variables.
Def: A component v is a view of a component c if: or
Examples:
CacheMailServer is a data view of MailServer
WeakMailClient is an object view of MailClient
CV FF CV VV
PDSG - NYU 22
View Generation
VIG is an automatic view generator Input: original component and view definition rules Output: new component (i.e. view) Based on bytecode modifier (Javassist) Interactive tool to verify correctness of views
Operations allowed when defining a view: Add new fields; copy fields from the original component Add new methods; copy or customize methods from the
original component Restrict interfaces; add new interfaces Extend class or view
PDSG - NYU 23
View Descriptionclass
MessageInterface, AddressInterface , MeetingInterface
Vector recvMessage() { return server.getMessages(); }
void sendMessage( Message _mes ) { server.sendMessages( _mes ); }
void addMeeting( Time _t, Person _p ) {
Calendar cal = server.getCalendar( _p );
cal.requestMeeting( _t, this.name );
}
ContactInfo getInfo( String _name ) { String phoneNumber = server.getPhoneNumber();
String email = server.getEmailAddress();
return new ContactInfo( phoneNumber, email );
}
MailServer server;
}
{
MailClient
implements
view WeakMailClient represents MailClient
String email = server.getEmailAddress();
return new ContactInfo( email );
PDSG - NYU 24
Benefits of using views
Increase chances to find a valid deployment plan: Different properties of new components
Provide customized, single sign-on access control: Customizing / removing / adding operations Distributing minimum necessary code to users No need to access sources
Permit flexible consistency between multiple replicas
Ease the programming effort: Defining simple rules instead of duplicating code
PDSG - NYU 25
Flexible cache coherence protocol
Challenges: PSF deploys general distributed applications There might be consistency requirements for multiple
instances of the same component No assumptions can be made about the application
structure or data access patterns
Our solution:
Flexible cache coherence protocol
(submitted to IPDPS 2004)
PDSG - NYU 26
Consistency requirements for the mail application
Insecure, slow link
Secure, fast link
Secure, slow link
CipherWeak Mail
Client
ClientCache
Mail Server
Server
A
B
C
PDSG - NYU 27
Contributions of the cache coherence protocol
PSF employs a flexible and neutral cache coherence protocol that uses application-specific information.
With whom to synchronize? Data properties are used to characterize the shared data Two views share data if their property sets intersect
When to synchronize? Quality triggers indicate when updates should be pushed
or pulled between replicas What to synchronize?
Merge/extract methods are used to merge/extract data and resolve conflicts between updates.
PDSG - NYU 28
Description of the cache coherence protocol
Directory
manager
Cache
manager
Cache
manager
Cache
managerCache
manager
Cache
manager
(user, {alice, bob})(user, {alice, david})
(user, {alice})
(user, {alice})
1. acqIm
2. getIm
3. relIm 3. relIm
3. relIm
4. imRel 4. imRel
4. imRel5. sendIm
(user, {charlie})
PDSG - NYU 29
Roadmap
Motivation Problem: Seamless access to distributed applications Our solution: Partitionable Services Framework (PSF)
Architecture Modules Evaluation
Related work Contributions and future plans
PDSG - NYU 30
Evaluation of Partitionable Services Framework
Would like to verify that: User input is minimal
Describing application, network, QoS Adding PSF-specific code
Flexible application deployments might improve the application performance when executing in resource constrained networks.
Overhead of automatic deployments is not significant Results of dynamically deployed applications and
manually deployed applications are comparable
PDSG - NYU 31
User input is minimal
Natural expression of required additional information: Description of application properties and the network status Description of views Description of application specific information for the
consistency protocol
Minimal PSF-specific code: Component needs to extend PSFObject Small number of cache coherence APIs
PDSG - NYU 32
Example of a PSF-aware component
public class CacheMailServer extends PSFObject
implements MailServerInterface
{
ViewPropertyList vpl = new ViewPropertyList( “user”, “alice” );
CacheManager cm = new CacheManager( vpl );
public CacheMailServer() {
super();
cm.initImage();
}
public void sendMessage( Message _message ) {
cm.startUseImage();
accounts.addMessage( _message );
cm.endUseImage();
}
public void setInterface( String _interface ) { ... }
}
PDSG - NYU 33
Testbed used to evaluate PSF
50M/20ms2M/50ms
56k/75ms
AC
B 3 domains, 10 nodes/domain
Nodes have 100 units CPU Links have 100Mbps/0ms
Links connecting domains: 56Kbps/75ms 2Mbps/50ms 50Mbps/20ms
Testbed of 32 nodes Click router to modulate
bandwidth and latency
PDSG - NYU 34
Scenarios
Mail server is running in domain A Clients connect from domains A, B, C:
A AA
B A
C AC AC
A A
B AB
C AC B
C-S
C-$-S
C-S
C-$-S
C-S
C-$-S
C-$-$-S
PDSG - NYU 35
Flexible application deployments - Switchboard
No single configuration ensures best performance in all scenarios → need for automatic deployments
A
0
5
10
15
20
25
A B C
Client domains
Tim
e[s]
C-S C-$-S 20sec C-$-S 90sec C-$-$-S 20sec C-$-$-S 90sec
PDSG - NYU 36
Dynamic vs. manual deployments
Performance of dynamically deployed applications is comparable with performance of applications manually deployed in similar configurations.
0
2
4
6
8
10
12
A B CClient domains
Tim
e [s
]
manual deployment dynamic deployment
PDSG - NYU 37
Overhead of automatic applications deployments
Overhead of automatic application deployments is negligible.
0
2
4
6
8
10
12
Client domains
Tim
e [s
]
generate plan contact wrapper install clientcontact wrapper
A B C
install cache
PDSG - NYU 38
Properties of the planning algorithm
Scales with size of application Scales with the size of the network Reuses existing deployments Finds deployment plans fast
0.0
0.5
1.0
1.5
2.0
2.5
20 28 44 54 64 72 79 93Number of nodes in the network
Tim
e (s
)
PDSG - NYU 39
Related work
Globus CANS Ninja PSF
Dynamic composition
NO YES YES YES
Extensible properties
NO YES YES YES
Multiple Namespace
NO NO NO YES
Application
structure
DAG Chains DAG DAG
Dynamic deployment
YES YES NO YES
PDSG - NYU 40
Summary
Hypothesis: By exposing qualitative and quantitative properties of component-based applications and the relationships between the applications and the environment, automatic deployment is feasible.
Partitionable Services Framework Application and network description models AI-based planning algorithm Secure deployment process Extensions based on views
• Flexible cache coherence protocol
PDSG - NYU 41
Future work
Refine the Partitionable Services Framework: Extend the application model Design a network monitoring system that extracts the
information required by PSF Decentralize PSF Support run-time adaptation through re-planning
Use the ideas developed while working on PSF to address problems in other areas: e.g. web caching, sensor networks Placement of web caches Automatic deployment senselets
PDSG - NYU 42
Thank you!
PDSG - NYU 43
General stuff
PDSG - NYU 44
Hypothesis: Automatic application deployment
Hypothesis: By exposing qualitative and quantitative properties of component-based applications, and the relationships between the applications and the environment, automatic deployment is feasible.
Feasibility: User input is minimal
• i.e. additional programming effort, application specification If a valid deployment exists, it will be found Dynamic deployment does not incur significant overhead Performance of dynamically deployed application is
comparable with manual deployments
PDSG - NYU 45
Partitionable Services Framework (PSF) Architecture overview
RegistrarPlannerDeployer
Network Monitor
PSF Runtime
Wrapper Wrapper Wrapper
1. register
application2. make
request
3. plan
Wrapper Wrapper
Service Description
4. deploy
PDSG - NYU 46
Anatomy of PSF
PSF runtime infrastructure Registrar: registers applications with PSF Monitor: extracts the current state of the environment Planner: finds valid application deployments Deployer: deploys applications
Wrappers Forward client requests to the PSF runtime infrastructure Download, connect, and start applications Provide additional services: e.g. cache coherence
PDSG - NYU 47
Application and network model
PDSG - NYU 48
Example – Node and link specifications
<Node>
<Address>node1.nyu.edu</Address>
<Property>
<Name>NodeCPU</Name>
<Value>100</Value>
</Property>
<Property>
<Name>Secure</Name>
<Value>false</Value>
</Property>
<Property>
<Name>OS</Name>
<Value>Windows XP</Value>
</Property>
</Node>
<Link>
<Start>node1.nyu.edu</Start>
<End>node2.nyu.edu</End>
<Property>
<Name>LinkBandwidth</Name>
<Value>500</Value>
</Property>
<Property>
<Name>Secure</Name>
<Value>true</Value>
</Property>
</Link>
PDSG - NYU 49
What information should be exposed by the application?
Design applications as sets of components
A component specifies: Linkage information Deployment requirements and effects
• Quantitative: number of requests, available CPU
• Qualitative: privacy, availability of certain software
Link crossing requirements and effects QoS requirements
CipherWeak Mail
Client
Mail ClientCache
Mail ServerMail Server
PDSG - NYU 50
Example – Mail Client
<Component> Name: MailClient
<Linkages>
<Implements> Name: MCI </Implements>
<Requires> Name: MSI </Requires>
</Linkages>
<Conditions> Node.OS = Linux
Node.CPU > 50%
MSI.Secure = true
MSI.NoReq > 120
</Conditions>
<Effects> MCI.Secure = true
Node.CPU = Node.CPU – 50%
Link.Bandwidth = Link.Bandwidth – ( MSI.NoReq * MSI.ReqSize )
</Effects>
</Component>
PDSG - NYU 51
Planning algorithm
PDSG - NYU 52
Example of using the planning algorithm
Input: application description and state of the network Goal: placing a component on a node Output: list of components deployed on nodes
Linux56Kbps
Win XPLinux2Mbps
MSIMSIMSIMSI
PDSG - NYU 53
Description of the planning algorithm
Phased algorithm:
1. Compilation
2. Regression
3. Progression
4. Replay
5. Decompilation
PDSG - NYU 54
Phase 1 of the planning algorithm
Phased algorithm:
1. Compilation
2. Regression
3. Progression
4. Replay
5. Decompilation Facts
MSI_available_node_2 MC_placed_node_3
Actions place_MS_node_2 cross_MSI_link_2_3
PDSG - NYU 55
Phase 2 of the planning algorithm
Phased algorithm:
1. Compilation
2. Regression
3. Progression
4. Replay
5. Decompilation
PDSG - NYU 56
Phase 3 of the planning algorithm
Phased algorithm:
1. Compilation
2. Regression
3. Progression
4. Replay
5. Decompilation
PDSG - NYU 57
Phase 4 of the planning algorithm
Phased algorithm:
1. Compilation
2. Regression
3. Progression
4. Replay
5. Decompilation
PDSG - NYU 58
Planning Algorithm
Assumptions Size of the deployment plan is small compared to the size
of the network All resource functions are monotonic Properties of implemented interfaces (interfaces at
destination) do not appear in formulae Limit the search
Find all operators relevant/possible for achieving the goal Propagate resource constraints from the initial state Use function monotonicity for pruning Only then perform search in small set of operators
PDSG - NYU 59
Example of deploying application into network
0 1 256k100M
CPU=100 CPU=100 CPU=100
MC requirements:
available MSI
CPU > 80
NoReq > 120
MC effects:
available MCI
CPU -= 80
VMS requirements:
available MSI
CPU > 80
VMS effects:
available MSI
CPU -= 80
NoReq *= 2
MS requirements:
CPU > 80
MS effects:
available MSI
CPU -= 80
NoReq = 200
PDSG - NYU 60
Phase 1: Compilation
Tranform state of the world, goal, and application and network descriptions into AI operators and facts.
Operators: place_comp_node + cross_interface_link
pl_MC( node ?n ): precond: av_MSI( ?n ) effects: av_MCI( ?n ) cpu( ?n ) > 80 placed_MC( ?n ) noReq( MSI, ?n ) > 100 cpu( ?n ) -= 80
Facts about the initial state of the world: av_MSI(2) and noReq_MSI(2) = 200
Goal: placed_MC(2)
PDSG - NYU 61
Phase 2: Regression Graph
pl_VMS( 0 ) cr_MSI( 1, 0 )
pl_MC( 0 )
av_MSI( 0 )
av_MSI( 1 )
cr_MSI( 2, 1 )cr_MSI( 0, 1 ) pl_VMS( 1 )
av_MSI( 1 )
placed_MC( 0 )
0 1 256k100M
av_MSI( 2 )
pl_VMS( 1 )cr_MSI( 2, 1 )cr_MSI( 0, 1 )
av_MSI( 1 )
av_MSI( 2 )
av_MSI( 0 )
pl_VMS( 0 ) cr_MSI( 1, 0 )
av_MSI( 0 )
pl_VMS( 0 ) cr_MSI( 1, 0 )
av_MSI( 0 )
MSIMSI MSIMSI
PDSG - NYU 62
av_MSI( 0 )
cr_MSI( 1, 0 )
pl_VMS( 1 )cr_MSI( 1, 0 )
Phase 3: Progression Graph
placed_MC( 0 )
pl_VMS( 0 )
pl_MC( 0 )
av_MSI( 0 )
av_MSI( 1 )
av_MSI( 2 )
cr_MSI( 0, 1 )
av_MSI( 0 )
pl_VMS( 0 ) cr_MSI( 2, 1 )
av_MSI( 1 )
0 1 256k100M
pl_VMS( 1 )
av_MSI( 1 ) av_MSI( 2 )
cr_MSI( 0, 1 )
av_MSI( 0 )
pl_VMS( 0 ) cr_MSI( 1, 0 ) cr_MSI( 2, 1 )
MSIMSI MSIMSI
av_MSI( 2 )
PDSG - NYU 63
Phase 4: Replay
placed_MC( 0 )
av_MSI( 1 )
pl_MC( 0 )
pl_VMS( 0 )
av_MSI( 0 )
cr_MSI( 1, 0 )
pl_VMS( 1 )
av_MSI( 1 )
cr_MSI( 2, 1 )
av_MSI( 2 )
av_MSI( 0 )
cr_MSI( 1, 0 )
0 1 256K100M
cr_MSI( 2, 1 )
av_MSI( 2 )
N0_MSI.NoReq > 100
N0.CPU > 80%20056
N2_MSI.NoReq = 200
N2.CPU = 20%
N1_MSI_NoReq = 56
N0MSI_.NoReq = 56
100%100%100% 20%20%5656
PDSG - NYU 64
Phase 4: Replay
placed_MC( 0 )
av_MSI( 1 )
pl_MC( 0 )
pl_VMS( 0 )
av_MSI( 0 )
cr_MSI( 1, 0 )
pl_VMS( 1 )
av_MSI( 1 )
cr_MSI( 2, 1 )
av_MSI( 2 )
av_MSI( 0 )
cr_MSI( 1, 0 )
0 1 256K100M
cr_MSI( 2, 1 )
av_MSI( 2 )
NoReq > 100
N0.CPU > 80%
N2_MSI.NoReq = 200
N2.CPU = 20%
2005656112
N1_MSI.NoReq = 56
N0_MSI.NoReq = 112
N0.CPU = 20%
100%100%100% 20%20%
N0_MSI.NoReq = 56
56
PDSG - NYU 65
Phase 4: Replay
placed_MC( 0 )
av_MSI( 1 )
pl_MC( 0 )
pl_VMS( 0 )
av_MSI( 0 )
cr_MSI( 1, 0 )
pl_VMS( 1 )
av_MSI( 1 )
cr_MSI( 2, 1 )
av_MSI( 2 )
av_MSI( 0 )
cr_MSI( 1, 0 )
0 1 256K100M
cr_MSI( 2, 1 )
av_MSI( 2 )
NoReq > 100
N0.CPU > 80%
N2_MSI.NoReq = 200
N2.CPU = 20%
20056112112
N1_MSI.NoReq = 56
N0MSI_.NoReq = 112
N1_MSI.NoReq = 112
N1.CPU = 20%
100%100%100% 20%20%
PDSG - NYU 66
Phase 5: Decompilation
Transform the plan into a list of actions: Install component on
node Connect component
with other components
placed_MC( 0 )
av_MSI( 1 )
pl_MC( 0 )
av_MSI( 0 )
cr_MSI( 1, 0 )
pl_VMS( 1 )
av_MSI( 1 )
cr_MSI( 2, 1 )
av_MSI( 2 )
Install VMS on node 1
Connect VMS_1 with MS_0
Install MC on node 0
Connect MC_0 with VMS_1
PDSG - NYU 67
Phase 2: Regression Graph
pl_VMS( 0 ) cr_MSI( 1, 0 )
pl_MC( 0 )
av_MSI( 0 )
av_MSI( 2 )
av_MSI( 1 )av_MSI( 0 )
pl_VMS( 0 ) cr_MSI( 1, 0 )
av_MSI( 0 )
cr_MSI( 2, 1 )cr_MSI( 0, 1 ) pl_VMS( 1 )
av_MSI( 1 )
placed_MC( 0 )
0 1 220M100M
av_MSI( 2 )
pl_VMS( 0 ) cr_MSI( 1, 0 )
av_MSI( 0 )
pl_VMS( 1 )cr_MSI( 2, 1 )cr_MSI( 0, 1 )
av_MSI( 1 )
MSIMSI MSIMSI
PDSG - NYU 68
Planning under Various Conditions
0
5000
10000
15000
20000
25000
30000
Number of nodes in the network
Tim
e[m
s]
22 99887766554433
PDSG - NYU 69
Support for Complex Application Structures
0
500
1000
1500
2000
2500
3000
3500
4000
4500
20 30 40 50 60 70 80
Number of nodes in the network
Tim
e[m
s]
PDSG - NYU 70
Scalability w.r.t. Irrelevant Components
PDSG - NYU 71
Scalability w.r.t. Relevant Components
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
Tim
e (s
)
2 comp, high bw, secure
3 comp, low bw, secure
4 comp, high bw, insecure
5 comp, low bw, insecure
PDSG - NYU 72
Reusability of Existing Deployments
PDSG - NYU 73
Secure deployment
PDSG - NYU 74
Example of Secure Deployment
IBM
PDSG
[IBM.PC→ NYU.PC]NYU
[PDSG.PC → NYU.PC]NYU
[IBM.PC → Linux]IBM
[Bob → PDSG.member]PDSG
NYU
[Mail.X → IBM.Service]IBM
[Linux → Mail.Node]Mail
[Mail.X → IBM.Service]IBM[Mail.X → IBM.Service]IBM
PDSG - NYU 75
Evaluation of the view generation process - VIG
0
2
4
6
8
10
12
14
16
18
Siz
e [k
b]
vig
javac -g
javac -g:none
javac -O
javac
0
0.5
1
1.5
2
2.5
3
3.5
Tim
e [s
]
vig
javac -g
javac -g:none
javac -O
javac
PDSG - NYU 76
View Example
<View name = WeakMailClient />
<Represents name = MailClient />
<Restricts>
<Interface name = MessageInterface />
<Interface name = AddressInterface />
<Adds_Methods>
<MSign> m4
<MBody> a = 10
<Customizes_Methods>
<MSign> m2
<MBody> y = 6
PDSG - NYU 77
Description of the VIG algorithm
IC,FC,VCIADD,FADD, VADD,
ICOP,FCOP, VCOP
take x VADD
x VV x VV
take x VCOP
Warning
YES
VV = VV {x}
NO
x VC
NO
VV = VV {x}
YES
Warning
YES
NO
IV,FV,VV
PDSG - NYU 78
Flexible deployments of applications - RMI
-1
1
3
5
7
9
11
13
15
vmc 4 vmc 20 vmc 17
Tim
e[s]
direct connection
cached connection 1000
cached connection 5000
double cached connection 1000
double cache connection 5000
PDSG - NYU 79
Flexibility of using triggers in the cache coherence protocol
0
5
10
Time line [ms]
Dat
a q
ual
ity
0
10
20
30
40
Time line [ms]D
ata
qu
alit
y
PDSG - NYU 80
Flexibility of cache coherence protocol – Switching between strong and weak consistency
0
200
400
600
800
1000
1200
1400
Tim
e [m
s]
0
5
10
15
20
25
30
35
Nu
mb
er o
f u
nse
en u
pd
ates
Time to execute a method Data quality
