Distributed Computing Toolkit in Java

Document Sample
Distributed Computing Toolkit in Java Powered By Docstoc
					Distributed Server Framework
            in Java

          Quickware™
            Introduction
 Idle capacity in (intranet) workstations
 Inability to execute generic function
 Need for distributed infrastructure
    – flexible
    – scalable
    – secure
            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
           Objective
 Distributed computation based on
  configurable metrics
 Load balancing
 High availability
 Scalability
 Platform independence
            Architecture
 Access is provided through API
 API can be viewed as local
  (asynchronous) calls
 Provide transparency:
    – Access transparency
    – Location transparency
    – Replication transparency
    – Failure transparency
          Communication
   Call setup
          Communication
   Initialization step
      Object Execution
 Class Loading
 Security Manager
         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.
Class Loading (continued)

                  Client                                                  Server


   MyObject                                                                        MyObject

                                                   Object Serialization
                       Object Serialization


   ResultObject
                                                                               ResultObject


                                              Class Loader


                             Class Server
 MyObject.class
  MyObject.class
    MyObject.class
      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.
         Failure Handling
   Broker failures:
    – Primary - Backup approach
    – Multicast functionality
   Server failures:
    – Alive messages
    Application Properties
 Trial and error / Backtracking algorithm
 Iterative algorithm
 Task with independent computation
Checkmate Engine Overview
 Basic implementation of backtracking
 Ported from Borland Pascal code to
  Java
 Cut-off condition
       Benchmark (Broker)
   Initial setup times
       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

   Election resolving times (To = 2sec)
       System with One Backups : 9.8 sec
       System with Two Backups : 11.8 sec
       System with Three Backups : 28.2 sec
    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
            Future Work
   Security considerations
    – Authentication of Clients and Servers


   Billing for work
    – Based on CPU time utilized
            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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:5/4/2012
language:
pages:18