Distributed Server Framework in Java

1
Distributed Server Frameworkin Java

• Quickware

2
Introduction

• Idle capacity in (intranet) workstations
• Inability to execute generic function
• Need for distributed infrastructure
• flexible
• scalable
• secure

3
Overview

• Broker-based distributed computing
• Client defines the function to compute and its
  metrics
• Broker will select a suitable Server
• Client contacts Server and sends the function

4
Objective

• Distributed computation based on configurable
  metrics
• Load balancing
• High availability
• Scalability
• Platform independence

5
Architecture

• Access is provided through API
• API can be viewed as local (asynchronous) calls
• Provide transparency
• Access transparency
• Location transparency
• Replication transparency
• Failure transparency

6
Communication

• Call setup

7
Communication

• Initialization step

8
Object Execution

• Class Loading
• Security Manager

9
Class Loading

• Servers do not necessarily have the
  implementation details of the functions to be
  shipped from clients. So, normal object
  serialization scheme does not work.
• We need to have a class loading scheme to allow
  Servers to obtain the implementation details to
  deserialize the objects.

10
Class Loading (continued)
Client
Server
Object Serialization
MyObject
MyObject
Object Serialization
ResultObject
ResultObject
Class Loader
Class Server
MyObject.class
MyObject.class
MyObject.class
11
Security Manager

• No knowledge of what the functions shipped to the
  Servers might contain within their
  implementation.
• We need a mechanism to protect our Servers.
• By using Security Manager, we are providing a
  Sandbox Model of security for our architecture.

12
Failure Handling

• Broker failures
• Primary - Backup approach
• Multicast functionality
• Server failures
• Alive messages

13
Application Properties

• Trial and error / Backtracking algorithm
• Iterative algorithm
• Task with independent computation

14
Checkmate Engine Overview

• Basic implementation of backtracking
• Ported from Borland Pascal code to Java
• Cut-off condition

15
Benchmark (Broker)

• Initial setup times
• Election resolving times (To 2sec)

Setup time for the Primary 7.8
sec Setup time for the First Backup 2.2
sec Setup time for the Second Backup 2.4
sec Setup time for the Third Backup 3.2 sec
System with One Backups 9.8 sec System with
Two Backups 11.8 sec System with Three
Backups 28.2 sec
16
Benchmark (Application)

• Standalone w/o framework 193.5 sec
• Distributed with framework 104.8 sec
• Overhead with Class-loading
• One request with NOP class 0.643 sec
• Consecutive with diff. classses 1.870 sec

17
Future Work

• Security considerations
• Authentication of Clients and Servers
• Billing for work
• Based on CPU time utilized

18
Summary

• Broker, Server based architecture to serve
  Clients with large computations
• Focus on intranet environment
• Class-loading for remote execution
• Election algorithm for failure handling
• Highly beneficial for back-tracking algorithms