DoD EXI Implementations Considerations

DoD’s Network-Centric vision equates to heavy leverage of the XML family of languages (ASD NII, 2006; DOD CIO IM, 2006; Langevin et al., 2008; Jacobs, 2008).

EXI is being tested within DoD frameworks with success, and is likely to see adoption into the DoD information technology framework soon (MITRE, 2008).

a. EXI Must Become a Recognized Standard

Before DoD formally adopts any compression solution, EXI or other, it must be an official international standard. Without being a standard, support for

continued development ranges from limited to nonexistent due to the narrow number of informed developers using the nonstandard solution. Nonstandard solutions, whether for cost or not, ultimately equate to proprietary solutions because only a few corporations will understand or will assume the cost and risk of maintaining a narrowly focused solution.

Nonstandard solutions only further propagate the existing stovepipe problems the DoD is trying to transition away. If a solution is not standardized, then other systems will not be able to interoperate. Each existing system would have to be

redesigned manually to enable them to collaborate with each new “Stovepipe,” which is expensive, inflexible to changes, and not likely to happen.

b. EXI Must Not be a DoD-Only Standardized Solution Even if a solution passes various standards boards, and receives international standardization certification, that does not automatically equate to an acceptable and adoptable solution. In addition to being a recognized standard, a solution must also be adopted in many domains. Widespread adoption proves the solution is sound technically and is understood by many developers. Without wide adoption, a solution that has a standards certification becomes a pseudo nonstandard due to the reduced number of informed developers who invest time and effort into the discovery of the standard’s domain rules. With limited available developers and limited adaptation, the risk of loss of interoperability can repeat much like a nonstandard stovepipe solution.

An example of such an occurrences is the High Level Architecture (HLA), a standard simulation protocol (IEEE 1516) that was adopted by DoD, but not adopted by other simulation based corporations. Prior to the HLA standards intuitive, simulations from different developers could not work together which resulted many non-interoperable simulations stovepipe. The purpose of HLA was to enable arbitrary simulation

developers to interconnect their simulation together seamlessly without requiring combined development effort. That is, a Boeing aircraft simulation could work with a Lockheed ship simulation out-of-the-box enabling DoD wide simulation of war-gaming or needs-gap-analysis.

DoD and a handful of other NATO militaries are the only entries that adopted the HLA standard. Because DoD and other militaries are not developers, they rely on corporate contractors to build their simulations. However, because only DoD and other militaries adopted the HLA and corporations did not, the cost of development sky rocketed due to lack of existing expertise in HLA within the simulation corporations.

(RTI). The RTI is the key to HLA interoperability, in that as long as all HLA

simulations, called Federates, talk to the same RTI, they can interoperate. What actually happened is each contractor developed their simulations based on their own RTI, which disabled simulation interoperability between different developers. Figure 27 shows the RTI and Federate integration in general form.

Figure 27. HLA General Architeture Overview Example

The result of HLA is a well-defined collection of standardized, but inoperable simulations. Ironically, counter to what the vision of HLA was trying to eliminate. HLA was for all intended purposes a failure as it ended up costing more and did not deliver interoperable simulations. Lack of interoperability requirements being set by the primary customer, the U.S. Department of Defense, is the primary root cause of this inevitable failure.

c. Possible Standalone Application

While the ideal implementation base for EXI is the Web server/browser integration, there is also merit for EXI as a standalone desktop application that would operate similar to that of WinZip or other desktop applications. However, by deploying EXI as a standalone application, several security and network administration concerns have to be considered in greater detail than if a part of a larger server suite.

(1) Security and Accreditation. DoD must approve all network software and devices before they can be installed on any DoD network architecture. EXI as a standalone application without a sponsoring activity, such as a Web server, as the backbone support forces would be forced to manage the entire security and accreditation process alone. While this is not an impossible task, the magnitude of the effort,

confounded by lacking sponsor support, muscle, can potentially delay the deployment of EXI into the DoD networks for years.

A standalone DoD EXI implementation might require the EXI developer to conduct extensive and documented testing of the compatibility and security risk the EXI implementation poses to every network within DoD, or at least those networks that intend to implement EXI. This would delay the deployment of EXI, but would prove its security risk is low. However, if EXI were encapsulated in a sponsor’s product, Web server, the sponsors, while simultaneously testing their array of

applications, would also test EXI, and ultimately get EXI deployed faster and more reliably. Additionally, by simply having a trusted sponsor indirectly implies warranted trust and validation, which EXI as a standalone will not have until years of fleet usage.

(2) Network Administrator Workload Increase. As a standalone application, an EXI solution would have to be manually installed and maintained at each computer, not a single central point. This increases network administrator workload in terms of maintenance, installation, and most importantly, version control. As updated versions of EXI are released, those releases will have to be manually updated at each

to a loss of interoperability due to codebase changes between versions. Further, as a standalone application, the probability of EXI being abandoned or inadequately supported increases.

d. EXI and DoD Integration Summary

Any DoD adopted solution must be interoperable with the existing network architecture, must be standardized by competent authority, and must be widely adopted in order to keep with the Network-Centric vision of a system-of-systems. If EXI does not receive W3C standardization endorsement and business-world acceptance, the DoD should not adopt EXI. If these prerequisites are satisfied, EXI is best suited for integrated within an existing sponsored program in order to simplify the integration and deployment process. Lastly, a HTTP server deployment of EXI can enable DoD the maximum leverage of EXI’s potential as a majority of network XML traffic is HTTP based.