paper-4

ABSTRACT
“Grid” computing has emerged as an important new field, distinguished from conventional distributed computing by its focus on large-scale resource sharing, innovative applications, and ,in some cases, high-performance orientation .In this technical paper we presented this new type of computing. First we reviewe the problem which we define as flexible, secure, coordinated resource sharing among dynamic collections of individuals, institutions, and resources—what we refer to as virtual organizations. In such settings, there encounter unique authentication, authorization, resource access, resource discovery, and other challenges. It is this class of problem that is addressed by Grid technologies. We presentedmm the Grid concept in analogy with that of an electrical power grid and Grid vision We also discussed the reason why grids are needed and why now we are concentrating on this Grid computing .Next, we present an extensible and open Grid architecture, in which protocols, services, application programming interfaces, and software development kits are categorized according to their roles in enabling resource sharing. We also describe requirements that must satisfy and also protocols to provide interoperability among different Grid systems . We also compared the Grid computing with that of Cluster computing and Internet. Finally we present a brief introduction about the successful Grid technology GLOBUS toolkit a defacto standard for major protocols and services. We have been part of Grid network whose main target is to cure cancer and also trying to be part of another grid network which concentrates on SETI(Search of Extraterrestrial Intelligence)..

INDEX



1. Introduction
1.1Grid Concept and Grid Vision
2. What is Grid?
3. The Grid problem
4. Why Grids and Why now?
5. The Grid Architecture Description
5.1 Fabric Layer: Interfaces To Local Control
5.2 Connectivity Layer: Communicating Easily and Securely
5.3 Resource Layer: Sharing Single Resource
5.4 Collective: Coordinating Multiple Resources
6. Cluster Computing –Grid Computing –Internet
7. The Future: All Software is Network- Centric
8. Benefits of Grid Computing
9. Summary







1. INTRODUCTION:
The term “THE GRID” was coined in the mid1990’s to denote a proposed distributed computing infrastructure for advanced science and engineering. Considerable progress has since been made on the construction of such an infrastructure, but the term “Grid” has also been conflated, at least in popular perception, to embrace everything from advanced networking to artificial intelligence. One might wonder whether the term has any real substance and meaning. Is there really a distinct “Grid problem” and hence a need for new “Grid technologies”? If so, what is the nature of these technologies, and what is their domain of applicability? While numerous groups have interest in Grid concepts and share, to a significant extent, a common vision of Grid architecture, we do not see consensus on the answers to these questions.
Our purpose in this article is to argue that the Grid concept is indeed motivated by a real and specific problem and that there is an emerging, well-defined Grid technology base that addresses significant aspects of this problem. In the process, we develop a detailed architecture and roadmap for current and future Grid technologies. Furthermore, we assert that while Grid technologies are currently distinct from other major technology trends, such as Internet, enterprise, distributed, and peer-to-peer computing, these other trends can benefit significantly from growing into the problem space addressed by Grid technologies.
1.1 GRID CONCEPT AND GRID VISION
The following are points to be noted when comparing our Grid with that of a power grid.
• “On-demand” access to ubiquitous distributed computing
• Transparent access to multi-petabyte distributed data bases
• Easy to plug resources into
• Complexity of the infrastructure is hidden
“When the network is as fast as the computer's internal links, the machine disintegrates across the net into a set of special purpose appliances”
E-Science and information utilities (Taylor)
• Science increasingly done through distributed global collaborations between people, enabled by the Internet
• Using very large data collections, terascale computing resources, and high performance visualisation
• Derived from instruments and facilities controlled and shared via the infrastructure
• Scaling x1000 in processing power, data, bandwidth
2. What is Grid?
“Resource sharing & coordinated problem solving in dynamic, multi-institutional virtual organizations”.



3. THE GRID PROBLEM
The real and specific problem that underlies the Grid concept is coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations. The sharing that we are concerned with is not primarily file exchange but rather direct access to computers, software, data, and other resources, as is required by a range of collaborative problem-solving and resource-brokering strategies emerging in industry, science, and engineering. This sharing is, necessarily, highly controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs. A set of individuals and/or institutions defined by such sharing rules form what we call a virtual organization (VO).
VOs vary tremendously in their purpose, scope, size, duration, structure, community, and sociology. Nevertheless, careful study of underlying technology requirements leads us to identify a broad set of common concerns and requirements. In particular, we see a need for highly flexible sharing relationships, ranging from client-server to peer-to-peer; for sophisticated and precise levels of control over how shared resources are used, including fine-grained and multi-stakeholder access control, delegation, and application of local and global policies; for sharing of varied resources, ranging from programs, files, and data to computers, sensors, and networks; and for diverse usage modes, ranging from single user to multi-user and from performance sensitive to cost-sensitive and hence embracing issues of quality of service, scheduling, co-allocation, and accounting.
Current distributed computing technologies do not address the concerns and requirements just listed. For example, current Internet technologies address communication and information exchange among computers but do not provide integrated approaches to the coordinated use of resources at multiple sites for computation. Business-to-business exchanges focus on information sharing (often via centralized servers).
4. WHY GRIDS AND WHY NOW?
• A biochemist exploits 10, 000 computers to screen 100,000 compounds in an hour
• 1,000 physicists worldwide pool resources for petaop analyses of petabytes of data
• Civil engineers collaborate to design, execute, & analyze shake table experiments
• Climate scientists visualize, annotate, & analyze terabyte simulation datasets
• An emergency response team couples real time data, weather model, population data
• A multidisciplinary analysis in aerospace couples code and data in four companies
• A home user invokes architectural design functions at an application service provider
• Scientists working for a multinational soap company design a new product
• A community group pools members’ PCs to analyze alternative designs for a local road
Why Now?
The following are the reasons why now we are concentrating on Grids:
• Moore’s law improvements in computing produce highly functional end systems
• The Internet and burgeoning wired and wireless provide universal connectivity
• Changing modes of working and problem solving emphasize teamwork, computation
• Network exponentials produce dramatic changes in geometry and geography
The network potentials are as follows:
Network vs. computer performance
• Computer speed doubles every 18 months
• Network speed doubles every 9 months
• Difference = order of magnitude per 5 years
A comparison of networks vs Computer performance from 1986 to 2000 is as follows:
The Computers performance is increased 500 times where as Network performance is increased by 340,000 times.
5.THE GRID ARCHITECTURE DESCRIPTION
Our goal in describing our Grid architecture is not to provide a complete enumeration of all required protocols (and services, APIs, and SDKs) but rather to identify requirements for general classes of component. The result is an extensible, open architectural structure within which can be placed solutions to key VO requirements. Our architecture and the subsequent discussion organize components into layers, as shown in Figure. Components within each layer share common characteristics but can build on capabilities and behaviours provided by any lower layer. In specifying the various layers of the Grid architecture, we follow the principles of the “hourglass model”. The narrow neck of the hourglass defines a small set of core abstractions and protocols (e.g., TCP and HTTP in the Internet), onto which many different high-level behaviours can be mapped (the top of the hourglass), and which themselves can be mapped onto many different underlying technologies (the base of the hourglass).
A p p l i c a t i o n s Diverse global



services core services


Local OS




5.1 FABRIC LAYER: INTERFACES TO LOCAL CONTROL
The Grid Fabric layer provides the resources to which shared access is mediated by Grid protocols: for example, computational resources, storage systems, catalogs, network resources, and sensors. A “resource” may be a logical entity, such as a distributed file system, computer cluster, or distributed computer pool; in such cases, a resource implementation may involve internal protocols.
There is thus a tight and subtle interdependence between the functions implemented at the Fabric level, on the one hand, and the sharing operations supported, on the other.

5.2 CONNECTIVITYLAYER: COMMUNICATING EASILY AND SECURELY
The Connectivity layer defines core communication and authentication protocols required for Grid-specific network transactions. Communication protocols enable the exchange of data between Fabric layer resources. Authentication protocols build on communication services to provide cryptographically secure mechanisms for verifying the identity of users and resources.
Communication requirements include transport, routing, and naming. While alternatives certainly exist, we assume here that these protocols are drawn from the TCP/IP protocol stack: specifically, the Internet (IP and ICMP), transport (TCP, UDP), and application (DNS, OSPF, RSVP, etc.) layers of the Internet layered protocol architecture
5.3 RESOURCE LAYER: SHARING SINGLE RESOURCE
The Resource layer builds on Connectivity layer communication and authentication protocols to define protocols (and APIs and SDKs) for the secure negotiation, initiation,
monitoring, control, accounting, and payment of sharing operations on individual resources. Resource layer implementations of these protocols call Fabric layer functions to access and control local resources. Resource layer protocols are concerned entirely with individual resources and hence ignore issues of global state and atomic actions across distributed collections; such issues are the concern of the Collective layer discussed next.
Two primary classes of Resource layer protocols can be distinguished:
• Information protocols are used to obtain information about the structure and state of a
resource, for example, its configuration, current load, and usage policy (e.g., cost).
• Management protocols are used to negotiate access to a shared resource, specifying, for example, resource requirements (including advanced reservation and quality of service) and the operation(s) to be performed, such as process creation, or data access. Since management protocols are responsible for instantiating sharing relationships, they must serve as a “policy application point,” ensuring that the requested protocol operations are consistent with the policy under which the resource is to be shared. Issues that must be considered include accounting and payment. A protocol may also support monitoring the status of an operation and controlling (for example, terminating) the operation.
5.4 COLLECTIVE: COORDINATING MULTIPLE RESOURCES
While the Resource layer is focused on interactions with a single resource, the next layer in the architecture contains protocols and services (and APIs and SDKs) that are not associated with any one specific resource but rather are global in nature and capture interactions across collections of resources. For this reason, we refer to the next layer of the architecture as the Collective layer. Because Collective components build on the narrow Resource and Connectivity layer “neck” in the protocol hourglass, they can implement a wide variety of sharing behaviors without placing new requirements on the resources being shared.
6. CLUSTER COMPUTING –GRID COMPUTING –INTERNET
Cluster computing focuses on platforms consisting of often homogeneous interconnected nodes in a single administrative domain.
• Clusters often consist of PCs or workstations and relatively fast networks
• Cluster components can be shared or dedicated
• Application focus is on cycle-stealing computations, high-throughput computations, and distributed computations.
Web focuses on platforms consisting of any combination of resources and networks which support naming services, protocols, search engines, etc.
• Web consists of very diverse set of computational, storage, communication, and other resources shared by an immense number of users
• Application focus is on access to information, electronic commerce, etc.
Grid focuses on ensembles of distributed heterogeneous resources used as a platform for high performance computing.
• Some grid resources may be shared, other may be dedicated or reserved
• Application focus is on high-performance, resource-intensive applications
7. THE FUTURE: ALL SOFTWARE IS NETWORK- CENTRIC
• We don’t build or buy “computers” anymore, we borrow or lease required resources
o When I walk into a room, need to solve a problem, need to communicate
• A “computer” is a dynamically, often collaboratively constructed collection of processors, data sources, sensors, networks
o Similar observations apply for software
And Thus …
• Reduced barriers to access mean that we do much more computing, and more interesting computing, than today => Many more components (& services);massive parallelism
• All resources are owned by others => Sharing (for fun or profit) is fundamental; trust, policy, negotiation, payment
• All computing is performed on unfamiliar systems => Dynamic behaviors, discovery, adaptivity, failure.
8. BENEFITS OF GRID COMPUTING
• Grid computing enables organizations to aggregate resources within an entire IT infrastructure no matter where in the world they are located. It eliminates situations where one site is running on maximum capacity, while others have cycles to spare.
• Organizations can dramatically improve the quality and speed of the products and services they deliver, while reducing IT costs by enabling transparent collaboration and resource sharing.
• Grid computing enables companies to access and share remote databases. This is especially beneficial to the life sciences and research communities, where enormous volumes of data are generated and analysed during any given day.
• Grid computing enables widely dispersed organizations to easily collaborate on projects by creating the ability to share everything from software applications and data, to engineering blueprints.
• Grid computing can create a more robust and resilient IT infrastructure better able to respond to minor or major disasters.
• A grid can harness the idle processing cycles that are available in desktop PCs located in various locations across multiple time zones. For example, PCs that would typically remain idle overnight at a company's Tokyo manufacturing plant could be utilized during the day by its North American operations.
9. SUMMARY
• The Grid problem: Resource sharing & coordinated problem solving in dynamic, multi- institutional virtual organizations
• Grid architecture: Emphasize protocol and service definition to enable interoperability and resource sharing.

paper-3

Abstract
Increasing desktop CPU power and communications bandwidth have lead to the discovery of a new computation environment which helped to make distributed computing a more practical idea. The advantages of this type of architecture for the right kinds of applications are impressive. The most obvious is the ability to provide access to supercomputer level processing power or better for a fraction of the cost of a typical supercomputer. For this reasons this technology can be termed as the “Poor mans Super Computer”.
In this paper we discuss “How Distributed Computing Works”, The Application Characteristics that make it special from other networking technologies. When going for a new technology it’s a must for us to the competing technologies and compare it with the new trends. We also discuss the areas where this computational technology can be applied. We also discuss the level of security and the standards behind this Technology.
Finally coming to the conclusion, however, the specific promise of distributed computing lies mostly in harnessing the system resources that lies within the firewall. It will take years before the systems on the Net will be sharing compute resources as effortlessly as they can share information.
\

Introduction
The numbers of real applications are still somewhat limited, and the challenges--particularly standardization--are still significant. But there's a new energy in the market, as well as some actual paying customers, so it's about time to take a look at where distributed processing fits and how it works.
Increasing desktop CPU power and communications bandwidth has also helped to make distributed computing a more practical idea. Various vendors have developed numerous initiatives and architectures to permit distributed processing of data and objects across a network of connected systems.
One area of distributed computing has received a lot of attention, and it will be a primary focus of this paper--an environment where you can harness idle CPU cycles and storage space of hundreds or thousands of networked systems to work together on a processing-intensive problem. The growth of such processing models has been limited, however, due to a lack of compelling applications and by bandwidth bottlenecks, combined with significant security, management, and standardization challenges.
How It Works
A distributed computing architecture consists of very lightweight software agents installed on a number of client systems, and one or more dedicated distributed computing management servers. There may also be requesting clients with software that allows them to submit jobs along with lists of their required resources.
An agent running on a processing client detects when the system is idle, notifies the management server that the system is available for processing, and usually requests an application package. The client then receives an application package from the server and runs the software when it has spare CPU cycles, and sends the results back to the server. If the user of the client system needs to run his own applications at any time, control is immediately returned, and processing of the distributed application package ends.

A Typical Distributed System
Distributed Computing Management Server



The servers have several roles. They take distributed computing requests and divide their large processing tasks into smaller tasks that can run on individual desktop systems (though sometimes this is done by a requesting system). They send application packages and some client management software to the idle client machines that request them. They monitor the status of the jobs being run by the clients. After the client machines run those packages, they assemble the results sent back by the client and structure them for presentation, usually with the help of a database.
The server is also likely to manage any security, policy, or other management functions as necessary, including handling dialup users whose connections and IP addresses are inconsistent. Obviously the complexity of a distributed computing architecture increases with the size and type of environment. A larger environment that includes multiple departments, partners, or participants across the Web requires complex resource identification, policy management, authentication, encryption, and secure sandboxing functionality.
Administrators or others with rights can define which jobs and users get access to which systems, and who gets priority in various situations based on rank, deadlines, and the perceived importance of each project. Obviously, robust authentication, encryption, and sandboxing are necessary to prevent unauthorized access to systems and data within distributed systems that are meant to be inaccessible.
If you take the ideal of a distributed worldwide grid to the extreme, it requires standards and protocols for dynamic discovery and interaction of resources in diverse network environments and among different distributed computing architectures. Most distributed computing solutions also include toolkits, libraries, and API's for porting third party applications to work with their platform, or for creating distributed computing applications from scratch.
Comparisons and Other Trends

Distributed vs. Grid Computing
There are actually two similar trends moving in tandem--distributed computing and grid computing. Depending on how you look at the market, the two either overlap, or distributed computing is a subset of grid computing. Grid Computing got its name because it strives for an ideal scenario in which the CPU cycles and storage of millions of systems across a worldwide network function as a flexible, readily accessible pool that could be harnessed by anyone who needs it.
Sun defines a computational grid as "a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to computational capabilities." Grid computing can encompass desktop PCs, but more often than not its focus is on more powerful workstations, servers, and even mainframes and supercomputers working on problems involving huge datasets that can run for days. And grid computing leans more to dedicated systems, than systems primarily used for other tasks.
Large-scale distributed computing of the variety we are covering usually refers to a similar concept, but is more geared to pooling the resources of hundreds or thousands of networked end-user PCs, which individually are more limited in their memory and processing power, and whose primary purpose is not distributed computing, but rather serving their user.
Distributed vs. Other Trends



Application Characteristics
Obviously not all applications are suitable for distributed computing. The closer an application gets to running in real time, the less appropriate it is. Even processing tasks that normally take an hour are two may not derive much benefit if the communications among distributed systems and the constantly changing availability of processing clients becomes a bottleneck. Instead you should think in terms of tasks that take hours, days, weeks, and months. Generally the most appropriate applications consist of "loosely coupled, non-sequential tasks in batch processes with a high compute-to-data ratio." The high compute to data ratio goes hand-in-hand with a high compute-to-communications ratio, as you don't want to bog down the network by sending large amounts of data to each client, though in some cases you can do so during off hours. Programs with large databases that can be easily parsed for distribution are very appropriate.
Clearly, any application with individual tasks that need access to huge data sets will be more appropriate for larger systems than individual PCs. If terabytes of data are involved, a supercomputer makes sense as communications can take place across the system's very high speed backplane without bogging down the network. Server and other dedicated system clusters will be more appropriate for other slightly less data intensive applications. For a distributed application using numerous PCs, the required data should fit very comfortably in the PC's memory, with lots of room to spare.
Taking this further, it is recommended that the application should have the capability to fully exploit "coarse-grained parallelism," meaning it should be possible to partition the application into independent tasks or processes that can be computed concurrently. For most solutions there should not be any need for communication between the tasks except at task boundaries, though Data Synapse allows some interprocess communications. The tasks and small blocks of data should be such that they can be processed effectively on a modern PC and report results that, when combined with other PC's results, produce coherent output. And the individual tasks should be small enough to produce a result on these systems within a few hours to a few days
Types of Distributed Computing Applications
The following scenarios are examples of types of application tasks that can be set up to take advantage of distributed computing.
• A query search against a huge database that can be split across lots of desktops, with the submitted query running concurrently against each fragment on each desktop.
• Complex modeling and simulation techniques that increase the accuracy of results by increasing the number of random trials would also be appropriate, as trials could be run concurrently on many desktops, and combined to achieve greater statistical significance (this is a common method used in various types of financial risk analysis).
• Exhaustive search techniques that require searching through a huge number of results to find solutions to a problem also make sense. Drug screening is a prime example.
• Complex financial modeling, weather forecasting, and geophysical exploration are on the radar screens of the vendors, as well as car crash and other complex simulations.
• Many of today's vendors are aiming squarely at the life sciences market, which has a sudden need for massive computing power. Pharmaceutical firms have repositories of millions of different molecules and compounds, some of which may have characteristics that make them appropriate for inhibiting newly found proteins. The process of matching all these ligands to their appropriate targets is an ideal task for distributed computing, and the quicker it's done, the quicker and greater the benefits will be.



Security and Standards Challenges
The major challenges come with increasing scale. As soon as you move outside of a corporate firewall, security and standardization challenges become quite significant. Most of today's vendors currently specialize in applications that stop at the corporate firewall, though Avaki, in particular, is staking out the global grid territory. Beyond spanning firewalls with a single platform, lies the challenge of spanning multiple firewalls and platforms, which means standards.
Most of the current platforms offer high level encryption such as Triple DES. The application packages that are sent to PCs are digitally signed, to make sure a rogue application does not infiltrate a system. Avaki comes with its own PKI (public key infrastructure). Identical application packages are typically sent to multiple PCs and the results of each are compared. Any set of results that differs from the rest becomes security suspect. Even with encryption, data can still be snooped when the process is running in the client's memory, so most platforms create application data chunks that are so small, that it is unlikely snooping them will provide useful information. Avaki claims that it integrates easily with different existing security infrastructures and can facilitate the communications among them, but this is obviously a challenge for global distributed computing.
Working out standards for communications among platforms is part of the typical chaos that occurs early in any relatively new technology. In the generalized peer-to-peer realm lies the Peer-to-Peer Working Group, started by Intel, which is looking to devise standards for communications among many different types of peer-to-peer platforms, including those that are used for edge services and collaboration.
The Global Grid Forum is a collection of about 200 companies looking to devise grid computing standards. Then you have vendor-specific efforts such as Sun's Open Source JXTA platform, which provides a collection of protocols and services that allows peers to advertise themselves to and communicate with each other securely. JXTA has a lot in common with JINI, but is not Java specific (thought the first version is Java based).
Intel recently released its own peer-to-peer middleware, the Intel Peer-to-Peer Accelerator Kit for Microsoft .Net, also designed for discovery, and based on the Microsoft.Net platform.
Conclusion
The advantages of this type of architecture for the right kinds of applications are impressive. The most obvious is the ability to provide access to supercomputer level processing power or better for a fraction of the cost of a typical supercomputer.
Scalability is also a great advantage of distributed computing. Though they provide massive processing power, super computers are typically not very scalable once they're installed. A distributed computing installation is infinitely scalable--simply add more systems to the environment. In a corporate distributed computing setting, systems might be added within or beyond the corporate firewall.
For today, however, the specific promise of distributed computing lies mostly in harnessing the system resources that lies within the firewall. It will take years before the systems on the Net will be sharing compute resources as effortlessly as they can share information.

paper-2

Abstract
We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure. Distributed computing became a field of intense study as the result of computer hardware miniaturization and advances in networking technologies. Distributed computing aims to unify multiple networked machines to let them share information or other resources, and encompasses multimedia systems, client-server systems, parallel computing, Web programming, mobile agents, and so on.
We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the small size of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible.
We conclude by discussing what is required of both systems-level and application-level programmers and the following topics
 What are distributed computer systems?
 Distributed Computer Systems – 1
 Distributed Computer Systems – 2
 Distributed Computer Systems – 3
 How It Works
 Distributed Computing Management Server
 Motivation for Distributed Computer Systems
 More complex distributed computing examples – 1
 More complex distributed computing examples – 2
 Distributed Computer System Metrics
 Distributed Computer System Architectures
 conclusion



Introduction to Distributed Systems
 What are distributed computer systems
 Architectures
 Transparency and design issues
 Distributed computing paradigms
 Distributed operating systems
 Parallel and concurrent programming concepts

What are distributed computer systems?
 Compare: Centralised Systems
 One system with non-autonomous parts
 System shared by users all the time
 All resources accessible
 Software runs in a single process
 (Often) single physical location
 Single point of control (manager)
 Single point of failure

Distributed Computer Systems - 1
 Multiple autonomous components
 Components shared by users
 Resources may not be accessible
 Software can run in concurrent processes on different processors
 (Often) multiple physical locations
 Multiple points of control
 Multiple points of failure
 No global time
 No shared memory





Distributed Computer Systems - 2

 Networked computers (close or loosely coupled) that provide a degree of operation transparency
 Distributed computer system =independent processor + net working infrastructure
 Communication between processes (on the same or different computer) using message passing technologies is the basis of distributed computing
 Virtual computing
Two issues
 How do computers communicate
 How do processes on different computers interact




Distributed Computer Systems - 3

 A distributed system is:
 A collection of independent computers that appears to its users as a single coherent system.

(Idea of a virtual computer)
 . . Autonomous computers
 . . Connected by a network
 . . Specifically designed to provide an integrated computing environment
How It Works
In most cases today, a distributed computing architecture consists of very lightweight software agents installed on a number of client systems, and one or more dedicated distributed computing management servers. There may also be requesting clients with software that allows them to submit jobs along with lists of their required resources.
An agent running on a processing client detects when the system is idle, notifies the management server that the system is available for processing, and usually requests an application package. The client then receives an application package from the server and runs the software when it has spare CPU cycles, and sends the results back to the server. The application may run as a screen saver, or simply in the background, without impacting normal use of the computer. If the user of the client system needs to run his own applications at any time, control is immediately returned, and processing of the distributed application package ends. This must be essentially instantaneous, as any delay in returning control will probably be unacceptable to the user.
Distributed Computing Management Server
The servers have several roles. They take distributed computing requests and divide their large processing tasks into smaller tasks that can run on individual desktop systems (though sometimes this is done by a requesting system). They send application packages and some client management software to the idle client machines that request them. They monitor the status of the jobs being run by the clients. After the client machines run those packages, they assemble the results sent back by the client and structure them for presentation, usually with the help of a database.
If the server doesn't hear from a processing client for a certain period of time, possibly because the user has disconnected his system and gone on a business trip, or simply because he's using his system heavily for long periods, it may send the same application package to another idle system. Alternatively, it may have already sent out the package to several systems at once, assuming that one or more sets of results will be returned quickly.
Motivation for Distributed Computer Systems
 High cost of powerful single processor – its cheaper (£/MIP) to buy many small machines and network them than buy a single large machine. Since 1980 computer performance has increased at 1.5 per year
 Share resources
 Distributed applications and mobility of users
 Efficient low cost networks
 Availability and Reliability – if one component fails the system will continue
 Scalability – easier to upgrade system by adding more machines, than replace the only system
 Computational speedup
 Service Provision -Need for resource and data sharing and remote services
 Need for communication



More complex distributed computing examples – 1
Computing dominated problems
(Distributed processing)
 Computational Fluid Dynamics (CFD) and Structural Dynamics (using Finite Element Method)
 Environmental and Biological Modeling – human genome project, pollution and disease control, traffic simulation, weather and climate modeling
 Economic and Financial modeling
 Graphics rendering for visualization
 Network Simulation – telecommunications, power grid



More complex distributed computing examples – 2

Storage dominated problems
(Distributed data)
 Data Mining
 Image Processing
 Seismic data analysis
 Insurance Analysis


Distributed Computer System Metrics
 Latency – network delay before any data is sent
 Bandwidth – maximum channel capacity (analogue communication Hz, digital communication bps)
 Granularity – relative size of units of processing required. Distributed systems operate best with coarse grain granularity because of the slow communication compared to processing speed in general
 Processor speed – MIPS, FLOPS
 Reliability – ability to continue operating correctly for a given time
 Fault tolerance – resilience to partial system failure
 Security – policy to deal with threats to the communication or processing of data in a system
 Administrative/management domains – issues concerning the ownership and access to distributed systems components







Distributed Computer System Architectures

 Flynn, 1966+1972 classification of computer systems in terms of instruction and data stream organizations
 Based on Von-Neumann model (separate processor and memory units
 4 machine organizations
 SISD - Single Instruction, Single Data
 SIMD - Single Instruction, Multiple Data
 MISD - Multiple Instruction, Single Data
 MIMD - Multiple Instruction, Multiple Data











Distributed Computers are essentially all MIMD machines
SM – shared memory, multiprocessor, e.g. SUN Sparc
DM – distributed memory, multicomputer, e.g. LAN Cluster







Distributed Computing Application Characteristics
Obviously not all applications are suitable for distributed computing. The closer an application gets to running in real time, the less appropriate it is. Even processing tasks that normally take an hour are two may not derive much benefit if the communications among distributed systems and the constantly changing availability of processing clients becomes a bottleneck. Instead you should think in terms of tasks that take hours, days, weeks, and months. Generally the most appropriate applications, according to Entropies, consist of "loosely coupled, non-sequential tasks in batch processes with a high compute-to-data ratio." The high compute to data ratio goes hand-in-hand with a high compute-to-communications ratio, as you don't want to bog down the network by sending large amounts of data to each client, though in some cases you can do so during off hours. Programs with large databases that can be easily parsed for distribution are very appropriate.
Clearly, any application with individual tasks that need access to huge data sets will be more appropriate for larger systems than individual PCs. If terabytes of data are involved, a supercomputer makes sense as communications can take place across the system's very high speed back plane without bogging down the network. Server and other dedicated system clusters will be more appropriate for other slightly less data intensive applications. For a distributed application using numerous PCs, the required data should fit very comfortably in the PC's memory, with lots of room to spare.
About Peer-to-Peer Features?
Though distributed computing has recently been subsumed by the peer-to-peer craze, the structure described above is not really one of peer-to-peer communication, as the clients don't necessarily talk to each other. Current vendors of distributed computing solutions include Entropia, Data Synapse, Sun, Parabon, Avaki, and United Devices. Sun's open source grid engine platform is more geared to larger systems, while the others are focusing on PCs, with Data Synapse somewhere in the middle, however, client PCs can work in parallel with other client PCs and share results with each other in 20ms long bursts. The advantage of Live Cluster’s architecture is that applications can be divided into tasks that have mutual dependencies and require interprocess communications, while those running on Entropia cannot. But while Entropia and other platforms can work very well across an Internet of modem connected PCs, Data Synapse’s Live Cluster makes more sense on a corporate network or among broadband users across the Net.





Conclusion
Distributed computing proves a very attractive cost effective method of computing. The current concepts of clustering must be expanded to include mainframes; MPP and other special propose hardware to provide best fit scheduling between jobs and hardware. Higher speed networking capabilities, global file systems, and improved security mechanisms will move distributed computing beyond the confines of local area networks into a single transparent global network.
A great challenge in this global network scheme is the effective management of resources. Without effective resource management, the cost effectiveness dwindles as the size of the distributed pool grows.
DQS attempts to provide a single coherent allocation and management tool for this environment, incorporating not only dedicated compute-servers, but also idled interactive workstations when possible. By providing support for single/multiple node interactive and batch jobs, using the best-fit concept, DQS increases the efficiency of the matching of available resources to user needs.

paper-1

INTRODUCTION:
For the past decade, "distributed computing" has been one of the biggest buzz phrases in the computer industry. At this point in the information age, we know how to build networks; we use thousands of engineering workstations and personal computers to do our work, instead of huge behemoths in glass-walled rooms. Surely we ought to be able to use our networks of smaller computers to work together on larger tasks. And we do--an act as simple as reading a web page requires the cooperation of two computers (a client and a server) plus other computers that make sure the data gets from one location to the other. However, simple browsing (i.e., a largely one-way data exchange) isn't what we usually mean when we talk about distributed computing. We usually mean something where there's more interaction between the systems involved.
You can think about distributed computing in terms of breaking down an application into individual computing agents that can be distributed on a network of computers, yet still work together to do cooperative tasks. The motivations for distributing an application this way are many. Here are a few of the more common ones:
• Computing things in parallel by breaking a problem into smaller pieces enables you to solve larger problems without resorting to larger computers. Instead, you can use smaller, cheaper, easier-to-find computers.
• Large data sets are typically difficult to relocate, or easier to control and administer located where they are, so users have to rely on remote data servers to provide needed information.
• Redundant processing agents on multiple networked computers can be used by systems that need fault tolerance. If a machine or agent process goes down, the job can still carry on.
There are many other motivations, and plenty of subtle variations on the ones listed here.
Assorted tools and standards for assembling distributed computing applications have been developed over the years. These started as low-level data transmission APIs and protocols, such as RPC and DCE, and have recently begun to evolve into object-based distribution schemes, such as CORBA, RMI, and OpenDoc. These programming tools essentially provide a protocol for transmitting structured data (and, in some cases, actual run able code) over a network connection. Java offers a language and an environment that encompass various levels of distributed computing development, from low-level network communication to distributed objects and agents, while also having built-in support for secure applications, multiple threads of control, and integration with other Internet-based protocols and services.
Would be better or worse if you chose a different set of tools in building something similar.


1.1. Anatomy of a Distributed Application
A distributed application is built upon several layers. At the lowest level, a network connects a group of host computers together so that they can talk to each other. Network protocols like TCP/IP let the computers send data to each other over the network by providing the ability to package and address data for delivery to another machine. Higher-level services can be defined on top of the network protocol, such as directory services and security protocols. Finally, the distributed application itself runs on top of these layers, using the mid-level services and network protocols as well as the computer operating systems to perform coordinated tasks across the network.
At the application level, a distributed application can be broken down into the following parts:
Processes
A typical computer operating system on a computer host can run several processes at once. A process is created by describing a sequence of steps in a programming language, compiling the program into an executable form, and running the executable in the operating system. While it's running, a process has access to the resources of the computer (such as CPU time and I/O devices) through the operating system. A process can be completely devoted to a particular application, or several applications can use a single process to perform tasks.
Threads
Every process has at least one thread of control. Some operating systems support the creation of multiple threads of control within a single process. Each thread in a process can run independently from the other threads, although there is usually some synchronization between them. One thread might monitor input from a socket connection, for example, while another might listen for user events (keystrokes, mouse movements, etc.) and provide feedback to the user through output devices (monitor, speakers, etc.). At some point, input from the input stream may require feedback from the user. At this point, the two threads will need to coordinate the transfer of input data to the user's attention.
Objects
Programs written in object-oriented languages are made up of cooperating
objects. One simple definition of an object is a group of related data, with
methods available for querying or altering the data (get Name(), set-Name()), or
for taking some action based on the data (send Name(Out-upstream()). A
process can be made up of one or more objects, and these objects can be accessed
by one or more threads within the process. And with the introduction of distributed
object technology like RMI and CORBA, an object can also be logically spread across multiple processes, on multiple computers.

Agents
For the sake of this book, we will use the term "agent" as a general way to refer to significant functional elements of a distributed application.While a process, a thread, and an object are pretty well-defined entities, an agent is a higher-level system component, defined around a particular function, or utility, or role in the overall system. A remote banking application, for example, might be broken down into a customer agent, a transaction agent and an information brokerage agent. Agents can be distributed across multiple processes, and can be made up of multiple objects and threads in these processes. Our customer agent might be made up of an object in a process running on a client desktop that's listening for data and updating the local display, along with an object in a process running on the bank server, issuing queries and sending the data back to the client. There are two objects running in distinct processes on separate machines, but together we can consider them to make up one customer agent, with client-side elements and server-side elements.
The term "agent" is overused in the technology community. In the more formal sense of the word, an agent is a computing entity that is a bit more intelligent and autonomous than an object. An agent is supposed to be capable of having goals that it needs to accomplish, such as retrieving information of a certain type from a large database or remote data sources. Some agents can monitor their progress towards achieving their goals at a higher level than just successful execution of methods, like an object. o a distributed application can be thought of as a coordinated group of agents working to accomplish some goal. Each of these agents can be distributed across multiple processes on remote hosts, and can consist of multiple objects or threads of control. Agents can also belong to more than one application at once. You may be developing an automated teller machine application, for example, which consists of an account database server, with customer request agents distributed across the network submitting requests.
1.1.1 Distributed Computing Applied to Computation
Distributed computing offers researchers the potential of solving complex problems using many dispersed machines. The result is faster computation at potentially lower costs when compared to the use of dedicated resources. The term Distributed Computation has been used to describe the use of distributed computing for the sake of raw computation rather than say, remote file sharing, storage or information retrieval.
This paper will tend to focus mainly on distributed computation, however, many of the concepts and tools apply to other distributed computing projects.
Distributed computation: a Community Approach to Problem Solving
Distributed Computation offers researchers an opportunity to distribute the task of solving complex problems onto hundreds and in many cases thousands of Internet connected machines. Although, the network is itself distributed, the research and end user participants form a loosely bound partnership. The resulting partnership is not unlike a team or community. People band together to create and connect the resources required for the achievement of a common goal. A fascinating aspect of this continues to be humanity’s willingness to transcend cultural barriers.
Distributed-computing to open source tools
Distributed Computing projects are successfully utilizing the idle processing power of millions of computers. Open Source tools can be used to harness the vast computing potential of Internet connected machines.

Cluster Computing
As machines became more powerful, researchers began exploring ways to connect collections (clusters) of smaller machines to build less expensive substitutes for the larger, more costly systems.
In 1994, NASA researchers, Thomas Sterling and Don Becker connected 16 computers to create a single cluster. They named their new cluster, Beowulf, and it quickly became a success. Sterling and Becker demonstrated using commodity-off-the-shelf (COTS) computers as a means of aggregating computing resources and effectively solving problems, which typically required larger and more dedicated systems.
DISTRIBUTED COMPUTING APPLIED TO DATA BASE.
Distributed data bases bring the advantages of distributed computing to the data base management domain. We can define a distributed database (DDB) multiple logically
Interrelated databases distributed over a computer network and a distributed data base management system (DDBMS) as software that manages a distributed data base while making the distribution transport to the use. A collection of files stored at different nodes
Of a network and the maintaining of interrelationship among them via hyperlinks has become a common organization on the INTERNET with files of web pages.
COMPARISON BETWEEN PARALLEL & DISTRIBUTED TECHNOLOGY

a>SHARED MEMORY ARCHITECTURE: Multiprocessor share secondary storage and also share primary memory.
b>SHARED DISK ARCHITECTURE :( loosely coupled)
Multiple processors share secondary storage but each has their own primary memory.
The above architecture enables processors to communicate without the overhead of exchanging messages over a network. The above point deals with parallel system architecture. Another approach is distributed data base approach. In this case each and every system do have their own memory and they communicate over a communication network.

ADVANTAGES OF DISTRIBUTED COMPUTING
Distributed computing has been proposed for various reasons ranging from organizational decentralization to economical processing to greater economy.
a>MANAGE OF DISTRIBUTED DATA WITH DIFFERENT LEVELS OF
TRANSPARENCY
By means of hiding the details of the locations where each file is physically stored within the system.
















Site-1
A n/w architecture with centralized data accessing















b>DISTRIBUTION OR NETWORK TRANSPARENCY
This refers to the freedom for the user from the operational details of the network. It
may be location transparency and naming transparency Location transparency refers to the fact that the command used to perform a task is independent of the location of the data and the location of the system where the command was used .Naming transparency
Implies that once a name is specified the named objects can be accessed unambiguously
Without any additional specification.
c>REPLICATION TRANSPARENCY
Copies of data can be stored at multiple sites for better availability, performance and reliability. Replication transparency makes the user unaware of existence of copies.



Name
Project
Age

Name
Project
Age

Name
Project
Age Name
Project
Age


d>INCREASED RELIABILITY AND AVAILABILIY
These are two of the most common potential advantages cited for distributed computing. Reliability is broadly defined as the probability that the system is running at a
Certain time point .When data is distributed over sites, and when one system fails other
can perform that job .This increases the reliability.
e>INCREASED PERFORMANCE
Since data is closer to every sites, data localization occurs, which reduces the contention of cpu and i/o services and simultaneously reduces access delays involved
In wide area networks. Local queries can be developed at each & every site so as to extract the required data which may improve the performance of the system.