1.0 Introduction 2

2.0 Maintaining System Interfaces 2

2.1 User Interface 2

2.2 FTP Interface 2

3.0 System Architecture 3

3.1 Illustrations of Major System Processes and Components 4

3.1.1 Login and Business Thread Instantiation Process 4

3.1.2 Logout Process 5

3.1.3 Application Database Access 5

3.1.4 Screen (Terminal) Input and Output 5

3.1.5 Client Synchronization and Screen I/O Message Formats 6

3.1.5.1 Client Synchronization Message 6

3.1.5.2 Screen Output Message 7

3.1.5.3 Screen Input Message 7

4.0 Figures 7

Figure 1: Existing EOSS Accountability System Interfaces & Data Flow 8

Figure 2: System Architecture 9

Figure 3: Login Process 10

Figure 4: Logout Process 11

Figure 5-A: Application Database Access – File Open Process 12

Figure 5-B: Application Database Access – File Write Process 13

Figure 5-C: Application Database Access—File Read Process 14

Figure 6: Screen Input / Output 15

1.0 Introduction

The purpose of this document is to describe how the TSRI modernization effort of the EOSS Accountability System will preserve the interfaces between the modernized EOSS Accountability System and any external systems with which it interfaces, as well as to describe the modernized system’s architecture.

Section 2.0 describes the method by which interfaces will be preserved, thus allowing interoperability of the modernized EOSS Accountability System and any external systems.

Section 3.0 describes the modernized system’s architecture. This architecture provides significant scalability benefits. Although the system resulting from this effort will be deployed on only two machines, the architecture supports further distribution to additional machines if required to meet future requirements. In order to reduce the technical risk associated with this architecture, TSRI has completed a mock-up of the architecture in house to validate the approach.

2.0 Maintaining System Interfaces

There are two types of system interfaces to preserve from the existing EOSS ACC system (Figure 1 in section 4.0). The first is the user interface, which is currently provided by user telnet sessions via remote terminals. The second type is FTP, transferring to and from various external systems.

2.1 The User Interface

User terminal interfaces are to be replaced by web browser connections. These browser connections can be made within a local area network, through a virtual private network (VPN), from external Internet sites using SSL, or combinations of these modes. Application behavior will remain the same regardless of chosen network security scheme. HTML forms presented by web server scripts provide screen I/O similar to the original telnet sessions. The new interface does not aim to provide the full capability of a telnet session outside of the EOSS application context, i.e. it does not provide the operating system shell capabilities of a telnet session. The user can’t create, modify, delete, run, or print arbitrary application or files as in a telnet session. All EOSS system components such as main executables (EAMAIN.EXE, FROMTO.EXE), COM scripts (RMMETA.COM), and text files (SGMLPODA.PRN) will be presented in a new master menu to the user’s web browser. This menu will also provide access to certain system text files (RMMETA.TXT). User access level, based upon the logon, determines the availability of different system components.

2.2 FTP Interface

FTP connections are currently used to transfer text files to and from EOSS. The modernized EOSS application will produce and read files required for the FTP interfaces in the same format as the current application. Thus the FTP interface will be preserved. Systems which currently use FTP to push files to EOSS will have to be changed to point to the new Sun Server hosting the modernized EOSS application. The modernized EOSS application will use a Java FTP library to push FTP files to the same destination as the current EOSS application

3.0 System Architecture

The TSRI proposed architecture for the new system is an N-Tier system designed for modularity and flexibility. Figure 2 shows the major system components correlated to the five different tiers specified in the SOW. Briefly, the existing EOSS system is transformed to the new design as follow:

· Original VAX-BASIC EOSS code is transformed into JAVA while preserving exact code functionality.

· User telnet sessions and terminal I/O are to be replaced by SSL web connections and html pages.

· The VAX flat file database system is to be replaced by an Oracle relational database accessed through a JDBC based API.

· Scheduled automated processes on the VAX system are to be replaced by UNIX system “cron” scheduled processes.

· FTP sessions to and from external sessions will work the same way as before, using a Java FTP library.

Components residing in tiers A through D below are planned to run on a Sun Solaris server and those in tier E are to be run on a Windows IIS server. Though this is the current plan, the nature of such an N-Tier system allows for different components to run on different computing platforms and at different physical locations. For example, each of the tiers A through D can exist on different computers. Application processes in tier C can also be distributed across multiple platforms. Such flexibility allows for future growth and re-organization without major modification to the system.

A. Data Tier:
This tier is implemented in the form of a single Oracle 8i (or Oracle 9i) database running on a Solaris based server. The database contains only EOSS Accountability system data (ACDATA). No business logic in the form of stored procedures, triggers, or any other Oracle programmatic interfaces is encoded in this database. The database will be implemented using standard data types and table formats so that it can be re-hosted to other database servers such as Oracle 9i or Microsoft SQL Server.

B. Data Access Tier:
This tier is the interface layer between the EOSS business logic code and the Data Tier (A). It is written in Sun J2SE Java using JDBC. Its function is to perform I/O operations on the ACDATA database in place of the original VAX flat file operations. Such layering isolates the business logic code from implementation details of the data storage.

C. Business Logic Tier:
This tier contains all EOSS Java code translated from VAX-BASIC and any scripts designed to replace other functionalities such as “cron” batch scripts and ftp scripts. Formerly separated processes (EAMAIN.EXE, FROMTO.EXE, RMMETA.COM…) will be grouped into a single Java application with logic to be invoked separately via a menu or command line option. These processes are invoked and managed by a master “broker”, enabling multiple simultaneous, multi-threaded execution instances. This tier interfaces with the Data Access Tier (A) and the Presentation Tier (D) through API’s isolating the business logic from screen I/O and database implementation details. All of this is written in Java.

D. Presentation Tier:
This tier encompasses all functionality related to generating the user interface. To accomplish this, it has a “Screen API” written in Java to setup and to manipulate screen I/O data. Screen I/O and process synchronization data are stored in another database in this tier. This database is different from the one in tier A, but will reside on the same physical machine and Oracle server, although it could reside on a different Oracle server to meet future scalability requirements. This database provides inter-process communication and synchronization between this tier and the Web Tier (E). Communication messages are stored as rows in a table with columns representing data fields such as process id, session id, message type, message status, date/time, and message data. Both tiers (D & E) maintain synchronization and data display continuity through this mechanism.

E. Web Tier:
This tier is an IIS web server running VB Scripts and providing SSL communication with end user browser sessions. It communicates with the Presentation Tier (D) using ADO. The user authentication process is slated to run on the web server in this tier, but it can be adapted to use the standard Navy portal for user authentication in the future.

3.1 Illustrations of Major System Processes and Components

3.1.1 Login and Business Logic Thread Instantiation Process (Figure 3)

Initially with all components of the system up and running, the main application “broker” in tier C waits for a user to begin a new session. The user begins a new session by opening a URL to the web server (tier E) and logging on successfully. After successful authentication, the web server tells the application broker that a new session has begun by entering a record into the message database in tier D. The application broker detects this new record and instantiates a new EOSS business logic thread based on the logon authentication level. This thread and the corresponding user browser session are correlated by unique session and process identification numbers, which are recorded in the message database record along with other state information. After the business thread is started, the application broker continues to scan for other new session requests. It cleans up the EOSS business logic thread when there’s information in the message buffer saying it has been terminated.

3.1.2 Logout Process (Figure 4)

An application session can end in several ways. The first occurs when the business logic comes to an end and returns. The second occurs when the user terminates the browser session by either clicking a “logout” button or simply closing the web browser. The third occurs when the browser session has been idling for too long and the web server automatically terminates it. In any case, the appropriate client synchronization record in the presentation database is modified with a “TERMINATED” status. In the first case, the business logic and the application broker make the modification, whereas the web server makes the modification in the second and third case. The web browser and the application broker scan for this termination status and clean up the appropriate browser session and the business logic thread as required.

3.1.3 Application Database Access (Figures 5-A, 5-B, 5-C)
The VAX flat-file database implementation is replaced by a modern relational database system. The transformed EOSS business logic accesses this database through a Data Access API which uses JDBC and SQL to interface with the database.

During normal operation, the application logic might open an indexed file using a certain channel and perform I/O operations on it.

To open a new file, it calls an open_File() API function with the channel number, file name, file access mode, associated record buffer, etc. The data access API takes this information and creates a “File” object and associates it with a database table with the same name. Depending on the specified open mode and the existence of the database table, it can be created, appended, or truncated at this point. Other file behavior will also be replicated by the file object. Upon a successful “open”, the API uses a Java map language construct to associate the channel number to the file object so it can be referred to later by the channel number.

To write a record to a file, the application prepares the record buffer and invokes the file object .put() method to transfer data from the record buffer to a row in the database table. The opposite occurs when reading from a file using the .get() method. Other file operations such as delete and insert are handled similarly by other API methods using JDBC and SQL. Both sequential and indexed data files are stored in the database and treated in similar manners with the exception that some operations are not valid for one file type or the other.

3.1.4 Screen (Terminal) Input and Output (Figure 6)

The user interacts with the application using a secure web browser. Beside the initial login screen, EOSS application screens are presented as a succession of HTML forms which display text information and a maximum of one input field in an area 80 columns by 25 rows. Around this text area are other html graphics and buttons such as the EOSS logo, the logout button, and the “Help” button. The help button may be used to provide usage and contact information. There will also be a list of links to text files generated by the current user. For each user, these print files persist from one session to another until specifically deleted by the user. The user can download these files to his or her local machine for viewing or printing. This functionality replaces users ability to view, modify, and print files on the original VAX system.

During an interactive process, the application logic displays something on the screen by invoking the .io_Put() method of a screen API object; passing to it the text to be displayed and position information. The screen API collects these display messages and builds up a screen buffer. Once the application issues a “flush” command or requests a user input with the .io_get() method, the screen API completes the screen image in buffer and generates a corresponding HTML form. It then sends this output request to the web server by inserting an entry into the presentation database, with the HTML form as a data field. The web server(tier E) detects and reads this entry and sends the form data to the user web browser. It also deletes the output database entry after reading it.

If the previous screen ended with a request for input, once the user enters a value into the input field and submits the form, the web server sends the input data back to the application by adding a record to the presentation database with the input value in the data field. The screen API, which has been waiting for a user input, reads this database entry and copies the input value into the application variable associated with the original .io_Get() method. This cycle repeats until the application thread ends.

3.1.5 Client Synchronization and Screen I/O Message Formats
Communication messages between the Business Logic (tier C) and the Web Tier (tier E) are stored as records in the presentation database. They have the following fields:

Name	Type	Description
PROCESS_ID	NUMBER	Unique ID for each Business Logic Thread.
COLUMN_ID	NUMBER	Reserved – To be used for screen positioning if needed
ROW_ID	NUMBER	Reserved – To be used for screen positioning or multi-line data if needed
ENABLE	VARCHAR2 (2)	To enable or disable a message
SESSION_ID	VARCHAR2 (64)	Unique ID for each web browser session
STATUS	VARCHAR2 (16)	Message status
USAGE	VARCHAR2 (255)	Message type
DATA_NAME	VARCHAR2 (255)	Class name / method name of the producing agent
DATA_SET	VARCHAR2 (4000)	Message data
REQUEST_ID	NUMBER	Request ID from web browser for multiple requests
DAY_ID	VARCHAR2 (2)	Day of month session started.

3.1.5.1 Client Synchronization Message
This message is created when a user starts a new session. It gets removed after that session is terminated and cleaned up.

· PROCESS_ID: Starts out as blank, filled in by application broker after it instantiates a new thread.

· SESSION_ID: Filled in with unique session number by the web server process.

· STATUS:

o ”NEW” – When first created by web server process

o ”RUNNING” – Set by application thread broker after it started the thread

o ”TERMINATED” – Set by whichever process detected a termination condition.

· USAGE: “NEW-CLIENT”

3.1.5.2 Screen Output Message

This message is created by the screen API when the business logic wants to display something on the screen. The web server removes it after reading it.

PROCESS_ID: Set by screen API with unique process id for this thread
SESSION_ID: Set by screen API with unique session id given by web server
STATUS: “DONE”
USAGE: “OUTPUT-HTML”

3.1.5.2 User Input Message

This message is created by the web server process when there’s user input to be sent back to the business logic. The screen API removes this message after reading it.

PROCESS_ID: echo back
SESSION_ID: Set by web server with the same unique session number.
STATUS: “DONE”
USAGE: “INPUT-FROM-HTML”

4.0 Figures

See the following pages for the figures referenced throughout the previous sections of the document.

Architecture and Interface Design Document

Subcontract # 4400083940

Table of Contents

2.1 The User Interface

2.2 FTP Interface

3.1 Illustrations of Major System Processes and Components

Name

Type

Description

PROCESS_ID

NUMBER

Unique ID for each Business Logic Thread.

COLUMN_ID

NUMBER

Reserved – To be used for screen positioning if needed

ROW_ID

NUMBER

Reserved – To be used for screen positioning or multi-line data if needed

ENABLE

VARCHAR2 (2)

To enable or disable a message

SESSION_ID

VARCHAR2 (64)

Unique ID for each web browser session

STATUS

VARCHAR2 (16)

Message status

USAGE

VARCHAR2 (255)

Message type

DATA_NAME

VARCHAR2 (255)

Class name / method name of the producing agent

DATA_SET

VARCHAR2 (4000)

Message data

REQUEST_ID

NUMBER

Request ID from web browser for multiple requests

DAY_ID

VARCHAR2 (2)

Day of month session started.

· PROCESS_ID: Starts out as blank, filled in by application broker after it instantiates a new thread.

· SESSION_ID: Filled in with unique session number by the web server process.

· STATUS:

o ”NEW” – When first created by web server process

o ”RUNNING” – Set by application thread broker after it started the thread

o ”TERMINATED” – Set by whichever process detected a termination condition.

· USAGE: “NEW-CLIENT”