Recommendations for RCAF system integration

Prepared By: Marc-Andre Labrie Patrick Cinq-Mars Louis Tanguay Contractor Name and Address: LTI Informatique et Genie 825, boulevard Lebourgneuf, bureau 204, Québec, PQ, G2J 0B9 PWGSC Contract Number: W7701-083652 CSA: Jean Berger, Defence Scientist The scientif ic or technical validity of this Contract Report is entirely the responsibility of the Contractor and the contents do not necessarily have the approval or endorsement of Department of National Defence of Canada.

Contract Report DRDC-RDDC-2015-C127 June 2015

© Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2015

© Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2015

(Royal Canadian Air Force, 2014) (R(Royall CCCaanadiann AiAir Force,e, 220101014)4))

Prepared for: Abderrazak Sahi Jean BergerDefence Research and Development Canada - Valcartier 2459, de la Bravoure Road Quebec City (Québec)

Contract: W7701-083652 – Open Architecture Analysis TA-5 – Integration of applications and systems, Cycle-III, Integrated RCAF optimisation March 2015

Marc-André LabriePatrick Cinq-Mars Louis Tanguay

Recommendations for RCAF system integration

Abstract

Royal Canadian Air Force (RCAF) is using various Command & Control (C2) systems to support their activities. These systems are developed to handle various tasks and are not necessarily built to exchange data with other systems. On the other hand, exploring the added value offered by combining capabilities of different systems may be convenient as it necessitates only creating bridges between these applications. This perspective is attractive, but careful thinking is necessary, since creating a bridge can sometimes cost more than simply adding the capability to a given system. This report was produced during the TA-5 task of the Open Architecture Analysis project (W7701-083652) realized in February and March 2015 for DRDC-Valcartier.

The main objective of this task was to explore technological alternatives to address two of the main concerns of Combined Aerospace Operations Centre (CAOC) related to their business process; 1) give CAOC a synthesized view of planned missions as they are executed by Wings, and 2) offer CAOC one source of data for after-action review (AAR) when missions are completed.

After an analysis of both tools (NAPPIC and FlightPro), different solutions are proposed; 1) Implement FlightPro at CAOC, 2) Web interface to FlightPro databases, 3) Create an ESB based bridge between FlightPro and NAPPIC and 4) Other Cots/Gots.

Our recommendation is that solution 1 should be evaluated first as it is the simplest and probably cheapest solution. However, it may not answer all the needs either. Solution 2 should be analyzed if solution 1 is not feasible or does not provide enough benefits. Solution 3 is the costliest in terms of development, but it offers more flexibility, and future needs may influence such a choice. Solution 4 may be a good answer, but its cost and the offered must be evaluated. Also, the best approach could also be a mix of solutions like, for example, solution 1 and 2, as these solutions are not mutually exclusive.

In other words, a more detailed cost/benefits analysis is needed, for all solutions. A clever choice would require more information (data, needed interfaces or reports, needed GUI, needed functionalities, other constraints, etc.). Interface prototypes should be presented to users to validate the concepts, and finally a prototype of a chosen solution should be evaluated in a test facility (e.g. DRDC) with users feedback if possible.

i

Table of Contents

ABSTRACT .......................................................................................................................................................................... I

TABLE OF CONTENTS ...................................................................................................................................................... II

LIST OF FIGURES..............................................................................................................................................................IV

LIST OF TABL ES.................................................................................................................................................................V

1 INTRODUCTION ....................................................................................................................................................... 1

1.1 BACKGROUND ....................................................................................................................................................... 1 1.2 GLOBAL OBJECTIVE ................................................................................................................................................ 1 1.3 DOCUMENT OUTLINE.............................................................................................................................................1

2 PROBLEM DESCRIPTION......................................................................................................................................... 2

2.1 CONTEXT............................................................................................................................................................... 2 2.2 BUSINESS PROCESS OVERVIEW................................................................................................................................22.3 PROBLEM OVERVIEW ............................................................................................................................................. 3

3 SCOPED SYSTEMS OVERVIEW............................................................................................................................... 4

3.1 FLIGHTPRO...........................................................................................................................................................43.1.1 Architecture Overview............................................................................................................................ 4 3.1.2 Software Technologies ........................................................................................................................... 4 3.1.3 Architecture Metrics...............................................................................................................................5

3.2 NAPPIC ............................................................................................................................................................... 6 3.2.1 Architecture Overview............................................................................................................................ 6 3.2.2 Software Technologies ...........................................................................................................................63.2.3 Architecture Metrics ............................................................................................................................... 6

3.3 TECHNOLOGICAL BASELINE .................................................................................................................................... 7

4 SYSTEMS INTEGRATION ARCHITECTURES........................................................................................................10

4.1 DATA-ORIENTED INTEGRATION .............................................................................................................................11 4.1.1 File Transfer pattern .............................................................................................................................12 4.1.2 Maintain Data Copies pattern.............................................................................................................134.1.3 Shared Database pattern .....................................................................................................................14

4.2 FUNCTIONAL INTEGRATION ..................................................................................................................................14 4.2.1 Remote procedure invocation pattern ..............................................................................................15 4.2.2 Web Services pattern............................................................................................................................16 4.2.3 Enterprise Service Bus pattern............................................................................................................16

4.3 PRESENTATION INTEGRATION ...............................................................................................................................17

5 DATA DISPLAY........................................................................................................................................................19

ii

6 DISCUSSION ............................................................................................................................................................20

6.1 SOLUTION 1 – REUSE FLIGHTPRO.........................................................................................................................206.1.1 Option 1...................................................................................................................................................20 6.1.2 Option 2...................................................................................................................................................21 6.1.3 Option 3...................................................................................................................................................21

6.2 SOLUTION 2 – WEB-BASED INTERFACE ................................................................................................................21 6.3 SOLUTION 3 – ENTERPRISE SERVICE BUS (ESB) ....................................................................................................22 6.4 SOLUTION 4 – OTHER COTS/GOTS....................................................................................................................23

7 RECOMMENDATION .............................................................................................................................................24

8 CONCLUSION ..........................................................................................................................................................25

REFERENCES....................................................................................................................................................................26

iii

List of Figures

FIGURE 1 : OVERVIEW OF THE GENERIC ARCHITECTURE. ........................................................................................................10 FIGURE 2 : POSSIBLE LAYER CONNECTIONS BETWEEN TWO APPLICATIONS. .............................................................................11 FIGURE 3 : DATA-ORIENTED INTEGRATION............................................................................................................................11 FIGURE 4: SIMPLIFIED VIEW OF THE FILE TRANSFER PATTERN.................................................................................................12 FIGURE 5 : SIMPLIFIED VIEW OF THE MAINTAIN DATA COPIES PATTERN. ................................................................................13 FIGURE 6 : SIMPLIFIED VIEW OF THE SHARED DATABASE PATTERN. ........................................................................................14 FIGURE 7 : FUNCTIONAL INTEGRATION. ................................................................................................................................15 FIGURE 8: SIMPLIFIED VIEW OF THE REMOTE PROCEDURE INVOCATION PATTERN. ..................................................................15 FIGURE 9: SIMPLIFIED VIEW OF THE WEB SERVICES PATTERN.................................................................................................16FIGURE 10: SIMPLIFIED VIEW OF THE ENTERPRISE SERVICE BUS PATTERN...............................................................................17 FIGURE 11 : PRESENTATION INTEGRATION. ..........................................................................................................................18 FIGURE 12 : DISPLAYING DATABASE CONTENT IN A WEB BROWSER. .......................................................................................21FIGURE 13 : WEBTAS ARCHITECTURE (ISS, 2015). .............................................................................................................23

iv

List of Tables

TABLE 1 : ENTERPRISE SERVICE BUS EVALUATION. .................................................................................................................. 8 TABLE 2 : BUSINESS INFORMATION LAYER EVALUATION. ......................................................................................................... 8 TABLE 3 : USER INTERFACE LAYER EVALUATION. .....................................................................................................................8TABLE 4 : TEST MANAGEMENT PLATFORM EVALUATION. ........................................................................................................ 9 TABLE 5 : SYSTEMS INTEGRATION ARCHITECTURE EVALUATION. .............................................................................................. 9 TABLE 6 : PROS AND CONS OF THE FILE TRANSFER PATTERN. .................................................................................................13TABLE 7 : PROS AND CONS OF THE MAINTAIN DATA COPIES PATTERN. ..................................................................................13 TABLE 8 : PROS AND CONS OF SHARED DATABASE PATTERN. .................................................................................................14 TABLE 9 : PROS AND CONS OF THE REMOTE PROCEDURE INVOCATION PATTERN.....................................................................16TABLE 10 : PROS AND CONS OF THE WEB SERVICES PATTERN. ...............................................................................................16 TABLE 11 : PROS AND CONS OF THE ENTERPRISE SERVICE BUS PATTERN. ...............................................................................17

v

1 Introduction

1.1 Background

This document is the report produced for the TA-5 task of the Open Architecture Analysis project (W7701-083652) realized by LTI in February and March 2015 for DRDC-Valcartier.

Royal Canadian Air Force (RCAF) is using various Command & Control (C2) systems to support its activities. These systems are developed to handle various tasks and are not necessarily built to exchange data with other systems. On the other hand, exploring the added value offered by combining capabilities of different systems may be convenient as it necessitates only creatingbridges between these applications. This possibility is appealing, but careful thinking is necessary, since creating a bridge can sometimes cost more than simply adding the capability to a given system.

This task is the fifth realized during the present contract, and is in line with the work completed in task 1 and 2 (TA-1 and TA-2). These two tasks allowed to: 1) analyse the systems to be implemented in the DRDC-Valcartier Laboratoire d’Intégration et Développement des Systèmes (LIDS) in regard of two different aspects; technological analysis and C2 capabilities analysis, and 2) recommend good governance rules for implementation of systems in the LIDS.

1.2 Global objective

The main objective of this task is to explore technological alternatives to address two of the main concerns of Combined Aerospace Operations Centre (CAOC): 1) give CAOC a synthesized view of planned missions as they are executed by Wings, and 2) offer CAOC one source of data for after-action review (AAR) when missions are completed. Since CAOC uses the National Air Planning Process Integrated Capability (NAPPIC) and Wings use FlightPro, we assume the need is to enhance the capabilities of these two systems in order to reach the wanted goals.

Given relative short time and task budget, this analysis covers a first glance of technological alternatives, and a more complete evaluation would require deeper analysis of the possibilities, limitations, cost and effort of each alternative.

1.3 Document outline

This document presents the result of the work in the following manner. Section 2 presents a detailed problem description; context, business process overview and problem overview. Section 3 presents an overview of the NAPPIC and FlightPro systems. Sections 4 and 5 introduce technological approaches for interoperability. Finally, Sections 6 and 7 present solutions that should be considered and our recommendations.

1

2 Problem description

This section describes the existing Canadian aerospace power command and execution context, business process and problem overview which are critical to properly understand and realize thecurrent project.

2.1 Context

In Winnipeg, Manitoba, is located the 1 Canadian Air Division Headquarters (1 Cdn Air Div HQ), Canadian NORAD Region Headquarters (CANR HQ) which includes the CAOC. The CAOC provides the means by which the Joint/Combined Force ACC effects centralized command and decentralized execution of Canadian aerospace power. Among the CAOC deliverables are the Air Tasking Orders (ATO), which are provided to the various RCAF Wings. Requests for effect (RFE) are involved during ATO production as the upstream command requirements.

Wings are a grouping of operational and support units (squadrons, schools, etc.) under a single commander, which are tasked by the CAOC to execute mission orders in the form of the ATO. According to the RCAF, “Thirteen wings are located across Canada, from Gander, Newfoundland, to Comox, British Columbia. The Wings conduct Air Force operations under the direction of 1 Canadian Air Division/CANR. Ten Wings also include a Canadian Forces Base along with other operational and support units. Wings vary in size from several hundred personnel, such as at 9 Wing Gander and 5 Wing Goose Bay, to larger wings, such as, 8 Wing Trenton, 4 Wing Cold Lake and 14 Wing Greenwood with several thousand personnel.” (Royal Canadian Air Force, 2014).

2.2 Business process overview

The CAOC currently uses NAPPIC, a C2Core-Based tool developed by Intelligent Software Solutions1 as its primary battle management weapon system. Among other things, this operational level C2 tool includes the processing of RFEs and the generations of ATOs. The CAOC’s ATO uses a Master Aerospace Action Plan (MAAP) and the Decision Scheduling System (DSS) to create the ATOs.

At the RCAF Wings level, the ATOs sent by CAOC are managed through the use of a unit-level tool (ULT), currently a commercial software named FlightPro2. Once the ATO is published, the combat operations are responsible for its execution and continuous monitoring, which is conducted by the Senior Operations Duty Officer (SODO). The interaction between the operations and planning levels over plan execution is currently ensured only through a single

1 www.issinc.com 2 www.ocean.com.au/flightpro.asp

2

team. This team is also led by a SODO (who may adjust the ATO if required) and is continuously monitoring and synchronizing with higher planning levels (ATO production/revision).

2.3 Problem overview

A lack of operational feedback has been identified as one of the main deficiencies of the command and execution of Canadian aerospace power process as well as a need for further data source integration. Indeed, the CAOC has enunciated a need to get access to some unit level information to properly achieve its mandate.

NAPPIC-ULT information integration is suitable to facilitate business wide process integration. Obviously, a more integrated link with the unit levels would currently imply information exchange with the FlightPro ULT data sources. The aforementioned identified issues should be properly addressed in order to enhance the ability of the CAOC to conduct operations.

3

3 Scoped systems overview

This section describes the systems that have been overseen for integration as part of TA-5. The two systems presented below are the NAPPIC system and the commercially available FlightPro software. The following sections describe these systems and present an overview of their structure. For analysis purposes, summary evaluation grids from previous tasks were used in order to generate the required level of insight about the systems. Thus, both systems were evaluated using criteria, preliminary metrics and analysis topics with respect to the Task 1 report of this project (Halle S. , 2011). The next two sub-sections will also present the results of this evaluation for FlightPro and NAPPIC respectively.

The understanding of the NAPPIC system obtained through the aforementioned evaluation suggested that the latter system might qualify as technological baseline according to task 2 requirements for systems integration. The requirements for technological baseline were briefly evaluated and will be found in section 3.3.

3.1 FlightPro

FlightPro is a Commercial off-the-shelf (COTS) application used at tactical level for mission planning and training. FlightPro is used for the day-to-day planning and scheduling of military operations with respect to ATO. All aspects of planning, tasking, mission execution and re-planning are managed into this single Unit-Level Tool (ULT).

3.1.1 Architecture Overview

The FlightPro server operates off a single integrated database, with client workstations communicating with the server through a real-time messaging layer. FlightPro thus uses a classical client-server architecture model. The database component is implemented using Microsoft SQL Server and the messaging layer uses Windows services. The graphical user interface (GUI) of the client is built upon .NET technologies.

3.1.2 Software Technologies

The FlightPro software is known for using the following technologies:

SQL Server 2000 Windows Services Custom sockets .NET Framework, WPF

4

3.1.3 Architecture Metrics

Flexibility Scalable: FlightPro application is really task-oriented in the sense that it fulfills a specific need (support specifics tasks). It is not meant to be reused in contexts other that air planning operations. The scalability of the system is therefore very limited. In: The architecture of the application is not open enough to allow new components to be added. However, FlightPro is capable of importing some data format from legacy systems or standards. Out: Applications like FlightPro are difficult to integrate in other architectures, as they are not conceived to do so. Reusing some functionalities of the system would require prior analysis.

Up-to-date: FlightPro is implemented using .NET technologies which are still up-to-date. The database version is a little outdated, but can easily be migrated to recent version. Maintenance: FlightPro instance available at DRDC is poorly maintained in terms of version management. Multiple versions of the software are stored in a coarse manner with the installation guide referring to media that are not provided. The system’s updates are not really packaged and it is hard to know what the current or up-to-date version is. Maturity: FlightPro is mature enough to be used in the field. The use of FlightPro software for planning operational situation in contexts such as military air bases and small airports gives confidence about the maturity level of the system. Size: The system addresses various aspect of air planning, including flights schedules, operators training management, etc. The scope of the system is however limited to the domain of air planning operations. Distributed: FlightPro uses a client-server architecture allowing the content to be stored centrally while clients access the information remotely. Database: FlightPro server side applications are backed by a SQL database. The database should contain all the information required for the clients. Documentation: The level of documentation provided on the software architecture is limited, but user guides and installation instructions are well documented. Restrictions: FlightPro seems to be licensed application. The complete system does not have specific software requirements. Overall: The system is a simple application that seems to be respectably built to allow all needs to be satisfied. There is however no evidence that interoperability was a design requirement.

5

3.2 NAPPIC

The National Aerospace Planning Process Integration Capability (NAPPIC) supports the CAOC in the production of Air Tasking Order (ATO). NAPPIC is built upon the C2Core software suite, which is an advanced solution designed to offer various C2 capabilities, from strategy to planning, tasking, execution and assessment.

3.2.1 Architecture Overview

The NAPPIC system uses the Three-tier architecture model. The business layer components are developed using WebTAS, an Enterprise Service Bus (ESB) allowing abstraction of data sources while implementing business logic. Therefore, the resulting architecture is open for future integration and transition of information directly to the presentation layer. The presentation layer is a web-based rich client interface that provides configurable graphical components for visualization and analysis.

3.2.2 Software Technologies

NAPPIC uses a large framework embedding various technologies such as:

Oracle Database WebLogic Server SOAP services (Axis2) WebTAS Mule ESB Java EE

3.2.3 Architecture Metrics

Flexibility Scalable: The NAPPIC system seems to have a great potential for scalability. In: The use of an ESB for supporting business logic allows for integration of new components on the server side. On the client side, the framework application should ease the integration of new views, but it may require altering the client. Out: NAPPIC business logic components should be easily interoperable in other architectures.

Up-to-date: The NAPPIC system uses recent architecture paradigms such as an ESB and SOA. The implementation is based on up-to-date Java technology standards. Maintenance: The system is not trivial to install because it is composed of many technological components. Configuration of the components requires following strict instructions in order to ensure proper system operation. Maturity: The NAPPIC system is currently in use by governmental organisations and is mature enough to support nation-wide operations.

6

Size: NAPPIC is a very large system aiming to encompass a large domain of application. The data is mostly related to air military matters, but the system covers multiple aspects of planning and management within its field of interests (at strategic, tactical and operational levels). Distributed: The system uses distributed SOAP services for delivering business logic to the client applications. Database: An Oracle database stores most of the NAPPIC data and other databases are used as complementary information sources. The data is centralized on the server side. Documentation: NAPPIC documentation provides enough details about the software architecture to perform this review. The documentation is exhaustive and seems complete. Restrictions: Licensed software is used in NAPPIC and the whole system is under ITAR restrictions. Overall: NAPPIC appears to benefit from an architecture design that precedes the system itself. It reuses a proved framework and possesses many of the desirable qualities a system might have.

3.3 Technological Baseline

The framework underlying NAPPIC is believed to largely facilitate the implementation of business logic and the presentation of relevant information with respect to the tasks the system is meant to satisfy. Although limited in coverage and deepness, the technological analysis performed has shown evidence that a very mature software suite or toolkit was the core of the NAPPIC system’s design.

The following evaluation grid from Task 2 report (Halle & Cinq-Mars, 2011) was used to assess important aspects of a technological baseline promoting interoperability and composability of legacy, current and future systems inside an organization. Using tables from this grid helps in getting better insight in the overall technological capabilities of a system and, thus, makes it easier to later formulate recommendations on how to perform integration of new components using existing baseline.

Using distinct table for each important aspect of a technological baseline, the evaluation criteria are presented below with the result of the evaluation performed. The Eval column contains a Yes/No value when the information provided for this analysis gives enough evidence on the criterion and a not-evaluated (N/E) value otherwise.

7

Table 1 : Enterprise Service Bus evaluation.

TNB-ESB-1 Enterprise Service Bus Eval.

TNB-ESB-1.1 ESB offers a user authentication mechanism YesTNB-ESB-1.2 ESB controls the access to resources according to user rights YesTNB-ESB-1.3 ESB uses a standard protocol for data transfer YesTNB-ESB-1.4 ESB can capture failure in the information flow N/E TNB-ESB-1.5 ESB executes custom workflows YesTNB-ESB-1.6 ESB control the services orchestration YesTNB-ESB-1.7 ESB encrypts data for transfer N/ETNB-ESB-1.8 ESB uses redundancy for critical capabilities N/E TNB-ESB-1.9 ESB has recovery mechanism in case of failure N/E TNB-ESB-1.10 ESB uses backups to support redundancy or recovery No TNB-ESB-1.11 ESB is implement to deliver long term availability YesTNB-ESB-1.12 ESB can manage classification-level permissions NoTNB-ESB-1.13 ESB can manage need-to-know NoTNB-ESB-1.14 ESB offers logging capabilities for the data it manipulates YesTNB-ESB-1.15 ESB monitors performance of a system YesTNB-ESB-1.16 ESB offers application specific log technology YesTNB-ESB-1.17 ESB provides a quality of service (QoS) implementation N/E

Table 2 : Business Information Layer evaluation.

TNB-BIL-2 Business Information Layer Eval.

TNB-BIL-2.1 BIL concretely define information objects YesTNB-BIL-2.2 BIL performs ontology management YesTNB-BIL-2.3 BIL abstracts information access mechanisms YesTNB-BIL-2.4 BIL offers data mapping for different contexts YesTNB-BIL-2.5 BIL can locate information objects using GIS YesTNB-BIL-2.6 BIL can retrieve map information from a GIS Yes

Table 3 : User Interface Layer evaluation.

TNB-UIL-3 User Interface Layer Eval.

TNB-UIL-3.1 UIL implements a thin client web interface YesTNB-UIL-3.2 UIL offers a rich client platform YesTNB-UIL-3.3 UIL is bound to an authentication mechanism YesTNB-UIL-3.4 UIL can manage user profile YesTNB-UIL-3.5 UIL allow different application context for each user profile YesTNB-UIL-3.6 UIL offer a system configuration interface Yes

8

TNB-UIL-3.7 UIL provides generic built-in interfaces Yes

Table 4 : Test Management Platform evaluation.

TNB-TMP-4 Test Management Platform Eval.

TNB-TMP-4.1 TMP implements self-testing unit tests No TNB-TMP-4.2 TMP provides integrated unit test suite NoTNB-TMP-4.3 TMP offers automated diagnostic statistics No

Table 5 : Systems Integration Architecture evaluation.

TNB-SIA-5 Systems Integration Architecture Eval.

TNB-SIA-5.1 SIA is based on a known interoperability standard YesTNB-SIA-5.2 SIA implements a composition framework N/E TNB-SIA-5.3 SIA facilitates a high level of composability N/ETNB-SIA-5.4 SIA uses a distributed architecture YesTNB-SIA-5.5 SIA limits transfer via a publish/subscribe mechanism N/E TNB-SIA-5.6 SIA minimizes coupling between components Yes

9

4 Systems integration architectures

Organisations are commonly using several and diversified applications, based on various technologies, to support their business operations. When they are facing new opportunities, challenges or goals, their interest to integrate systems together can become an appealing solution. The systems integration architecture required to support this consolidation must be selected meticulously and require a depth understanding of the organisation core business activities. Integration means different things to different organizations. Systems integration can be defined as the secure and orchestrated sharing of processes and/or data between different applications within an organisation (Microsoft, 2003).

In this section, common systems integration patterns, adapted to the problem depicted in Section 2 are presented. The current CAOC requirement, which can be summarized to remote data monitoring, allows considering various options each one having different impacts on the emerging system.

The resulting system-of-systems (SoS) can be viewed as an implementation of the portal integration pattern where information is aggregated in a unified view (dashboard) for the end users (Microsoft, 2004). Thus, integration style is data-oriented rather than functionalities-oriented. Figure 1 depicts an overview of the generic solution to be detailed.

InterOp

FlightProFlightPro

Operators

NAPPIC

Unit Level Tool(FlightPro)

Planners

Dashboard

Operators

Ope

ratio

nal L

evel

Uni

t Lev

el

Figure 1 : Overview of the generic architecture.

10

The unification of data requires interactions between underlying applications, which is possible at different application layers. As shown in Figure 2, it is feasible to connect an application to another one using the presentation layer, the business logic layer or the data layer (Microsoft, 2004).

Application

PresentationLayer

Business LogicLayer Application

Data Store

?

Figure 2 : Possible layer connections between two applications.

All combinations of interconnection have their advantages and disadvantages that shall be taken into account when selecting the appropriate solution for the problem under study. These layer interconnections will act as a generic classification for systems integration patterns for the remainder of this section.

4.1 Data-oriented integration

A common way of interconnecting systems is by directly accessing the data layer (Figure 3). Applications typically keep their data in flat files or databases (relational, hierarchical or object-oriented). With an appropriate mechanism (ex.: DBMS, FTP) and the right security level, other applications can retrieve information from these data stores.

Application

PresentationLayer

Business LogicLayer

ApplicationData Store

Figure 3 : Data-oriented integration.

11

In the following sub-sections are depicted three patterns that constitute three types of data-oriented integration patterns that should be considered: file transfer, maintain data copies and shared database.

4.1.1 File Transfer pattern

Based on the File Transfer pattern, the CAOC could use a mechanism allowing the transfer of regional data to the CAOC server (Figure 4).

OperationalLevel im

port Unit

Level

export

Figure 4: Simplified view of the File Transfer pattern.

4.1.1.1 Context

Case 1 - Importing FlightPro current status (STRIPs)

A new Windows service could be created, and installed on each regional site, capable of interrogating the local regional database for a specific subset of data that is relevant to the CAOC. The service exports the extracted data to a dedicated location (such as a Windows share) that is remotely accessible by the CAOC. A second application, located on the CAOC server, would retrieve (import) the files and integrate the data in a local database.

Case 2 - Post-analysing mission execution related data

The CAOC wants a post analysis mode allowing generating reports of aggregated information related to mission execution. This also could be accomplished using a Windows service, able to launch a complete backup of the local regional database and copy the file(s) in a share folder. Thereafter, the CAOC can restore databases of all regional sites on a common server where queries can be defined and used to summarize relevant information.

Another solution would consist in FlightPro automatically generating reports at the end of a mission and transferring them into a shared location, accessible by the CAOC. This solution would require some modifications to FlightPro, or at least its current use.

Table 6 shows a summary of the pros and cons of the File Transfer pattern.

12

Table 6 : Pros and cons of the File Transfer pattern.

Pros Cons

Simple Batch updateReduced development time Bypass business logic

No data encapsulationCoarse-grained securityData synchronization Concurrent access No real-time integrationLatency

4.1.2 Maintain Data Copies pattern

Using the Maintain Data Copies pattern, the CAOC could use a mechanism allowing to remotely access regional databases.

OperationalLevel

Unit LevelCopy

DBrepl

icat

ion

RegionalDB

Figure 5 : Simplified view of the Maintain Data Copies pattern.

4.1.2.1 Context The CAOC wants an application that displays the information contained in regional FlightPro databases. A software component is required to fetch all regional databases and store the data in a local database, on which required data manipulation can be performed.

Table 7 shows a summary of the pros and cons of the Maintain Data Copies pattern.

Table 7 : Pros and cons of the Maintain Data Copies pattern.

Pros Cons

Simple Multiple connections to regional databases CAOC business process will link to a local database

Bypass business logic

No encapsulationCoarse-grained security

13

4.1.3 Shared Database pattern

OperationalLevel

Unit Level

Central DB

Figure 6 : Simplified view of the Shared Database pattern.

4.1.3.1 Context All regional sites write their data into a central database. The CAOC can also access this database and extract relevant information to be displayed on a dashboard.

This solution is already available with the FlightPro multi-site installation. This installation mode deploys a central database on which all sites dump their data. Via a FlightPro installation also deployed at their location, the CAOC could visualize all data of interest and generate appropriate reports.

Table 8 shows a summary of the pros and cons of the Shared Database pattern.

Table 8 : Pros and cons of Shared Database pattern.

Pros Cons

Solution seems to be already available (may require some customization)

Multiple network access

Data already accessible in a single location Bypass business logicNo encapsulation Coarse-grained security

4.2 Functional integration

An application can benefit from a second one by accessing its business logic through an appropriate interface (Figure 7). Unlike data-oriented integration, this way of integrating systems allows preserving data encapsulation.

14

Application

PresentationLayer

Business LogicLayer Application

Data Store

Figure 7 : Functional integration.

Unfortunately, not all applications have interfaces and specifications, ready to be accessed by external components. Another possible drawback, if an application programming interface (API) is available, is related to the granularity of the exposed methods that may not suit the needs of the accessor. In both cases, code customization would be required.

4.2.1 Remote procedure invocation pattern

Using the Remote procedure invocation (RPI) pattern, the CAOC could use a mechanism allowing to remotely access software components. Thus, an application has to expose a part of its functionalities so that another application can use them via a communication protocol.

OperationalLevel st

ub Unit Level

skeleton

Figure 8: Simplified view of the Remote Procedure Invocation pattern.

Unlike data-oriented techniques, the RPI pattern preserves encapsulation by directly calling application exposed business logic (by the use of an API or other mechanisms that permit to link to the “business logic” of the application), as opposed to the presentation layer or data layer as shown in Figure 7: Functional integration. Various technologies can be used to implement this pattern such as CORBA, COM, .NET and Java RMI.

4.2.1.1 Context Each regional site has an application on which the CAOC can connect to retrieve information of interest.

Table 9 shows a summary of the pros and cons of the Remote Procedure Invocation pattern.

15

Table 9 : Pros and cons of the Remote Procedure Invocation pattern.

Pros Cons

Data encapsulation CoupledRobust Required firewall modifications (port used)

4.2.2 Web Services pattern

Using the Web Services pattern, the CAOC could use a mechanism to remotely access services. This is a RPI-style architecture where business services are abstracted from the application, services contracts are defined and services are registered in a repository allowing to easily accessing them. A valuable feature of web services is that they work easily with HTTP, which is easy to get through firewalls (Hohpe & Woolf, 2003).

OperationalLevel

Serv

ice

requ

este

r

Unit Level

Service provider

Figure 9: Simplified view of the Web Services pattern.

4.2.2.1 Context Each regional site host a web service on which the CAOC can connect to retrieve information of interest.

Table 10 shows a summary of the pros and cons of the Web Services pattern.

Table 10 : Pros and cons of the Web Services pattern.

Pros Cons

Abstraction Point to point connection Loose coupling Reusability Discoverability Open standardsRobust

4.2.3 Enterprise Service Bus pattern

Using the Enterprise Service Bus (ESB) pattern, the CAOC could connect software components to a service bus, allowing to access remote services and data. ESB are message-oriented: they support sending and receiving messages between heterogeneous systems that may be local or distributed. The middleware allows reducing the complexity of developed systems by providing various mechanisms while hiding implementation details.

16

OperationalLevel

conn

ecto

r connector

Unit Level

RegionalDB

Figure 10: Simplified view of the Enterprise Service Bus pattern.

4.2.3.1 Context According to the documentation, NAPPIC is built on the MULE3 enterprise service bus. To link a FlightPro database to this ESB, a connector would be necessary to inject the FlightPro data directly in the business logic workflow. A consumer of the produced data, the dashboard, would still have to be implemented.

Table 11 shows a summary of the pros and cons of the Enterprise Service Bus pattern.

Table 11 : Pros and cons of the Enterprise Service Bus pattern.

Pros Cons

Ease new system integration (configuration instead of coding)

Slower communication speed

Robust Architecture can become complex Flexible Initial cost is highStandards-based

4.3 Presentation integration

This kind of integration (Figure 11) allows access to an application’s functionality through its user interface by mimicking a user’s input and by extracting data from the screen. This technique is usually done using regular expression functionality from a programming language, to parse the screen output.

3 http://www.mulesoft.org/

17

Application

PresentationLayer

Business LogicLayer

Data Store

Application

Figure 11 : Presentation integration.

There are some serious drawbacks to this method (Microsoft, 2004):

can only access what is also available to a human user; granularity of the exposed data and functionality is very coarse; easily disrupted;tightly coupled to the host application’s presentation.

This technique has a certain revival, caused by the surge of web-based thin-client architectures. For systems having HTML-based interfaces, it is possible to make an HTTP request and parse out the results (Hohpe & Woolf, 2003).

This is a solution that should be considered if the access to the business logic layer or the data layer is not possible, which is not the case of the current project context. This method may be more useful when integrating legacy systems.

18

5 Data display

Previous sections have presented patterns regarding the access of data from remote sites. With this data at hand, a solution shall also be selected to visualize relevant information.

The quantity of information that will be displayed at the CAOC is important and shall be presented in a structured way, in order to help the decision making process. GUI components (charts, tree views, heatmap, etc.) based on data visualization techniques4, and standard GUI widgets (tab bar, combo-box, etc.) allowing filtering and classifying information would certainly help the decision makers (end-users).

Having that in mind, a custom solution, suiting the nature of the data to be displayed, the operational context and the end-user needs, is required. At this stage, various options should be considered to support data display:

1. Adapting FlightPro; 2. Developing a new application, using a custom front-end or a web browser; or 3. Modifying NAPPIC.

4 Using 3rd party APIs l ike d3.js (http://d3js.org/)

19

6 Discussion

Scalability is often targeted when selecting an integration pattern. By doing so, the architect wishes to create a system on which new functionalities can be added at a low cost. However, various criteria should also be considered when selecting an integration technology. Realistically, the project context, available technologies, infrastructures, budget, schedule, organisations politics, etc., can all have major influence on the suitability of an integration pattern.

The following sections present the recommended approaches for the problem under study. The following criteria were used to propose appropriate solutions:

cost; robustness; impact on regional sites; impact on CAOC site; and maintenance.

6.1 Solution 1 – Reuse FlightPro 6.1.1 Option 1An appealing solution would consist in using the FlightPro multi-site installation as introduced in Section 4.1.3. This would provide a central database containing all regional sites information. This database could be accessed via a FlightPro installed on a CAOC computer. The FlightPro information displaying and report generation functionalities could then be taken advantage of. The disadvantage of this solution is the centric nature of this solution vs. the decentralized nature of the operation carried by regional sites. Some concerns are raised by this option:

How are displayed each regional sites data (regarding STRIPs)? Are they gathered in a view for each site or all accessible in a unique view? Can we control information access so that a regional site is not allowed to view the data from another regional site? What occurs if the network crash? Are regional sites still able to operate without access to the central database? Can a local database be used as a temporary buffer in that case?

Before opting for this solution, a review of the limits would have to be studied. Notice that the limits could be circumvented by modifying FlightPro itself.

20

6.1.2 Option 2 Another option would be to keep the actual deployment (each regional site having its database). A FlightPro client could be installed at the CAOC. Instead of linking to a local database, the CAOC FlightPro application could change its connection string to link to a remote database. On demand, the remote database could link to another remote database. The only modification required on regional sites would consist in configuring their database to allow a connection with the CAOC. Thus, only one regional site data would be visualized at a time using this technique. The robustness of the solution would be assured by the decentralized database. Regional sites would also have only a view of their data. 6.1.3 Option 3 Based on critics formulated in Option 1, a more decentralized database access solution, based on the Maintain Database Copy pattern (Section 4.1.2), could be advantageous and fix some observed problems. A FlightPro client could be installed at the CAOC. Each regional site could still continue to populate their database. The CAOC FlightProapplication would fetch each regional database and store the data of interest on a local database. FlightPro would be used to display relevant information in a structured way. The only modification required on regional sites would consist in configuring their database to allow a connection with the CAOC. The robustness of the solution would be assured by the decentralized database. Regional sites would also have only a view of their data.

6.2 Solution 2 – Web-Based Interface

The difference between this solution and the previous one is that FlightPro is replaced by a light front-end. This solution would have to be considered in the case where FlightPro cannot be modified or installed on CAOC site. Naturally, some development would be required to display the data.

Because the resulting system is considered as an implementation of the data portal pattern, an intuitive and flexible solution would be to use a web browser as the front-end interface (Figure 12).

Web Server Data StoreApplication ServerFront-End

Figure 12 : Displaying database content in a web browser.

21

6.3 Solution 3 – Enterprise Service Bus (ESB)

This solution requires the creation of a connector (or set of connectors) for NAPPIC using its ESB, so FlightPro can export the needed data. A new NAPPIC interface, a custom front-end or even FlightPro could be used to consume the databases data. The last two options necessitate probably more development, since only NAPPIC uses ESB for the moment.

This may be the most elegant approach amongst proposed solutions, because it is scalable to more systems integration, a situation that may occur in the future as CAOC needs evolve. By developing new components directly into the core of NAPPIC using its own technologies, the CAOC can fully control the evolution of its system. However, this alternative is expensive because it necessitates a considerable analysis and development effort.

On the other hand, this approach keeps a clear separation between the tools by preserving data encapsulation. FlightPro would need to be modified or extended in order to add ESB export capabilities, and NAPPIC could need modifications, but it uses already the ESB so modifications on its side should be less important. Furthermore, if FlightPro should be replaced at Wing level, the NAPPIC side should not be affected too much.

That being said, a Government off-the-shelf (GOTS) technology framework, named WebTAS5, could be used together with Mule ESB to facilitate the integration and development. This avenue could be interesting for CAOC, as WebTAS is maintained by Intelligent Software Solutions (ISS), the same developer behind NAPPIC. A schema, presenting its global architecture is shown in Figure 13.

5 http://www.issinc.com/products/webtas/

22

Figure 13 : WebTAS architecture (ISS, 2015).

This extensible and modular toolset is employed widely by U.S. government agencies in C2 contexts. WebTAS offers various functionalities of interest for data visualization, data analysis, reporting, data sources connection, etc.

6.4 Solution 4 – Other COTS/GOTS

A fourth solution would be the use of COTS/GOTS solutions like ACUMEN, from Intelligent Software Solutions (ISS), the creators of NAPPIC.

ACUMEN is a tool that “enables strategic plan development, assessment and tracking in support of adaptive planning process”. It also offers “timely awareness of plan execution, and if the plan is achieving desired effects” (according to ACUMEN documentation). These elements are totally in line with the two objectives of CAOC: 1) offer a solution to follow mission execution and 2) offer a solution to support AAR for planning.

The very brief documentation available from ISS specifies it can be fed by external systems, as well as databases, Excel sheets, structured messages, etc. It can also produce automated briefings and documents, which may answer some if not all of the CAOC needs.

We do not know to what extent ACUMEN can fill the gaps of the current CAOC situation. At least, an analysis of its functionalities, advantages and disadvantages; and how it can answer the CAOC needs compared to the other solutions, should be conducted.

23

7 Recommendation

This report described many solutions regarding the two important problems the CAOC wants to solve: 1) offer a solution to follow mission execution and 2) offer a solution to support AAR for planning. Four solutions were presented, with increasing cost and efforts but offering also increasing flexibility.

Solution 1 (Implement FlightPro-multisite at CAOC) should be evaluated first as it is the simplest and probably cheapest solution. However, it may not answer all the needs either. Solution 2 (web interface to FlightPro databases) should be analyzed if solution 1 is not feasible or does not provide enough benefits. Solution 3 (create an ESB based bridge between FlightPro and NAPPIC) is the costliest in terms of development, but it offers more flexibility, and future needs may influence such a choice. Solution 4 (other COTS/GOTS) may be a good answer, but its cost and functionalities must be evaluated.

Also, the best approach could be a mix of solutions like, for example, solution 1 and 2 (implementation of FlightPro at CAOC with the help of an additional interface for AAR), or a mix of other solutions. These solutions are not mutually exclusive.

In other words, a more detailed cost/benefits analysis is needed, for all solutions. A clever choice would require more information (needed data from ULT (FlightPro), needed interfaces or reports, needed GUI, detailed needed functionalities, other constraints, etc.) to support such decision. Secondly, interface prototypes should be presented to users to validate the concepts, and finally a prototype of a chosen solution should be evaluated in a test facility (e.g. DRDC) with users feedback if possible.

24

8 Conclusion

In this report, various techniques regarding systems integration were depicted. Recommendations based on these techniques, adapted to RCAF situation, were formulated. These recommendations were based on our comprehension of the overall RCAF context and were established taking into account: cost, robustness, impact on regional sites, impact on CAOC site and maintenance.

The scope and budget of this task has allowed depicting an overview of the potential systems integration solutions. A more detailed study would nevertheless be necessary to have a better grasp of the complete client business process and infrastructure, or at least the part implied by the two needs to be addressed. Discussions with clients and end-users could reveal undocumented constraints or preferences, so the findings that would result could have an incidence on the systems integration pattern selection.

25

References

Halle, S. (2011). Open Architecture Analysis – C2 Systems Overview. LTI inc. W7701-083652, unpublished.

Halle, S., & Cinq-Mars, P. (2011). Open Architecture Analysis – Concept Overview and System Requirements Specifications. LTI inc. W7701-083652, to be published.

Hohpe, G., & Woolf, B. (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional.

ISS. (2015). WebTAS. Retrieved March 25, 2015, from http://www.issinc.com/products/webtas/#tabs-2

Microsoft. (2003). Guidelines for Application Integration (Patterns & Practices). Microsoft Press.

Microsoft. (2004). Integration Patterns. Microsoft Press.

Royal Canadian Air Force. (2014). Wings and Squadrons. Retrieved March 20, 2015, from http://www.rcaf-arc.forces.gc.ca/en/wings-squadrons.page

26