Enabling Peer-to-Peer Interactions for Scientific Applications on the Grid

Enabling Peer-to-Peer Interactions for Scientific Applications on the Grid? Vincent Matossian and Manish Parashar The Applied Software Systems Laboratory Department of Electrical and Computer Engineering Rutgers University, Piscataway NJ 08855, USA {vincentm,parashar}@caip.rutgers.edu

Abstract. P2P and Grid communities are actively working on deploying and standardizing infrastructure, protocols, and mechanisms, to support decentralized interactions across distributed resources. Such an infrastructure will enable new classes of applications based on continuous, seamless and secure interactions, where the application components, Grid services, resources and data interact as peers. This paper presents the design, implementation and evaluation of a peer-to-peer messaging framework that builds on the JXTA protocols to support the interaction and associated messaging semantics required by these applications.

1

Introduction

The Grid[3] is rapidly emerging as the dominant paradigm for wide area distributed computing. This new computing paradigm comes at a time when network models based on client/server architectures are facing constraining issues such as scalability, flexibility, and resilience to failure. The goal of the Grid is to provide an infrastructure that leverages standardized services and protocols to enable the coordinated sharing of geographically distributed hardware, software, and information resources across domains and user communities. This infrastructure will enable new applications that will symbiotically and opportunistically combine computations, experiments, observations, and real-time data to provide important insights into complex scientific problems. The emergence of these Grid applications coincides with that of Peer-to-Peer (P2P) applications such as SETI@HOME[14] or Napster[11]. This parallel is manifested in the similarities in infrastructural requirements of Grid and P2P systems, such as the underlying decentralized (overlay) network architecture, the dynamic discovery of resources, the aggregation of distributed resources, or the need for system integrity and security guarantees. As noted in [4], the issues addressed by Grid and P2P communities are complementary, and will mutually benefit from each other’s advances. Considerable efforts are currently invested in ?

Support for this work was provided by the NSF via grants numbers ACI 9984357 (CAREERS), EIA 0103674 (NGS) and EIA-0120934 (ITR), DOE ASCI/ASAP (Caltech) via grant numbers PC295251 and 1052856.

standardizing Grid protocols/services (e.g. the Open Grid Service Architecture [18]), and P2P protocols/services (e.g. Sun’s Project JXTA [12], Berkeley’s Open Infrastructure for Networking [1]), towards enabling seamless interactions across peer domains and virtual organizations on the Grid. The evolving Grid infrastructure, supporting peer-to-peer interactions and compositions, naturally complements the needs of the applications it will enable. These applications will be based on continuous, seamless and secure interactions, where the application components, Grid services, resources (systems, CPUs, instruments, storage) and data (archives, sensors) interact as peers. A key requirement for enabling these application-level interactions on the Grid is a P2P messaging layer that supports the interactions and their associated messaging semantics. The overall objective of this work is to prototype such a messaging framework to support Grid applications in a P2P environment. In this paper we present Pawn, a publisher/subscriber messaging substrate that offers interaction services for distributed object management, monitoring and steering, group formation, and collaboration through guaranteed, flexible, and stateful messaging. Pawn builds on Project JXTA[12], and extends it to provide advanced messaging semantics such as guaranteed message delivery, push, pull, transactions, and request/response interaction modalities, support for synchronous and asynchronous communications, coordination through message ordering, and remote procedure calls.These interaction services are interoperable and are accessible through a simple to use API. This paper makes three contributions: (1) the definition of messaging requirements for scientific investigation in a P2P Grid environment, (2) the identification and implementation of corresponding services and mechanisms in Pawn, (3) the deployment of the Pawn messaging substrate and its evaluation using a “real-world” Grid application. The rest of this paper is organized as follows. Section 2 presents the motivating application process and describes the underlying interactions. Section 3 presents related work. Section 4 gives an overview of Project JXTA. Section 5 presents the design and implementation of Pawn. Section 6 describes the use of Pawn to enable the interactions require in the motivating application described in section 2. Section 7 presents an experimental evaluation of Pawn.Section 8 concludes the paper.

2

Motivating Application: Enabling Autonomic Oil Reservoir Optimization

The research presented in this paper and the Pawn messaging substrate is motivated by the autonomic oil reservoir optimization process on the Grid. The goal of the process is to dynamically optimize the placement and configuration of oil wells to maximize revenue. The overall application scenario is illustrated in Figure 1. The peer components involved include: (1) Integrated Parallel Accurate Reservoir Simulator (IPARS)[20] providing sophisticated simulation components that encapsulate complex mathematical models of the physical in-

Fig. 1. Autonomous optimization in IPARS using VFSA

teraction in the subsurface, and execute on distributed computing systems on the Grid. (2) IPARS Factory responsible for configuring IPARS simulations, executing them on resources on the Grid and managing their execution. (3) Very Fast Simulated Annealing (VFSA) optimization service based on statistical physics and the analogy between the model parameters of an optimization problem and particles in an idealized physical system. (4) Economic Modeling Service that uses IPARS simulation outputs and current market parameters (oil prices, costs, etc.) to compute estimated revenues for a particular reservoir configuration. (5) DISCOVER Middleware that integrates Globus [5] Grid services (GSI, MDS, GRAM, and GASS), via the CorbaCoG [19], and DISCOVER remote monitoring, interactive steering, and collaboration services, and enables resource discovery, resource allocation, job scheduling, job interaction and user collaboration on the Grid. (6) DISCOVER Collaborative Portals providing experts (scientists, engineers) with collaborative access to other peers component. Using these portals, experts can discover and allocate resources, configure and launch peers, and monitor, interact with, and steer peer execution. The portals provide a shared workspace and encapsulate collaboration tools such as Chat and Whiteboard. These entities need to dynamically discover and interact with one another as peers to achieve the overall application objectives. The experts use the portals to interact with the DISCOVER middleware and the Globus Grid services to discover and allocate appropriate resource, and to deploy the IPARS Factory, VFSA and Economic model peers ((1)). The IPARS Factory discovers and interacts with the VFSA service peer to configure and initialize it ((2)). The

expert interacts with the IPARS Factory and VFSA to define application configuration parameters ((3)). The IPARS Factory then interacts with the DISCOVER middleware to discover and allocate resources and to configure and execute IPARS simulations ((4)). The IPARS simulations now interacts with the Economic model to determine current revenues, and discovers and interacts with the VFSA service when it needs optimization ((5)). VFSA provides IPARS Factory with optimized well information ((6)), which then launches new IPARS simulations ((7)). Experts at anytime can discover and collaboratively monitor and interactively steer IPARS simulations, configure the other services and drive the scientific discovery process ((8)). Once the optimal well parameters are determined, the IPARS Factory configures and deploys a production IPARS run.

3

Background and Related Work

A number of messaging solutions for P2P/Grid systems have been proposed in recent years. These systems define generic APIs and protocols for sending and receiving messages using publisher/subscriber or centralized models. Message Oriented Middleware (MOM) systems such as JMS [13], LeSubscribe [2], and IBM MQSeries[9] provide publisher/subscriber support for content-based routing and event notification across wide area networks. Content-based routing typically defines servers (also called access points) that are responsible for filtering and aggregating incoming messages before distributing them to all the subscribed peers. While these systems can be leveraged to enable interactions on the Grid, only few recent projects specifically address messaging for Grid applications. These include messaging systems such as GridRPC [16] and XEvents/XMessages[15], , or P2P messaging systems such as the NaradaBrokering [6] system. NaradaBrokering provides wide area event brokering targeting large scale collaborations in education and science. It is based on a publisher/subscriber model and defines a network of broker peers that can be dynamically deployed to provide efficient events distribution among groups of interested peers. The NaradaBrokering system was built on JMS and then integrated with JXTA. GridRPC [16] provides a remote procedure call API for applications on the Grid. It extends standard Remote Procedure Call[17] and combines it with asynchronous coarse-grained parallel tasking to address specific requirements of scientific computation in Grid environments. It is designed to hide the dynamicity, insecurity, and instability of the Grid from programmers. The XEvents/XMessages [15] framework is based on the publisher/subscriber model, and builds on SOAP to provide an event system on the Grid. The framework provides an API to publish and listen for events on the Grid. Communication is managed by middleware agents that dispatch messages in response to events. Outgoing messages are stored at the middleware before being sent to their final destination, allowing the framework to provide historical data and be resistent to failure. The ICENI Grid middleware[7] enables component-based application composition for

e-Science. It defines a middleware on which services and resources are exposed and accessed through policy and security managers. ICENI follows the Open Grid Services Architecture (OGSA) [18] to define the interfaces of services. It uses Java and Jini for communication between components and for enabling the dynamic composition and deployment of Grid applications at runtime. Pawn combines properties from messaging and P2P messaging on the Grid to provide publisher/subscriber functionalities (push, pull, request/response, transactions). Unlike other publisher/subscriber systems, Pawn focuses on interaction services to support application monitoring and steering, collaboration, and application execution on the Grid. It extends JXTA pipe and resolver services to provide guaranteed application-level message delivery. Messages contain state information, that allow the system to recover from failure.

4

An Overview of Project JXTA

Project JXTA[12] (from juxtapose) is a general-purpose-peer-to-peer framework introduced by SUN Microsystems in April 2001. The main drive behind JXTA is to provide developers with an open, platform and language agnostic framework for deploying interoperable peer-to-peer applications and services. JXTA defines concepts, protocols, and a network architecture. JXTA Concepts: JXTA concepts include peers, peergroups, advertisements, modules, pipes, rendezvous and security. A peer is any compute capable device on the network. A peergroup is a group of peers that share a common set of services. An advertisement is a language agnostic document (using XML) that describes a resource or functionality. A module is a piece of code (i.e. functionality) that can be initialized and started at runtime. A pipe is a virtual communication abstraction that provides input and output channels to a peer. A rendezvous peer acts as a relay as well as a distribution peer for messages and advertisements. Any peer can be a rendezvous peer, and a rendezvous can join or leave the network at any time. A peer may also act as a relay (implementing Network Address Translation) to enable peers behind firewalls to be part of a wide-area peergroup. Security in JXTA is provided by the routing and transport layers at every endpoint, where each message can be encrypted in order to guarantee integrity, authenticity and confidentiality. JXTA Protocols: JXTA defines protocols for : (1) discovering peers (Peer Discovery Protocol, PDP), (2) binding virtual end-to-end communication channels between peers (Pipe Binding Protocol, PBP), (3) resolving queries (Peer Resolver Protocol, PRP), (4) obtaining information on a particular peer, such as its available memory or CPU load (Peer Information Protocol, PIP) (5) propagating messages in a peergroup (Rendezvous protocol, RVP), (6) determining and routing from a source to a destination using available transmission protocols (Endpoint Routing Protocol, ERP). Protocols in JXTA define the format of the messages exchanged as well as the behavior adopted on receiving a message.

5

Design and Implementation of Pawn

A conceptual overview of the Pawn framework is presented in Figure 2 and is composed of peers (computing, storage, or user peers), network and interaction services, and mechanisms. These components are layered to represent the requirements stack enabling interactions in a Grid environment. The figure can be read from bottom to top as :“Peers compose messages handled by services through specific interaction modalities”. 5.1 Types of Peers in Pawn

Fig. 2. Pawn requirements stack.

In Pawn, peers can implement one or more services (behaviors); the combination of services implemented by a peer defines its role. Typical roles for a peer are client, application or rendezvous. A client peer deploys applications on resources and accesses them for interactive monitoring and/or steering. It also collaborates with other peers in the peergroup.An application peer exports its application interfaces and controls to the peergroup. These interfaces are used by other peers to interact with the application. The rendezvous peer is an extension of the JXTA rendezvous; it distributes and relays messages, and filters them en route to their destination. 5.2

Pawn Services

A network service is a functionality that can be implemented by a peer and made available to a peergroup. File-sharing or printing are typical examples of network services. In Pawn, network services are application-centric and provide the mechanisms to query, respond, subscribe, or publish information to a peergroup. Pawn offers four key services to enable dynamic collaborations and autonomic interactions in scientific computing environments. These services are: Application Runtime Control, Application Monitoring and Steering,Application Execution, and Group Communication. Application Execution service [AEX]: The Application Execution service enables a peer to remotely start, stop, get the status of, or restart an application. This service requires a mechanism to make synchronous and guaranteed remote calls for resource allocation and application deployment (transaction oriented interaction). Application Monitoring and Steering service [AMS]: The Application Monitoring and Steering service handles interactive(i.e. Request/Response) application querying (i.e. PULL) and dynamic setting (i.e. PUSH) of application

parameters. It requires support for synchronous and asynchronous communications and guaranteed message delivery and dynamic data injection (e.g. to push information to an application at runtime). Application Runtime Control service [ARC]: The application runtime control service announces the existence of an application to the peergroup, sends application responses, publishes application update messages, and notifies the peergroup of an application termination. This service requires a mechanism to push information to the peergroup and respond to queries (PUSH and Request/Response interaction). Collaboration Service [Group communication, Presence]: The collaboration service defines collaborative tools, group communication and presence. Collaborating peers need to establish direct end-to-end communications through synchronous/asynchronous channels (e.g. for file transfer or text communication), and be able to publish information to the peergroup (Transcation and PULL interactions). 5.3

Implementation of Pawn Services

Pawn builds on the current Java implementation of the JXTA protocols. JXTA defines unicast pipes that provide a communication channel between two endpoints, and propagate pipes that can propagate a message to a peergroup. It also define the Resolver Service that sends and receives messages in an asynchronous manner. Recipients of the message can be a specific peer or an entire peergroup. The pipe and resolver service use the available underlying transport protocol (TCP, HTTP, TLS). To realize the four services identified above, Pawn extends the pipe and resolver services to provide stateful and guaranteed messaging. This messaging is then used to enable the key application-level interactions such as synchronous/asynchronous communication, dynamic data injection, and remote procedure calls. Stateful Messages: In Pawn, every message contains a source and destination identifier, a message type, a message identifier, a payload, and a handler tag. The handler tag uniquely identifies the service that will process the message. State is maintained through the payload that contains system/application parameters. These messages are defined in XML to provide platform-independence. Message guarantees: Pawn implements application-level communication guarantees by combining stateful messages and a per-message acknowledgment table maintained at every peer. Guarantees are provided by using message queues (FIFO) to handle incoming and outgoing messages. Every outgoing message that expects a response is flagged in the table as awaiting acknowledgment, this flag is removed once the message is acknowledged. Messages contain a default timeout value representing an upper limit on the estimated response time. If an acknowledgement is not received and/or the timeout value expires, the message is resent, blocking or not blocking the current process depending on the communication type (synchronous or asynchronous). The message identifier is a composition of the destination and sender’s unique peer identifiers; it is incremented for ev-

ery transaction during a session (interval between a peer joining and leaving a peergroup) to provide the application-level message ordering guarantees. Synchronous/Asynchronous communication: Communication in JXTA can be synchronous when using blocking pipes, or asynchronous when using nonblocking pipes or the resolver service. In order to provide reliable messaging, Pawn combines these communication modalities with stateful messaging and guarantee mechanism.

Fig. 3. AMS to ARC interaction

Dynamic Data Injection: In Pawn, every peer advertisement contains a pipe advertisement, which uniquely identifies a communication channel to it. This pipe is used by other peers to create an end-to-end channel to send and receive messages dynamically (see figure3). Every interacting peer implements a message handler that listens for incoming messages on the peer’s input pipe channel; the message payload contains application-sensitive data that can be dynamically passed to the application/service identified by the handler tag field. Remote Method Calls (PawnRPC): The PawnRPC mechanism provides the low-level constructs for building applications interactions across distributed peers. Using PawnRPC, a peer can invoke a method on a remote peer dynamically by passing its request as an XML message through a pipe. The interfaces of the methods that can be remotely invoked are published as part of the peer advertisement during peer discovery. The XML message is a composition of the destination address, the remote method name, the arguments of the method, and the arguments associated types. Upon receiving an RPC message, a peer locally checks the credentials of the sender, and if the sender is authorized, the peer invokes the appropriate method and returns a response to the requesting peer. The process may be done in a synchronous or asynchronous manner. PawnRPC uses the messaging guarantees to assure delivery ordering, and stateful messages to tolerate failure.

6

Enabling autonomic reservoir optimization using Pawn

In this section we describe how the interaction services provided by Pawn are used to support the autonomic oil reservoir process outlined in Figure 1 (Section 2). Every interacting component described in Section 2 is a peer that implements Pawn services. The IPARS Factory, VFSA, and the DISCOVER middleware are

Application peers and implement ARC and AEX services. The DISCOVER portals are Client peers and implement AMS and Group communication services. Key operations in the process include peer deployment (IPARS Factory deploys IPARS), peer discovery (IPARS Factory discovers VFSA), peer initialization and configuration (Expert configures VFSA), autonomic optimization (IPARS and VFSA interactively optimize revenue), interactive monitoring and steering (Experts connect to, monitor and steer IPARS), and collaboration (Experts collaborate with one another). Peer Deployment: The Application Execution service in Pawn uses the CorbaCoG kit (and the Globus Grid services it provides) in conjunction with the DISCOVER middleware to provide client peers access to Grid resources and services, and to deploy application peers. The DISCOVER portal provides access to available machines (using Globus services via the CorbaCoG). Security (authentication, authorization and delegation) is handled by the Globus GSI (Grid Security Infrastructure) service. Application deployment uses the Globus Resource Allocation Manager service (GRAM). GRAM enables clients to obtain information about available resources (heartbeat, CPU, memory, load), and to deploy an application on a resource. For example, the expert (client peer) uses AEX to deploy the IPARS Factory peer and the VFSA optimization peer. Similarly, the the IPARS Factory uses AEX to deploy IPARS simulation instances. Peer and Peer Interfaces Discovery: When a peer starts, it uses the JXTA discovery service to publish an advertisement to the peergroup. This advertisement describes the functionalities and services of the peer. It contains a pipe advertisement and the Remote Procedure Call interfaces offered by the peer. The discovery process is used by the IPARS Factory and IPARS simulation peers to discover the VFSA optimization service. Peer Initialization and Configuration: Application peers use the Application Execution service (AEX) for initialization and configuration. For example, the IPARS Factory configures and initializes IPARS while deploying it. Client peers use the Application Monitoring and Steering Service (AMS) for initialization and configuration. For example, the client peer uses AMS to configure the initialization parameters for IPARS (e.g. bounding box size, number of iteration steps) and for VFSA (e.g. number of moves). Autonomic Optimization: Autonomic optimization involves interactions between the IPARS simulation, VFSA service and the IPARS Factory. VFSA provides the IPARS Factory with an initial guess based on the initialization parameters entered by the client. The IPARS factory then configures and spawns an IPARS instance. The simulation output is used by the Economic Model to generate the estimated revenue. This revenue is normalized and then fed back to VFSA, which generates a subsequent guess. The process continues until the terminating condition is reached (e.g. revenue stabilizes). These interactions build on the Application Runtime Control service (ARC) and the PawnRPC mechanism. Collaboration and Interactive Monitoring and Steering: Users can collaboratively connect to, monitor, and interactively steer the IPARS Factory, VFSA,

Economic model and an IPARS simulation instance using the Collaboration Services to communicate with other users, and the Application Monitoring and Steering service (AMS) to interact with the Application Runtime Control service (ARC) implemented by the application peer. An interaction between AMS and ARC is presented on Figure3.

7

Experimental evaluation of Pawn

Pawn was deployed on 20 hosts (Pentium IV processors at 1.5 GHz with 512 MB of RAM, running Linux RedHat 7.2) located at Rutgers University. The Wide Area measurements were performed using two PCs (a 750 MHz Pentium III with 256 MB RAM and a 350 MHz Pentium II with 256 MB RAM) deployed on a private ISP. The evaluation consisted of the following experiments:

Fig. 4. RTT measurement in a LAN

Fig. 5. Effectiveness of message queueing

Round Trip Time communication (RTT) over LAN: This experiment evaluates the round trip time of messages sent from a peer running the Application Monitoring and Steering service, to peers running the Application Runtime Control service over a LAN. The message size varies from 10 bytes to 1 Megabyte. The Pawn services (AMS and ARC) build the query and response messages that are then sent using the JXTA Endpoint Routing Protocol. The overall message transfer time is tightly bound to the performance of the JXTA platform, and is likely to improve with the next generation JXTA platform. The results are plotted in Fig.4. Note that the difference in RTT between 2 peers and 20 peers decreases as the message size increases. Effectiveness of message queuing: This experiment compares the behavior of a Pawn rendezvous peer implementing the application-level message queuing to the behavior of a core JXTA rendezvous peer. The number of messages published on the rendezvous peer range from 10 to 500. The ratio of messages received is plotted in Figure 5. It can be seen that the message queuing functionality guarantees that no application-level messages are dropped even under heavy load.

Fig. 6. Pawn and JXTA memory cost

Fig. 7. PawnRPC over JXTA pipes

Memory cost of JXTA and Pawn: In order to bootstrap a peer in Pawn, every peer has to load a core application implementing the JXTA and Pawn protocols. Figure 6 plots the memory used for loading the Java Virtual Machine, and the core JXTA protocols for every type of peer in Pawn. Pawn services add, on an average, an overhead of 20% to the JXTA core. Note that the client peer loads a Graphical User Interface in addition to the AMS and Collaboration services and is an exception. Overhead of PawnRPC on JXTA pipes: Figure 7 shows a comparison between PawnRPC and JXTA pipes. Using PawnRPC, a message describing the remote call is marshaled and sent to the remote peer. The remote peer unmarshals the request, processes it before marshaling and sending back a response to the requesting peer. The marshaling, unmarshaling, and invocation add an overhead on the plain pipe transaction. This overhead remains however less than 50% on average.

8

Summary and Conclusions

This paper presented the design, implementation, and evaluation of Pawn, a peer-to-peer messaging substrate that builds on project JXTA to support peerto-peer interactions for scientific applications on the Grid. Pawn provides a stateful and guaranteed messaging to enable key application-level interactions such as synchronous/asynchronous communication, dynamic data injection, and remote procedure calls. It exports these interaction modalities through services at every step of the scientific investigation process, from application deployment, to interactive monitoring and steering, and group collaboration. The use of Pawn to enable peer-to-peer interactions for an oil reservoir optimization application on the Grid were presented. Pawn is motivated by our conviction that the next generation of scientific and engineering Grid applications will be based on continuous, seamless and secure interactions, where the application components, Grid

services, resources (systems, CPUs, instruments, storage) and data (archives, sensors) interact as peers.

References 1. Berkeley Open Infrastructure for Network Computing. http://boinc.berkeley.edu, 2002 2. F. Fabret, H. A. Jacobsen, F. Llirbat, J. Pereira, K. A. Ross, and D. Shasha. “Filtering algorithms and implementation for very fast publish/subscribe systems”. In ACM SIGMOD 2001, Santa Barbara, CA, May 2001 3. I. Foster, C. Kesselman. “The Grid: Blueprint for a New Computing Infrastructure”, Morgan-Kaufman, 1999. 4. Ian Foster, Adriana Iamnitchi. “On Death, Taxes, and the Convergence of Peerto-Peer and Grid Computing”. To appear in IPTPS 2003, Berkeley, CA, February 2003 5. I. Foster and C. Kesselman. “Globus: A Toolkit Based Grid Architecture”. In I. Foster, and C. Kesselman eds. “The Grid: Blueprint for a New Computing Infrastructure”, Morgan Kaufmann, 1999, 259-278. 6. G. Fox and S. Pallickara, “The Narada Event Brokering System: Overview and Extensions”. International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA’02), 2002 7. N. Furmento, W. Lee, A. Mayer, S. Newhouse, and J. Darlington, “ICENI: An Open Grid Service Architecture Implemented with Jini”. SuperComputing 2002. 8. Global Grid Forum: http://www.gridforum.org 9. IBM MQSeries. http://www-3.ibm.com/ software/ts/mqseries/ 10. S. Kaur, V. Mann, V. Matossian, R. Muralidhar, M. Parashar; “Engineering a Distributed Computational Collaboratory”. 34th Hawaii Conference on System Sciences, January 2001. 11. http://www.napster.com 12. Project JXTA. http://www.jxta.org 13. R. Schulte. “Java Message Service: A Standard that works”. TechRepublic, August 22, 2001 14. http://setiathome.ssl.berkeley.edu 15. Aleksander Slominski, Yogesh Simmhan, Albert Louis Rossi, Matthew Farrellee, Dennis Gannon. “XEvents/XMessages: Application Events and Messaging Framework for Grid”, Technical report, Indiana University, September 2002 16. K. Seymour, H. Nakada, S. Matsuoka, J. Dongarra, C. Lee and H. Casanova, “GridRPC: A Remote Procedure Call API for Grid Computing”, Third International Workshop, Baltimore, MD, USA, November 18, 2002, LNCS 2536, p. 274 ff. Grid Computing- Grid 2002 17. R.Srinivasan, “RPC: Remote Procedure Call Protocol Specification Version 2”, Request for Commnets, August 1995 18. S. Tuecke, K. Czajkowski, I. Foster, J. rey, F. Steve, and G. Carl. “Grid Service Specification”, February 2002., 19. Snigdha Verma, Manish Parashar, Jarek Gawor and Gregor von Laszewski, “Design and Implementation of a CORBA Commodity Grid Kit”, In SC2001, Denver, CO, USA, November 10-16, 2001 20. J.A. Wheeler et al. “IPARS: Integrated Parallel Reservoir Simulator”, Center for Subsurface Modeling, University of Texas at Austin, http://www.ticam.utexas.edu/CSM.