| Specific Capabilities | Demonstration Goals |
| Technologies used | Looking ahead |

To support the warfighter, the Department of Defense (DOD) must move increasingly into systems of communications, data processing, and personal interaction that are seamlessly integrated in real time across great distances and across disparate hardware and software systems. The Defense Information Infrastructure Common Operating Environment (DII COE) is intended to provide a framework for that integration. In the general marketplace, the World Wide Web has shown the resources that can be accessed over the Internet; Sun's Java programming language is designed to permit the Web's processing power to grow even faster. Java bytecode runs on the huge number of enduser platforms, not the limited number of Web hosts. Looking, then, at the variety of needs and technologies, the Ada 95 programming language is uniquely positioned to meet those needs and to maximize use of those technologies. Ada 95's Annex E provides the mechanism for distributed processing. Java's semantic similarity to Ada made it straightforward to develop a compiler that produces bytecode indistinguishable from that provided by Java. (See AdaIC News, Winter 1996-1997. "Ada Java Compiler Released", which describes the Appletmagic compiler developed by Intermetrics, Inc.) One natural combination, therefore, is endusers/clients running Java bytecode generated from Ada 95 source code, and a host/distributed server using Ada 95's Annex E distribution mechanism internally. Both these technologies have been discussed within the DII community. Until recently, though, neither had been demonstrated in live software, nor had the two been combined in a single client/server demonstration. To meet this need, the Ada Joint Program Office (AJPO) sponsored a successful demonstration project -- the GCCS Ada 95 Client Demo Applet. Developed by CACI, Inc., it is now available on the Web. You can link to it via http://archive.adaic.com/java/. The prototype client/server pair demonstrates the use of two new technologies within a context similar to that of the DII COE. For a bare-bones example, developers chose the sort of application that might be built on top of the DII Global Command and Control System/Global Combat Support System COE (DII GCCS/GCSS COE). For this demo's prototype client/server pair, they chose to simulate a hypothetica command, control, communications, computers, and intelligence (C4I) application. The prototype has been successfully demonstrated on Sun Sparcstation server hardware with no COE present, and on PC (Windows 95 and NT), Macintosh, and Sun client hardware. At CACI, the server ran on three Sun Workstations as a single distributed Ada 95 program. The client software was written in Ada 95 and compiled with the Intermetrics AppletMagic(tm) compiler. The generated Java bytecode runs on any Java Virtual Machine (JVM) -- for example, a Java-enabled Web browser such as Netscape 3.x, the Microsoft Internet Explorer 3.x, or a JVM Applet Viewer. Suitable hardware could be a Sun, a Macintosh, a PC running Windows NT 4.0, or a PC running Windows 95). Specific capabilities The client/server pair provides basic functionality in simulating simplified information on enemy troop locations and troop types with which a commander might be presented during a battle. This information is gathered from three "sensors" (implemented as simple software simulations) in near real-time and displayed as standard military icons on a simulated texture map. The system allows multiple clients to connect to the server simultaneously. All clients observe the same battlefield. Each receives the same set of sensor observations, so all client displays will be identical. The client software initially displays a login screen. Once the user presses the login button, the client connects to the server and begins the download and display of the data. The client software displays an icon representing each observed enemy on a pseudo-map. The icons are color coded to correspond with each sensor (ground => blue, air => red, satellite => yellow). Each type of unit is represented by the standard military icons. As each "sensor" observes the units, the new data is sent to the client. The client applet then continuously updates the display with the new data. Once the user selects "quit" from the menu or closes the map window, the client disconnects from the server. The user is then presented with the login screen again. Demonstration goals The prototype has successfully shown some of the benefits of the JVM for the DII environment: Client neutrality: The client software will run (without change) on Sun/Solaris, Macintosh/System 7.5.5, PC/Windows NT 4.0, and PC/Windows 95 environments. (Observed differences in client software behavior for identical .class files appear to be due to differences in JVM implementations. In this respect, the behavior of the Ada 95 client is no different than a Java client -- it runs identically on different machines within the known differences/bugs present on those JVM implementations.) No physical distribution and/or installation of client software: The demonstration application will run on any machine preconfigured with a Java-enabled Web browser. There is no need to supply users with a disk containing client software; and, therefore, no user-run installation of client software. It has also shown a strong advantage of the Ada 95 Annex E distributed-programming approach: Scalability: The server software is able to be configured and run on anywhere from 1 to 5 Sun systems. Repartitioning the distributed server system does not require any changes to the software. It requires only a simple edit of the .cfg file and re-running of the partitioning tool. Of course, the ability to distribute the server over multiple machines affords corresponding performance gains with no Ada 95 source-code modifications. (Instant update of clients is one other benefit of Java bytecode and the Ada 95 Distributed Annex, but is not currently demonstrated at this time: If the demonstration application is updated from v1.0 to v.1.1, then all clients automatically run the latest version the next time they launch their Web browser.) Technologies used All new software written for the prototype was written in Ada 95. The server software was compiled with the GNU Ada Translator (GNAT v3.09) from Ada Core Technologies and the GNAT implementation of the Distributed Systems Annex (GLADE 1.01) for Sun Sparc running Solaris 2.5. The client software was compiled using Intermetrics AppletMagic compiler v1.38 for Macintosh. The client software makes extensive use of the standard Java toolkits and libraries via the Ada 95 bindings supplied with AppletMagic. Once the sensor server has been launched, one or more clients may connect to it. Both the HTML server (providing the Web page and the downloadable Java-bytecode client applet) and the Sensor Server application must be hosted on the same machine. This is due to a "limitation" of the security software that is part of the Java Virtual Machine. A Web-based applet (client) is allowed to open up a network connection only to the same host machine from which the applet was downloaded (that is, the HTML server). Looking ahead The technical success of this prototype opens up the possibility for further investigation of the areas in which these technologies may be applied. It demonstrates Ada 95's ability to provide these benefits to the DII.