Technical Architecture
The FlitePlan architecture separates an application into distinct layers, each having a specific purpose, which are typically the responsibility of different people. It uses a model-view-controller (MVC) framework to manage the relationships between the data on the server (the model), its presentation in a web browser (the view), and the buttons and other widgets by which the application is used (the controller). A finite state machine (FSM) governs the behaviour of each business object and controls the visibility and availability of widgets according to the current state of the object. The FSM has guards to enforce integrity and business rules when moving between states. The model is partially replicated on the client as a proxy created in response to requests sent to the server, typically triggered by controller events. Careful design ensures that the partial model is compact and relevant to the task at hand so as to minimise network traffic of these requests and responses. Client devices deliver fast graphics and rapid response to the user when there is no interaction with a remote server, but can be slowed significantly by network and database delays when such interaction is required. An elegant solution to this problem is for the client to interact with the server asynchronously. This means that the client does not wait for a response to its request, but continues with other work, and handles the response from the server if and when it is received. Although simple in concept, asynchronous programming introduces complexity that is difficult for the average application programmer to control. FlitePlan hides this complexity entirely within its MVC framework. Business applications are further simplified by the FSM which eliminates most of the conditional if..then..else branching found in procedural code. The integrated RBAC furthermore removes the need for security concerns in application programming. This is broadly illustrated by the following diagram:
Presentation Layer
FlitePlan applications execute in standard web browsers without plug-ins or any other software on the client device. This eliminates the logistical, management, licensing, version control and other technical problems associated with traditional client-server software. A new version of a FlitePlan application is downloaded automatically if and when the web browser detects that it has changed, otherwise the browser continues to use the previously loaded version. Applications can take advantage of the formatting abilities of the browser, including cascading style sheets (CSS), to gain maximum visual impact. An application is formatted simply by modifying its css file with the desired page markup. This work is typically the domain of creative marketing people and may be delegated accordingly with no risk to the functionality, integrity and security of the application.
An application can also be displayed in any language, including those with non-Roman alphabets, by simply translating the text in a properties file to the target language(s). The correct language version is displayed according to the locale setting in the user’s browser. Date and number formats are also locale sensitive. Perhaps most importantly, what the user can see and do is controlled by the current state of the business object, and by the roles he or she has been allocated by the system administrator. Users see only the forms and fields that are required for them to do their work, and may execute only tasks for which they have permission. Finally, FlitePlan makes extensive use of lazy loading to ensure that only objects that are actually required are loaded.
This advanced framework relieves the application programmer of many difficult technical tasks, allowing the focus to be on the application logic itself. FlitePlan applications are assembled from a set of high-level components, which encapsulate access control, state management, service request and other functions behind simple programmer interfaces. Typically a single line of code is all that is required to add a new widget to a form. The many business objects supplied (including source code) are sufficient to illustrate how to develop advanced applications in FlitePlan. Unlike tools that rely on code generation, component based applications may easily be adapted to suit particular needs by persons with minimal web programming experience. Someone with a good understanding of the business domain and process requirements can typically develop and adapt client applications.
The finite state machine – which does not rely on code generation - radically simplifies code in any non-trivial application. A state transition is defined by a line of declarative code to specify its event, action, guard and states – and is easily derived directly from a state diagram. This both simplifies code and encourages software engineering discipline. User interface components may be controlled by the FSM to change their appearance and function according to the current process or entity state. In addition, declarative role based access control enforces the user’s read, write and execute permissions at form, field, command and code levels. Finally, business objects requiring work are automatically routed to users with the appropriate role. Custom workflow rules may be added to the application if required.
Service Layer
The server architecture required to support FlitePlan is also radically less complex than that required for traditional client-server and web applications, which typically need session state to be maintained on the server to 'remember' what the user is seeing and doing between requests. Web applications using Active Server Page (ASP), JavaServer Page (JSP) or JavaServer Face (JSF) technologies reconstruct entire HTML pages on the server and send them to refresh the browser every time a change is made. Asynchronous JavaScript and XML (AJAX) techniques help to improve the user experience but are difficult to program and generally have nowhere near the interactive quality of desktop applications. FlitePlan emulates the desktop experience by delegating all user interface processing to the client browser and obtaining and updating data as required from the server via stateless services.
Stateless services know nothing about their clients but merely respond to requests by doing one or more tasks and (optionally) returning data to the client. For example, a request for data might return information while a request to save a record or create a report might not. Because they do not maintain session state for each client, stateless services scale to serve very large numbers of concurrent users without significant increase in response times. Furthermore, a service can perform a series of operations, including computationally intensive tasks, in response to a single request. A pricing service, for example, might have to obtain inventory availability, currency exchange rates, shipping costs and other data to determine and return a simple number - the price - to the client.
Services are typically used by different applications and are designed accordingly. Standard information is obtained and maintained via services that directly support business objects – account, asset, finance, product, party, sale, purchase, receipt, payment, price – are examples common to most organizations. Specialised business domains such as retail trade, distribution, manufacturing, maintenance, project management, travel and accommodation, scheduling, shipping et cetera typically require customized services. Standard UN/CEFACT, ISO and SI services provide country, currency, language, location, taxation and unit data needed for international trade. System administration is facilitated by authentication, organization, role, user and session services. The computing infrastructure is exposed via reporting, email, messaging and other technical services, and so on.
FlitePlan services are typically implemented by plain old Java objects (POJO) without any need for heavyweight enterprise frameworks. Complex objects can be assembled from multiple and distributed data sources such as relational databases and web services. Standard functions enable CRUD operations on entities and relationships in the database with minimal Java and without any structured query language (SQL) code. Simple high-level methods post values to the data warehouse and ensure that transactions having financial significance are correctly balanced. Very sophisticated accounting needs can be satisfied using such methods. These features also allow attribute, relationship and transaction types to be added and deleted without change to the database schema. Finally, advanced transaction management ensures the integrity of service requests under fault conditions.
Services are best developed by experienced software engineers. While simple changes can be made by relatively inexperienced programmers, the key challenge is to analyse and design the most suitable services and their operations. This requires an understanding of how a service might be used, often without a clear specification. Standard FlitePlan services are guidelines for new and adapted services, but other approaches may suit the needs and constraints of particular environments. For example, services can be written in C# for the .NET framework should this be preferred. Such decisions should be made by senior people who know both the business objectives and technology constraints of the organization.
Data Layer
The data layer accesses database and web services and maps their data into formats suitable for the service layer described above. Any modern relational database including MySQL, DB2, Derby, PostgresSQL, SAP, Oracle, SQL Server, Sybase and Informix may be used for object persistence and data warehousing. A configuration file defines network location, login parameters, the dialect of SQL, and other database idiosyncrasies. The file uses an extensible mark-up language (XML) dialect to map database tables and columns to object classes and fields. Object and table data types, formats and default values are defined by simple XML declarations, and CRUD and other operations by parameterised SQL statements. Queries may also be formulated in the service layer and passed as parameters to the data layer, although this approach is discouraged for all but the most complex functions.
The standard data schema is normalised to eliminate redundant data and carefully indexed to accelerate performance, and the data warehouse is further enhanced for fast response even with very large datasets. However, many organizations have existing applications and databases, which cannot be abandoned overnight in favour of a new system. This legacy data can be used by FlitePlan applications with appropriate XML configuration files and services. For example, a service may draw information from several existing databases and tables, possibly residing on different computers in different locations. No changes are required to any of the applications using the service because its interface (ie: the operations that it supports) does not change. Similarly, migration of data between databases requires only minor changes to the configuration files, thus allowing cost effective, high performance, options to be used.
This flexibility also enables organizations to benefit from cloud computing resources provided by Amazon.com, Google, IBM and other major corporations. Because customers do not own the infrastructure - they are merely accessing or renting - they forego capital expenditure and consume network, computer and database resources as a service, paying instead for what they use. Many cloud computing offerings have adopted the utility computing model which is analogous to how traditional utilities like electricity are consumed, while others are billed on a subscription basis. By sharing computing power between multiple tenants, utilization rates can be improved (as servers are not left idle) which can reduce costs significantly while increasing the speed of applications. A side effect of this approach is that computer capacity rises dramatically as customers do not have to engineer for peak loads. Adoption has been made even more attractive by increased network bandwidth, which enables excellent response times from centralized infrastructure at remote sites [Wikipedia].
The data layer is the foundation on which services are built so requires people with in-depth knowledge of information technology. Object-relational mapping (ORM) requires some skill in SQL programming and optimisation, use of web services is often non-trivial, and providing reliable internet access and capacity can be challenging in some situations. While many of the issues can be delegated to a cloud computing service provider, technical skills should be available in-house or through consultants to develop, extend, port and tune the data layer. This expertise can also evaluate the best browser, operating system, network, database and reporting options, as FlitePlan does not prescribe any particular mix of platform technology.