All connected nodes within the Advanced Grid Environment (The Grid) are interacting using a proprietary messaging protocol. Your application or service could communicated with other services published in the Grid. These activities are handled by the Agent controllers of each node. The common design principle of the communication between your App and the Node is to send asynchronous requests to the Node's Agent in order to commence particular Grid tasks. The Agent is generating and returning to your App a temporary request identifier (RID), and your program could receive responses by this RID for some period of time (timeout). Beyond the operational timeout the responses are losing their vitality and cannot be handled. The requests can be addressed to particular node from the Grid, to list of nodes, or to be broadcast to the entire Grid. Additionally you can manage the communication mode of the local Agent for signaling your tasks to the Grid and other properties explaine d in details for API function request/3. There are also special kind of requests for triggering and handling events within the Grid. Detailed explanation is provided on page "Notifications". |
The Node's Agent can handle the task categories: •To start and stop local and remote grid services. •To search for most relevant services within the Grid to your particular needs. •To find the best published functions required by your App. •To commence one or simultaneous executions of local and/or remote procedure calls. •To gather live information about the topology of your Grid. •To commence some maintenance activities. Detailed technical specification is provided for API function request/3. As explained above, you can address your requests for variety of tasks to the Grid with different modes and communication properties. Consequently, your application can execute multiple tasks on local and remote machines (nodes). |
As a result of task request with particular RID, the Agent is forwarding the requested activity and the data associated to this activity to the Node's Service controller. There, the tasks are classified and executed - all system and maintenance tasks are handled by the Node's core, all function-oriented tasks are handled by the corresponding services published in the Grid. The overall error handling is managed by the Service controller. The result of task execution is returned back to the Agent where it is collected, summarized and returned to the invoker as structured response with type #age_response{}. However, the invoker is not always your App - you're operating in a grid environment, remember? The responses, prepared by the current Agent, are returned to the previous invoker (the previous Agent) until the response is reached the original requester - your App or service. This process could be quite complex because the Agents simultaneously are collecting and forwarding responses. This is typical when the Agent is operating as concentrator in the Grid. Ultimately, all collected responses with their data are returned back to your application. You should take into considerations that AGE cannot guarantee that all responses shall be delivered to your application within the requested timeout. Of course, you can control this timeout from your App when you are constructing a request but you should consider the probability to receive responses less then expected, or event to receive zero responses. |
The Node's Agent calculates lots of operational and statistical data gathered from the Grid in order to decide how to route your requests. These decisions are not linear because the utilization and the topology of the Grid could be quite dynamic. For example, let's take a closer look to the diagram above: ✓Let's consider that your App requests Grid's service "age_db_service" to execute the published function "select/6". ✓The Agent of your local Node 24502152 could try to forward the request to remote nodes 95945490 and 14968180. As shown on the diagram, the request could be processed or limited in different ways. ✓The routing policy depends on the Grid's utilization (calculated automatically by the Agent) and the communication properties of your requests - mode, addressing and others (see the request options of function request/3). The following routing modes are supported by the Agent: i.local - To execute your request without forwarding it to the Grid; ii.share - To execute your request in local mode and by forwarding it to the entire Grid. This is the default bahavior; iii.share_once - To execute your request in the local node and by forwarding it to the local Node's neighbors. You can use this option to create local clusters of nodes; iv.adaptive - In this mode your request shall be executed in the entire grid with "Adaptive Polymorphism" turned on, which allows the Agent to decide automatically the best route and set of services capable to handle the request and to execute it within the expected timeout. This mode is still experimental. |
