Email this Article Email   

CHIPS Articles: Realizing FORCEnet: A Practical Example

Realizing FORCEnet: A Practical Example
By Lt. Cmdr. Edwin L. Armistead, Earle Kirkley, Andrew Mansfield, Dave Huff, Ryan Hofschneider and Ben Holt - January-March 2004
For Sea Power 21, the Chief of Naval Operations (CNO) stated, "FORCEnet will provide the architecture to increase substantially combat capabilities through aligned and integrated systems, functions and missions. It will transform situational awareness, accelerate speed of decision and allow us to greatly distribute combat power. FORCEnet will harness information for knowledge-based combat operations and increase force survivability. It will also provide real-time enhanced collaborative planning among joint and coalition partners."1

In July 2003, the CNO reiterated the importance of FORCEnet when he stated, "FORCEnet is the centerpiece of our roadmap to the future. Once implemented, FORCEnet will effectively give warfighters the knowledge of the battlefield to 'know first' and 'act first' — taking advantage of knowledge superiority over an adversary to prevail in battle."2

The task at hand is to fortify the warfighters with an underlying information network of superior battlespace knowledge. Both producers and consumers of data must have secure, reliable access to the required services with sufficient bandwidth to perform their required functions. The concept of this Distributed Services Architecture has been a common refrain since the publication of Joint Vision 2010 in 1996. However, the technology to accomplish this seamless transition has not been available until now. The emergence of Web Services has enabled developers to use common communication protocols and data structures to realize this new FORCEnet architecture.

In the notional example depicted in Figure 1, a diverse collection of applications and devices are shown communicating seamlessly. Through common Web-Services interfaces (e.g., SOAP, REST, XMLRPC) and operations-specific Extensible Markup Language (XML) documents and attachments, an unmanned aerial vehicle (UAV) sends its imagery payload (i.e., a possible target) and metadata through a geo-rectification mediation Web Service to the Global Information Grid (GIG). Applications requiring UAV information subscribe to its data feed and the UAV data stream is automatically transmitted to the subscriber clients who have the appropriate permissions to receive it.

Data filtering of the GIG information can be accomplished using a multi-level security Web Service leveraged by other Web Services and client applications. For example, coalition partners would be able to view a subset of the UAV imagery approved for non-U.S. forces.

Warfighters equipped with client software receiving information from the mediation service can identify targets and generate tasking based on the rapidly changing battlespace situation. These taskings are distributed throughout the FORCEnet (i.e., GIG) via the SOAP/XML Web-Services framework, possibly through the various mediation servers, to the net-enabled warfighter on the ground and in the sky. Speed-of-Command in this net-centric battlespace is such that aircraft may be tasked or re-tasked to strike targets that were acquired by network sensors only moments before the attack.

But questions still remain about the melding of these technologies and whether they can actually deliver on promises of speed-to-capability, deployment flexibility and open standards. Recently, a partnership of development organizations including Task Force Web (TFW); Space and Naval Warfare Systems Command (PMW 161); Space and Naval Warfare Systems Center Charleston3; and Fleet Numerical Meteorology and Oceanography Center (FNMOC) demonstrated some practical examples that they have developed and implemented over the past two years. This partnership can affirm that there really is substance to the lightning bolts and network clouds in the diagrams that often accompany presentations (including this one) depicting the Web-Services concept.

By leveraging widely adopted interfaces (SOAP) and a data description language (XML), these organizations have found that the performance of Web Services can far outshine the legacy stovepipe methodologies of the past.

The Web-Services interfaces mentioned above have been largely successful because their specifications comply with open standards, such as the use of SOAP and XML as defined by the World Wide Web Consortium. This is an association where everyone is welcome to participate in the development and discussion of standards. In this manner, Common Application Programming Interfaces (APIs) compliant with open specifications can be freely implemented without license fees or reverse engineering. This has led to a huge growth of their use in the popular programming languages of today.

Likewise, the widespread availability of development tools that support W3C standards has contributed to the speed with which software developers are able to integrate Web Services into their applications. Instead of writing customized code to support proprietary data formats and protocols, developers can leverage a common code base that supports a common set of standards and protocols. A reduction in programming errors and increased reliability are additional benefits reaped by using a common code base. Program management also benefits because research and development dollars can be redirected to increasing capability and functional richness of existing applications.

Web-Services components are self-identifying technologies, allowing the creation of a modular, distributed architecture. Interfaces like SOAP or REST provide data “envelopes” containing XML and associated binary data attachments. A data envelope describes the nature of its contents and how it should be processed by the recipient application. Likewise, the XML (www.W3.org/TR/ REC-xml) contained within the envelope describes the structure of the data payload.

Since Web Services leverage the same transport mechanisms that built the World Wide Web, the location of applications and servers in this distributed environment has become irrelevant to the warfighter. Applications and servers could be in the same room, the same building or halfway around the world.

In the past, client software frequently was developed with a small initial scope only to find that a broader need would require scaling of the project. With the tools provided in the Web-Services framework, scaling is no longer a problem. Today, all client-server communication is performed using interfaces that ignore physical location, so a programmer can now change the client-server architecture without having to change the code base. This type of deployment flexibility quickly fosters reuse, as services that are written and deployed at one facility can be leveraged at another, allowing for efficient application development.

A practical example of these melded technologies in action was the recent FORCEnet Integrated Prototype Demonstration (IPD) conducted onboard the USS Essex (LHD-2) from September 2530, 2003. TFW specific Web-enabled capabilities included:

-- A suite of Navy Enterprise Portal (NEP) Single Sign On (SSO) enabled collaborative tools such as Group Chat, Instant Messaging, Whiteboarding, Discussion Boards and a File Library all based on the Collaboration-at-Sea (CAS) tools.

-- A suite of Command, Control and Intelligence applications, including WebCOP, ITSWeb and Intel Shop.

-- A readiness tool based on Type Commander Readiness Management System (TRMS), including a Web Service built specifically to support the Expeditionary Strike Group (ESG) Commander’s assets view.

-- A suite of 10 Meteorology and Oceanography (METOC) tools, like Chemical Downwind Report, Ballistic Winds, MyWxmap and Web Search and Rescue, designed specially by FNMOC for FORCEnet support to the ESG.

From a TFW perspective, the Essex crew and the PHIBRON/ESG staffs successfully used all of the Web-Enabled applications during the FORCEnet IPD. One noteworthy achievement was a combination chat and whiteboard collaborative session between the USS Essex and USS Chancellorsville (CG-62) using the NEP with information extracted from the WebCOP and transmitted over the Intra-BattleGroup Wireless Network. Another highlight occurred when embarked staff of the Essex ESG trained members of the U.S.Army 25th Infantry Division based in Hawaii on WebCOP through the NEP, using collaboration tools while underway.

As shown, the particular capabilities of the NEP, and more generally Web Services, have great potential to enhance situational awareness and information sharing. The practical example of the FORCEnet IPD allowed TFW and FNMOC to demonstrate to a large warfighter group the inherent capabilities of these new technologies.

In conclusion, the effectiveness of Web Services, especially in the maritime environment of the Navy, is readily apparent. The ability to provide access to the applications from any enclave, anywhere in the world is truly extraordinary. This new capability is rapidly changing the way the Navy operates in the information battlespace, and lays the foundation for a successful transition to the FORCEnet envisioned by the CNO.

References
1. Clark,Vern. Proceedings,“Sea Power 21: Projecting Decisive Joint Capabilities.” October 2002.
2. Donaldson,John. Navy NewsStand,“NETWARCOM Celebrates First Year In Operation - Hosts CNO Visit.” July 2003. Story Number: NNS030717-16. (http://www.news.navy.mil/search/display.asp? story_id=8529)
3. Demonstrated during exercise Quantum Leap-1 under the OSD Horizontal Fusion portfolio (http://www.defenselink.mil/releases/ 2003/nr20030828-0413.html)

Lt. Cmdr. Edwin L. Armistead works in OPNAV 09W; Earle Kirkley works for SPAWAR PMW 161; Andrew Mansfield works for SSC Charleston, and Dave Huff, Ryan Hofschneider and Ben Holt work for FNMOC.

Figure 1 shows a diverse collection of applications and devices communicating seamlessly through Web-Services interfaces, XML documents, UAV imagery and metadata.
Figure 1.
Related CHIPS Articles
Related DON CIO News
Related DON CIO Policy

CHIPS is an official U.S. Navy website sponsored by the Department of the Navy (DON) Chief Information Officer, the Department of Defense Enterprise Software Initiative (ESI) and the DON's ESI Software Product Manager Team at Space and Naval Warfare Systems Center Pacific.

Online ISSN 2154-1779; Print ISSN 1047-9988
Hyperlink Disclaimer