The proficiency of the design of software over the past decades has seen a progression from the use of horizontal modularisation of programs, for example in stepwise-refinement, to the use of vertical modularisation, for example, in the use of threads.
Together with advances in the concepts of program (and data) encapsulation; usually in the form of an object-oriented programming approach, these ideas have contributed much to the ability of software designers to address complex problem solutions.
These methodologies are of course relevant to the design of BlueAP applications; however, the Blue Application Platform provides a tighter and stricter platform for building applications. Although these may seem to constrain the freedom of software designers, they do in fact, provide the control and discipline necessary for building high-performance distributed client/server systems with the necessary robustness and reliability.
The advantages of such control and discipline are many:
- a uniform and concise program structure for every application;
- a succinct and readable summary of every applications behaviour;
- a simple but complete method of tracing the flow of events between applications;
- the adaptability that enables applications to be quickly enhanced and scaled;
- the ability to separate the interaction of events (the design) from their actions (the programming).
Logical Processes
Logical Processes are an extension of the use of threads. In the BlueAP System they provide the functionality of building several (logical) processes within a single executable (process). Each logical process is designed and programmed as if it were a separate application.
There are three main advantages for using this functionality.
Firstly, during the development stage, logical processes can be incorporated into an application to represent other applications that are not yet ready. These can be built as emulators for the missing service. This provides for useful stand-alone testing of an application.
Secondly, during the testing phase, several applications can be combined (as logical processes) into a single executable. This provides for testing the inter-operability of applications without concern for the underlying behaviour of a network. In a BlueAP System these applications communicate with one another exactly as if they were spread over a distributed network of hosts.
Thirdly, by designing applications using logical processes, a future upgrade would be to physically separate them into individual applications and executables. This provides for application scalability, as the now separate applications can be distributed over several hosts.
Of course, the use of logical processes also provides the advantages usually associated with highly structured program design such as easier maintainability, and re-usability.
Events
Examples of events are the arrival of inter-process messages, the expiration of timers, and the arrival of query results from databases. All events are identically structured.
Events are characterized by an event identifier, some descriptive information (such as the senders name) and an accompanying data block.
Every BlueAP application essentially waits for events to arrive, queues them and processes them one at a time, one after the other. When the queue is empty the process waits. All events are processed in the order they are received.
States
Each BlueAP application has an overall process state and a communications state for each dialogue with a communicating partner; whether this is another application or a database.
Typically, applications begin in a ‘start-up’ process state, and attempt to connect with the other applications they require. Once this is achieved, they may enter a ‘loading’ state waiting for certain pre-requisite information (for example from a database). Once this stage has been completed the application may enter a ‘running’ state and begin to provide its normal service. An example of this is shown in Figure 5.
In some cases, an application may enter a ‘recovery’ state when it temporarily loses its connection with another application; for example, the other application was running on a host that failed and has been migrated to another host. Once the connection has been re-established (this is automatic) the application can enter its ‘running’ state once more.
Communications states are generally not as complex as process states, and for many applications are not required at all; for example, that the dialogue is either open or closed is sufficient. However, if a dialogue is designed with a complex request and reply protocol then the communication state can be used to manage it.
Actions
Actions are implemented as routines. These are normal C, C++ or Java functions, with a standard API. All action routines are identically structured.
All action routines return a status value that indicates the success or failure of the action, and whether or not the event causes a state transition in the Event/State Handler.
Action routines typically call other application functions and/or BlueAP library functions, in the same way as any normal C, C++ or Java function. The event is passed as a parameter to the action routine, so that the data may be accessed.
Event/State Handlers
BlueAP applications consist of a collection of actions that are activated by events received when in a particular state.
All BlueAP applications are based on the Event/State Handler model. The Event/State Handler (ESH) tables declare the links between events, states and actions.
An identical event may activate different actions, depending on the current state of the application. Or, the event may be ignored for some states and it may be processed for some other states.
For example, a server application may queue any incoming client dialogue request events when the server is not yet ready (the initialising state). When the initialization is finished, the server changes state (e.g. to a running state), processes all the queued events and from then on, processes any incoming client dialogue request events immediately.
Inter-Process Messaging
The BlueAP System provides reliable, asynchronous, cross-platform messaging.
Inter-process messages are delivered asynchronously; this minimises delays (as processes are not required to wait for a response) and also improves response times.
Message delivery is reliable because:
- messages are received once and only once.
- messages are received in the order they were sent.
- messages are always delivered if the receiver is running.
- messages are complete and uncorrupted.
- messages are translated automatically to the required format defined for the receiver. This is achieved by BlueAP using a platform independent protocol for communications between BlueAP applications, and providing the necessary codecs, protocols and transports for communications with Gateway applications.
- messages are only delivered to the designated receiver(s)
A BlueAP System is tuned for optimised network performance with minimal network usage overhead.
All messages are received as events by applications and are therefore seamlessly integrated into the event/state programming paradigm of BlueAP Systems.
Layered Architecture
The Blue Application Platform consists of many layers, providing consecutive levels of abstraction, as shown in Figure 6.
These are:
System Management: that provides an operating system abstraction layer that hides all platform-specific issues. All software above this level is independent of host and operating system and a single common source compiles and links on all platforms.
Communications Management; that comprises the internal layers for managing different codecs, transports and protocols.
Platform; that incorporates other basic functionalities, such as process control and timers.
Event/State Handler; that integrates the disparate objects of the lower layers into a standard and consistent platform.
Resource Management; that provides application development tools, such as memory management, data-structure management, diagnostic aids etc.
Application Platform; that provides high level tools for building particular types of applications. These include for example; Cache Servers (or Blotters), Transaction Servers, and Gateway Servers. Currently the Blue Application Platform also includes libraries to manage dialogues with many clients, to interpret queries and match them to cached data, translate messages, to build HTML Web Pages, and to send messages to external network monitor applications.
Memory Management
One of the many problems involved in the design and implementation of complex applications is the management of scarce resources. Often the most problematic of these is the management of memory; for example, the use of excess memory, the loss of memory through leakage, and the dangers of inadvertently writing over memory are just some of the dangers.
These kinds of dangers almost invariably lead to many problems during the development cycle, such as the time wasted in debugging, and in production, where hosts may fail if memory is not managed correctly.
For these reasons the Blue Application Platform provides extensive libraries for the careful management of memory so that these types of problems are generally avoided, and quickly located and corrected.
Data-Structure Management
High performance distributed systems always need the ability to organise their data quickly and efficiently.
In real-time systems it is sometimes necessary to queue arriving messages; for example, in order to dispatch them to a synchronous Gateway or legacy system.
In addition, it is very often necessary for server applications to cache information, so that it is readily available to clients. Typically, these client applications request information from the server that must search through the data they have cached in order to deliver what is required quickly to the client.
To satisfy these common demands the Blue Application Platform provides extensive libraries for managing common data structures, such as queues, b-trees and avl-trees.
Diagnostics
The Blue Application Platform provides many tools to aid the application developer.
All the Blue Application Platform Libraries have embedded trace statements that can print information to a log file. Every BlueAP application creates its own log file automatically, in a designated log directory, using its own name and the date and time to build the file name used.
These trace statements can be activated by setting a trace level. This trace level is used to determine how much information is sent to the log file. The following conventions are used:
- Trace Level Zero: no extraneous information is logged; only vital messages are sent to the log file.
- Trace Level One: All function entry and exit points are logged so that the execution flow of an application can be traced.
- Trace Level Two: All level one traces, plus all function entry and exit parameter values are logged, together with exit statuses.
- Trace Level Three: All level two traces plus the contents of all the applications major data-structures are logged.
Trace levels can be set for a complete application, for one or more particular modules of an application and for one or more Blue Application Platform Libraries. The trace levels can either be set from within the code (during development) or can be set in real-time from the BlueAP Kernel Controller process.
For example, setting the trace level for the Blue Application Platform Library that manages a particular protocol would result in the complete logging of all messages sent or received using this protocol.
The Blue Application Platform provides the tracing tools, and encourages the programming discipline, by which BlueAP applications are built with these embedded trace statements.
The BlueAP Systems Methodology also means that all action routines used to process the arrival of events all use the same prototypes; with identical parameters and return values. This, together with the formalism of the BlueAP Event/State Handler mechanism means that the behaviour of an application, and its interactions with communicating peer applications can easily and consistently be monitored and traced.
Because all events are managed in an identical fashion even errors returned from a database call can be managed, and if necessary logged, within a BlueAP application.
For errors that require the external intervention of System Managers or Operators, the Blue Application Platform provides the functionality of sending messages to the BlueAP Kernel Supervisor process, that are forwarded to the BlueAP Kernel Controller process for display.
Of course, all BlueAP applications integrate seamlessly into standard normal C, C++ and Java development frameworks.
Recovery
The Blue Application Platform is designed to provide system solutions of high availability, often systems that provide 24/7 services.
However, because systems will fail, BlueAP has many functionalities to:
- recover automatically from the failure of software and hardware
- to predispose the design of applications to be reliable
- to predispose the design of applications to incorporate fast and efficient recovery strategies
The BlueAP Kernel processes ensure that failed servers are re-started and that servers running on failed hosts are migrated to back-up hosts. Failed hosts are re-integrated into the BlueAP System when they become online, and they themselves become the back-up hosts in case of further failures.
All clients of failed servers are informed of the failure so that they can be designed to take appropriate action. They are also informed when the server re-enters service and are automatically re-connected to the server so that communications can resume. This occurs even if the server has been migrated to another host; this fact being transparent to the client.
BlueAP Servers are re-started automatically within a matter of seconds, and clients can quickly be re-connected.
Because all BlueAP applications are fully informed of failures of other applications (that they are communicating with) they can be designed to take the necessary action. This may be to inform users, or to implement a more complex recovery strategy.
For example, the requirements of some systems may demand that ‘hot standby’ servers are available that shadow the behaviour of servers and take over the provision of the services if and when the main server fails.
Usually however servers can re-start from scratch and quickly resume the service they provide. This is achieved by clients automatically re-connecting (and consequently re-sending their service requests), and by the server re-loading its information cache either from a database or some external gateway service.
The Blue Application Platform provides the utilities for designing recovery strategies that allow the effects of failures to be contained and limited, and such that the restoration of normal services is quick and efficient. In particular, for example, the methodology of a BlueAP solution avoids the saturation of a network during recovery. This can occur in systems without a coherent recovery strategy where applications are constantly repeating their requests for information, and thus downgrading the system performance even further, and perhaps even preventing the possibility of recovery without a complete system re-start.
Cerulean 