System Architecture

Each distinct host running applications on the Blue Application Platform is known as a BlueAP host. Server hosts run server applications. Workstation hosts run client applications

A BlueAP System may also have communication links to processes on hosts that are not controlled by a BlueAP Kernel Manager; for example, a database server. These hosts are known as external hosts.

System Processe

Each BlueAP System requires a set of BlueAP Kernel processes to control and manage the system. These are shown in Figure 4 and described below.

BlueAP Kernel Manager

Every host in a BlueAP System has a BlueAP Kernel Manager process running on it; it manages all the BlueAP application processes running on that host.

On a server host the BlueAP Kernel Manager process is always running and is usually started when the host boots. All BlueAP application processes are child-processes of the BlueAP Kernel Manager, that is therefore responsible for starting and stopping the BlueAP applications (usually on commands from the BlueAP Kernel Supervisor process).

In addition, the BlueAP Kernel Manager process also monitors the BlueAP applications such that if any should fail, all their clients are informed of the fact, and that the BlueAP application is automatically re-started.

On workstation hosts the BlueAP Kernel Manager process is started by a user when they login. At this time the BlueAP Kernel Manager accesses a database for the required details of the user; These details determine which BlueAP applications the BlueAP Kernel Manager must start. In addition, these details provide customised settings for these particular applications; for example, how the user-interface windows are tessellated.

As in the case of server hosts the BlueAP Kernel Manager process on a workstation host creates all the BlueAP application as child processes and is therefore responsible for re-starting them should they fail for any reason.

BlueAP Kernel Supervisor

The BlueAP Kernel Supervisor is a process that runs on any host within a BlueAP environment. It is responsible for supervising the complete BlueAP System as defined in the BlueAP Configuration File.

This means that BlueAP servers are started and stopped on their allocated hosts at their specified times. This includes the ability to run servers 24/7, to have open and close times, or to run them periodically at set intervals.

The BlueAP Kernel Supervisor also monitors the running state of all BlueAP applications such that if a host in the network fails, any servers previously running on that host are automatically migrated to run on an alternative host. It is also responsible for informing the clients of these failed servers of the failure and subsequent re-starts.

In addition, all BlueAP applications may send informational, warning or error messages to the BlueAP Kernel Supervisor, that are subsequently logged.

In this way the BlueAP Kernel Supervisor passes information about the current state of the BlueAP System to the BlueAP Kernel Controller process so that the System Administrator and Operator can monitor the system and perform manual interventions if necessary.

BlueAP Kernel Controller

The BlueAP Kernel Controller is a process that runs on any host. It provides a graphical user-interface to the BlueAP Kernel Supervisor process and is used by the System Administrator/Operator to monitor the state of a BlueAP System.

It is also used to manually send commands to the BlueAP Kernel Supervisor as necessary, for example, to specifically stop or start BlueAP applications, to send commands to individual applications, or to send messages to users.

Application Processes

Applications can be divided into Server and Client applications. The distinction is usually applied in a three-tier client/server system where Client applications are those providing service to an individual user, and Server applications are those that are providing services to many clients.

In a multi-tiered system this distinction is often blurred as applications may have both of these characteristics. For example, a Client application could be designed to retrieve a certain type of information on behalf of several other Client applications.

In practice the distinction between Server and Client applications is important only for process management reasons.

Server applications are started automatically on server hosts and are permanently available, within the constraints of the BlueAP Configuration File. Client applications are only started when a user logs in and are available only as long as the user remains logged in.

Only Server applications are automatically migrated to another host in the event of a host failure.

Server applications only have a single instance in the BlueAP System, whereas Client applications are (or may be) replicated on each Client host, depending on the user’s requirements.

Gateways

BlueAP Systems are often required to communicate with legacy systems or with external service providers; for example, real-time data feeds. These systems are usually characterized by using proprietary codecs, protocols and transports.

The Blue Application Platform provides extensive facilities for quickly integrating new codecs, protocols and transports into the Blue Application Platform, via a standard API in the BlueAP Communications Libraries. Once built, this extension to the Blue Application Platform is known as a Coupler; it joins the internal protocols of BlueAP with those of the external service.

The design and implementation of the application that will communicate with the external service however is exactly the same as if the application were communicating with another BlueAP application. This means that the design and implementation of the BlueAP Gateway Server, and its corresponding Coupler can proceed independently of one another, and in parallel.

In practice the BlueAP System comes ready supplied with many codec, protocol and transport handlers (including gpb).

Databases

Database resources are an essential part of client/server systems. BlueAP, however, does not impose the use of any particular proprietary database, or even a particular database methodology.

Within a BlueAP System, databases appear to applications in a way that is identical to other applications. Applications communicate with databases as they do with server applications, and also receive notification of database failures and recoveries in exactly the same way as they do for servers.

This transparency enables applications to be developed in parallel; for example, a server could be implemented before the database it required was ready and simply retrieve and send its information to a file. Whether this source or destination for the data was a file or a database is transparent to the application and simply a matter of the configuration of the BlueAP System. The design and implementation of the server is therefore independent of the nature of its communicating partners. In time, for example, the configuration could be updated to indicate a database.

This kind of system functionality provides for scalability and extensibility.

For example, communications to a database could simply be replaced by communications to a server that acts as a transaction server when increasing demand on the database warrants it – this provides scalability. For example, when a change in the functional requirements, say increased security, warrants a migration from the use of files to the use of a database – this provides extensibility.