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 such as,
  • A Database
  • A Microsoft Excel spreadsheet
  • Batch computation run in a dedicated environment
  • Other third party software

To a large extent, the particular resource requirements above will define the EASA system architecture.

• Processing and performance requirements constrain the number and capability of machines required by EASA.
  • These requirements might include,
    • Number of simultaneous Users
    • Degree of complexity within an Excel spreadsheet
    • Availability of 3rd party software licenses
    • Intrinsic complexity of the EASAP

• The following four architecture examples cover the most common use cases,
  • Default EASAP
  • Database Backend EASAP
  • Specialized Compute Server EASAP
  • Excel Server EASAP

The simplest EASA system combines several EASA computational roles within a single physical machine.

This configuration has the same capabilities of a distributed architecture.

This default single EASA machine provides a simple, way to get going, see Get started with EASA Evaluation on Windows

• For example, after installing the 'off-the-shelf' system above, one may,
  • Run an example EASAP as a User
  • Author a new EASAP from the steps in a tutorial

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,
  • The EASA Server is a single machine and occupies a central role in every EASA system
    • On an EASA Server, a User, an Author or an Administrator perform their various duties
      • A User may select a published EASAP which is then dispatched to be run on an EASAP Server
      • An Author may select an EASAP in development, modify, save or test it via the EASAP Builder
      • An Administrator may manage the operation and administration of the entire EASA system
  • An EASAP Server hosts the Java application that serves the EASAP user interface to a browser
    • A User is allocated a unique instance of the EASAP for the duration of the task
  • An Excel Server hosts the spreadsheet and live Excel instance that is linked to each running EASAP
    • An EASAP/Excel Server pairs two server roles
    • As the number of Users grows, more EASAP/Excel Servers may be needed

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,
  • The database is a scalable product.
  • The EASA/EASAP Server has a lightweight role as a database client.

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,
  • May contain a large spreadsheet
  • May involve lengthy computational dependencies between cells
  • May need to be available for many simultaneous Users

• 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.

A very common use of Excel uses a spreadsheet to conduct an analysis of a business 'case' or 'case record'.

Historically an Author would use the Excel Range Wizard to automatically generate an EASAP with an Excel 'look and feel' and whose GUI elements were linked to an actual spreadsheet running on an Excel Server.

The Excel Desktop Client provides an alternative interface. This functionality involves very specific GUI objects to select a single business case and VBA support has been added to allow a business analysis of the case within an Excel Client.

An Excel Client is an Excel spreadsheet on the User's desktop machine initialized with existing case data from a database

An Excel Client has the built-in capability to write a case record back to the database via an EASA Ribbon→Save click.

An EASAP launches an Excel Client after a case is selected by a User with CASE VIEWER.

• With CASE VIEWER and Child FILTER's, an Author may present a User with an EASAP that,
  • Queries the database for cases that meet User-specified criteria
  • Lets a User select a single case
  • Delivers a database-linked Excel spreadsheet
    • → Initialized with that case's data
  • Lets a User modify the case within Excel
  • Lets a User save that case back to the database instance from within Excel

This novel architecture is outlined below,