A top-to-bottom architectural view of Anima is illustrated in the following diagrams. The topmost view (Figure 1) presents Anima as a box interfacing Excel with a fully-distributed, OS-neutral framework for the concurrent execution of proprietary and third-party analytics. The results of those analytics are returned to Excel either directly, as in the case of centrally-deployed Excel functions, or indirectly via Anima's real-time A5Rt function, as in the case of analytic results dynamically published into the enterprise's data distribution bus. More traditional, batch-oriented data interfacing via SQL or remote Perl scripting are also supported as shown.

Figure 1.   Anima's Top-Level Architecture.

A closer look at the system (Figure 2) shows the process-level components and their main data flows. A critical component in the system is Anima's asynchronous Excel add-in, which is in charge of interfacing Excel with the rest of the Anima system. Outside Excel's world, in an OS-neutral environment, Anima's generic execution engines implement the necessary logic to dynamically integrate the external analytics libraries into Anima's distributed execution framework. Any number of engines can be concurrently deployed, with some engine instances in charge of interfacing with real-time market data services (subscribing and/or publishing) via the enterprise's data distribution bus. The same code base is used for all engine instances, and their actual role (analytics engine, and/or real-time receiver, and/or real-time publisher) is determined at run time via XML configuration files.

Figure 2.   Anima Process-Level Architecture.

Function and library definitions, Excel models and their XML representation, real-time contexts, SQL queries, calendars, etc, are all examples of XML static data elements defined by Anima. Supporting this static data backbone is the Data Definitions Server and its XML data store. A single, hot-standby backed-up instance of this server performs the distribution (reading) and safekeeping (writing) of all defined data elements. All other components of the system communicate with the server via a common client API. The API and the server implement a "connected-cache" protocol to keep server-maintained and API-maintained caches of requested data elements transparently synchronized at all times. The end result is a robust and dynamically extensible system with an extremely high overall performance.