Technical Architecture of eLoadsheet

Attention: open in a new window. | Print |

eLoadsheet Architecture
eLoadsheet is a modular three tier application based on the Microsoft .NET framework. It is developed in Visual Studio 2005 Team Foundation development environment. The development of the application was done according to Microsoft Agile Framework for software development. Flyware uses Microsoft Team Foundation Server environment for controlling, storing, developing, testing and management of user requirements, project tasks, scenarios, quality and configuration management. eLoadsheet exposes interfaces to its core functionality which makes it possible for third party systems to utilize its business functionality. eLoadsheet uses an N-Tier architecture to achieve its Service Oriented architecture. eLoadsheet is using 3 tiers: Interface layer, Load control services layer and a Data access layer. eLoadsheet also as a forth layer which is the presentation layer which hosts the user interface.




















WCF Interface Layer

eLoadsheet uses the Windows Communication Foundation (WCF) standard to expose its interfaces. WCF simplifies development of connected applications through a new service-oriented programming model. WCF supports many styles of distributed application development by providing a layered architecture. At its base, the WCF channel architecture provides asynchronous, untyped message-passing primitives.

Load Control Services Layer

The Load Control Services Layer (LCS) is the middle tier in eLoadsheet. The LCS is the “brain” of eLoadsheet. It hosts the “business” rules and objects. All calculations are done within the LCS. The LCS exposes standard .Net interfaces consumed by the WCS Interface layer.The LCS is compiled to a .Net Assembly which is stored in a DLL file. The LCS is typically deployed to the same server as other service layers of eLoadsheet and runs in the same process space.The LCS calls functions in the Data Access Layer to gain access to the data stored in the database. The LCS is totally abstracted from the physical database platform used.

Data Access Layer

The Data Access Layer (DAL) is responsible for communicating with the Database. It hosts specific code to access a particular database. It  uses typed datasets and stores custom business classes. Furthermore it exposes the custom business objects through a rich interface to the Business Logic layer. The DAL uses role based security to assure that a calling application or component is properly authenticated and furthermore authorized to carry out the transaction.

Database
eLoadsheet supports Oracle 10g R2 and newer, which is a proven stable version of the Oracle database. eLoadsheet does not use any Oracle specific features and supports Oracle Enterprise Edition, Oracle Standard Edition and Oracle Standard Edition One.

Authentication and authorization and Security
User authentication and authorization is configurable. The system is able to authenticate against a Microsoft Active Directory domain and any user store which extends the Microsoft user/role provider framework. The system uses role based authorization to manage privileges in the system. eLoadsheet uses industry standards to defend against i.e. DOS attacks. Specific database layer with parameterized queries defend against SQL injection vulnerabilities. In general the security framework from Microsoft is used. WCF services can be made secure against Active Directory and SSL can be applied as well.

High availability capabilities of the system

eLoadsheet can be deployed to support various requirements in terms of high availability and resilience. Scaling is an intrical part of the design consideration. eLoadsheet was designed to be scaled out through a web farm, a load balanced middle tier, or any of the multiple native database options available.  Scaling up on to „larger“ hardware is off course an option as well.

The services framework, WCF Service Layer is based on Windows Communication Foundation Framework, a Microsoft standard of exposing interfaces. The interface implementation is split up into DCS Services, Aircraft Data Services, Load Control Services and UI Support Services. In a clustered scenario all these services are available in each of the servers so the entire functionality stack is available from every node in the cluster.

In addition to the segregation of the service layer, a Manager layer that interacts with the WCF Service Layer and the Data Access Layer is also split up into DCS Manager, Aircraft Data Manager and Load Control Manager. Therefore the inner working of the application and the way it operates is designed to segregate transactions based on functions.

Adding nodes to the cluster will increase the transactional capabilities of the solution to meet increasing levels of usage. Data in the database is available to all the nodes, and the same applies to information from other systems or data sources.

eLoadsheet supports Oracle Database Management System. The Oracle database has excellent features for high availability, scalability, data replication, failover scenarios, cluster solution and solutions for total site failure. All these different scenarios can be used to support specific requirements. In addition to that, eLoadsheet Enterprise Edition uses Global Unique Identifiers (GUID) to identify primary and foreign keys in database tables, which in short (and plain English) allows records in a database to be globally unique in any context which is particularly necessary in challenging data operations in distributed enterprise environments.

Load control audit trail
For a mission critical system like eLoadsheet it is necessary to log all user inputs and also all input by external systems. These logs are stored in the Load control audit trail. It is also necessary to log all changes made to the aircraft data in the AHM-560 database.eLoadsheet maintains and audit trail of all information that users enter into the system.  The Load control audit trail life time is configured by the system administrator. There is no design limit on the length of the time period for which the audit trail can be stored.

Aircraft Data audit trail

The Aircraft Data database contains critical weight and balance information. It is therefore imperative to keep an audit log of all changes made. When ever a change to any data is recorded, a Aircraft Data audit trail record is created. The Aircraft Data audit trail is stored in the database. It should be considered during deployment to store the audit trail log in a separate tablespace, due to the potential amount of data that needs to be stored. In addition to the Aircraft Data audit trail, eLoadsheet keeps full archived records of all versions of the Aircraft Data that have ever been marked as ACTIVE. This means that there is always a full copy of a Aircraft Data record for each aircraft type which has ever been made available to users for the purpose of creating a loadsheet.

System Log

The System Log contains information about the overall system health of eLoadsheet. A list of all errors and exceptions is maintained. The System Log can be configured to be stored in the Database, comma delimited file and/or at the Server Event log.

Data Management
The eLoadsheet database supports the industry standard AHM-560 standard in terms of managing and storing Aircraft Data. In addition to that the emerging AHM-565 standard, that has yet to be finalized, also factored into the database design.
Scalability and availability – Disaster Recovery and Fault Tolerance
eLoadsheet is an N-tiered application. Importantly, it is a stateless application and the various relations of the software loosely coupled modules are designed to optimize cohesion and strongly related to maximize cohesion – which makes the application more robust, more reliable and increases reusability.

Monitoring and maintenance
eLoadsheet contains a set of features that provide information on the health status of the application and certain database parameters. The information is gathered and maintained in a monitoring agent that connects to a monitoring system. Actions within the system above or below defined thresholds trigger notification of the situation – whether it is derived from failure or as a preemptive measure to take action against.

Offline Capabilities
eLoadsheet can be deployed in an offline-like scenario where the application uses a locally installed database. This scenario supports deployment on a laptop that is synchronized with a master database to keep all the Aircraft Data up to date. In essence, eLoadsheet Enterprise Edition can be run in an EFB configuration.