TABLE OF CONTENTS

   

LIST OF FIGURES

LIST OF TABLES

PREAMBLE

1.0  INTRODUCTION

2.0  THE IWSDB ARCHITECTURE AND KEY COMPONENTS

2.1  Overview

2.1.1  Heterogeneous Platforms
2.1.2  Client-Server Architecture
2.1.3  Communications




2.2  Local Site
2.3  Regional Repository


2.3.1  Distribution of Repositories
2.3.2  Repository Data Formats




2.4  Regional Control

2.4.1  Version Control
2.4.2  Directory Service
2.4.3  Security
2.4.4  Data Dictionary Service
2.4.5  Activity and Data Modeling
2.4.6  Project Control
2.4.7  Maintenance



2.5  Global Control

2.5.1  Directory Service
2.5.2  Data Replication and Version Control

2.5.2.1  Data Replication
2.5.2.2  Version Control


2.6  Three-Schema Architecture

3.0  OPERATION SCENARIOS

3.1  Data Creation
3.2  Data Retrieval


4.0  STANDARDS AND SYSTEM ENGINEERING ENVIRONMENTS

5.0  IMPLEMENTATION ISSUES

5.1  Migration to the CALS-Standard Repository
5.2  Federated Database System (FDBS)
5.3  Security
5.4  Scaling Issue
5.5  Implementing STEP in the IWSDB
5.6  Integrating Electronic Commerce/Electronic Data Interchange in the IWSDB

REFERENCES

      

Figure 2.2-1  The IWSDB Architecture ­ Local Site

Figure 2.3.2-1  Full Restriction

Figure 2.4-1  The IWSDB Architecture ­ Regional Control and Repository

Figure 2.5-1  The IWSDB Architecture

Figure 2.6-1  Three-Schema to the IWSDB Architecture Mapping

Figure 5.1-1  Migration Stages

Figure 5.1-2  Phased Approach

Figure 5.2-1  Five-Schema to the IWSDB Architecture Mapping

Figure 5.4-1  Global Control Enhancement

LIST OF TABLES

      

PREAMBLE

      

The chosen implementation strategy is based on a "client-server" architecture supported by Local and Wide Area Networks for a distributed strategy. All authorized levels of Government and industry would participate throughout the life-cycle of a single weapon system with the goal of creating data once and using it many times no matter where it resides.

This paper is considered to be a "Living Document" and will be periodically updated throughout the course of our project, and will serve as a key reference for the "CALS and Technical Data Rights" (Task 3), as well as the formulation of a CALS/IWSDB Business Case Model and Functional Requirements (Task 7 and 8). As time and resources permit, we will cover additional information topics. Topics such as our strategy for determining "High Cost Drivers" for our Business Case Model, Legacy Data Transition, as well as findings from performing the tasks will be reflected in future versions of this strategy paper. Also, as we continue our information exchange with the Joint CALS (JCALS) Project and other related programs, we will update our paper to be consistent, not just with ourselves, but with the full Department of Defense (DoD)/CALS community.

______________________

Robert S. Kidwell

Technical Director

OSD CALS Project

1.0  INTRODUCTION

      

Reaching consensus on the CALS database environment specifications is critical in order to progress into an era of shared data. This strategy paper is an effort to identify and characterize a scalable "create data once, and use it many times" IWSDB architecture. This architecture is capable of integrating the heterogeneous hardware and software systems to capture, store, and distribute engineering data much more efficiently. The proposed architecture is obviously not a unique solution to the CALS IWSDB; however, it is a feasible one. This paper is also an effort to provide a unified view for the OSD-CALS development groups so that all of the individual efforts will be directed toward the achievement of a single goal.

Finally, this strategy paper is considered to be a "Living Document" of year 2010 vision IWSDB and will be periodically updated throughout the course of our project. The proposed architecture and its component systems along with their relationships are presented in the next section. A series of information sharing scenarios are described in Section 3.0. The preliminary OSD/CALS Open Systems standards and specifications are summarized in Section 4.0. Several implementation issues regarding the migration approach and integration of legacy data, the Standard for The Exchange of Product Model (STEP) Data, and Electronic Commerce/Electronic Data Interchange (EC/EDI) are discussed in the last section.

2.0  THE IWSDB ARCHITECTURE AND KEY COMPONENTS

      

2.1  Overview

The IWSDB architecture sketched in Figure 2.1-1 utilizes a client-server approach, with the entire IWSDB distributed into multiple regional Repositories. One or more servers are running at each region, and an arbitrary number of clients is running on geographically distributed local sites. Each regional repository contains physical data as well as associated metadata (data about data). The repositories are supported by a set of tools that provides services, including:

• Database Management.
  
• Security.
  
• Directory Management.
  
• Data Dictionary Management.
  
• Version Control.
  
• Project Control.
  
• Data Modeling.
  
• Maintenance.
  

This data management tool (DMT) set is intended to support the CALS community in providing an integrated user support environment that includes a common and integrated set of software tools within an Open Systems Architecture (OSA).

2.1.1  Heterogeneous Platforms

One of the most important implementation issues associated with a practical IWSDB is the bridging and integration of heterogeneous platforms. Heterogeneity can include differences in computer hardware, operating systems, application products, vendors, and/or data formats among local, regional, and global control entities. In other words, in order to support heterogeneous platforms, not only the hardware and operating systems but also the various application products must all be integrated seamlessly. To overcome heterogeneity among local users and regional controls/repositories, OSA will be utilized. An OSA environment is capable of integrating different types of computer systems such that they can communicate through the use of common standards and protocols, such as the Government Open System Interconnection Profile (GOSIP) and Portable Operating Systems Interface (POSIX). The Open Systems Architecture not only provides for an integrated shared information environment, but also allows existing systems to be connected and accessible to the various users.

2.1.2  Client-Server Architecture

In a client-server computing environment, one or more clients running on heterogeneous platforms send queries or commands to the server(s). Each client translates one or more user queries or commands into one or more Structured Query Language (SQL) statements, sends them to the server, and presents the output returned by the server to the user. On receipt of a SQL query or command from the client, the server checks the syntax of the SQL statements and verifies the existence and access rights of the client. Then it executes the statement and returns resulting data, if any, to the client.

The two characteristics that distinguish a client from a dumb terminal connected to a host are:

A client forms one or more queries or commands in a predefined language (e.g., SQL) for presentation to the server. It uses caching and optimization techniques to reduce queries to the server and thus to reduce network traffic.

A client analyzes data (on the query or commands results sent from the server) and subsequently presents them to the user.

In other words, a client possesses intelligence and processing capability. Therefore, it does not consume as much of the precious server(s) CPU-cycle as a dumb terminal.

A server merely responds to the queries or commands from the clients. Thus, a server does not initiate a conversation with any client. It also hides the entire client-server system from the client and user. Each client, using SQL as the interface, can access any server which exposes SQL as the interface. Thus, a client application can be implemented in any language or environment. A client communicating with a server can be completely unaware of the server platform, as well as the technology employed for communication. Therefore, a client-server architecture is essential to the bridging and integration of heterogeneous platforms.

2.1.3  Communications

The IWSDB architecture will be supported by the communications network infrastructure. This infrastructure will interconnect systems and sites to provide a seamless distributed data delivery service. The network will be composed of Local Area Networks (LANs) for intra­local-site communication and Wide Area Networks (WANs) for communications and data transfer among local sites and regional repositories. In addition, a designated high-speed, high­bandwidth communication network should be implemented to connect the global, regional controls, and regional repositories in order to enhance the overall system performance. Using LANs interconnected with one another through WANs and a designated network will provide a highly robust architecture for disseminating information. This robustness is achieved by allowing multiple pathways among local sites, regional controls/repositories, and the global control.

2.2  Local Site

Ideally, all the cooperative users would be connected to one of the regional repositories with extremely fast communication. All the users would interact with the repository as if they were at that location. In reality, it is too expensive and impractical for local sites to have such fast links. Therefore, access times are often too slow if every data sharing activity requires a file transfer from a regional repository to a user.

A feasible way to solve the performance problem is to introduce a local cache repository to each local site (shown in Figure 2.2-1). The local cache repository contains a portion of a regional repository's data objects that are used most frequently at the local site. The first access to a data object at a regional repository causes that data object to be retrieved from the regional repository. Subsequent accesses to the same data object on the same site are purely local. System performance can thus be improved.

The local caching of repository objects can lead to significant performance improvements in access times over a single shared repository. However, serious synchronization problems can arise if the cache objects of local sites do not accurately reflect modifications made by other sites. We must avoid wasted effort by users working on obsolete versions of data object. To alleviate this problem, each local site will provide a version control service that cooperates with the regional version control. A more detailed discussion of version control is presented in the following sections.

2.3  Regional Repository

The entire IWSDB discussed in this paper will consist of multiple regional repositories that can be physically or logically distributed across the architecture. Each regional repository will contain physical data and metadata (data about data) for the physical data. The advantage of the complete separation of the repositories from the supporting hardware/software systems is that new data and new data formats can be added to the repositories without redesigning the system. Conversely, new computer technology can be modularly implemented without reconstructing existing repositories. Furthermore, the separation of the repositories from the supporting hardware/software will also promote the reusability of data objects, data management tools, and testing tools.

2.3.1  Distribution of Repositories

In order to provide better information sharing, the architecture ideally will store all the shared information on a particular weapon system design in the same regional repository. This arrangement not only will improve the performance of the IWSDB because most of the activities will take place within a region, but also will make the weapon system easier to manage. This situation will be achieved because a shared data object will be brought into the regional repository from another one upon request. However, this distribution will introduce a problem if a regional repository becomes overfilled with data objects which are of no interest to anyone in the corresponding region. Therefore, periodical redistribution and removal of IWSDB data object will be required.

One way to deal with the need to redistribute and remove IWSDB data objects is to associate a reference count with each data object. An access to a data object will increase its reference count by one. The higher the count, the more accesses to the data object. After a certain period of time, a report can be generated from each region based on the reference count associated with each data object. A data object with a reference count lower than a predetermined value will be removed from this regional repository.

2.3.2  Repository Data Formats

The data objects stored in repositories will conform to the CALS-Standard defined in the MIL­STD-28000 series, including:

• Initial Graphics Exchange Specification (IGES).
  
• Standard Generalized Markup Language (SGML).
  
• Consultative Committee of International Telephone and Telegraphic (CCITT) Group4 Raster.
  
• Computer Graphics Metafile (CGM).

To create the year 2010 CAL-Standard data format repositories and to eliminate the inevitable distortion from conversion tools, a full restriction approach will be taken. The full restriction approach will require all end users to use only CALS-compliant product­generation tools as shown in Figure 2.3.2-1. This approach will imply that all data objects created by any user will be in CALS-Standard formats; thus, very limited or no conversion facilities will be required, and information sharing and exchange will be accomplished in a smoother manner.

2.4  Regional Control

The regional repositories are supported by a set of tools in the regional control (shown in Figure 2.4-1) that provides services, including database management, security, directory management, data dictionary management, version control, project control, data modeling, and maintenance. This DMT set is intended to support the CALS users in providing an integrated user support environment with a common and integrated set of software tools within the architecture. Each of the components is described below.

2.4.1  Version Control

As discussed in Section 2.2, to avoid wasted effort, the architecture will require a regional version control to accurately reflect modifications made by local sites. Version control will maintain lock information, perform version management, and assure consistency of local sites' cache repositories with automatic updates. If the data object is modified at one site, the updates are automatically propagated to the other sites and the regional repositories. Locks will allow the regional version control to insure that no two users of local sites will ever have modifiable copies of the same data object at the same time.

A regional version control will also provide other services, including:

• Notifying certain users when a particular data object has been modified.
  
• Retrieving past revisions of data objects.
  
• Retrieving locking information.
  
• Retrieving update history.

2.4.2  Directory Service

The directory service will be a collection of open systems which cooperate to hold a database of information about the data objects in the IWSDB. The directory is not intended to be a general­purpose database system, although it may be built on such systems, because it is assumed there will be a considerably higher frequency of queries than of updates to the directory information.

By facilitating communication between users of local sites and regional repositories, directory services will play an important role within the IWSDB architecture. The services will provide name-to-address conversion which will allow user requests to be routed in a network without the user having to specify the location of data objects. It will also assist in IWSDB network security by storing information such as data object classifications.

To improve performance and availability, this architecture will use a distributed approach of the directory service with replicated directory information in the global directory service. Consequently, mechanisms to ensure the consistency of duplicated directory entries will be provided. One directory service will be included in each regional control to support the processing of the IWSDB by authorized users. It will provide the services by looking up its directory that stores information on all the data objects within its corresponding repository. If a requested data object can be found in the regional repository where the user resides, data can be retrieved directly from the repository. However, when a user requested a data object that is not stored in a regional repository, the regional directory service will then cooperate with the global directory service which contains location information of all data objects in the IWSDB. Once the location of the data object has been obtained, a retrieval process can then proceed for the requested data object. Further discussion of the global directory service is presented in Section 2.5.1.

2.4.3  Security

Each local user will be assigned a unique user-id and password for system authentication. A user classification level will be determined based upon information such as background, ranking, and task requirement. Locally, a site administrator will maintain the security of data objects stored in the local cache repository. In addition, the data classification will be applied to local cache repositories to prevent unauthorized users from accessing classified data. For data processing at the regional level, the user's identification will be included in the message sent from the local site. A security check can therefore be executed based on such identification.

Two security implementation alternatives can be made to support this architecture. One is to use add-on security application products to carry out all necessary security checks. Another is to depend upon the security features provided by the underlying database management systems and the operating systems used. In either case, the database management systems, operating systems, or add-on products used must all be capable of providing a B1 level of trust.

Careful attention must also be given to communications security because users will be accessing the IWSDB through LANs, WAN, or the designated network. The transmission mechanisms used for data communications are vulnerable to intrusions such as altering or inserting messages or retransmitting invalid messages. These intrusions can be accomplished by physically connecting to a communication path. Vulnerabilities exist at switching centers and network interfaces. An approach that can be used to avoid intrusion problems is the end-to-end security method. It will provide uniform protection for a message all the way from its source to its destination. An advantage of end-to-end security over other common security methods is that an individual user or host can elect to employ these measures without affecting other users and hosts. Two encryption schemes that can be implemented to achieve end-to-end security are the conventional scheme and the public-key scheme. The conventional encryption scheme uses the same keys for enciphering and deciphering messages. The public-key encryption scheme, however, consists of a pair of keys, one secret and one public. In theory, both keys in the key pair can be used for enciphering, with the secret key being used to decipher if the public key was used, and the public key being used to decipher if the secret key was used. However, in practice, the latter method is appropriate. An advantage of this approach is that the public key can be freely distributed without concern for secrecy, thus providing a higher degree of security. Therefore, a public-key encryption scheme is highly recommended at both regional and Local controls.

2.4.4  Data Dictionary Service

Data dictionary services will support a repository of IWSDB information to provide for definition, structuring, access, and usage of data within the repository. The data dictionary services will provide a mechanism for populating the repository with new data. A means of populating the data dictionary with legacy data will also be provided.

A data dictionary used in the CALS IWSDB will be based on IDEF modeling, FIPS PUB 156 Information Resource Dictionary System (IRDS), and client-server architecture. The data dictionary will be dynamic in nature. That is, the data dictionary will be dynamically updated to always provide the freshest metadata possible throughout the run­time state. The different approaches for implementing a dynamic data dictionary are being explored. One approach fully utilizes the proposed client-server architecture and incorporates use of a protocol such as the Remote Procedure Call (RPC). Therein, a mapping from the global directory service will be created which identifies the locations of targeted databases, tables, and physical data within the regional repositories. Using this mapping to locate a targeted data object set, a user may utilize a protocol like RPC dynamically retrieve the schema of the database/tool at run­time (i.e., when the user queries the database). Another approach may be one wherein a fixed global schema is developed similar to the FIPS 156 Minimal Information Resource Dictionary (IRD) schema. All local systems must then comply with this schema. Thus, on query by a local system, the schema can be retrieved using an import/export command similar to the IRD import/export command. Still another approach utilizes a commercial-off-the-shelf (COTS) product providing a schema gateway to resolve queries to/from heterogeneous database schemata. This approach will take a DBMS schema and process it into an Entity-Relationship model. The modeled data dictionary schema and its functional dependencies would then be normalized. Then, a BCNF/3rd Normal Form schema will be generated to a different or the same database.

2.4.5  Activity and Data Modeling

OSD/CALS will use IDEF modeling methodologies as a standard means of producing business case models for achieving consistency across business activities within the Government and for achieving data sharing objectives. Data modeling services, incorporating IDEF-based modeling tools, will be incorporated in the architecture to support graphical characterization of business environments as per the FIPS PUB 184 standard. The IDEF graphical data modeling language, developed for relational data modeling, consists of IDEF0 and IDEF1X. IDEF0 functional modeling provides for structured representation of activities or processes within an environment or system. IDEF1X informational modeling, providing representation of data structures and semantics within an environment or system, supports the conceptualization of information systems through the use of entity-relationships. The value of IDEF modeling tools will be in business process improvement simulation and analysis.

The aim of the IDEF0 activity modeling technique is to support the specification of positive changes in business processes, as well as to support the discovery and documentation of data requirements from the business process improvement perspective. The IDEF1X information modeling technique supports the modeling of conceptual schemata which provide definition of information entities, relationships, and attributes. IDEF1X modeling may be used to automatically generate database design and data integrity controls.

2.4.6  Project Control

Project control services within the OSD/CALS architecture will support systems development and maintenance activities through access to and manipulation of repository data objects. Project control services include:

• Requirements analysis.
  
• Design.
  
• Automated code generation.
  
• Ada programming support.
  
• Testing.
  
• Application migration.
  
• Program/project management.
  
• Configuration management.
  
• Quality assurance.
  
• Documentation production.
  
• Presentation production.
  
• Requirements traceability.
  
• Re-engineering design and development impact analysis.

The project control service will provide Upper CASE tool services for requirements analysis and preliminary design. During requirements analysis, hardware, software, and interface requirements may be entered into the repository for shared project access, analysis, modification, and tracking. Project control CASE tool-based DMTs will provide for mapping of requirements to design components or functions in order to produce high level designs consisting of logic algorithms and/or logical database data structure definitions. This procedure will continue until a detailed design is attained. Report tools will facilitate analysis of project management and concurrent engineering efforts through production of reports on systems engineering design integrity, consistency, tracing, and validation. Code generation capability will be maintained in accordance with the need for consistency, system interoperability, compatibility, portability, and integration conformance. Test tools will also be provided for ensuring quality assurance of design and implemented products. Document generation features within the project control DMT will provide templates for the generation of technical documents representative of IWSDB engineering and development. These templates will adhere, as a minimum, to DoD documentation standards, which include DoD-STD-2167A (successor of Software Design and Development) for defense software development and DoD-STD-7935QA for information systems development. Project control-based graphical production tools will support MIL­STD­1840 interchangeable digital data constructs. Exchange of textual data and documents will conform to markup tag requirements, and computer-aided design CAD data interchange will conform to IGES, CGM, and CCITT Group4 raster file formats for compatibility in data exchange across the CALS theater of Government and industry components.

Through it all, project control will provide program management functions for planning, work breakdown controls, resource and cost estimating and tracking, controlling, measuring, and reporting of concurrent engineering efforts throughout the life-cycle of any project.

2.4.7  Maintenance

Maintenance services will support the administrative controls needed to assure that the CALS environment consistently supports access to the IWSDB. Maintenance services will provide system monitoring, backup, and reporting functions at regional and global control points within the architecture. Disastrous data loss potential will be examined for the CALS environment, and a contingency plan will be devised for recovering from the possibility of such a disaster. Plans will include guidance on policy and procedures for the recovery process and for the establishment of intra-regional communications required during the recovery process. Anticipated maintenance functions include the following:

System Operations and Support Functions

These functions will support all functional area user and system activities. They will provide the foundation for all system operations, applications, database access, communications, and security. They will also provide a central facility for user support, system monitoring, maintenance, and troubleshooting for the CALS system. Operational and technical support, hardware and support application configuration management, and IWSDB backup support will be managed 24 hours per day, 7 days per week.

System Monitoring Function

This function will collect performance and maintenance information on each site in the CALS system. Performance problems and component failures can be identified and corrective actions taken by using tools within this maintenance function. Internal accounting status on DMTs and their users, as well as necessary telecommunication status, will be monitored throughout the CALS IWSDB system.

Incident Reporting and Tracking Functions

These functions will provide an on-line reporting and tracking capability for problems across the CALS system. Errors and deficiencies with hardware, software, and documentation will be reported through an automated problem report system. Problem reports will be logged by configuration management and sent to the appropriate personnel for analysis. On-demand and periodic reports will be available via this service.

Backup Support Function

This function will be the primary backup of the IWSDB data. When a site is fielded and the database is loaded at the site, a copy of the database is backed up and the data directory service updated as to content and location. During normal operations, the regional control system will automatically apply all IWSDB update transactions. Data will be backed up in real-time at each regional control site. Maintenance servicing is intended to provide for backup of the entire repository across all regional controls. The backup policy will be enforced as a minimum policy at all local sites, as well as the regional sites for full and incremental archival. Maintenance functions will provide for the intra-sites communication of requests across regional controls for initiation of retrieval of archived data at a local site. There is potential for development and integration of knowledge-based system backup automation for startup, auditing, and maintenance. Knowledge-based system operations may be incorporated in the automated decision making process which determines existence of low-usage data within the IWSDB repository. The architecture is intended to provide for archival of low-usage data to off-line storage where warranted. Consideration for database roll-back and roll-forward capabilities will also be offered via maintenance services. The maintenance service will also facilitate reporting of backup and archival versions.

A contingency plan shall be generated to assure that maintenance services prepare for, guide, and assist in implementing a data disaster recovery process. The level of criticality of regional data must be determinable. Recovery will then be enforceable in the order of data criticality. Backup capabilities will be implemented to facilitate data loss disaster without interrupting ongoing system operation at any regional site. Backup procedures and policy will provide for maintenance of IWSDB in such a way that security or integrity of off-line data is never compromisable.

2.5  Global Control

Finally, a global control that can be distributed or centralized for managing the regional repositories, handling data requests across the regions, and monitoring the overall system performance is incorporated to complete the system. The complete diagram of the architecture is illustrated on Figure 2.5-1.

2.5.1  Directory Service

As discussed in Section 2.4.4, each regional directory will contain information only about its repository. In the IWSDB architecture, a global directory service containing location information of all data objects in the IWSDB is introduced. Therefore, even though a regional directory service may not know exactly where a particular data object resides, it can always communicate with or pass the request on to the global directory service to carry out the user request. The combination of regional and global directory services not only will free the users from having to know the location of the data objects, but also will provide the users with more efficient access.

Moreover, when dealing with data replication in several repositories, the global directory service will provide functions to choose the best location from which to retrieve data object in order to maintain overall request performance. The determination of location will be based on information such as availabilities of those regional repositories and the relative communication impacts for accessing a particular regional repository. This information can also be used for early determination of whether a user request can be completed successfully.

2.5.2  Data Replication and Version Control

2.5.2.1  Data Replication

Replication of data objects in more than one regional repository can be used to improve the service by:

• Improving the performance of data access by moving data objects "closer" to particular users and;

• Improving the availability of data objects by the redundant copies so that an individual component system failure does not prevent all accesses to a data object.

However, data replication always creates a data consistency problem and complicates locking and updating procedures. The more replicated data objects, the higher the overhead. Therefore, it is recommended to establish two thresholds: high water mark and low water mark. When the number of replicated copies of a data object is greater than the high water mark, it will be decreased to the low water mark by removing some of the copies. The selection of copies to be removed will be based on the copies' respective reference counts.

The trade-off between preserving and disallowing replicated copies within the IWSDB will be carefully examined. Also, if it is allowed, the replication will be applied to read-only data objects or all data objects will be further researched. The thresholds will be monitored and adjusted constantly in order to achieve better system performance.

2.5.2.2  Version Control

The primary function of this section is to describe and discuss alternative methods of version control if the data replication approach is taken. The decision as to which of the alternatives is most appropriate (in terms of performance) should be determined by examining the network topology, supporting hardware, and data object access patterns.

The Centralized Approach

An additional Global Version Control (GVC) will be added to the global control to cooperate with regional version controls. When a data object is checked in or out, the GVC will perform the necessary lock and version management and will propagate these activities to other regions where the same data object resides. For example, if regional repositories A, B, and C all have a replicated modifiable copy, before a user from region A can check out the data object, a locking message will be sent from regional control A to the global version control. Two scenarios can happen:

1. If the data object has not been locked, the global version control then place a lock on the data object. Subsequent access to the same data object will be regarded as an access to a locked data object.
   

2. If the data object has been locked, the access will then be regarded as an access to a locked data object, and will be granted only a symbolic-link to the data object.

The main advantage of the centralized approach is the ease of implementation. It will also reduce the number of messages passed within the architecture and relieves the regional version controls of the responsibility for locking data objects. However, the global control may become a performance bottleneck if there will be a substantial number of replicated data objects within the IWSDB.

The Distributed Approach

This approach will not include the GVC to perform lock and version management but will rely on communications among regional version controls. When a regional version control receives a request to check out a replicated data object, it must check to determine whether one of the other copies has been locked by another regional version control. Synchronization among the regional version controls is critical to ensure that the same data object cannot be locked by two different users.

This approach will require each regional version control to know all the location information of replicated data. Therefore, the location's information will be included in each regional directory. Consequently, addition or removal of a copy from a regional repository will require the updating of all other regions that also have a copy. System performance may be degraded if a great portion of system usage and network capacity will be devoted to version control.

2.6  Three-Schema Architecture

The American National Standards Institute's Standards Planning and Requirements Committee (ANSI/SPARC) Three-Schema architecture can be mapped to the IWSDB architecture. At the local and regional repositories within the IWSDB architecture, a conceptual schema stores the database structures as described by a data definition language for the selected CALS database. The internal schema stores the physical characteristics of the logical data structures in the conceptual schema, such as data address information and storage methods. The external schema is the user or application view of the conceptual schema. Figure 2.6-1 presents a preliminary mapping of the Three-Schema database distribution approach to the IWSDB architecture.

3.0  OPERATION SCENARIOS

      

3.1  Data Creation

If a local user wishes to store a newly created data object into the IWSDB, the user will be allowed to do so only if the data object is determined to be valuable to other users, either regionally or globally. This decision will be made according to established criteria or matrices. A data object can then be stored in a regional repository followed by a sequence of corresponding updates. These updates will include the insertion in the regional directory and data dictionary of a new entry representing the new data object. This new entry will contain metadata about the new data object, including the object's location and its classified level. Updates will conclude with the cross-system dissemination of general information about the data object and its creation. When the update process is complete, users can share the new data object.

3.2  Data Retrieval

There are several possible scenarios when a user requests a data object for modification.

Scenario 1:  The requested data object exists in the user's local cache repository.

Scenario 2:  The requested data object does not exist in the user's local cache repository, but exists in the corresponding regional repository.

Scenario 3:  The requested data object does not exist in either the local cache repository or the corresponding regional repository, but exists in other regional repositories.

Scenario 4:  The requested data object does not exist in the IWSDB.

Scenario 1

In this simplest case, the requested data object is found in the local site's local cache repository. A modifiable copy of the data object can then be obtained directly from the local cache repository. However, before the data object is checked out by the user, a message should be sent to the regional version control placing a lock on the data object to prevent other users from obtaining another modifiable copy of the same data object. In other words, other users can now obtain only read-only copies through a symbolic-link to the data object until it is checked back in. If this data object is a unique copy within the entire IWSDB, no further action is required. Otherwise, additional version management for those replicated data objects will be performed by using one of the two approaches described in Sections 2.5.2.1 and 2.5.2.2.

Scenario 2

After first checking into the local cache repository and finding the requested data object does not exist, a data retrieval message will then be sent to regional control from the local site. The requested data object is determined to be stored in the regional repository by looking up its location in the regional directory. A proper data object retrieval can then proceed following a similar locking activity as described above if the object is not already locked. Otherwise, a symbolic-link will then be established for read-only access.

Scenario 3

In this scenario, a data retrieval message will be passed to the global directory service from regional directory service indicating the absence of the requested data object from the corresponding repository. Afterwards, the location(s) of the data object can be obtained from the global directory service followed by a data retrieval process. In the case of multiple replications within the IWSDB, an evaluation would be performed to determine the most suitable from which to retrieve the data object. A lock should be placed on the data object by either one of the two approaches. The centralized approach has an advantage over the distributed one because the locking message can be issued directly from the global version control. In the distributed approach, the regional version control has to obtain location information on those regional repositories first from the global directory service or regional directory. Then the locking message can be sent from the regional version control to the regions.

Scenario 4

After all the attempts to locate the requested data object as described above, the global directory service may eventually decide that the data object does not exist in the IWSDB. Consequently, a message will be sent to the originating user, indicating the absence of the data object.

A user will not be granted a physical data object under certain circumstances, including:

If a user requests a modifiable data object that has been locked by another user;

If a user has read-only access to a particular data object; or

If any data rights issue arises.

A user will then be given only a symbolic link that points to the data object stored either in local cache repository or in any regional repository. Because a user is given a symbolic link to a data object rather than a physical copy of the object, no data transfer is required. Thus, the system performance is improved. Also, version management and lock activity will not be necessary because no data object will be modified.

4.0  STANDARDS AND SYSTEM ENGINEERING ENVIRONMENTS

      

To be consistent and fully compatible with current DoD architecture practice, Table 4.0-1 highlights Open System standards. Note that standards and specifications continue to emerge and that CALS will adhere only to standards approved by the government.

5.0  IMPLEMENTATION ISSUES

      

5.1  Migration to the CALS-Standard Repository

The full restriction approach described in Section 2.3.2 will be targeted as a goal for the year 2010. However, before the target vision will be accomplished, a phased approach will be taken based on the considerations of user acceptance, reality, and functionality. The stages in this phased approach are categorized by the restriction level imposed on the product-generation tools used by the users.

Non-CALS-Standard Repository

A Non-CALS-Standard repository shown in Figure 5.1-1(a) will provide users with the greatest ease of importing data objects into repositories because the objects can be stored directly in repositories regardless of the original data formats. It will also provide users the flexibility of using any product-generation tools. Unfortunately, the success of this approach will rely on the quality of the conversion facilities required. It will also limit the potential of standardization.

No Restriction

In this case, the local users can choose any product-generation tool(s) without restriction. Conversion and format testing facilities will then be required to convert data from a particular user data format to the desired CALS-Standard format before the data can be stored in a repository. Conversely, another conversion will be required to convert from CALS-Standard data format to a user accessible data format (if the user does not use CALS-compliant tools). This scenario is illustrated in Figure 5.1-1(b). Distortion introduced by the conversion process is inevitable. An Artificial Intelligence (AI) enhancement process or pattern recognition technique may be utilized during the conversion process to guarantee that all the important information of the original data has been preserved in the converted copy, even though these two copies may not be identical. This AI or pattern recognition technique can also be applied to the testing process.

Limited Restriction

The third approach is shown in Figure 5.1-1(c). In addition to end users selecting CALS compliant product-generation tools, a limited number of Non-CALS compliant product­generation tools will be recommended. Recommendation of these tools will be based on certain established criteria (presented in "Tools Assessment Report" by Task 2). In this approach, only a limited number of conversion facilities will be required. This approach will provide users with a certain degree of freedom in terms of tool selection. On the other hand, it will reduce the conversions required (as in the no restriction approach).

The phased approach is illustrated in Figure 5.1-2. It emphasizes the partnership between government and industry that is a major objective. Initially, government contracts will invoke "incremental compliance" with CALS-Standard in accordance with CALS and services policies. For each contract over a threshold, there will be a defined schedule that will establish an increasing level of CALS compliance during a contract period of performance. The defined schedule and milestones will be used to assess progress and track performance toward achieving the Full Restriction CALS-Standard IWSDB.

5.2  Federated Database System (FDBS)

An FDBS is a collection of cooperating but autonomous component database systems that can differ in such aspects as data models, query languages, and database management system (DBMS). A FDBS represents a compromise between no integration, in which users must explicitly interface with multiple autonomous databases, and total integration, in which the autonomy of each component DBMS is sacrificed. The utilization of a FDBS will allow partial and controlled sharing of data without affecting existing applications and hence preserving significant investment in existing application software. Therefore, it is well-suited to the phased approach to the migration of a set of distributed, heterogeneous, and autonomous databases to IWSDB.

Traditionally, two approaches have been used for developing a FDBS. The first approach uses an extended language to retrieve information from a collection of databases. This is also referred to as a loosely coupled federated system. The second approach is to have a tightly coupled federation in which a globally unified view of all databases in the federation is provided by generating a global and unified schema in which structural, semantic, and other types of heterogeneities have been resolved. One approach to a possible tightly coupled federation utilizing Five-Schema is summarized below.

In order to integrate these existing distributed, heterogeneous, and autonomous databases, two additional levels of schemata are added to the traditional ANSI/SPARC Three-Schema architecture. These two added levels are the regional export schema and the federated schema. They are added in the following manner:

Regional Internal Schema

A regional internal schema or physical view depicts a particular implementation structure and formats for data in a regional repository. It consists of the definitions of information as it is actually stored.

Regional Conceptual Schema

A regional conceptual schema is derived by translating the conceptual schema of a regional DBMS into a Common Data Model (CDM) of the IWSDB. The CDM uses a single data model to represent all of the conceptual schemata of regional DBMSs and to establish data semantics. This translation is not necessary for a regional DBMS schema that is already specified using the CDM. The heterogeneity of the different component DBMSs and data models can then be supported by using the regional conceptual schema.

Regional Export Schema

A regional export schema represents a subset of a regional conceptual schema and provides access control information regarding its use by authorized IWSDB users. Multiple regional export schemata can be created from a single regional conceptual schema and can be used as hooks to other regions or to local sites. If all of the data in a regional database can be accessed by any user, then this level of schema declaration can be eliminated. Regional export schemata will be of the same data model as the regional conceptual schema. Therefore, all regional export schemata will be of the same data model throughout the IWSDB.

Federated Schema

A federated schema is an integration of all the IWSDB regional export schemata. It also includes data distribution information that is generated when integrating regional export schemata. It also will be of the same data model as the regional conceptual schemata and the regional export schemata. Therefore, by using a federated schema, the distributed IWSDB regional sites can be integrated seamlessly.

External Schema

A external schema is a user's view of the IWSDB. It consists of definitions of data as a particular user, application, or user organization understands them. This includes data formats and application screen layouts.

The Five-Schema architecture introduces redundancy between schemata (regional export schema and regional conceptual schema) that should be minimized during implementation. It might also create a potential bottleneck from the extensive accessing to the federated schema. In order to improve performance, the federated schema or subsets of the federated schema can be distributed to the region or local sites along with data distribution information. Figure 5.2-1 presents a preliminary mapping of the Five-Schema approach (one incorporates a distributed federated schema) to the proposed IWSDB architecture.

5.3  Security

Accurate identification is a prerequisite for security. A user's identity will be verified by checking the user's account and password. The password is the most widely used authentication technique. It is not unusual for users to write down their passwords in exposed places or to divulge them to others. Therefore, user passwords should be changed periodically. An individual can use a method called spoofing to learn a user's password. Spoofing is a method that generates a display exactly like the system's sign-on in a time-sharing system. Additional technology that would recognize some physical characteristics of the user such as the user's voice, fingerprint, or signature should be considered to provide protection from spoofers trying to access classified information.

Security products used at the regional controls and local sites must be able to provide efficient, multilevel secure systems which meet the B1 level of trust. To achieve B1 level of trust, several criteria which must be satisfied are listed below.

Existence of a Discretionary Access Control (DAC)

The DAC will dictate who has the privilege to access data objects within the IWSDB.

Existence of a Mandatory Access Control (MAC)

Sensitivity labels associated with each subject will be maintained. These labels will be used as the basis for MAC. The MAC will assign different permission levels for different data objects within the IWSDB. It will place constraints on a user's access to information on the basis of both the individual's clearance and authorization, and the classification designation of the information. In general, a user will not be allowed to read an object that has a higher security level than the user's security level; a user will not be allowed to write an object to a security level lower than user's security level.

Existence of an Audit Control Mechanism

It will be necessary to keep a system log or audit trail that contains information such as the user's identity, the transaction or job identifier, the name of the object being accessed, the type of access, the data values actually read or written, the date, the time, and how many times a client or server has been accessed over a day, a week, or a month. This log or trail can be utilized to deter and detect unauthorized users.

Existence of an Object Reuse Mechanism

This process clears the random access memory (RAM) or the hard disk of sensitive material after it has been used, and before anyone else can use it.

Existence of an Auto-locking Procedure

An auto-locking procedure will automatically log out users who have left their workstations unattended for a pre-determined period of time. This feature will prevent an unauthorized individual from easily accessing classified information through a workstation left unattended after log-in.

Existence of a Timing Constraint Feature

An additional level of security can be provided by restricting access privileges of users to normal business hours.

Existence of a Virus Protection Scheme

Data integrity checks and virus detection will also be used to provide optimal security.
 

5.4  Scaling Issue

The system performance will be determined primarily by the amount of time spent on responding to the users and on transferring data objects. As the size of the files, the number of regional repositories, and the number of local users increase, this will become even more of a factor. To prevent the global control from becoming a performance bottleneck and to meet the future increasing demand of IWSDB, regional repositories can be further gathered to form different domains mainly according to their supporting functionality: accounting, design, manufacturing and maintenance, administrative and procurement, and logistics/product support, as illustrated in Figure 5.4-1. The workload of the global control will then be distributed into different servers, and each functional domain will be supported by a server that shares the global directory with the other servers.

The major advantage of this domain-based repositories gathering approach is that a data object in a particular domain will probably not be used frequently in other domains. Therefore, a version server can mainly handle and control operations within its own domain. It will also ease the management of repositories within a domain due to their similarities. In the case of exceptional usage of a data object in another domain, data sharing can proceed as usual. That is, data can be transferred between repositories. However, whether to keep the data object in the domain requires further evaluation.

5.5  Implementing STEP in the IWSDB

As an emergent standard, Standard for The Exchange of Product Model (STEP) Data will become increasingly prevalent as a component of any weapon system database. This standard is being designed to give a complete computer-interpretable representation of manufacturing data during a product's complete life-cycle. STEP will eventually be able to express all the information relevant to the entire life-cycle of all products. This will enable the various systems utilizing an IWSDB to be able to receive and supply data about any product, intact with interrelationships, and retaining data completeness and functionality. In a sense, STEP parallels the development of the IWSDB itself and is thus a cornerstone of the CALS program. Once a Product Data Exchange Standard has been established, it is assumed that its use is intended to be mandatory for weapons procurement. In February 1993, the International Organization for Standardization (ISO) Technical Committee 184/Subcommittee 4 (TC184/SC4) registered STEP as a draft international standard (ISO 10303) and is expected to approve STEP as an official international standard sometime in 1994. Therefore, it will become a military procurement reality in the very near future.

One major stumbling block in the implementation of STEP as an integral entity within an IWSDB will be the conversion or inclusion of legacy data. Many CAD and CAE systems use various data standards to convey various types of product data. One of the most prevalent standards to emerge in the last decade is IGES which was developed as a neutral data format for the exchange of graphical data between CAD systems. It was not and still is not intended for the capture of product life-cycle information. In the long term, STEP will replace (or better yet, absorb) IGES. For many users, by extension of the IWSDB, IGES will suffice as a data model. In response to this need, industry is beginning to develop IGES-to-STEP translators. Other Product Data Exchange Standards, specifically IPC-350-D, EDIF (Electronic Design Interchange Format) and VHDL (VHSIC Hardware Description Language), which are used to convey data representing electronic/electrical devices, have been targeted for harmonization with STEP. It must be noted that for simple data models, STEP should be considered overkill. An example that highlights this is as follows: A coffee cup manufacturer wishes to place photocopies of faces upon its product. The most prevalent format for this data would be of a raster type. A raster to STEP translation is one possible solution for inclusion of this in a complete product model. However, the most efficient means to convey this data would be to incorporate the raster data within a STEP framework. With this in mind, TC184/SC4 is considering providing "hooks" through which more primitive types of data can be harmonized with STEP, thus eliminating the need to translate a large portion of legacy data that will make up a large portion of an IWSDB. This will become increasingly important as older weapon systems are retrofitted to incorporate the IWSDB concept. By necessity, the amount of translation performed on legacy data needs to be minimized. This reduction is critical, not only because of the cost and time involved in translation, but also because the inherent error due to these translations has to be kept at an absolute minimum.

It is in this context that STEP will possibly emerge as the dominant data exchange standard. STEP is intended to replace outdated standards in some cases and absorb or encompass others. As stated previously, the development of an IWSDB will parallel the establishment and emergence of STEP as an accepted data exchange standard. Therefore, a migration path to enable technology insertion of STEP technologies and its repository data to the CALS IWSDB will be established.

5.6  Integrating Electronic Commerce/Electronic Data Interchange in the IWSDB

(TBD)

REFERENCES

      

R. S. Kidwell, J. P. Brazy, and P. D. Garnett, et al, "Database Concept Paper," CALS Information Technology Group Database Subcommittee, September 1990.

R. Sriram, B. K. Livezey, and W. A. Perkins, "A Distributed Shared Database System for Concurrent Engineering," Lockheed Artificial Intelligence Center, Palo Alto, CA.