Index Changes
ESB Console Home

Alerting Architecture

Use Cases

  1. Capture Alert Event Notifications from Composite Applications (both JBI and Repository-based), repository based components, modern EE components, the JBI runtime, JBI Component Containers, and JMS Servers
  2. Allow the client to enable/disable the persistence of events generated by the Composite application.
  3. Allow the client to define a policy that will remove alerts from the persistence to prevent persistence from degrading system performance. An Alert removal policy can define the alert max age, the alert level to discard and the total number of alerts allowed to be persisted.
  4. Allow the client to enable/disable the policy mentioned above
  5. Allow the client to register itself for events from one/or multiple domains with one or multiple servers
  6. Allow the subscribed client to de-register itself from receiving events
  7. Allow the client to subscribe to receive all the events reliably

Generating Alerts from Composite Applications

Java CAPS 6 has the ability to generate alerts from Composite Applications (both JBI and Repository-based), repository based components, modern EE components, the JBI runtime, JBI Component Containers, and JMS Servers.

Capturing Alerts from various sources

Generate alerts from Java EE Applications

The following screen-shot from the Java CAPS 6 NetBeans IDE shows a custom alert being generated from a Java EE composite application

Generating custom alerts from a Java EE Composite Application

Generate alerts from BPEL business process composite applications

The following screen-shot from the Java CAPS 6 NetBeans IDE shows a message being mapped to the alert message structure to generate alerts from a BPEL business process application.

Generating alerts from a BPEL Business process in Composite Applications

Accommodating Common Services Framework (CSF)

The Alert Schema today can handle alerts generated from from Composite Applications (both JBI and Repository-based), repository based components, modern EE components, the JBI runtime, JBI Component Containers, and JMS Servers. The alert schema can very easily be changed to accommodate the CSF schema. Also the API can be enhanced with one operation that takes in the payload and persist it into the database. The same infrastructure can be used to capture logs and errors.

Design Overview

The current design is based on the following technologies :
  • Database technology to allow persistence of alert events, managing their lifespan, and ensure delivery reliability
  • Web technology to enable delivery of alert events to the clients
  • A Common Management API to manage and control the configuration aspects of the system.

System Design

The system is made up of four modules (see the picture below):

  1. Alert Capturing Target Module - that captures alert notifications from Composite Applications (both JBI and Repository-based), repository based components, modern EE components, the JBI runtime, JBI Component Containers, and JMS Servers. Any server in the domain (standalone, cluster instance as well as the DAS itself) made up of an event forwarding component bean that is responsible for accepting event(s) from composite applications and components installed on the instance and storing them in the database if configured to do so. If persistence is not enabled, the events will be forward to the client via a notification channel.
  2. The DAS (Domain Administration Server) Module - which is made up of two main components:
    1. Event Management Web application which client applications will be connected to (via the client management API) that will deliver the events to the client application. The events are retrieved from an external database managed by the alert configuration service or delivered directly via the management channel. Only one delivery channel is active at any given time and controlled by the one of the alert configuration service API (EnablePersistence)
    2. An Alert Management Controller bean that clients can use to manage the persistence behavior of the system as well as an agent to the web application to deliver management channel events from the target modules in the domain (see next paragraph).
  3. The Client application - which could be java, JSR-223 based scripting (groovy, jruby, etc.) or a web based application that includes the alert client management API package. The alert management API contains methods to access the three services APIâ??s.
    1. Alert Administration Service - managing the events in the database allow deletion, marking events observational state and filtering of events.
    2. Alert Configuration Service - Manage the configuration of the database used to store the events generated by components and application.
    3. Alert Notification Service - Management client subscription for events

Configuration Management

  • Enabling persistence (see sequence diagram below).
Persistence in this design is under user control. Persistence is disabled by default on all the target instances. This operation applies to all the targets in the given domain. Persistence enablement also provides a Journaling option that will prevent deletion of the event after delivery (see AlertNotificationService API).
  • Alert removal policy (see sequence diagram below).
Persistence in this design provides the user with capability to control the event storage. The design guards against the database from growing uncontrollably in case events are not consumed and removed. The design provides the user with a programmable policy to manage its size. The policy has the following three elements under user control:
  1. Event Age - define the youngest of the events that will be subject to the removal.
  2. Event Severity - define the events severity level that will be the base from which events will be removed.
  3. Events Count - The maximum number of events allowed to be persisted in the database.
Any combination of the three elements makes up the policy to be enforced by the user enabled policy execution. The policy execution enablement is also under user control as well as the interval by which it will be executed. The precedence by which the policy elements are enforced is also defined by the user (via Alert Configuration Service API).

Event delivery and Management

Event delivery has two modes of operation depending on the persistence setting described above.

  1. Database persisted Alert Delivery
  2. Management Alert Delivery

1. Database persisted Alert Delivery

Persisted Alert Delivery has two modes of operation depending on the clients subscription to events. A reliable mode is assumed if at least one client subscribes for reliable delivery otherwise reliability guarantee is NOT enforced.
  1. Persisted Alert Delivery - without reliability guarantee
  2. Persisted Alert Delivery - reliable

1.1 Persisted Alert Delivery - without reliability guarantee

The persisted Alert with No Reliability Guarantee mode means that the event is delivered to all the currently subscribed clients if it meets each client filtering criteria . After the event is delivered to the last client it is removed from persistence (the event is deleted from the database table).

1.2 Persisted Alert Delivery - reliable

The persisted Alert in reliable Delivery mode assumes that there is One and only one client that subscribes for reliable alert delivery. In this mode the alert is not removed from the database until the reliable client acknowledges receiving and processing the message. The acknowledgment is sent back to the controller in the form of management message where the database table id is the parameter to indicate which alert should be deleted. As mentioned earlier the deletion will not take place in case the persistence was enabled with journaling. In the case where the journaling option is enabled, the user will need to use the alert removal policy to clean overgrown database tables.

2. Management Alert Delivery

If the persistence is disabled all the events are forwarded from the domain instances via the management notification channel. This channel has no reliability guarantee. In this mode domain instances channel their events via the controller management bean on the DAS. The controller on the DAS periodically queries the system for new instances that came on line or restarted instances. It then registers a listener for each one of them. The forwarder management bean on each of the instances get forwarding requests from JBI components or composite application (via the alerter module) and send them as management notifications to the controller management bean on the DAS. The DAS checks to see if the web app is running by checking the registration of the channel support management bean. If it does not exist, the event is dropped, otherwise the event is forward to the channel support. If the client is registered for notification prior to the event reaching the channel support management bean and the registration filtering passed the event is forwarded to the client via HTTP socket that was open during the client subscription (registration).

Also see

Alert Configuration Service Details

Alert Notification Service Details

Refactoring the Alerting Service

General Information about Alerting

How do I use the Alert Reception API

How do I use the Alert Sender API

How do I use the Alert Framework Configuration Service API

How do I use the Alert Management API




Number of visits: 51

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-6) was last changed on 11-Nov-09 11:11 AM, -0800 by Gopalan Suresh Raj