Technical Overview

Flexibility of the underlying Aviarc Technology

The Aviarc developer does not think in terms of client-server or web-based programming, they think in terms of a simple functional single-user language and abstract concepts - the architecture is responsible for the running and management of this application. It is the role of the Aviarc Product team to work out the best way to deliver the application via the web; therefore the developer is not left trying to decide which is the best framework and technology to bring the application to life.

It is also unnecessary for the developer to worry about things such as:

  • Which parts run on the client and which parts run on the server (this can also change between releases without it impacting existing applications, due to the application itself being captured at a higher level in XML).
  • What is the best way to implement screen aspects such as widgets (in fact the widget framework has changed a number of times during the life of Aviarc, with no impact on the existing applications)
  • How application backward compatibility is maintained (the XML abstraction allows significant changes in the architecture to have no impact on existing applications).
  • How to allow real-time updates and bug fixes.
  • Ensuring applications are secure and cannot be exploited or hacked (when a new web vulnerability is discovered, the engine can be updated to prevent possible intrusions – this way all the Aviarc applications do not need to be updated themselves).
  • Methods that will simplify testing needs (so the testing focuses on "functionality testing" rather than "code accuracy testing".
  • What present versions of Websphere / Java / Web-services (etc) are supported. As clients upgrade to later versions, it is an engine issue, rather than a per-application issue – this greatly eases application lifecycle management and cost.
  • What new engine features will enhance the manageability or usability of Aviarc applications, for example; recently a “busy” timer was added for events that are likely to take longer than the user would expect – this is configured in the Administration application and available to all applications without any changes)