Report

JPPF grid computing
INTRODUCTION
1.1 MOTIVATION AND INSPIRATION
Grid computing is gaining a lot of attention within the IT industry. Though it has been used
within the academic and scientific community for some time, standards, enabling technologies,
toolkits and products are becoming available that allow businesses to utilize and reap the
advantages of grid computing.
Motivation of Grid computing is to aggregate the power of widely distributed resources, and
provide non trivial services to users. Grid Computing is emerging as a dominant technology for
high performance computing. Although there has been considerable recent progress on building
the software infrastructure to enable transparent use of globally distribute computers on the grid,
the issue of job scheduling on grids has not received much attention. An analysis of the resources
usage pattern at several supercomputer centers (San Diego supercomputer center ,National
Center for Supercomputer applications, Cornell Theory center , KTH Royal institute of
Technology ),shows an interesting “sine wave ” pattern. During evenings, the resources
requested reaches and sometimes exceeds the maximum capacity of the system , while usage
dips to a minimum early hours of the morning . By integrating centers in a computational grid ,
in addition to providing more computation power than any single site can provide , the time
dependent and bursty nature of resources requests can be better averaged by distributing the
requests to different centers.
Effective scheduling is important in optimizing resources usage & performance, but the task of
scheduling is more complex in a metacomputing environment since many clusters with different
local scheduling policies are involved. With the emergence of the computational grid, new
scheduling algorithms are in demand for addressing new concerns arising in the grid
environment. The grid system is responsible for sending a job to a given machine to be executed
.In the simplest of the grid systems, the users may select a machine suitable for running his job
and then execute a grid command that sends the job to the selected machine .More advanced grid
systems would include a job scheduler of some kind that automatically finds the most
appropriate machine on which to run any given job that is waiting to be executed . Schedulers
react to current availability of resources on the grid. The term scheduling is not To be confused
with reservation of resources in advance to improve the quality of services. Sometimes the
resource broker is used in place of scheduler, but this term implies that some sort of bartering
capability is factored into scheduling.
SVKM’s Mukesh Patel School of Technology & Engineering Page- 1

JPPF grid computing
1.2 CONCEPTS AND TERMINOLOGIES
The grid system is responsible for sending a job to a given machine to be executed .In the
simplest of the grid systems, the users may select a machine suitable for running his job and then
execute a grid command that sends the job to the selected machine .More advanced grid systems
would include a job scheduler of some kind that automatically finds the most appropriate
machine on which to run any given job that is waiting to be executed . Schedulers react to
current availability of resources on the grid. The term scheduling is not To be confused with
reservation of resources in advance to improve the quality of services.
Sometimes the resource broker is used in place of scheduler, but this term implies that some sort
of bartering capability is factored into scheduling
1.3 PROBLEM DEFINITION
Traditional Client/Server architecture
In the traditional Client-Server Application, multiple clients requesting to a server for a

particular service offered by server. After a certain limit Server resources get saturated which
leads to the overloading of the server ultimately resulting to ‘CRASH’
Hence the objective is to develop an Application software which should help Server in reducing
the work load...

JPPF grid computing
The project deals with efficient assignment of tasks & utilization of resources, commonly
referred to as load balancing problem. These algorithms are based on the intuition that for better
resources utilization, it is desirable for the load in a grid to be balanced evenly. Thus a load
balancing algorithm tries to balance a total system load by transparently transferring the
workload from heavily loaded nodes to lightly loaded nodes in an attempt to ensure good overall
performance relative to some specific metric of system performance.
The user submits his jobs with the QOS parameters to the Grid to scheduler through one of the
workstations in the grid.
Selection of resources depends upon the algorithms used for scheduling. Some of the
algorithms are balance constrained FIFO, Job –random which selects a random site for
computation: Min-which selects the smallest job to assign to machine which could produce result
faster i.e. least loaded site Min –Max which selects the largest job to assign to machine which
will produce the result faster i.e.. Least loaded site, Min –Min Heuristic and Ant colony
algorithm.Static algorithm: "manual" -This algorithm simply distributes a fixed number of tasks
to each node. It is suited for networks where each node has equivalent characteristics (hardware
and software), and where the type and number of tasks remains the same. Heuristic
algorithm:-"auto tuning" This algorithm is heuristic in the sense that it determines a good
solution for the number of tasks to send to each node, while the solution may not be the optimal
one. Deterministic algorithm: "proportional" As for the heuristic algorithm, this one is purely
adaptive and based solely on the known past performance of the nodes.
Primary performance goal is maximizing resources utilization, and increasing the system
throughput.
1.4 OBJECTIVE
Consider the requirements, here proposing a model to analyze and implement job scheduling
algorithms for computational grid to optimize the load balancing among available resources. The
purpose of the software is to provide user with the more computing power by balancing the
computational load among the available resources to utilize underutilized resources for the sake
of increasing the speed of processes.
The model is based on the facilities provided by the JPPF toolkit to implement the scheduler
like resource management and information services. The model is a part of the larger system
comprising the JPPF that runs and delegating them to the scheduler for scheduling and placing
on appropriate workstations or execution hosts. The scheduler communicates its decision
regarding workstation allocation to the resource manager of JPPF, which then dispatch the job to

JPPF grid computing
the chosen workstation. Once assignment to a workstation has occurred, the scheduler is
responsible for implementing the scheduling policy on the jobs executing at the workstations. No
modifications to the O.S. are required.
1.5 SCOPE OF PROJECT

The open source JPPF toolkit is the defacto standard in the grid computing environment.
JPPF is a computational grid framework for Java focused on performance and ease of use. It
provides a set of tools and APIs to enable the parallelization of CPU intensive applications, and
distribute their execution over a network of heterogeneous nodes. It features platform
independence thanks to Java 1.5, does not require you to deploy your application classes to a
server, scales up to millions of nodes, has a built-in fail-over mechanism on all the framework's
components, and has a monitoring and administration GUI tool to enable remote monitoring of
the server health and server shutdown/restart operations. JPPF provides a set of tools and API’s
to enable the parallelization of CPU intensive applications and distribute their execution over a
network of heterogeneous nodes. It is also platform independent & can scale up to millions of
nodes.
This project(load balancing) will work with open source JPPF which will be based on the tools
and interfaces provided by JPPF Framework. The scheduler will offer System –centric (resource
centric ) service for managing jobs on the grid and aims to optimize performance of resources to
increase the throughput .node selecting strategy can be based on the prediction of the processor
utilization and computing power of the host . JPPF driver will take care of synchronization of
activities.
JPPF is a grid toolkit for Java that makes it easy to run your applications in parallel, and
speed up their execution by orders of magnitude. Write once, deploy once, and execute
everywhere!
E.g. The matrices are considered dense matrices. For a matrix size of N, there will be N JPPF
tasks, each multiplying a row (or vector) of A by each column of B.
1.6 FEASIBILITY
scheduler is based on JPPF toolkit as grid software , all the functions of the grid like security ,
resources discovery, information services , data management etc will provided by it. it works on
windows or Linux operating system with J2SE software. As JPPF is the defacto standard in grid
environment, open source and readily available over the internet, the project is technically
feasible.

JPPF grid computing
When it comes to the software requirement, the project is based on JPPF framework and Linux
operating system, both are open sources and readily available free of cost. Thus the project is
economically feasible.
1.7 PROPOSED SYSTEM

In today’s system, for multiplication of a huge size of matrix requires lot of time as well as
computations which becomes very tedious. Moreover even if there is an optimized algorithm
then also the complexity involved is more because it is performed only on a single node. The
existing frameworks which can perform computations in parallel are neither open source nor
platform independent.
JPPF toolkit have its own scheduler(algorithms), it doesn’t required third party schedulers
like….Condor (workload management software-couples resource allocation & job allocation),
Load leveler(job management software-poor scalability) ,PBS(portable batch system –single
threaded-not suitable for large clusters )
Therefore, with implementation of different algorithms of load balancing, JPPF proves to be a
good solution for the existing system.A 1000*1000 matrix will be split into 1000 tasks, which
are given to various nodes for execution by the server, and thus the server is relaxed as the load
gets balanced to a great extent. This is how JPPF manages 10,000,000 computations in few
seconds.
JPPF framework provides the following features:
 A JPPF grid can be up and running in minutes

 Full platform independence
 Highly scalable, distributed framework for the execution of tasks
 Easy programming model that abstracts the complexity of distributed and parallel processing
 Graphical and programmatic tools for fine-grained monitoring and administration
 Reliability through redundancy, recovery and failover capabilities
 A JPPF server node enables the automatic use of idle computers
 Very flexible and non-constraining open-source licensing

JPPF grid computing
2 What Grid computing is
The current computational power demands and constraints of organizations have led to a new
type of collaborative computing environment called Grid Computing. Grid computing is a new
way of the parallel and distributed computing.
Grid computing is the sharing, selection, and aggregation of a group of resources such as
supercomputers, mainframes, storage systems, data sources, distributed applications and
management systems that behaves as a network of computation.
The aim of Grid computing is the utilization of underutilized resources to achieve faster job
execution time. Grids can also provide access to software, computers, data, and other computing
resources. The growth in using the Internet and the improvement of technological advances have
facilitated the use of distributed computing which was extended to Grid computing. P2P
computing is the sharing of PCs, which are connected to the Internet.
The objective of this sharing is to provide better computing capability or sharing computer
data between the connected PCs (Kazaa, Imesh, etc...). Grid computing is the aggregation of
clusters of computers that are geographically distributed using suitable protocols and standards.
The enhancement in the speed and reliability of networks, in addition to the use of distribution
protocols were important factors that led to the Grids use, to enable users to utilize resources
remotely which was impossible before. For example, for the last three decades, the speeds of
computers were doubled every year and a half. Moreover, for the last five years, the speeds of
networks were doubled every eight months. Add to that the manufacturing of hardware is
continuously decreasing.
An example of the benefit of using Grids is Shell: a Grid-enabled infrastructure which is used for
applications that are responsible for the interpretation of seismic data. This use led to faster
processing time of seismic data, improving the quality of the output, and easier integration of
existing software. Grid computing reduces the cost by connecting different machines like PCs
and workstations to behave as a large computational machine rather than purchasing special
expensive machines to execute these complicated jobs. This can be
sometimes showed as dividing the cost of the resources participating in the Grid between the
users who use the Grid.
The definition of Grid is taken from the electrical power Grid that provides pervasive access to
power without caring where and how the power was produced.
On the same way, the computational Grid should provide pervasive access to high end
computing resources, without caring about where and how the jobs were executed
There are five main goals for employing Grid computing:

JPPF grid computing
• Providing a framework for utilizing unused computational power as well as unused storage
capacity.
• Simplifying collaboration between different organizations including direct access to computers,
software, and storages.
• Splitting users into different groups according to their functional areas (virtual organizations)
leading to better management. There are some differences between different virtual
organizations. These differences include purpose, size, scope, structure, duration, sociology, and
community.
• It provides the user an access to resources which can’t be accessed locally (remote resources).
• The jobs can be executed more quickly due the fact that the job can be executed in parallel on
multiple resources(Multi-site computing/Co-allocation).
But, this need the job to be parallel execution enabled. Grids can be classified into
computational Grids which concern computing power, scavenged Grids which concern utilizing
unused resources, and data Grids which concern providing access to data.
Other distributed computing technologies can benefit from Grid technologies to solve some of
their existing problems. e.g. Enterprise distributed computing systems can employ Grid
technologies to get over the problems of sharing resources across institutional boundaries.
The most complicated task in Grid is the allocation process; mapping jobs to various resources.
The authors of say it is a NP- complete problem. For example, the mapping of 50 jobs onto 10
resources produce 105 possible mapping . This task becomes more complicated in the case of co-
allocation [?] which means that the job is executed on a number of resources instead of on a
single resource. Another complexity of resource allocation is the lack of accurate information
about status of resources.
Much work has been done on finding an optimal allocation. Some of the projects used
conventional techniques that concern the system performance in general and doesn’t consider
economics (prices) for allocating jobs to resources.
On the other hand, A large number of projects study economics as strategies for allocating jobs.
Economic techniques take into consideration the price of the resources when it needs to allocate
jobs to resources and that price usually reflects the value of the resource to the user.

JPPF grid computing
2.1 Grid components

Grids consist of many components. The general components of every Grid are:
• Applications: Applications are the jobs needed to be executed on the resources of the Grid. The
applications can be scientific or commercial applications. In some cases, jobs consist of sub-jobs
that their results are gathered and combined to represent the overall job result. It is referred to the
split of a task into homogeneous subtasks by task profiling.
The applications can be classified into two categories: Pre-emptive where an application can be
moved from a resource to another resource if there is a benefit from the movement, and Non pre-
emptive where an application is assigned just once to a resource and can’t be moved to another
one
• Resources: The resources represent the working power of the Grid, and they are where the jobs
get executed. The resources could be computational, storage, or communication resources. The
Grid’s resources differ in speed, capacity, architecture, and operating system (heterogeneous). In
economic scheduling, the resources have costs that are paid by users running their jobs on these
resources. Usually, the demand and supply affect the prices. So, if the demand is higher than the
supply, the prices go up, and it is the opposite if the supply is higher than the demand. The
resources can be combined together to form a service which can be bought by the user. This is
referred to by Service aggregation [?]. Employment of authorization and authentication
mechanisms is necessary to regulate the access to resources.
• Scheduler: The task of scheduler is executing the applications/jobs on the available resources.
The scheduler also takes care of discovery, allocation, and aggregation of resources. It must take
into account the user requirements for the jobs which can also be called Quality of Service (QoS)
The scheduler can be centralized or distributed depending on the Grid implementation.
• Broker: Its role is searching the Grid to find suitable resources to execute the jobs submitted to
it. It is sometimes responsible for negotiating the prices between various users and resource
providers. The common situation is having many brokers act on behalf of users to find suitable
resources to execute them. Interfaces are important to facilitate the user access to the Grid. Those
interfaces are usually web interfaces, which are common and easy to use.
2.2 Mapping categories

Mapping is considered an important part in Grid computing. The used mapping has a large effect
on the performance of Grid computing. It determines if the task is going to be mapped
immediately or waits for some time before it is being mapped. The mapping can be static

JPPF grid computing
(mapping is determined before the jobs get executed), or dynamic (mapping can be changed
while the jobs are being executed).
There are two kinds of mapping:
• On-line mode: In this mode, the task is mapped after its arrival to the Grid (if this is possible).
Each task is considered just once. This mode gives better results when the arrival rate of jobs is
low. This results from the fact that when the arrival rate is low, the resources will not be highly
utilized. So, there is no need to delay the mapping of the job, until a predetermined time is
reached.
• Batch mode (Interval): In this mode, tasks are gathered in a collection which is called a meta-
task, and which is mapped at predetermined times. If a task hasn’t been mapped in the first
mapping time, then it is considered in the next mapping time to find out if it can be mapped then.
When the arrival rate is high, the batch mode results in better scheduling due to the use of
heuristics(e.g. minimizing the start time of the jobs) that lead to better assignment
of a collection of jobs depending on the jobs in the set, especially the resources are often highly
utilized. out of Eight (5 on-line based and 3 batch based) heuristic algorithms , five on-line based
algorithms are minimum completion time, minimum execution time, switching, k-percent best,
and opportunistic load balancing, while the three batch based algorithms are min-min, max-min,
and suffrages. Makespan and average sharing penalty are the two metrics used to determine the
performance of different algorithms.
Consider four scenarios in comparison that are high task and machine heterogeneity, low task
and machine heterogeneity, high task heterogeneity and low machine heterogeneity, and low task
heterogeneity and high machine heterogeneity. For the case the task arrival rate is high and
number of tasks is big, the algorithms that are based on batch mode outperforms the algorithms
that are based on on-line mode. Mapping a group of tasks together is better than mapping one
task only at a time. But, the choice of batch mapping only leads to a slight enhancement in the
case the task arrival rate is low and the number of tasks is small.
Use a centralized mapper which is known not scalable, and also suffers from single point of
failure. The expected execution time for each task on every machine is known, which is untrue in
the real situation where the estimations can’t be predicted accurately.

JPPF grid computing
2.3 Application requirements

As mentioned before, Applications are the jobs needed to be executed on resources and
sometimes they consist of smaller parts called subtasks. But those applications have their
requirements that need to be considered by the scheduler. Thus, the scheduler must select the
resources that are capable to meet those requirements. Some of the application requirements
which need to be handled by the scheduler are:
• Deadline: It is the time specified by the user to finish executing his job on a resource or a
collection of resources, and is usually measured in seconds.
• Budget: It is the amount of money a user can afford for executing its job on a resource.
• CPU speed: This is an important requirement in the case of computational Grid. It is the
microprocessor speed required for running the application. Speed is defined as the number of
instructions the processor can execute per time unit. The common used measurements are
Million Instruction Per Second (MIPS) and Floating-point Operations per Second(FLOPS).
• Physical memory: The number of rams needed for running the application
(e.g. 256 or 512 MB).
• File size: It represents the required storage space for running the application and usually
measured by Mega Byte or Giga Byte. This storage space is important for storing the program
files needed for running it on the specified resource.
• Bandwidth: This requirement arises, because of the need to move the program to the location
where it is going to be executed, and transferring the results of the execution to the user. This
movement of a program code and results requires a network bandwidth, and the user might
specify the amount of bandwidth needed.
• Security: It represents the minimum security level the resource must have in order to be
accepted for executing the job of the user.

JPPF grid computing
2.4 Grid resource management and scheduling

The management is an essential part in any system in the world. It comprises both hardware and
software management. It determines if the system succeeds or fails. This issue becomes more
important in Grid systems due to heterogeneity and dynamics of resources in Grids. Furthermore,
the Grid’s resources are scattered and geographically distributed, therefore more care is needed
when they are being managed.
The scheduling is as important as management. It determines how to discover, allocate, and
aggregate resources. Moreover, it determines under some circumstances the suitable resources
for executing the submitted jobs. Any scheduler must be simple, fair in dividing jobs between
resources, and has to use the available resources efficiently .Resource management and
scheduling in Grids are considered a complicated task. The complexity arises from the fact that
there are various layers of schedulers. In addition to the lack of control over resources, the
unpredictable behavior of resources , their heterogeneity, handling different local access policies,
and differences between objectives of users and resource owners. The importance of scheduling
arises because of the limited number of resources and which is usually far less the number of
jobs need to be executed. Thus, the scheduler must map the jobs to resources in such a way that
maximize the utilities of both users and resource provider’s Universal awareness Spreads the
information to all other entities in the network. Neighborhood awareness spreads the information
to all entities within a specific distance. Distinctive awareness the range of the information
spread out is determined by the importance of the entity.
2.5 Resource scheduler tasks
The following are a list of tasks the scheduler is responsible for. These tasks are important to
efficient execution of applications on resources.
• Resource discovery: The rule of the discovery is providing a list of resources that are available
and authorized for a specific user. This list is usually obtained by searching a database which
contains information about the available resources. An example of this database is Monitoring
and Discovery Service (MDS) in Globus . This step is also important for handling the situation
of resources entering and leaving the Grid. In general, resource discovery mechanisms use a
database (centralized approach), or a set of databases (Distributed approach) reside at different
places to obtain information about available resources such as their speeds, current loads,
architecture , and operating systems in order to find the resources that can meet the requirements
of users. The use of a distributed discovery approach has the advantage that it is scalable, but

JPPF grid computing
suffers from communication cost when the databases need to be updated. Three schemes exist to
spread the information about the current situation of resources to other entities.
.
• Resource selection: The scheduler selects a number of resources from the list provided in
resource discovery step that meet the user requirements such as deadline, cost, or both. The
execution of jobs that consist of a number of distributed services.
• Job mapping: the mapping function is moving the submitted jobs to the appropriate resources
to start their execution. The mapping is done based on the user requirements like time and cost.
• Job monitoring: The jobs may face unpredictable situations which need to be addressed. For
that reason, job monitoring has the rule of checking how the execution of jobs are going and
detecting if there is a failure or unexpected situation that needs to be addressed by the scheduler.
Network Weather Service (NWS) is an example of job monitoring.
• Re-allocation: re-allocation is the movement of the job being executed to another resource
under some circumstances which leads to better scheduling performance. The cases that lead to
re-allocation include machine failure, finding cheaper resource, performance slowdown, and
fluctuation in resource prices .Job re-allocation based on economic factors.
2.6 Grid resource management and scheduling challenges

The challenges that face Grid resource management due to the nature of the Grid environment.
The challenges make the management of Grid resources a complicated issue. So, the resource
management systems must consider them and be able to handle those challenges.
• The resources are geographically distributed across the world. This arise the need of
discovering the available resources on the Grid.
• The resources on the Grid are heterogeneous. They may have different architectures, speeds,
and operating systems. Thus, the resource management models must take that into consideration
and send the job to the resource which is suitable for it.
• There are various administrative domains on the Grid, each with its local access and security
policies. For that, the management models must handle that issue by supporting different access
policies, and mapping the security model used in the Grid to the security models used in those
domains.
• Due the fact that there are many entities (e.g. users, resources) participating in the Grid, the
security becomes an important thing to ensure the identity of the entity attempts to use a service
(authentication), and if this entity has the privilege to use the service (authorization). Securing
the Grid is important to encourage both the resource providers and users to participate in the

JPPF grid computing
Grid, because they will know that their resources and jobs are in a safe environment, and are
protected against attacks. There are two security issues in Grids that are programs that include
code which in turn infect the resources that run it, and infected resources that crush the programs
run on them. Globus GSI is a toolkit that handles security issues, and uses public-key for
authentication,Resource allocation based on trust.
• The users who submit their jobs for execution don’t have control over their jobs. As a result, the
completion time of them can’t be predicted accurately all the time, and some jobs might not meet
their deadline.
• The Grid resources are dynamic in nature. Thus, the information about resources must be
updated regularly to reflect any change in their status.
2.7 Scheduling schemes
The following are the kinds of scheduling schemes used in Grids. They show the strategies that
can be used for scheduling jobs on the resources.
• Centralized scheme: In this scheme, a centralized scheduler has information about all the
domains and the resources of these domains. All jobs are submitted to that centralized scheduler
which in turn submits the jobs to the resources that are suitable for them based on the
information it has about the domains and their resources. None of the domains has any
scheduler, and the domains just send information regarding their resources such as resources
speeds and their availability to the scheduler to help it in making scheduling decisions. Besides
this scheme is not scalable due to the large amount of information the centralized scheduler
retains, the jobs that are submitted to the scheduler sometimes suffer from a long access delay
when they access the scheduler, because all jobs have been submitted to the
Same scheduler. It also suffers from single point of failure, because there is only one scheduler.
Thus, if the scheduler fails, the interaction between the users and resource providers stops
• Hierarchical scheme : Here the jobs are submitted to a central scheduler. Then, the central
scheduler forwards the jobs to the domains which meet the jobs requirements. At this point, the
central scheduler has no control on those jobs. The advantage of this scheme is that each domain
can employ its own scheduling policy and which can be different from other domains scheduling
policies. Unfortunately, the job cannot be reallocated to another resource at another domain even
in the case a better resource has been found.

JPPF grid computing
• Distributed scheme: There is no central scheduler in the distributed scheme. Instead, each
domain has its own scheduler. Each domain queries other domains either periodically or in the
case an event happens to obtain information about the resources states reside in other domains.
When a job needs to be executed, it is submitted to the local scheduler which resides in the same
domain. The job is then submitted to a suitable local resource or to a resource in another domain,
if it is found more suitable than the available local resources for executing it. This scheme has
many advantages like scalability, reliability, easily implementable, and no single point of failure.
But, this scheme leads to allocation instability in some situations. A number of distributed
scheduling algorithms that are adaptable to changes in resource usage are proposed and
compared to other algorithms that rely on centralized, hierarchical, and distributed schemes.
Average job turnaround time and average job slowdown are used to determine the performance
for each algorithm. The authors say that their proposed distributed algorithms generally behave
better than the other algorithms.
It is important to have communication between the domains reside on the Grid. A heuristic
scheme to allow communications between the Grid networks with bursty background traffic.
2.7.1 Scheduling performance metrics

Every scheduling system aims to improve its scheduling performance. However, each scheduling
system uses a metric for specifying the quality of scheduling, and which may be different from
other metrics used by other scheduling systems. The common metrics (or combination of them)
used in determining the performance quality are:
• Execution time : It is the time needed for running a job on a resource or a group of resources.
The scheduler selects a resource that leads to less execution time.
• Completion time : It is equal to the execution time plus the time needed to begin the execution
of the job. Sometimes, it includes the time needed to return the results of execution to the user.
• Load balancing: The scheduling quality is specified by the fairness of division of work load
between various resources. Each resource gets a piece of work load depending on its
specifications.
• Speedup: It is the percentage of improvement achieved when using more than one resource
(processor) to execute the job, in contrast to using one resource only for executing the same job .
• Utilization: Utilization can mean two things here. If we mean the percentage of resources
utilized, then it equals to the number of used resources divided by the number of free and used
resources (all resources) at a specific time. On the other hand, if we mean the resource utilisation

JPPF grid computing
percentage, then it equals to the utilisation rate of that resource divided by the maximum
resource utilisation allowed at a specific time. If it is found at any time that
a number of resources are highly utilised and the rest of resources are free or have low
utilisation, then this means there is something wrong in the scheduling system.
• Resource Profit: The scheduler that uses thismetric for determining scheduling
quality attempts to increase the profit generated by its various resources.The common situation is
having an agent for each resource which tries to maximise its resource owner profit. Part of the
profit is used to compensate the expenses paid by resource providers such as security and
management costs.
• Users consumption: It is about decreasing the budgets paid by the users (jobs owners).
• Failure rate: It is the percentage of jobs couldn’t be executed. There are many reasons for
failure such as job failure, machine failure, and unavailable resources. The Ethernet as an
efficient approach for resource sharing under the condition that the failure rate is high.
Sometimes, it is defined as the jobs that couldn’t be executed within the deadline defined by the
users who submitted those jobs .
• Reliability: Reliability is the percentage of jobs executed successfully. It can be considered as
the opposite of failure rate.
• Waiting time: In some cases, the job may not be executed immediately after it is being
submitted. Thus, it needs to be suspended until a suitable resource becomes available. Waiting
time can be defined as the time the job waits until it can be executed on a suitable resource(s).
• Makespan (schedule length): The makespan is defined as the maximum time needed to
complete all the jobs in the meta-task (set of tasks). However, Makespan applies for batch jobs
only. This metric is used in to measure the scheduling performance.
• Average sharing penalty: For a set of tasks in a set, Average sharing penalty is a sign of the
scheduling capability to reduce the effects of competition between different tasks.
2.7.2 Scheduling strategies

Resource management and scheduling projects are divided into two main categories;
Conventional and economic strategies. Usually, the utilities which are gained by parties are used
to determine the scheduling performance, and that are needed to be maximized.
a) Conventional strategies
Conventional (traditional) strategy considers the overall performance of a system as a metric for
determining the scheduling quality. For example, the time it takes to schedule all jobs

JPPF grid computing
(makespan). It usually employs batch mode for allocating jobs to resources. Moreover, it doesn’t
take the cost as a factor for scheduling jobs on resources, and treats all resources as the same at
all times.
b) SmartNet SmartNet is a framework responsible for managing resources and jobs. It executes
the user’s jobs on a group of machines as if they are a single machine only. It considers many
constraints when attempting to map a job to a machine like resource availability, and network
speed between the job and the machine. It supports both tasks with dependency and
independency. It concerns enhancing the performance of users’ jobs more than enhancing the
performance of machines.
SmartNet concerns two utilities in deciding the mapping performance; maximizing throughput
(minimizing makespan), and minimizing the average expected run time of each job. SmartNet
uses a collection of heuristics to find the best allocation in the possible maps.
Both machine availability and heterogeneity affect scheduling decisions. Two types of
heterogeneity are considered which tasks are and resources heterogeneity .This work uses a
centralized scheduler which has a poor performance if there are a large number of machines, and
which lacks scalability.
c) The AppLeS project This project is based on agents that use application level scheduling
paradigm which means that the system evaluation is based on its influence on the application.
In AppLeS, each application has an AppLeS agent that makes use of both static and dynamic
information to schedule its application on a suitable resource. The interaction within the system
works as follows: First, the user sends information to the AppLeS agent. Then, the Coordinator
filters possible schedules according to that information. Next, the Resource Selector determines
the collection of resources that the Coordinator must consider. This is followed by computing a
promising schedule for each possible resource structure by the Planner. Then, Performance
Estimator is employed by the Coordinator to assess each schedule performance based on the
performance objectives of the user. Finally, the Actuator
selects the schedule that improves the user’s performance objective. AppLeS project employs
Network Weather Service for observing the performance of different resources, predicting the
performance of resources in the future, and sending the results of prediction to all AppLeS agents
concerned in them

JPPF grid computing
d) Fully decentralized discovery in Grid environments This system concerns resource

discovery in a large and dynamic collection of resources using a fully decentralized architecture.
In this framework, the users submit their requests to a node which is often a local node. If this
node has the resources that meet the user needs, then it responds to the user with the matching
resource information. Otherwise, it forwards the requests to another node and this node submits
the requests to another node and so on. This process continues until time to live field of the
request expires or suitable resources are found. In the case a node has
information matching the forwarded request, it sends the information directly to the node that
initiated the forwarding which in turn sends it to its user. Four request forwarding algorithms are
used: Random, Experience-based + Random, Best neighbor, and Experience based + Best
neighbor. Random algorithm chooses the node to which a request is forwarded at random.
Experience based + Random algorithm records the requests served by other nodes, so the request
is forwarded to the node that served similar requests previously. If there is
no such node, then the request is forwarded to a random node. Best neighbor algorithm
forwards a request to the node that served the largest number of requests neglecting the type of
requests served. Finally, Experience based + Best neighbor behaves as Experienced based +
Random algorithm mentioned before except in the situation where no node that served similar
requests before exists. In that situation, the request is forwarded to the node that served the
largest number of requests.
e) Performance prediction technology for agent-based resource management in Grid

environments This work provides a dynamic resource publication and discovery using agents.
In architecture, an agent represents the local Grid resource and behaves as a service provider and
service requester. The architecture uses a hierarchy organization of agents to enable them to
provide service advertisement and discovery. Agents also may work together to discover
available resources. It supports quality of service (QoS) using Performance Analysis and
Characterization environment (PACE). The task of PACE is providing quantitative predictive
data to evaluate the performance of complex applications which are allocated to a local Grid
resource. The agent manages its local resource using a combination of scheduling algorithm and
PACE in order to provide predictive capabilities concerning the local Grid resources and their
services. The system consists of Grid users, Grid resources, agents, and a Performance Monitor
and Advisor (PMA). The Grid’s users are divided into Grid service, tool developers, applications
developers, and Grid end users. The system concerns scientific super-computing applications.

JPPF grid computing
The Grid’s resources might be Massive Parallel Processors (MPP), or a cluster of workstations or
PCs. The system uses
PACE to create a hardware characterization template in order to provide a model of each
hardware resource. Agent Capability Tables (ACTs) are used by each agent to record service
information belongs to other agents. They are tuples comprising an agent ID and corresponding
service information. The system uses data pull (agent requesting other agents service
information) and data push (submitting an agent service information to other agents) for
maintaining ACT coherency. In this system, the architecture of agent comprises three component
layers. The communication layer is the first layer, and its task is performing communication
functions and acting as an interface to external environment.
The coordination layer is the second layer and consists of ACT manager, PACE evaluation
engine, scheduler, and a matchmaker. ACT manager regulates ACT database access from
agents. PACE evaluation engine is responsible for producing performance prediction
information. The scheduler searches for the application that has the shortest execution time on
the resource specified by an ACT item. The role of matchmaker is comparing the requirements of
the request with the scheduling results which in turn affects the agent behavior. Those
components determine the behavior of an agent upon receipt of messages from the
communication layer. Finally, local management is responsible for application management,
resource allocation, and resource monitoring.
The scheduling algorithm selects a group of processors to execute the application. The selected
processors must lead to a minimum completion time for the application. The minimum
completion time equals to the earliest start time in addition to the expected time to finish
executing the application. The earliest start time is the time when all the required processors for
execution are free. However, the selected processors should meet the application’s requirement
which is the deadline in this case. Overall system efficiency, load balancing, service discovery
speed, and discovery success rate are the metrics considered to determine the system’s
performance
Condor-G Condor-G is a distributed computing framework that concerns the user requirements
for resources at different locations that include discovering, acquiring,reliability management of
computational resources in a dynamic way, and the time needed for executing these tasks.
Condor-G uses mechanisms to provide security, resource discovery, and access to resources
across different domains. It also provides management for computation and use of resources
within a single administrative domain as well. It uses both the inter domain resource

JPPF grid computing
management protocols of the Globus Toolkit and the intra domain resource management
functions of condor to permit the user to use multi-domain resources, so they behave as if they
all belong to a single domain. In this architecture, the user defines the
task he wants to execute. This structure has the role of discovering and acquiring suitable
resources, without any regard to their location. A part of its role is initiating, monitoring,
managing the applications execution on the specified resources, detecting failures and taking
actions against them, and informing of application termination. The Grid Resource Allocation
and Management(GRAM) protocol is used to remotely submit the computational request to a
remote computational resource and to monitor and control the computation results.
Condor-G agent uses the Grid protocols to interact with machines in order to execute user jobs
on these machines. It is also responsible for the resubmission of failed jobs and recording of
computation on storage to be able to restart the job if job failure happens. Its objective is to
maximise the resource utilisation. When a user requests to submit a job, a Grid-manager daemon
is created by the scheduler. Grid-manager is responsible for handling all jobs that belong to a
single user and terminates upon completion of those jobs. Globus Job-manager daemon resulting
form Grid-manager job submission request connects to the Gridmanager using Globus Toolkit’s
Global Access to Secondary Storage (GASS) to
transfer the job’s executable and standard input files to provide real time streaming of standard
output and error. As a next step, the job manager sends the jobs to the local scheduler of the site
which was chosen to execute it. For resource discovery and scheduling purposes, Condor-G uses
a resource broker that is considered as a part of the Condor-G agent to collect information about
user authorisation, application requirements, and resource status in order to provide a list of
suitable resources .
Grid Computing Pool Grid Computing Pool (GCP) concerns large scale computing devices and
computing tools that are connected by high speed networks. The system’s users use the Internet
from anywhere to access the computing services. GCP makes use of priorities to execute some
applications more quickly. The system may allocate a single computer or cluster to an
application, or many supercomputers or clusters may work together to execute the application if
it is computationally intensive. The system employs the Client-Server model. The users use a
client to submit their requests to the Grid. That client connects to an active node via GCP server
in order to get access to computing services. Each user must register first to be able to use Grid
computing services. By doing that, the user can sign in to check the status of his submitted tasks.
The system divides the applications into three layers according to their computational intensity.

JPPF grid computing
The server receives requests from clients and tries to allocate suitable resources to those
applications. The task of server are receiving requests, sending responses to clients, sending tasks
to compute engines, receiving outputs from compute engines, scheduling tasks, keeping log of
status of operations, and broadcasting
scheduling information to other servers in the Grid. This system has a number of servers that all
have the same functions. However, only one of those servers can function at a time. The reason
of having many servers is if failure occurs at a server, another server can be used. The system
employs Hyper Text Transfer Protocol (HTTP) for sending and receiving messages
between the clie n and server. Each server includes a task scheduler that ensures mapping
applications to the resources that meet their requirements. Compute engines provide the
computing resources for executing different applications. Servers use Grid Computing Engine
Interface to access compute engines and heterogeneous mathematical computing
tools.GCP uses Grid Software to provide interfaces for communication, resource scheduling,
resource location, authentication, and data access. Grid software is also responsible for building
different high-layer Grid computing services .
2.8 Advantages of Grid computing for parallel job scheduling

This system is implemented to demonstrate the advantages of sharing resources belong to
various autonomous domains. The system divides the Grid into autonomous sites, and each site
has its resources and users. Furthermore, each site consists of a single parallel machine which is
made up of nodes. Each node has its specifications such as processor speed, and memory size,
and is connected to other nodes via a fast interconnection network. The machines located at
different sites have similar nodes, but different number of them. This system uses space-sharing
allocation and doesn’t take into consideration that an application can surpass its permitted time.
The system has a centralized scheduler for scheduling various applications. The system uses
backfill scheduling algorithm for scheduling applications on the parallel machine. The idea of
backfilling is if the available resources are not enough to execute the next application in the list,
then it tries to find another application from the list that can be executed on the available
resources without delaying the execution of the next application. The system addresses three
scenarios that are local job processing, job sharing, and multi-site computing. In local job
processing scenario, the resources belong to one site can only be utilized by the users of to the
same site, so sharing between sites is prohibited. Job sharing scenario allows resources belong to
different sites to be used by the users of other sites, but doesn’t allow the application to be

JPPF grid computing
executed on resources of multiple sites concurrently. The scheduling in job sharing consists of
two steps machine selection (selecting machines using Best-fit strategy
on which the selected machine for the job must leave the least number of free resources
if started), and scheduling algorithm (Backfilling). Finally, the multi-site computing scenario
allows the resources of different sites to be used by the users of other sites as well as allowing
the application to be executed on multiple sites concurrently. In multi-site computing scenario,
the scheduler searches for a site that has enough available resources for executing the
application. In the situation no such site exists, the sites are sorted in non-increasing order
according to the number of free resources they have to decrease the number of sites that their
free resources are combined by the scheduler to execute the application. Then, the scheduler
executes the application on a combination of free resources belong to multiple sites. In multi-site
scenario, the overhead results from bandwidth and delay is addressed by increasing the required
execution time. configurations were simulated. Each of those configurations consists of 512
resources. Those configurations comprise two configurations that have sites with the same
number of resources, two configurations that have sites with different number of resources, and
one configuration that has a single site containing all resources. 4 types of workloads were used
each having 10000 jobs to ensure that the results are consistent.
Average Weighted Response Time (AWRT) is used to determine the scheduling quality and
equals to the sum of weighted response time divided by the sum of resources utilized. A smaller
AWRT means better scheduling quality.

JPPF grid computing
3. Project Management
3.1 Primary Task
The various subtasks of the model are as follows:-
Communication:
Project initiation :involves discussing the use and applications of the grid and the current
research topics in the grid computing . study of various techniques of JPPF grid toolkit.
Requirement gathering :involves analyzing the project requirements. Procuring papers
and research materials about the topic. Study and discussion of the papers and
materials,their applicability.Analyzing the inputs and requirements of the system.
Planning:
Estimating: Finding the feasibility by estimating the project’ s cost, duration and effort.
sheduling:Developing the detailed plan of the project. Deciding the deadline anddurations
for each subtasks of the project.
Modeling:
Analysis :Performing detailed analysis of existing scheduling and balancing algorithms.
Design:Developing the architectural , data and procedural design for every componenet
of the system.
Implementation:
Implementation of the JPPF Grid toolkit.
Implementation of load balancing algorithm.
Implementation of the client side programs
Designing the database
Establishing the Connectivity with user Interface
Deployment:
Deploying the Module on two Nodes.

JPPF grid computing
3.1.1 a) Schedule :-Project Work Breakdown Structure

Work Task Description
1 Analysis Phase
1.1 Study of Software Cost Estimation, their models and other
research in this area
1.2 Study of Java Parallel Processing Framework and its application
Matrix Multiplication.
1.2.1 Procuring papers and research material about the topic
1.2.2 Study and discussion of the papers and their applicability
1.3 Problem Definition ,Scope & Feasibility Study
1.3.1 Defining the problem
1.3.2 Fixing the scope of the project
1.3.3 Feasibility Analysis
1.4 Requirement Analysis
1.5 Project Estimation
2 Design Phase
2.1 Architectural Design
2.1.1 Understanding how to design and implement Matrix
Multiplication
2.1.2 Design of the Algorithmic model
2.2 Design diagrams
3 Implementation Phase
3.1 Coding of Matrix Multiplication,designing database , establishing
connectivity.
3.2 Implementing GUI tool for displaying the output of cost, effort
and schedule for Matrix Multiplication and sample database
application
3.3 Integrating all the separate tools
4 Testing Phase
4.1 Unit Testing & debugging
4.2 Integration Testing
4.3 System Testing
5 Project Deployment
b) Tasks Network

JPPF grid computing
5 Project Deployment

JPPF grid computing
3.2 Project Schedule
Timeline Chart:
Work W1 W2 W3 W4 W5 W6 W7 W8 W9 W10 W11

Task
1
1.1
1.2
1.2.1
1.2.2
1.3
1.3.1
1.3.2
1.3.3
1.4
1.5
2
2.1
2.1.1
2.1.2
Work W12 W13 W14 W15 W16 W17 W18 W19 W20 W21 W22
Task
2.1.3
2.2
2.2
3
3.1
3.2
3.3
Work W23 W24 W25 W26 W27 W28 W29 W30 W31 W32
Task
3.2
4
4.1
4.2
4.3
5

JPPF grid computing
3.3 Estimation
Estimation based on functional points;-
Sr. no. Question Weight Factor(0-5)

1 Does the system require reliable backup & 5
recovery?
2 Are data communications required to transfer 5
information to or from the application?
3 Are there distributed processing functions? 5
4 Is performance critical? 5
5 Will the system run an existing , heavily 3
utilized operational environment?
6 Does the system required online data entry? 3
7 Does online data eentry require input transction 2
to be built on multiple screens?
8 Are master files updated online? 2
9 Are i/p, o/p, or enquires complex? 4
10 Is internal processing complex? 5
11 Is code reusable? 4
12 Are conversion & installation included in 3
Design?
13 Does system support multiple installation? 4
14 Is application designed to facilitate change and 3
ease of use by user?
Total(∑Fi) 53
Table3.3 Functional point estimation 1
Information Domain count Weighting Factor Total

Value
Simple Average Complex
External inputs(EIs) 7 3 2 4 21
External 2 4 5 6 10
outputs(EOs)

JPPF grid computing
External 2 3 4 6 12
inquiries(EQs)
Internal Logical 4 7 10 15 60
Files(ILFs)
External Interface 1 5 6 4 4
Files(EIFs)
Count Total 107
Table3.4 Functional point estimation 2
Calculation of FP:
FP=Count Total *(0.65+0.01(∑Fi))
FP=107*(0.65+0.01*54)
FP=127.33
Estimation of Cost, Efforts & Duration
Assuming 1 FP=40 lines of code
Assuming 15 FPs are produced in 1 person –month of effort
Size=5000 Lines of code
Efforts= Person-month
Assuming labour cost is 20000 per month
Cost= *20000=Rs.
Average Estimation: Effort= person –month
Cost=
3.4 Project Resources

Hardware :- 512 Mb of RAM
Windows 2000, XP, 2003 (32/64 bits), Linux 2.4 or later (32/64bits), or any other OS that
support JDK 1.5.0 or later, such as Solaris, Mac OS/X, HP-UX and so on.
• TCP/IP connectivity (at minimum a loop back interface)

• Java 2 Standard Edition 5.0 or later (jdk 1.5.0+)

JPPF grid computing
• An "unzip" utility such as 7zip or WinZip

• 1+ nodes.
Software :-
JPPF will work with any OS supporting a Java JVM 1.5.0 or later, including:
Linux and Unix platforms (32 and 64 bits)
Windows 2000, XP, 2003 (32 and 64 bits)
JVM :-JPPF has been tested with The following JVMs:
Sun JDK 1.5.0 , Sun JDK 6 , IBM JVM 1.5.0 , BEA JRockit 1.5.0
Special Resources
Apache Ant 1.6.2 or later
4. JPPF Framework
JPPF is an open source Grid Computing platform written in Java that makes it easy to run
applications in parallel, and speed up their execution by orders of magnitude. Write once, deploy
once, execute everywhere! In JPPF terminology, the basic unit of execution is called a task. It is
the smallest self-contained piece of code that can be executed remotely.

JPPF grid computing
JPPF is particularly suited for a class of problems called embarassingly parallel problems, where
a problem or program can be split into many independent tasks, and each task can be executed in
parallel.
4.1 System Architecture
Execution Flow
Division of
task &puts
into queue
From the diagram, the framework has a 3-tiered architecture, made of 3 distinct layers:

JPPF grid computing
• Client layer: provides an API and communication tools to use the framework to submit
tasks, to execute in parallel.
• Service layer: responsible for the communication between with the clients and the nodes,
along with the management of the execution queue, the load-balancing and recovery features,
and the dynamic loading of both framework and application classes onto the appropriate
nodes.
• Execution layer: these are the nodes. They execute individual tasks, return the execution
results, and dynamically request, from the JPPF driver, the code they need to execute the
client tasks.
4.1.1 High Level Architectural View

JPPF grid computing
4.1.2 Class Loading in JPPF

JPPF grid computing
4. 2 Job Scheduling Algorithms

JPPF has 3 different algorithms to compute the distribution of tasks to the nodes, each with its
own configuration parameters.
1.Static algorithm: "manual"
This algorithm simply distributes a fixed number of tasks to each node. It is suited for
networks where each node has equivalent characteristics (hardware and software), and where
the type and number of tasks remains the same. There is only one parameter to configure:
task.bundle.size, its value being the number of tasks to distribute to each node.
2.Heuristic algorithm: "autotuning"

This algorithm is heuristic in the sense that it determines a good solution for the number of
tasks to send to each node, while the solution may not be the optimal one. This algorithm is
loosely based on the Monte Carlo algorithm. The heuristic part is provided by the fact that
this algorithm performs a random walk within the space of solutions. It is a purely adaptive
algorithm, based on the known past performance of each node. It does not rely on, nor does it
know about, the characteristics of the nodes. (i.e.hardware and Software on the physical
host).This algorithm is local to each node connection, meaning that a separate task bundle
size is determined for each node, independently of the other nodes. In fact, the other nodes
will adjust due to the performance changes generated each time the bundle size changes.
3. Deterministic algorithm: "proportional"

As for the heuristic algorithm, this one is purely adaptive and based solely on the known past
performance of the nodes. However, contrary to the heuristic approach, the computation is
performed without a random part. Each bundle size is determined in proportion to the mean
execution time to the power of N. Here, N is one of the algorithm's parameters, called
"proportionality factor", hence the algorithm name. The mean time is computed as a moving
average over the last M executed tasks for a given node. M is the other algorithm parameter,
called "performance cache size". Also contrary to the heuristic approach, this algorithm is
global to the server, which means that the bundle size for each node depends on that of the
other nodes. This also means that it does not allow overriding the bundle size tuning strategy
at the node level. This algorithm is particularly well suited for relatively small networks, 100
nodes or less, and it out-Performs the heuristic algorithm in most cases. Over that number of
nodes, the Computation overhead is likely to outweigh the performance gain.

JPPF grid computing
4.3 Design Diagrams

4.3.1 Activity Diagram
Above figure shows the Activity diagram. First we start the JPPF driver or the server. There are
basically many nodes connected to the JPPF driver. We then start the nodes. After that, the client
gives a request to multiply 1000*1000 matrixes. The node will check that, if it is connected to
the JPPF driver or not. If it is not connected to the driver then it will automatically try to
reconnect to the driver and then it will be ready for taking the requests.
Driver will read the request and divide the tasks and give it to different nodes for execution by
bundling the tasks in the size of our need. For eg. If we want to bundle 5 tasks and there are 5
nodes then tasks 1 to 5 will be executed by node 1, 6 to 10 by node 2 and so on in a round robin
fashion.The nodes will decode and execute the tasks and return the results back to the server. The
server notifies the completion and sends the response back to the client.

JPPF grid computing
Finally, we can see the time elapsed to execute the task.

4.3.2 Class Diagram
Matrix Runner:
It is the runner class for matrix multiplication.
jppfClient : JPPF client used to submit execution requests.
log : Logger for this class.
main(String …args) : Entry point for this class, performs a matrix multiplication a number of
times. The number of times is specified as a configuration property named "matrix.iterations".
The size of the matrices is specified as a configuration property named "matrix.size".
output(String message) : Print a message to the console and/or log file.
perform(int size, int iterations, int nbRows): Perform the multiplication of 2 matrices with the
specified size, for a specified number of times.
Matrix:

JPPF grid computing
This class represents a square matrix of arbitrary size.
RANDOM_RANGE : The range of values for random values.

size : The size of this matrix.
values : The values in this matrix.
assignRandomValues : Initialize this matrix with random values.
getRow(int row) :Get the row a matrix values at the specified index.
getSize() : Get the size of this matrix.
getValueAt(int row,int column): Get a value at the specified coordinates.
multiply(Matrix matrix) : Compute the result of mutiplying this matrix by another: thisMatrix
x otherMatrix
multiplyRow(int n, Matrix matrix): Multiply a row of this matrix by another matrix.
setValueAt(int row, int column, double value): Set a value to the specified coordinates.
Matrix Task:
This task performs the multiplication of a matrix row by another matrix, as part of the
multiplication of 2 whole matrices.
DATA KEY : Data provider key mapping to the second matrix operand in the multiplication.
result : The result of this task's execution, ie a matrix row.
rowValues : The row of values to multiply by a matrix.
doWork() : Perform the multiplication of a matrix row by another matrix.
getResult : Get the result this task's execution, ie a matrix row.
JPPFClient:
This class provides an API to submit execution requests and administration commands, and
request server information data.
It has its own unique identifier, used by the nodes, to determine whether classes from the
submitting application should be dynamically reloaded or not, depending on whether the uuid h
as changed or not.
debugEnabled : Determines whether debug-level logging is enabled.
Executor : The pool of threads used for submitting execution requests.
Log : Logger for this class.

JPPF grid computing
Close() : Close this client and release all the resources it is using
initPools() : Read all client connection information from the configuration and
initialize the connection pools accordingly.
requestStatistics() : Send a request to get the statistics collected by the JPPF server.
submitAdminRequest(String password, String newPassword, BundleParameter command,

Map< BundleParameter,Object> parameters) : Submit an admin request with the specified
command name and parameters.
JPPFTask:
Abstract super class for all tasks submitted to the execution server. This class provides the basic
facilities to handle data shared among tasks, handling of task execution exception, and handling
of the execution results.
JPPF clients have to extend this class and must implement the run method.
dataProvider : The provider of shared data for this task.

exception : The exception that was raised by this task's execution.
result : The result of the task execution.
getDataProvider() : Get the provider of shared data for this task.
setDataProvider(DataProvider dataProvider) : Set the provider of shared data for this task.
getException() : Get the exception that was raised by this task's execution.
getResult() : Get the result of the task execution.

JPPF grid computing
4.3.2.1 Additional classes in JPPF
Packages
org.jppf Base classes used throughout the framework.
Support for socket-based communication with
org.jppf.classloader
remote services.
Support for the clients connecting to the JPPF
org.jppf.client
driver.
org.jppf.client.event Support for event handling in the JPPF client.
Support for the load-balancing of local versus
org.jppf.client.loadbalancer
remote execution on the client side.
API used for JPPF-annotated tasks and POJO
org.jppf.client.taskwrapper
tasks.
org.jppf.comm.discovery Support for automatic discovery of JPPF servers.
org.jppf.comm.socket Support for network communications.
org.jppf.demo.console Classes supporting the demonstration console.
Support for HTML doc generation, using place
org.jppf.doc
holders for templates inserted in the HTML code.
org.jppf.io Support for communication with remote services.
Classes supporting the common client interface for
org.jppf.jca.cci
the JPPF resource adapter.
Classes supporting the service provider interface for
org.jppf.jca.spi
org.jppf.jca.util Utility classes for the JPPF resource adapter.
Classes supporting the JPPF server connectivity for
org.jppf.jca.work
Classes supporting the management of
org.jppf.jca.work.submission
asynchronous submission of tasks.
Support for the JMX-based management of JPPF
org.jppf.management
components.
org.jppf.node Bootstrap classes for launching a node.
org.jppf.node.event Support classes for node event notifications.
Classes supporting the application of execution
org.jppf.node.policy
policy to task bundles and nodes.
org.jppf.node.screensaver Screen saver implementation of a node..
Classes supporting the management and lifecycle
org.jppf.plugin
of the JPPF plugin architecture.
Classes supporting the creation of client, driver and
org.jppf.process
node processes to perform tests.
Classes supporting the notification mechanism for
org.jppf.process.event events occurring when a process writes to its output
or error stream.
org.jppf.security Classes supporting security, encryption and
password management for the server

JPPF grid computing
administration.
Classes providing support for alternatives to Java
org.jppf.serialization
standard serialization mechanism.
Classes supporting the core functionality of the
org.jppf.server
JPPF asynchronous comunication model.
Classes supporting the client application-side of the
org.jppf.server.app
Support for the JPPF driver management and
org.jppf.server.management
monitoring based on JMX.
Classes supporting asynchronous communication
org.jppf.server.nio
through the NIO APIs.
Support for socket-based communication with
org.jppf.server.nio.classloader
remote services.
org.jppf.server.nio.multiplexer Classes supporting the multiplexing of TCP ports.
org.jppf.server.nio.multiplexer.generic Classes supporting the multiplexing of TCP ports.
Classes supporting the server node-side of the
org.jppf.server.nio.nodeserver
Classes supporting the server node-side of the
org.jppf.server.node
Classes supporting the inter-driver comunication
org.jppf.server.peer
model.
Classes supporting the data transported between
org.jppf.server.protocol
components of the communication model.
org.jppf.server.queue Classes supporting the tasks queuing mechanism.
Classes supporting the automatic tuning of the task
org.jppf.server.scheduler.bundle
bundle size.
org.jppf.server.scheduler.bundle.autotuned bundle size, using the proportional bundling
algorithm.
org.jppf.server.scheduler.bundle.proportional bundle size, using the proportional bundling
algorithm.
org.jppf.task.storage Support for tasks to access and sharing data.
org.jppf.ui.monitoring Support the server monitoring UI.
Classes for creating, configuring, displaying and
org.jppf.ui.monitoring.charts
updating charts.
Classes for configuring charts and their container
org.jppf.ui.monitoring.charts.config
tabs in a tabbed pane.
Set of classes to handle the incoming statistics from
org.jppf.ui.monitoring.data
the server.
org.jppf.ui.monitoring.event Support for events in the server monitoring UI.
Classes supporting the UI for nodes monitoring via
org.jppf.ui.monitoring.node
JMX.
Classes supporting the actions and menu items for
org.jppf.ui.monitoring.node.actions
the popu menu for in the nodes panel.
org.jppf.ui.options Classes used for automatic generation of options

JPPF grid computing
pages.
Classes supporting the event handling mechanisms
org.jppf.ui.options.event
for the options.
Factory classes used for definiting the options
org.jppf.ui.options.factory
pages in the admin tool.
Utility classes to build UI components from XML
org.jppf.ui.options.xml
descriptors.
Utility classes to make building UI components
org.jppf.ui.utils
easier.
org.jppf.ui.utils.colorscheme Classes used for the color sceme editor utility.
Utility classes, mostly providing configuration
org.jppf.utils
handling support.
sample Classes supporting the JPPF samples.
Classes demosntrating how to run multiple JPPF
sample.allinone
components in the same JVM.
sample.commandline Classes for the tasks dependency sample.
sample.helloworld Classes the hello world tutorial and samples.
sample.matrix Classes for the matrix multiplication example.
sample.matrix.clientpool Classes for the JPPF client pool demo.
sample.misc Miscellaneous tests of the JPPF framework.
sample.notification Classes for the task notification example.
sample.tasklength Classes for the long task demo.

JPPF grid computing
4.3.3 Deployment
Each multiplexer instance will deployed as a separate process. It will be having its own
configuration file and logging configuration file, as for the JPPF components.
The TCP port multiplexer will released in its own package, so it can be easily deployed on any
machine. Then we have to run the multiplexer for server host, client or node host & from a shell
or command prompt, run the Ant target "ant run.multiplexer"
Above figure will be the Deployment diagram, where all the nodes and clients are connected
in a local area network to the JPPF driver.

JPPF grid computing
4.4 JPPF Tasks and Execution Policy
An execution policy is an object that determines whether a particular set of JPPF tasks can be
executed on a JPPF node.It does so by applying the set of rules (or tests) it is made of,
against a set of properties associated with the node.
The properties of the node include:
• JPPF configuration properties

• System properties (including -D*=* properties specified on the JVM command line)
• Environment variables (e.g. PATH, JAVA_HOME, etc.)
• Networking: list of ipv4 and ipv6 addresses with corresponding host name when it can be
resolved
• Runtime information such as maximum heap memory, number of available processors,
etc...
The kind of tests that can be performed apply to the value of a property and include:
• Binary comparison operators: ==, <, <=, >, >= ; for instance: property_value <= 15
• Range operators (intervals): property_value in [a,b] , [a,b[ , ]a,b] , ]a,b[
• "One of" operator (discrete sets): property_value in { a1, ... , aN }
• "Contains string" operator: property_value contains "substring"
• Regular expressions: property_value matches "regexp"
• Custom, user-defined tests
The tests can also be combined into complex expressions using the boolean operators NOT,
AND, OR and XOR.
Using this mechanism, it is possible to write an execution policy such as: "Execute on a node
only if the node has at least 256 MB of memory and at least 2 CPUs available"
An execution policy is sent along with the tasks to the JPPF driver, and evaluated by the
driver. They do not need to be sent to the nodes.

JPPF grid computing
4.4.1 Creating an execution policy
An execution policy is an object whose type is a subclass of ExecutionPolicy.

It can be built in 2 ways:
• by API, using the classes in the org.jppf.node.policy
3.4.2 The TCP port multiplexer
In the configuration section that JPPF requires at least 3 TCP ports to function. In network
environments where a policy imposes the use of a firewall, these ports will generally be blocked,
preventing any traffic through unauthorized ports.
This situation is very common, and in the case of JPPF, is very difficult, even nearly impossible,
to work around. To address this situation, we have implemented a tool called TCP port
multiplexer, that enables the routing of network traffic from multiple ports to a single port on
one side, and the routing of the same traffic from a single port to multiple ones on the other side.
With this tool, it becomes possible to work with JPPF in fire walled environments, without
having to deploy a complex hardware/software infrastructure. It also comes as a component
separate from JPPF clients, servers and nodes, which mean that client applications continue to
use and deploy JPPF in exactly the same way as they already do.
4.5 JPPF & Networking
4.5.1 TCP port multiplexer-Architecture
To understand how the multiplexer works and how it integrates with a JPPF grid, let's take the
example of a typical JPPF configuration:
• The JPPF client, server and node are all on separate machines and use the default ports
11111, 11112 and 11113
• The network environment includes a firewall that will only let traffic through port 443

JPPF grid computing
This results in a configuration illustrated by the following figure:
A directed red arrow represents an incoming connection. The small circle at one end means that
the corresponding component is listening for connections on the specified port.
This architecture bears a number of remarks:
• nodes and clients connect to the multiplexer as if it were a local JPPF server
• the JPPF server accepts connections from the multiplexer as if they came from local
clients and nodes
• the multiplexing and demultiplexing of the network traffic is completely transparent to
the JPPF components
• the multiplexer implementation is based on the same network communication APIs used
in JPPF, and incurs the same benefits in terms of scalability, robustness and reliability
• as additional network routing steps are added, a performance decrease should be
expected, compared to a non-multiplexed JPPF grid
• in this configuration, management and monitoring of the nodes and server is not possible,
and should be disabled for the nodes and servers behind a firewall

JPPF grid computing
4.5.2 Configuration
In terms of configuration, we have seen in the Architecture section that the multiplexer plays a
different role, depending on whether it is on the JPPF server machine or not:
• a multiplexer on a JPPF server host only needs to listen to connections on a multiplexing

port
• a multiplexer on a JPPF client or node host binds to the JPPF ports, as if it were a server.
It needs to know which ports to bind to, and for each bound port which remote
multiplexer to route the traffic to.
This is illustrated in the following figure:
Here is a full configuration example for a server host:
#------------------------------------------------------------------------------#
# Local forwarding port this multiplexer listens to #
# The local port number to which to forward messages to is the first message #

JPPF grid computing
# sent by any inbound connection #

#------------------------------------------------------------------------------#
multiplexer.ports = 443
And for a non-server host:
Note:
• The clients and nodes must use, in their multiplexer configuration, the same port numbers
as those specified for the JPPF server. These port numbers are actually sent to the server
multiplexer, so that it knows how to re-route the traffic.
• The JPPF host specified in the clients and nodes configuration must be set to localhost or
127.0.0.1, as they connect to the local multiplexer.
Another use case is when you have not only a JPPF server, but also a client or a node on the
same machine.In this case, the node or client does not need a multiplexer, as it will connect
locally to the JPPF server.
This is illustrated in this figure:

JPPF grid computing
5.1 User Interface

JPPF framework comes with an administration console for centralized monitoring and
management. The console also displays real time server statistics and activity charts that display
network activities one can view the average execution time over the network and also the
average execution time of the node. Likewise the chart also displays the latest execution time
again both over network and for node. One can customize these charts as well.
The console also allows you to control the JPPF server and be plugged in to any different tool
you want to use for viewing activity over your cluster.
Interfaces also include the panel for driver, node and client.
5.1.1Driver
This is a JPPF driver’s console which indicates that the JPPF driver has started and it will open
the server monitoring tool which is shown in the next figure.

JPPF grid computing
Configuring the Driver
In addition to the common communication properties, the JPPF server uses a number of
additional parameters, to define the communication with peer servers, the maximum heap
memory allocated to the driver, the settings for remote debugging, and the initial configuration of
its auto-tuning algorithm.
Communicating with peer drivers
A JPPF driver can communicate with other drivers, which are then called peers. When this
happens, the driver who initiates the communication with another will be seen by its peer as a
node. Therefore, it will need to know the the host and port numbers of its peer for driver-to-node
communication and network class loading, through a number of configuration properties.
5.1.2 GUI Administrating & Monitoring Tool(Test case –Matrix Multiplication)

JPPF grid computing
This shows the JPPF Monitoring and Administration tool which shows all the statistics required
for analyzing and comparison purposes. It shows the Execution time of the server, Node
execution time, Network overhead time, Queue time and the Connections.
5.1.3 Node console

JPPF grid computing
This is the node console which partly shows which rows are being executed on that particular
node and the corresponding results. There are various such nodes on which different rows are
getting executed and then each node individually sends the results back to the driver.
Configuring a Node

JPPF grid computing
The configuration of a node addresses 4 majors areas of its activity: network communication,
security, failure recovery and performance.
Network communication
A JPPF node requires 2 socket connections: one for receiving tasks bundles from the server, the
other for the network classloader.
In fact, a node uses multiple network class loaders, but they all share the same network
connection. The advantages of this include greater scalability, less system resources
consumption, as well as a more secure communication model.
Security
JPPF nodes can't just do whatever they want on the machine that hosts them. Therefore, they
provide the means to restrict what permissions are granted to them on their host. These
permissions are based on the Java security policy model. To implement security, nodes require a
security policy file.
Failover and Recovery
The nodes have a built-in failover mechanism that makes them try to reconnect, when the
connection with the server is severed. They will try to reconnect until the connection is
established or until a timeout has expired. There are 3 configuration parameters that allow a finer
control of how this is performed:
reconnect.initial.delay: defines the time, in seconds, before the node starts trying to reconnect to
the server.
Example:
# Try to reconnect after 5 seconds have passed
reconnect.initial.delay = 5
The default value for this property is 1 second.
reconnect.max.time: defines the amount of time, in seconds, after which the node will stop
trying to reconnect with the server. When this timeout is reached, the node will shutdown

JPPF grid computing
gracefully with an error message. The time is counted after the initial delay specified in the
property above.
Example:
# Try to reconnect during 15mn max, after that shutdown

reconnect.max.time = 900
The default value for this property is 60 seconds.
reconnect.interval: defines the time, in seconds, between two attempts at reconnecting with the
server.
Example:
# Try to reconnect every 3 seconds after initial delay

reconnect.interval = 3
The default value for this property is 1 second.
Node Performance
The nodes execute their assigned tasks using a pool of worker threads. Depending on the node
hardware and software environment, if can be benefitial, in terms of performance, to specify a
number of worker threads greater than the default, which is one thread. There is one
configuration property that allows it: processing.threads. Example:
# 2 worker threads in the pool

processing.threads = 2
The default value for this property is 1 thread.
Communications Interfaces
The communication model and the nodes topology:-

Currently JPPF uses a model where the nodes work asynchronously; executing a task when one
is available from the JPPF server.

JPPF grid computing
The server, also called driver, receives execution requests submitted by client applications. Each
request is made of one or several tasks (there can be thousands of tasks).
Upon reception of the request, all tasks are individually put into an execution queue. When
they're not busy executing a task, the nodes listen to that queue, and take a task from it as soon as
one is available. The node, then, executes the task, returns the results to the server and waits for
another task to execute.
When a task's results are received, the server is notified and places the results in a list, in the
same position as that of the corresponding task. Once all tasks in a request are completed, the
server sends all results back to the submitting application.
5.1.4 Client console
1)Matrix Multiplication
This is the client console which has actually made the request for 1000*1000 matrix
multiplication.
It first gets connected to the JPPF driver and after execution displays the elapsed time for the
calculation.

JPPF grid computing
A JPPF client can connect to multiple servers. Each of these server connections is named and is
assigned a priority. The server with the highest priority is the one the client will use to submit
tasks or administration requests.
If multiple servers have the same priority from the client's point of view, then they will be
considered as a pool and tasks will be evenly distributed over the connections in the pool.
The priority determines a fallback order for the client: if the connection with the highest priority
fails for any reason, the client will fall back to the next connection with the highest prority.
A JPPF client requires 2 network connections with each server: one for submitting tasks and
administration requests, and receiving responses, the other to provide class definitions (or other
resources) when requested by the server classloader.
Complexity- Distributed Matrix Multiplication (coordinator/worker interaction):
(l*m) (m*n) (l*n)

JPPF grid computing
The code for the workers is given below:

process worker [i = 0 to n – 1] {
integer a [n] -- row i of matrix a
integer b [n, n] -- all of matrix b
integer c [n] -- row i of matrix c
receive initial values for vector a and matrix b
for [j = 0 to n – 1] {
c [j] := 0
for [k = 0 to n – 1] {
c [j] := c [j] + a [k] * b [k, j]
}
}
send result vector c to the coordinator process
}
Below you will find the code for the coordinator process:
process coordinator
integer a [n, n] -- source matrix a
integer b [n, n] -- source matrix b
integer c [n, n] -- source matrix c
initialize a and b
for [i = 0 to n – 1] {
send row i of a to worker [i]
send all of b to worker [i]
}
for [i = 0 to n – 1]
receive row i of c from worker [i]
print the results, which are shown now in matrix c
}
Client Implementation
The client has to split up the calculations into pieces that are executed in a single server node,
and pass them to the JPPF framework. The atomic portions that are executed in a JPPF node are

JPPF grid computing
called tasks. It is up to the client application to define a reasonable part of the complete
algorithm as a task. Small tasks may cause a high transport overhead, while large tasks may
cause poor parallelity in execution.
Task Implementation
A task that can be submitted to the JPPF framework for execution must be a specialisation of the
JPPFTask. It must at least implement the run() method. The run() method contains the code that
is executed in a JPPF node.
Client Initialisation
A JPPF client must initialise a connection to a JPPF server. This is done by creating an instance
of JPPFClient. The client connects with default parameters to the server, if no configuration file
is set by system properties.
import org.jppf.client.JPPFClient;
public static void main(String[] args) {

JPPFClient client = new JPPFClient();
// .. use the client
}
Task Submission
Tasks are submitted to the JPPFClient instance as a List of JPPFTask instances. The list is passed
to the submit() method, and a List of JPPFTask instances is returned, containing the results.
public static void main(String[] args) {
JPPFClient client = new JPPFClient();
List<JPPFTask> tasks = new ArrayList<JPPFTask>();
tasks.add(new HelloTask());
try {
// execute tasks
List<JPPFTask> results = client.submit(tasks, null);
} catch (Exception e) {
e.printStackTrace();
}

JPPF grid computing
Task Results
The result of a submission of a task list is returned by the submit() method. Each of the returned
JPPFTask instances contains the result of this specific task, or the Exception if the execution
failed. A client should always first check if an Exception occurred before the result is examined.
List<JPPFTask> results = client.submit(tasks, null);
JPPFTask t0 = results.get(0);
if (null == t0.getException())
{
Object result = t0.getResult();
// use the result ...
} else {
Exception ex = t0.getException();
// handle the exception ...
}
The main build script (build.xml) uses a properties file, build.properties, used to configure the
way the build will be performed.
Constraints for the use of product

The limit of this algorithm is that it can perform up to 1000*1000 matrix multiplication or
10,00,000 computations only because of the Java memory overflow. But if a more optimized
algorithm is used then it can support a larger size of matrix. Matrix multiplication algorithm can
be more optimized to get a better advantage of parallel processing.
Since release 0.8.3 of JPPF, the framework enforces security restrictions on the nodes, to prevent
the executed code from performing some actions, potentially dangerous for the host it runs on.
This is (roughly) equivalent to what you have for an applet (restrictions on network connections,
file IO, halting the JVM, etc...).
You might want to switch it off in some cases (for instance if JPPF is installed on a private
network). However, if the security is on, then it will likely prevent you from connecting to the
database server, unless you allow it by granting the proper rights in the node's security policy
file.

JPPF grid computing
2) Database oriented application-

Enterprise Resource Solution (ERP) is one of them.
There are several modules like Employee Information, Human Resource, Sales Force
Automation, Organization Generator etc… in the ERP software. This ERP application can be
executed on different nodes by different clients. In today’s world, ERP plays an important role in
all the companies for organizing the resources. So, if it can be implemented using JPPF then it
will be of a great value.
5.2 Snapshots
One sample database oriented application considered as Second test case :-
Login :-
After Login task- OpenMDI Form

JPPF grid computing
Change the password
Enter the new policy

JPPF grid computing
JPPF Monitoring and administration Tool with Minimum three clients
Search the policy by no.

JPPF grid computing
Searched record of policy no.32
DATA DESIGN:-

JPPF grid computing
Login table
Agent Details

JPPF grid computing
Policy Details
Agent
Thus JPPF framework is also useful for different types of Applications.

JPPF grid computing
6. 1 Testing
Testing is a process used to uncover errors and ensure that defined input will produce actual
results that agree with required results .astrategy for software testing integrates software test case
design methods into a well planned series of steps that result in successful construction of a
software.
Testing for the project will begin at the module level and will work outward towards the
integration of the entire system . The testing is done at different levels of implementation .
Unit Testing: The unit testing will be done after implementation of each module by providing
test jobs and parameters .This is to test whether module is giving the expected output or not.
Integration Testing: This is done after integration of all modules to form the complete job
scheduler .This is to test whether all modules works well with each other and the interfaces
between them are correct.
Validation Testing: This is done after the integration testing is over to check the results are
validated and expected or not.
Test Plan
1. Test should be planned long before testing begins.
2. Testing should begin “in the small” and progress toward testing “in the large”.
3. Exhausting testing is not possible.
4. To be most effective, testing should be conducted by an independent third party.

JPPF grid computing
6.2 Test Cases

Develop test data input, events or transactions & expected output for each test under
consideration.
Test Case Input Expected Output Actual Output

Checking Network Configuration Parameters Connection Connected
Connections (IP Address, Port no.) established
successfully
JPPF Driver should Configuration Parameters Driver is running & Driver is running and
be up and running. to run the driver.(Apache GUI monitoring tool GUI monitoring tool
Ant commands) appears. appears.
Node should be Configuration Parameters Node connected to Node connected to
connected to the (IP Address, Port no) the driver. the driver.
driver.
Node should be Configuration Parameters Node is Node is
reconnected to the (IP Address, Port no) automatically automatically
driver in case of reconnected to the reconnected to the
failure. driver. driver.
Driver disconnected Configuration Parameters Driver starts and Driver starts and
and then reconnected. to run the driver.(Apache nodes reconnect to nodes reconnect to
Ant commands) the driver the driver
1) First Application considered for the testing is of matrix multiplication. In this problem
1000*1000 Matrix Size considered to find out their multiplication. Overall no.of computation
required could large to very very large i.e. 100000 computations, or it can depend upon size of
matrices. There are no of ways in which these multiplication can be done in parallel. Matrix
multiplication algorithm can be more optimized to get a better advantage of parallel processing.
This nature of the problem makes it suitable to test the working of JPPF scheduler.
For the testing no of such problems are given to the global scheduler to schedule at different
nodes within this grid toolkit. again as the problem can be solved in parallel. It is divided into no
of tasks and distributed among the nodes.
2) Second Application considered sample life insurance application. In this application four
tables are designed in Ms-access. Logintask and MDIform designed at server side, login program
client side using Java Programming language with different components such as Swing &
Frames.

JPPF grid computing
Comparisons and Analysis

The following Chart shows the comparison between Sequential and Parallel Execution time for
1000*1000 Matrix Size.
As shown sequential execution takes 2 minutes 05 seconds.
Whereas the maximum Execution time using JPPF Driver is 1 minute o7 seconds.
The minimum Execution time is 23 seconds 406 milliseconds
Thus, this proves that the Parallel Execution using JPPF gives much better performance than
sequential execution.
Bar chart - No. of Nodes vs Execution time
2.5
2
Execution Time
(seconds)
1.5 Serial
1 Parallel
0.5
0
1 2 3 4
No. of Nodes
Speedup Formula
Sequential execution time
Speedup =
Parallel execution time
Now Serial execution time =1.02 minutes

Parallel execution time = 26 seconds
Speedup = 1.02
0.23
Speedup = 3.92
Efficiency :

JPPF grid computing
Efficiency = . Speedup .
No of Processors
=. 3.92 .
4
= 0.98
Sequential time complexity: Θ(n3):

The Algorithm requires l*m*n additions and the same number of multiplications. Hence the
time complexity of multiplying two n*n matrices using the sequential algorithm is O(n3).
Parallel computation time: Θ(n3/p):

It is the time required by sequential algorithm / number of processors since process is
divided into number of tasks which is submitted to different processors.
Parallel communication time: Θ(n2log p):

It is the time required for transporting matrix elements among the processors.
Parallel overhead: T0(n,p) = Θ(pn2log p):

This is the total transport time required by all the processors collectively.
Status with Only one node :-

JPPF grid computing
Status with two nodes:-

JPPF grid computing
Network Chart

JPPF grid computing
This is a Network chart which shows the average execution time, latest execution time, average
node execution time and latest node execution time.
.
.

JPPF grid computing
7. Conclusion
As job scheduling becomes very difficult to find the optimal solution when the grid is heavily
loaded with the different job sizes and diversified computing capabilities of resources. it is a time
consuming job to find the perfect allocation to balance the load , reducing overall time and
system throughput. The ultimate solution over this problem is to use heuristic algorithm to
allocate the jobs to resources. This can be achieve greater load balancing in all cases, all job
sizes.
The scheduling algorithms will be implemented with Java Parallel Processing Framework
(JPPF-toolkit) in grid and evaluated against different number of jobs & job sizes. The problem of
matrix chain multiplication will considered as the test cases. At any time number of such
problem will be considered as jobs to the grid global scheduler to schedule it on the cluster
.Local scheduler at each cluster again subdivides each job of performing individual matrix
multiplication and these jobs will run in parallel on the cluster . Depending upon the algorithm
selected and jobs taken , various results will be produced and will be compared with each other
for the total time required to complete all the jobs . JPPF is a framework to denote the
parallelism of work on the available resources. It reduces time and effort to a great extent.
Thus successfully demonstrated the 1000*1000 matrix multiplication using JPPF
driver.
This program merits parallelization. Adding processors reduces the computation time to a great
extent in comparison with the serial program.
By keeping matrix size as constant and how increasing processors can reduce time.
By keeping nodes constant and varying the matrix size.
This program is scalable and the performance can be increased as the number of processors
increase and we can also see from the analysis graph that communication complexity is much
lower than the computational complexity.

JPPF grid computing
8. Future Scope
Extended Grid Topology
JPPF can be extended to include many servers, communicating together in a peer-to-peer

topology.
In this topology, each server is seen by its peers as a node, and sees its peers as clients.
There are a number of major advantages to this design:
• It enables a greater scalability of the JPPF grid, by allowing the "pluging-in" of additional
servers dynamcally. This way, a server can delegate a part of its load to other servers.
• No matter how many servers are present, nodes and clients communicate with them in the
exact same way
• Peer server connections benefit from the same failover and recovery features available to
nodes and clients
Matrix multiplication algorithm can be more optimized to get a better advantage of parallel
processing.

JPPF grid computing
Future Scope in case of other applications, are many.

Enterprise Resource Solution (ERP) is one of them.
We can have several modules like Employee Information, Human Resource, Sales Force
Automation, Organization Generator etc… in the ERP software. This ERP application can be
executed on different nodes by different clients. In today’s world, ERP plays an important role in
all the companies for organizing the resources. So, if it can be implemented using JPPF then it
will be of a great value.
Other applications include:
Mandlebrot fractals explorer:
A very graphical and interactive tool that generates Mandelbrot images and enables their
exporation by zooming panning, etc...
Sequence Alignment:
A graphical tool that performs the search of a DNA or protein sequence in a sequence database.
Web Search Engine:
A simple tool to perform web searches based on a user-spceified query.
Limitations
Some common problems are described in the following sections.
Remote Execution
The tasks are executed remotely in a server node. The instances of the tasks are serialized and
transferred to the node server for execution. This might cause some unexpected behaviour, in
particular:

JPPF grid computing
• All static fields are initialised in the node server, getting the initial values again as
defined in the class. So static fields should not be used in tasks, unless they are final or
set to the desired value in the run() method.
• All transient fields are not transferred to the node server. They will have a null value.
Fields that are required in the run method should not be transient, while all other fields
might be declared transient to reduce the amount of transferred data.
• Resources like network connections and files cannot be used in tasks. Network
connections have to be re-opened in the run method, and files must be read into class
fields before the task is submitted.
Security Restrictions
The node server that executes the tasks typically runs with a restricted access policy. The policy
needs to be adapted to the access required by tasks. The policy file delivered with JPPF is named
jppf.policy and contains only those rights required by the JPPF node server itself.
9. References
[1] The jppf Website :- www.jppf.org

JPPF grid computing
[2] Introduction to Grid Computing with Globus, IBM RedBook-SG24-6895

[3] Distributed Job Scheduling on Computational Grids using Multiple Simultaneous Requests
-Vijay Subramani Rajkumar Kettimuthu Srividya Srinivasan P. Sadayappan-IEEE-Department of
Computer and Information Science The Ohio State University subraman kettimut ,srinivas ,saday
-@cis.ohio-state.edu
[4] QoS Guided Min-Min Heuristic for Grid Task Scheduling *-IEEE Paper,
HE Xiaoshan (‰½ÏþŽX)1 Xian-He Sun (ËïÏÍ˜a)1 Gregor von Laszewski2
1 Department of Computer Science, Illinois Institute of Technology, IL, USA
2 Mathematics and Computer Science Division, Argonne National Laboratory, IL, USAE-mail:
hexiaos@iit.edu, sun@cs.iit.edu, gregor@mcs.anl.gov
Received, 2003; revised May, 2003
[5] IEEE paper-“ Basic Scheduling in Grid environment &Grid Scheduling Ontology “ -By:
Shreyansh Vakil CSE714 – Fall 2006 - Dr. Russ Miller. Department of Computer Science and
Engineering, SUNY Buffalo
[6] I. Foster, H. Kishimoto, A. Savva, D. Berry, A. Djaoui, A. Grimshaw, B. Horn,F. Maciel, F.
Siebenlist, R. Subramaniam, J. Treadwell and J. Von Reich,The Open Grid Services Architecture,
Version 1.0, http://forge.gridforum.org/projects/ogsa-wg, January 2005.
[7] Schopf J.M: A General Architecture for Scheduling on the Grid, special issue of JPDC on
Grid Computing, (2002).
[ 8] “Ant Algorithm for Grid Scheduling Problem” Stefka Fidanova and Mariya Durchova IPP –
BAS, Acad. G. Bonchev, bl.25A, 1113 Sofia, Bulgaria , 2006 stefka@parallel.bas.bg,
[9] “Dynamic Load balancing for grid computing”Belabbas Yagoubi and Yaha slimani,
TRANSACTION ON ENGG., COMPUTING AND TECHNOLOGY VOLUME 13 MAY 2006
ISSN 1305-5313.
[10] “Risk Resilient heuristics and genetic algorithms for security –assured Grid job
Scheduling”,Shanshag Song, Kai HWangand Yu-Kwong Kwok, IEEE Transactions on computers
vol-.55,no.6, June2006.
[11]Parallel Processing – Michael J. Quinn

Report

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Report

Diunggah oleh

Hak Cipta:

Format Tersedia

JPPF grid computing

SVKM’s Mukesh Patel School of Technology & Engineering Page- 1

1.2 CONCEPTS AND TERMINOLOGIES

1.3 PROBLEM DEFINITION

Traditional Client/Server architecture

In the traditional Client-Server Application, multiple clients requesting to a server for a

SVKM’s Mukesh Patel School of Technology & Engineering Page- 2

SVKM’s Mukesh Patel School of Technology & Engineering Page- 3

1.5 SCOPE OF PROJECT

SVKM’s Mukesh Patel School of Technology & Engineering Page- 4

1.7 PROPOSED SYSTEM

 A JPPF grid can be up and running in minutes

SVKM’s Mukesh Patel School of Technology & Engineering Page- 5

2 What Grid computing is

SVKM’s Mukesh Patel School of Technology & Engineering Page- 6

SVKM’s Mukesh Patel School of Technology & Engineering Page- 7

2.1 Grid components

2.2 Mapping categories

SVKM’s Mukesh Patel School of Technology & Engineering Page- 8

SVKM’s Mukesh Patel School of Technology & Engineering Page- 9

2.3 Application requirements

SVKM’s Mukesh Patel School of Technology & Engineering Page- 10

2.4 Grid resource management and scheduling

2.5 Resource scheduler tasks

SVKM’s Mukesh Patel School of Technology & Engineering Page- 11

2.6 Grid resource management and scheduling challenges

SVKM’s Mukesh Patel School of Technology & Engineering Page- 12

2.7 Scheduling schemes

SVKM’s Mukesh Patel School of Technology & Engineering Page- 13

2.7.1 Scheduling performance metrics

SVKM’s Mukesh Patel School of Technology & Engineering Page- 14

2.7.2 Scheduling strategies

SVKM’s Mukesh Patel School of Technology & Engineering Page- 15

SVKM’s Mukesh Patel School of Technology & Engineering Page- 16

d) Fully decentralized discovery in Grid environments This system concerns resource

e) Performance prediction technology for agent-based resource management in Grid

SVKM’s Mukesh Patel School of Technology & Engineering Page- 17

SVKM’s Mukesh Patel School of Technology & Engineering Page- 18

SVKM’s Mukesh Patel School of Technology & Engineering Page- 19

2.8 Advantages of Grid computing for parallel job scheduling

SVKM’s Mukesh Patel School of Technology & Engineering Page- 20

SVKM’s Mukesh Patel School of Technology & Engineering Page- 21

The various subtasks of the model are as follows:-

Analysis :Performing detailed analysis of existing scheduling and balancing algorithms.

Implementation of the JPPF Grid toolkit.

Implementation of load balancing algorithm.

Implementation of the client side programs

Designing the database

Establishing the Connectivity with user Interface

Deploying the Module on two Nodes.

SVKM’s Mukesh Patel School of Technology & Engineering Page- 22

3.1.1 a) Schedule :-Project Work Breakdown Structure

SVKM’s Mukesh Patel School of Technology & Engineering Page- 23

SVKM’s Mukesh Patel School of Technology & Engineering Page- 24

3.2 Project Schedule

Work W1 W2 W3 W4 W5 W6 W7 W8 W9 W10 W11

SVKM’s Mukesh Patel School of Technology & Engineering Page- 25

Estimation based on functional points;-

Sr. no. Question Weight Factor(0-5)

Table3.3 Functional point estimation 1

Information Domain count Weighting Factor Total

SVKM’s Mukesh Patel School of Technology & Engineering Page- 26

Table3.4 Functional point estimation 2