4.3.2 Software Architecture

The CSC/PBFI Team will ensure CHART II is an open system, meaning the operating system must comply with the IEEE Portable Operating System Interface (Posix) suite of standards, and it must use generally accepted standard communications protocols. CHART II must be platform independent (Microsoft Windows NT, UNIX, etc.) and able to run across heterogeneous networks. Software Architecture Alternatives

In order to ensure platform independence, the CSC/PBFI Team investigated a number of different approaches.

The Distributed Component Object Model (DCOM), based on the Open Systems Foundation (OSF) Distributed Computing Environment (DCE), is native to Microsoft Windows. It does not, however, provide a platform independent client-server infrastructure because it is too tightly coupled to the Microsoft Windows operating system family. DCE is based on the remote procedure call (RPC) facility and is available for many platforms. Unfortunately, DCE offers incomplete support for Object-Oriented languages and is founded on aging technology.

The Common Object Request Broker Architecture (CORBA) is a specification of the industry consortium Object Management Group (OMG) Object Management Architecture (OMA). It describes a framework to implement platform independent, Object-Oriented, client-server applications across heterogeneous networks. The US DOD Defense Information Systems Agency (DISA) study, dated 13 April 1998, endorsed CORBA as a de facto standard and advised defense organizations to use CORBA for developing MS Windows applications. A comparison of the DCOM and CORBA approaches is illustrated by figure 4-2.

Both approaches accomplish the primary task: insulating the client application from the communications process—the client doesn’t need to worry about where the server is or how to get to it. Beyond that, they diverge. DCOM, and DCE, provide client-server services at the transport layer of the ISO network reference model using RPC service requests. The CORBA Object Request Broker (ORB) provides client-server services at the presentation layer using Internet-Inter-ORB Protocol (IIOP) to make requests upon an object and the object can send responses back to the client—the ORB is an object bridge.




Figure 4-2. A Comparison of the DCOM and CORBA Client-Server Models

CSC/PBFI Advantage: DCOM provides client-server services at the transport layer while CORBA provides client-server services at the presentation layer The CORBA Solution

The architecture for software developed for CHART II will be based on OMG CORBA specification, version 2. CORBA provides more extensive Object-Oriented services than the MS DCOM and the OSF DCE remote procedure call (RPC) models. By using a commercial-off-the-shelf-software (COTS) ORB, the CSC/PBFI Team will avoid developing custom inter-process/inter-COTS software, as was done in the first CHART system. In addition, using CORBA instead of DCOM will not impact DCOM software already developed for the AVCM and Field Management Station (FMS). That software will be integrated by use of a COTS CORBA/DCOM gateway.

CORBA describes a peer-to-peer distributed computing facility, shown in figure 4-3, where all applications are objects (in the sense of object orientation). Objects can alternate between client roles and server roles. An object is in a client role when it is the originator of an object invocation. An object is in a server role when it is the recipient of an object invocation. Most objects often play both roles. For example, the graphical user interface is a client when it requests a service or information. It is a server when it builds the display for the service or information.




Figure 4-3. A Layered View of an ORB

CSC/PBFI Advantage: In a peer to peer distributed computing facility, all applications are objects that can alternate between client roles and server roles
 Interface Definition Language

However, an ORB cannot always be used, the integration may require working on an older platform for which there is no ORB support. In such cases, an Interface Definition Language (IDL) often provides a benefit in creating a well-described and controlled interface between the two pieces of software.

Client and server interfaces are defined using IDL Abstract Syntax Notation (ASN.1). IDL statements are compiler language independent. Thus, they support platform independence. These statements are subsequently compiled by a platform sensitive IDL compiler to create code (e.g., C++, Visual Basic, or Smalltalk).

One of the outputs of an IDL compiler—as shown by figure 4-4—is the header files that define method prototypes for a development language. Our developers use these header files when building clients and servers to define the application program interface (API) for each. By creating a well-defined interface using IDL, the application can be distributed as required with minimal or no impact on the code.




Figure 4-4. CHART II IDL Interfaces Described Using ASN.1

CSC/PBFI Advantage: By creating a well defined interface using IDL, an application can be distributed as required with minimal or no impact on code Integrating Legacy Applications

figure 4-5 illustrates the CHART II Software Architecture Model for integrating legacy ITS software applications, such as SCAN, into the CHART II operator interface. Here an object wrapper—a conversion server or protocol translator—makes the information flow to and from the legacy application transparent to CHART II and supports close integration of the legacy application.







Figure 4-5. Object Wrappers

CSC/PBFI Advantage: Protocol Translators will be used to integrate legacy applications