Application Architecture

The application prototype was engineered in accordance with a set of fundamental design decisions which guided the development process. This section commences with a discussion of these decisions before proceeding with an in-depth analysis of application functionality itself.

It was decided that each instance of the application should represent a single user or field worker. Therefore, the one application provides a common interface through which that user interacts and communicates with other users. For convenience it is implied that each engineer (application instance) is run on a dedicated portable computer which can be customised to suit the user’s individual job structure and personal preferences. Each engineer’s portable computer is able to make (intermittent) use of a range of networking technologies including, wide-area connection-oriented technologies such as a PMR or cellular telephone.

The application has been designed to avoid reliance on central services for assisting in the management of group or application state. The nature of the communications infrastructure and the mobility of the field engineers means that intermittent connectivity between the hosts is inevitable. Providing the application as a distributed set of components, one per host, decentralises the conference state to maximise fault tolerance. Furthermore, reliability is increased by using distributed algorithms to maintain inter-application interactions avoiding a central point of failure (a central point might be unavailable over such a network, despite other hosts remaining available). Note however, that in some PMR systems software can be run on base stations providing a convenient point for establishing group state. The

adoption of such an approach would impair the portability of the application to other technologies.

The application is required to perform the following functions for the engineer :- • Allow the retrieval and display of maps and schematics relating to the power

network.

• Establish and maintain multimedia conferences between field engineers (communication of voice plus data).

• Enable engineers to prepare information both off-line (stand-alone mode) or interactively through collaborative discussion within the conference.

• Provide auxiliary tools which allow fewer synchronous interactions, such as E- mail, queries to remote databases, and automated job dispatching and report completion.

• Supply tools for accessing and interacting with remote legacy systems such as project records, work instruction management and plant records and maintenance.

The requirement to support such a diverse range of functions, together with easily predicted impediments of the target platform, such as small physical screen size and the difficulty of using a keyboard in the field, led to the design of the prototype as a “tool-box” of component modules. In particular, the user can activate any subset of the available application modules to tailor their application to the task in hand. The architecture is extensible, allowing new modules and functionality to be added trivially (significant as the MOST project requirements analysis process ran for the duration of the project).

Each component module has an independent graphical interface which may be individually rearranged, iconised and sized to enable the current working set of modules to best fit the limited display size. A virtual window manager is used on each portable to enable a larger effective display area. The interfaces themselves make extensive use of colour icons to reduce the physical size of the interface without an attendant loss of information.

At the time the prototype was written there had been no work exploring collaborative interface design for mobile environments. The interface was developed by extrapolating from experience gained in fixed environments into a mobile context [Greenberg,91]. Recently, researchers have begun to address the particular problems posed by the communications delays inherent in mobile environments [Dix,95] but, as yet, no firm results have emerged.

The factoring of the application into separate interface components on the surface is mirrored underneath in the application itself. The application is built on top of a distributed object oriented architecture provided by a distributed systems platform (with semantics similar to those provided by ANSAware [APM,89]). The actual platform used and its relationship to ANSAware is discussed in detail in chapter 6. Briefly however, the architecture provides a uniform computational model consisting of objects which provide services through well defined interfaces (see section 6.2.3). Such an architecture greatly simplifies the challenges of writing applications for distributed environments by providing distribution transparencies (such as those highlighted in chapter 1) which enable services to be located and accessed regardless of physical location. In addition, the architecture provides a uniform set of system services and mechanisms for intercommunication which permit interoperability of applications within heterogeneous networks and end-systems (satisfying the requirement highlighted in chapter 4).

The application tools are implemented as a set of RM-ODP compatible objects which offer specific services via interfaces. All intercommunication is provided by the platform through an RPC or invocation mechanism. Each instance of the application accesses the modules of every other instance through invoking operations on the service interfaces. Thus, by converting the platform to run on a new architecture, the application can be ported with only minor changes. Furthermore, as all interactions are via service interfaces and the invocation mechanism, an application module need only support the specified interface to interwork with other application instances. So, for example, one module could be replaced by an equivalent without affecting the remaining components (for instance, replacing a particular GIS with a faster one) providing it is capable of supporting the same interface. Section 5.3 considers the application components in more detail.

Legacy applications also require RM-ODP compatible interfaces to be able to interwork with the application. These interfaces could notionally be integrated into the legacy applications themselves. However, since the majority of these applications are no longer under development, a gateway application is normally required to ‘wrap’ the application and offer its functionality through a service interface. Attaching well defined service interfaces to these applications has an additional benefit: once the interface has been defined, new applications can be developed by the organisation which are then able to interwork with the existing range of legacy applications using a simple common mechanism, despite the heterogeneous networks and end-systems in use.

An alternative, and much explored, strategy for implementing collaborative applications is through the use of a common windowing system, such as X, with a multiplexer to share graphical information between hosts [Abdel-Wahab,91]. However, research has shown little positive experience of using standard applications in a collaborative context [Lauwers,90]. Moreover, using such a protocol in a mobile environment raises a number of problems [Kantarjiev,93]. For instance, users are constrained to view shared information at exactly the same level of detail, resolution, size and position on their displays (violating the premise of a configurable toolkit approach). Moreover, such an approach would impair interactions between mobile field workers and office based colleagues that are using more powerful fixed workstations with larger higher resolution displays (particularly in the case of control centre staff who are required to deal with multiple field engineers simultaneously). In addition, windowing systems such as X generate a significant volume of high-rate latency sensitive protocol traffic which is poorly suited to mobile communications (although researchers are attempting to improve the performance of the X protocol over reduced capacity fixed links [Fulton,93]). Lastly, tying all hosts within the conference to a single windowing system implies firstly, that all hosts will be capable of running the system (which infers a range of hardware and software limitations) and, secondly, that the tools being used collaboratively will also run under the windowing system.