The Node controls a special kind of asynchronous messages, called "Events", using a dedicated controller called "Event Controller". This controller is completely integrated within Node's core and works fluently with the Agent controller and the Service controller. As usual, you application interacts with the Agent controller which is managing and controlling the between you and your local Node. On the other hand, the Service controller orchestrates all activities of the active services where events could be spawned. These principals remain the same when your App is working in local or shared mode - the Agents of all connected notes in the Grid are exchanging, routing and executing all tasks related to event management and notifications. The Event controller provides the following activities: •To register and unregister local event handlers; •To attach and detach remote event handlers; •To convey notifications to local and remote event handlers; •To Handle PUSH notification sent from remote nodes. |
The current version of AGE supports only native implementations of Erlang modules that work as Event handlers.
|
 1)Registration and Subscriptions The registration process declares that your Event handler as accessible, and most importantly defines unique event TAG for recognition of those event fired to your handler. To keep it simple - no tag, no events. The TAG is defined by the Invoker (your service or application) as a single Erlang's atom. To commence this process the following API is available: AGE offers you another powerful technology over the entire Grid - to register your event handlers onto remote Node. This is called Event Subscription. The event subscription requires you, firstly, to register your event handler locally as explained already, and then to attach this handler to remote Node, as a virtual event handler. Respectively, you can detach it from the same node. To commence event subscription the following API is available: 2)Invocation You are sending event from your service or application be invoking the API function age:notify/2. This function requires only two parameters - list with relevant event TAGs and data terms to be submitted... Yes, that's it! The concept behind this simplicity is to keep the event's notification completely transparent to the Invoker. The list with TAGs is used to find relevant handlers (local or virtual) to your particular search, and the data shall be submitted to these handlers only. 3)Routing All event notifications are validated by the local Agent before any invocations. The Agent is responsible to push the notification requests to all relevant handlers - local or remote. Consequently, all event data is duplicated and forwarded to the relevant handlers as: •UNATTENDED local notifications; •PUSH notifications to nodes on ground of remotely attached event handlers. 4)Handling Any data successfully submitted to Event handler is handled by the age_event behavior call-back function on_notify/3. By design, the Event controller spawns dedicated Erlang's process for each event in order to prevent performance and/or synchronization issues. |
Example of Event handler with simple file storage
