Geoffrey Fox, Marek Podgorny

NPAC Syracuse University

So we have tried to analyze the various XII electronic mail messages to clarify what is critical for May demonstration and what is relation between the so-called East and West coast efforts. We have come up with a particular integration strategy and overall architecture/approach. We believe that our analysis disagrees in several critical ways with both the system architecture and current implementation approach described in charter document. We have derived a plan for (our part) of East Coast approach but this

1. Requires a significant change in the West coast effort as we understand it.
2. Requires itself a better description of exactly what form the demonstration will take in May.

We give more details below but our differences with current approach come from

1. Observing that Tango is a communication and software integration system and using it and standard Web data dissemination and communication services seemingly obviates need for some of work described in charter document.
2. Our experience from building a command and control prototype and study of field at NRC workshop that the data model for Crisis management is very different from that of business enterprise systems (which seem to underlie current charter document). Thus we suggest that integration should not be done at the database level but rather at a higher level with information resources preserved as an underlying set of Web documents and (web-linked) databases. Such a loose knit federation of information resources underlies the Web today.

So we all agree that we have clients and backend services where latter is largely databases for resource information including maps and messages generated dynamically. In the above diagram, we draw a classic 3 tier architecture with various servers acting as interface to the backend tier data. Now there are many military and a few civilian implementations of such systems and XII is designed, in some not totally agreed way, to improve the situation. The clients are to collaborate in tackling crisis and this collaboration involves synchronous (real time interactive) technologies like Tango and the implicit and powerful asynchronous collaboration implied by access to the common backend data. Electronic mail and threaded mail based discussion systems are a well-known and quite successful asynchronous collaboration tools. Now in a perfect world all clients can both access all data and link information from different databases in a common view. There are two extreme approaches to this:

1. Map all data into same "database" (data model) and then use existing client interfaces to view this merged database.
2. Build a common client that can view the different backends, which are not merged at the data-model level but are merged in the view-format level (by using HTML VRML and Web multimedia standards if client is Web based).

Roughly the East coast focuses on 2) and the West coast on 1). Now 1) has the advantage of preserving existing interfaces that presumably reflect substantial experience in tackling crises or command and control activities. It would perhaps be natural in a business enterprise system, to merge data models but the situation is not so clear with XII. This by definition appears to need to access a wide variety of rapidly changing data sources with such a range of ownership and security level that a uniform data model is hard. In fact surely the web itself is as critical source of information for crisis management as traditional databases. We know that one does not map the web to a single data model but rather searches it with agents (as we have done for DoD for chemistry and other application specific resources) and then stores this dynamic data if needed in a database.

Thus the approach 2) is as follows

• For all or just critical parts of data, export a uniform interface at the middle tier. In some future object web this could involve CORBA but today a simple web model seems the most expeditious approach. Note that systems like Lotus Notes support JDBC and so one can build JDBC (Java Data Base Connectivity) web interfaces to Lotus Notes and similarly EIS offers a Web interface to some of their data.
• Data fusion is achieved by mapping different databases to a common web form and if necessary building special data manipulation services which can be accessed as a distributed resource.
• As we can’t do this for everything by May, where necessary use existing stovepipe systems

It is essential to note that 1) and 2) are not different parts of the same project but different approaches and for 2) to be successful, the West coast activities need to be redirected as described to providing Web interfaces for all relevant databases.

So given a set of Web (to become CORBA) entities at the middle tier, the East coast near term tasks are aimed at building a prototype client using conventional Web browsers combined with Tango to allow collaborative synchronous planning. Note Tango was originally built as the software and communication integration platform for our Rome laboratory project which was designed to show that Web technologies can be used to build command and control systems. Integration in this approach occurs at the user (client) and middle (exposing data with a common interface) tiers and backends are left unchanged.

Note in this analysis one could view the goal of West coast effort as producing the common (say JDBC) middle tier view of all relevant databases. We do not know if Shepperd agrees that this is correct way to link East and West coast efforts for it appears to be different from plan as we understand it from charter document. The goal of East coast is to provide the common (COP compliant) client display of these common middle-tier resources.

We remain unclear about one issue in any approach. Namely to be interesting, any demonstration needs both predefined data (such as maps of crisis area) and also a set of dynamic data describing crisis. If this dynamic data is to be largely generated by real people at consoles, then

• There needs to be quite a few such people and
• They need to be very familiar with crisis scenario to make interesting consistent decisions. Thus these individuals need to start practicing on final system with final scenario as soon as possible.

In work we did for Rome, we generated non-trivial activity using computers (which can make a slew of messages faster than people) but this required a detailed simulation engine and corresponding scenario with built-in messages.