Application Runtime Control service [ARC]


Using the Application Runtime Control service, a peer can remotely start, stop, get the status of, or restart (with a given set of input parameters) an application. When initializing the system, peers are deployed using web-based Grid-services as defined in the Globus toolkit, namely the Globus Resource Allocation Manager (GRAM) to select an available resource (based on availability of CPU, Memory or Bandwidth) on which to deploy a peer and the Grid Security Infrastructure (GSI) to delegate authentication and maintain integrity of the communication. Once a peer has been bound and deployed on an available Grid resource, an alternative implementation of this service supports binding each application control query to a system call that triggers the appropriate (start, restart, stop, status) command on the receiving peer; this approach is used at runtime by peers in response to a given rule, for example, restarting an application with a new set of input parameters when its return value exceeds a threshold value.

Application Monitoring and Steering service [AMS]

Dynamic and adaptive applications require robust event handling mechanisms and high-level application querying APIs in order to be self-modifying and autonomous. Human intervention on a simulation process is lessened because of this intelligence added by annex services such as a notification service controlling the flow of an application's result value (e.g. a stock market quote) and firing an event when the value exceeds a certain threshold. The application monitoring and steering service handles all communication from a peer to an application process. Typically, this communication is centered on a synchronous or asynchronous request/response mechanism. Implementing this service provides monitoring and steering capabilities to an application. This is achieved through simple calls such as sendAppRequest that takes as parameter a destination peer identifier, uniquely identifying the destination peer of this query. If no destination id is passed, the message is broadcast to the entire group: an application identifier, uniquely identifying the application to which this message is destined on the destination peer; a client identifier, defining the message source identifier; a query type representing the type of the message being sent; a string query defining the actual request; and finally, a handler (obtained from the application advertisement presented earlier) that uniquely identifies the network service that will process this given request.

Application Execution service [AEX]

While the AMS service provides mechanisms to request information from a uniquely identified application, the application execution service handles incoming requests for application-side processing. The AEX service handles incoming requests and parses queries by type before passing them to their registered listeners. The AEX service announces the existence of an application to the group, sends application responses (in response to queries, or by pushing information to a certain peer or a group of peers), publishes application update messages, (which may be any information relating to the application runtime besides a response to a specific query), or, finally, notifies the group of an application termination.

The collaboration service [Chat, Presence, Whiteboard]

Despite the adaptive and autonomous aspects of the application runtime, communication among users has to provide as many modalities as possible in order to foster new ideas and new simulations to deploy and test. Such "social" communication patterns share many similarities with the system's decentralized architecture, which behaves inherently in a collaborative manner (peers joining and leaving dynamically). Peers advertise their presence information to the group when changes to the group occur, for instance when a new peer joins or a peer's status is modified (from away to online), as opposed to a centralized server model. This information is propagated to the group through rendezvous peers and reaches all the peers which will update their status locally. The collaboration service defines collaborative tools such as Chat and Whiteboard for users' interactions with application data or textual information. Client peers register interest at the rendezvous peers they are connected to for filtering events by type (topics or patterns). Once a client publishes a collaborative message (being Chat, Whiteboard or Presence), it is multicast by the rendezvous to all client and rendezvous peers part of this client's peergroup.