It is fairly easy to integrate existing applications with Element Middleware in order to take advantage of its feature set. If the applications cannot be modified to explicitly integrate with the Element APIs, it is possible to wrap Element features around the application. 

For the most simple case of providing High Availability features, an unmodified application can be driven by an Element HA-aware proxy application that launches the application when the HA framework assigns it an Active HA role. The proxy then monitors the application for unexpected errors and can report those errors to the HA framework. At this point, the HA framework and the proxy can carry out a variety of error recovery mechanisms, including restarting the application in place, failing the application to another node, or even failing the whole node on which the failed application is running to another node. The Element-aware proxy can become more complex if the application has its own interface for high availability functions, management, or monitoring. The proxy can act as a functionality gateway, bridging Element services with the capabilities of the application, using the application’s interface. Application proxies can even be written in Python, using Element’s Python bindings, to provide a rapid development approach.

If the application can be modified, then more value can be derived from the Element services.  Most applications in a highly available environment are either daemons or at least have a reasonable life-span. These applications typically include an initialization sequence and one or more threads with one or more event loops. Adding Element support is as simple as making a few initialization calls for the desired Element services, and then adding a check for Element messages in the event loop. For blocking loops that use a socket select or poll, the Element socket descriptor can be added to the set of descriptors being checked. If there’s activity on the Element socket, then a simple call to ElemMsgReceive() and a subsequent call to ElemSigDispatch() takes care of everything, firing any necessary callbacks registered in the Element initialization calls or callbacks registered by the application to handle application-specific messages.  Adding High Availability, or AMF support, can be done using the standard AMF API calls, or even easier with the Element simplified AMF wrappers.  Additional services, like logging and the command service can be added for runtime system-level debugging.  The Element Name Service is a powerful tool for service discovery and supervision (i.e. let me know if this service goes away) as well as synchronization. It is as simple as publishing a tag (i.e. a name or string) to announce a service or subscribing for a tag to find a service. Embedded Management for configuration, monitoring, and notifications is also simple to use, and the associated modeling is not challenging.

The key is that applications can gradually integrate, making more use of Element services as needed. The Element APIs are very intuitive and support incremental integration. Lastly, utilities like the Element Signal Dispatch mechanism for handling events/messages and the Object API for payload construction and consumption simplify the use of asynchronous distributed solution development.