Homepage | About EASA | Contact
The EASA system is highly configurable to meet functional requirements specified by a User and implemented in an EASA application (an “EASAP”).
Consider which resources an EASAP requires. These might include:
To a large extent, the particular resource requirements above will define the EASA architecture.
Processing and performance requirements may place constraints on the capability and the number of machines recruited for an EASA system. These include:
The following four architecture examples cover the most common use cases.
The simplest EASA system combines several EASA computational roles within a single physical machine.
This configuration has the same capabilities of a distributed architecture. The default single EASA machine provides a simple, straightforward way to start off.
For example, after installing the 'off-the-shelf' system above, one may:
This architecture is not generally used in production as it will likely struggle under any significant User load. In particular, the Excel resource requirements (memory and CPU) will exceed the single machine's capacity above a modest number of simultaneous Users.
The diagram above illustrates three EASA computational roles in an EASA system:
One common configuration involves a backend database and a combined EASA/EASAP Server, below.
The EASA/EASAP Server hosts a user interface, creates database queries, and retrieves result sets.
In general, this system will scale well with increasing Users for two reasons:
A similar architecture involves specialized computation on a machine called a Compute Server.
This computation may require Matlab, a C program, a batch script, or other proprietary software.
This type of system may utilize a single-user license on the Compute Server and allow the EASA/EASAP Server to manage a queue of submissions. One User's EASAP may be granted temporary software license access to execute a task. When the task completes, the license will be released to the next User EASAP instance in the queue.
One of the most common and computationally intensive cases involves a 'live' Excel-linked EASAP that:
This case highlights EASA's impressive ability to scale: a single EASA Server will balance User load across multiple EASAP/Excel Servers.
The diagram below shows two EASAP/Excel Servers, though typically in practice there are many more.