11 JUNE 1999

Version 2.0

Prepared by

DII COE AOG Data Access Services Technical Working Group (DATATWG)

Semi-Structured Data and Metadata Sub-panel (SSD-MD)

Jim Pipher & Jim Schoening, Co-Chairs

Prepared For

Defense Information System Agency (DISA)

DRAFT

TABLE OF CONTENTS

1. SCOPE
1. IDENTIFICATION OF FUNCTIONAL AREA

This Software Requirements Specification (SRS) establishes the functional, performance, and verification requirements for the XML Services (XS) functional area of the Defense Information Infrastructure (DII) Common Operating Environment (COE). The XS functional area includes Registration of terms (tags and structures), Design of XML schemas, Generation and Consumption of XML documents.

 

2. FUNCTIONAL AREA OVERVIEW

XML Services provide infrastructure services for mission and support applications using XML technology. These services isolate vendor-unique implementations of data access and provide applications a means of avoiding dependencies on physical access models. These services also provide data management functions for access to distributed (local and remote) database management systems as one of the solutions for interoperablity.

 

3. DOCUMENT OVERVIEW

This document outlines the software capabilities required for the XS components for the DII COE. Section 2 lists the documents that are applicable to this specification. Section 3 provides a list of functional capabilities. Section 4 identifies the qualification requirements. Section 5 outlines the requirements and verification traceability matrix. Section 6 contains the applicable notes associated with the XS component.

2. APPLICABLE DOCUMENTS
1. GOVERNMENT DOCUMENTS

SPECIFICATIONS:

 

Defense Information Infrastructure (DII), Shared Data Environment (SHADE), CAPSTONE DOCUMENT Version 1.0, 11 July 1996

 

ACCS-A1-100-006 System Specification for ATCCS, 22 March 1995

ATCCS-A1-302-001A Army Tactical Command and Control System Common ATCCS Support Software (CASS) Systems/Segment Specification

CDRL A142 AWIS Software Requirements Specification (ASRD), July 1992

CDRL ML03 AWIS Systems Management Manual (SMM), 31 Oct. 1994

AWIS Support Software Design Document, December 1994

D18664A Standard Theater Army Command and Control System (STACCS) System Design Document Version 1.1/As Built, 1 Oct. 93

AAN-SDA001A Standard Theater Army Command and Control System (STACCS) System Specification, Version 1.1/As Built, 1 Oct. 93

Standard Theater Army Command and Control System (STACCS) System Software Programmers Manual, Draft.

 

Global Command and Control System (GCCS) Integration Standard, Version 1.0, October 1994.

Global Command and Control System (GCCS) Common Operating Environment Baseline, DISA, 28 November1994.

User Interface Specifications for Global Command and Control System (GCCS), Version 1.0, October 1994.

Draft Architectural Design Document for the Global Command and Control System (GCCS) Common Operating Environment (COE), Version 3, 24 July, 1994.

 

STANDARDS:

MIL-STD-498 Military Standard - Software Development and Documentation,

DOD, Dec. 1994.

FIPS PUB 127-2 Database Language SQL - Federal Information Processing Standards Publication 127-2, 2 June, 1993.

MIL-STD-6040 Military Standard –

ISO/IEC 9070 Formal Public Identifier

 

2. NON-GOVERNMENT DOCUMENTS

Petrucci, Steve, "Cross-Platform Power Tools, Application Developers for the Macintosh, Windows, and Windows NT", Random House Electronic Publishing, 1993.

Donald Lewine,"POSIX Programmer's Guide", O'Reilly & Associates, Inc. 1991.

W3C Working Draft "Namespaces in XML"

4. REQUIREMENTS
1. REQUIRED STATES AND MODES

 

1. Environmental Mode: This is the real-time operations that must react to varying degrees of readiness to full scale wartime operations such as crisis planning with the use of heterogeneous data types and sources, transfer capabilities, data management services.
2. COE Compliance. XML Services shall be segmented. COE sponsors shall adhere to compliance level requirements described in the I&RTS.
3. In the fixed (static) mode of operation (base or data processing megacenter), the data management services shall have the capability of being tuned by on-site personnel to adjust for varying workloads and sizes of associated databases. These workloads and databases are expected to change more frequently and to a greater extent than for processing associated with deployed units
4. In a changing (dynamic) environment, such as with deployed units, the workload and database sizes may be more predetermined (given a more precise mission) and require access to fewer data management administrative capabilities than needed in a fixed environment. The XS shall have the ability to redefine or reset names of connect descriptors to database server instances. Connect descriptors are fully qualified object names and include address (protocol/host/port) and instance name.
5. In a degraded communications environment, there is a need, for example, to be able to reset session time-out values if the data management services are being accessed by users affected by the communications degradation. At a minimum, the session time-out values shall be user definable and be able to be reset prior to initialization of a user session. The goal is to provide the option of dynamically changing session time values based on current communications performance identified by capabilities of the network management or DBMS.

 

6. End User Mode: Portion of XS services shall be used by various classes of users: data consumers, data and database managers, network information infrastructure resource managers. Some of these uses of the data management services will entail unique requirements that shall be fulfilled within the capability of XS services.

 

7. Maintenance Mode: This mode includes modification and/or addition of application data segments, user permission, privileges, and restructuring storage and memory areas. In addition, maintenance also shall pertain to shutdown, open not-mounted and online/off-line implementations, modifications, upgrade, or other related actions. The data management services shall support managing various types of data, database architectures and platforms that includes hardware and software at the specified sites.
8. Training Mode. In support of training activities, the data management services shall provide for the same processing as would be encountered in a production environment. However, access to the database may be via a training application access to the DBMS rather than from the production mission application.

 

2. XML SERVICES CAPABILITY REQUIREMENTS

The XS shall deliver inter-related components as shown in figure 3.2-1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 3.2-1

1. Register Terms and Structures (e.g., tags, DTDs, DCDs)
1. Producer services. A producer is an agent that contributes metadata for inclusion into an XML Registry for the purposes of ensuring maximum semantic understanding of a term as it appears in an XML document. To contribute metadata to a registry, the producer must be able to receive XML registry forms, submit metadata and the related information resource artifacts, and notify.

 

1. Produce and display submittal forms as part of the Information Resource Submittal Package from the web containing the following Information Resource artifacts: XML Tag Specification, XML Spec (i.e. DTD, DCD etc.), Sample of XML document of the tag to be submitted. The Package is to be compressed and emailed or sent ftp to an addressee.
2. Download Information Resource Submittal Package from the web containing forms, instructions, and tools for submission to XML Registry.
3. Submit prescribed metadata related to information resource type, information resource association, status code, data types specified and other related information specified in Appendix A within a combination of forms. These forms are part of the Information Resource Submittal Package containing the following Information Resource artifacts: XML Tag Specification, XML Spec (i.e. DTD, DCD etc.), Sample of XML document of the tag to be submitted. The Package is to be compressed and emailed or sent ftp to an addressee.

 

5. Submit metadata by an on-line interactive process
6. Submit metadata by a off-line and interactive batch process
7. Parse submitted XML Registry specification forms
8. Populate XML Registry database
9. Modify of specified terms & definitions of metadata and status of Information Resources.
10. Associate Information Resources specified in Appendix A.
11. Annotate rejected?
12. Assemble registered information resources to form new components.

 

13. Assemble new DTDs from current

 

14. Produce DTD as an instantiation (others are database schema, message definition) for modeling environment.

 

15. Notify change in Information Resources or authorized producer of tag.
16. Provide a capability to post planned changes to a registry
17. Approve and reject submissions
18. Forward request to different registry
2. Consumer services. A consumer examines a registry to select a tag structure for reuse in one or more applications that will exchange data according to a pre-defined agreement.
1. Discovery
2. View the XML Tags with the following relationships:
1. Ancestor/ Descendant relationship: Provide the capability to view a Tag’s origin
2. Uses/Used by relationship: Provide the capability to view a complex Container Tag’s parent/child relationship
3. Data type information: Provide the capability to view a tag’s data type and related information.
4. Versioning relationship: Provide the capability to view an Information resource’s versions
5. Reference Sets: Provide the capability to view text related to the domain values or the related reference set
6. Amplifying information: Provide the capability to view other information resources such as ERwin models, DTDs, documents, etc., which describe or otherwise provide amplifying information.

 

7. View the XML Tags via a tree/hierarchy structure or tabular format.
8. View the XML Tags by giving the user multiple search options to find a specific Tag.
9. View the XML tags by giving the user the search option to find all tags of a given subscriber/author.
3. Each Information Resource will have its own web page to allow the user to view all pertinent information, according to its information resource type.
4. View the Information Resource Submittal Package containing the following Information Resource artifacts: XML Tag Specification, XML Spec (i.e. DTD, DCD etc.), Sample of XML document of the tag to be submitted.

 

5. Display an XML Tag Specification form to the author of a given information resource. This XML Tag Spec will be used for inputting the requesting information for a specific Information Resource.

 

6. Provide capabilities to download the XML Tags or other selected Information Resources.

 

7. Catalog entities and attributes within servers to enable browsing, searching, retrieving of data related to XML sources.
8. Process ANSI standard SQL as specified in FIPS PUB 127-2

 

9. Establish rules to ensure maximum semantic understanding of a term as it appears in an XML document

 

10. Links to DTDs, DCDs,
11. Namespace
12. Provide a capability to subscribe for notification of changes to Communities of Interest (COE) or Information Resources.
3. Manager services
1. create and manage usernames, superusers

 

2. Establish acceptable naming convention not to be in conflict with the DOD data standards convention and establish a relationship to other naming conventions.

 

3. Create a naming structure within the COE architecture to express the context and relationship of the naming convention to other naming conventions specified in the I&RTS.
4. Define a set of metadata tags, information attributed to metadata tags (meta-metadata) and other related terms for the maintenance and control of XML tags.

 

5. Review/approve submission
6. Monitor changes to data models recorded in Registry

pass request off to … (per explicit federation agreements)

 

2. Design the schema for an XML document
1. Structure services
1. Record structure
2. Check against standard (e.g., style guide wizard for tags)
1. Validate

 

2. Use and reference existing tags and associated semantic structures
2. Content services
1. Use & reference existing tags & associated semantic structures (extracted from Registry)
1. create new tags & associated semantic structures
2. interchange w/other design tools & environments
3. Record semantic structure in JTA-compliant formalism

 

4. Generate standard views

 

5. Version metadata objects

 

3. Generate xml & schema documents
1. Generate a document that includes (by ref or by value) a schema
2. Develop scheme to permit dynamic cross-referencing and indexing of XML objects.

 

3. Generate language (natural language) and charset values
4. Check conformance
1. Well-formed
2. Validate
3. Extract views of data
5. Disassemble document to materialize different query results into different tree structure
6. Render
7. Interrogate document
8. Transmit sufficient metadata to construct alternate, semantically-valid views (e.g., XSL)
9. Express version

 

 

3. Consume xml & schema documents
1. Parsers (dom, sax)
2. Check conformance
1. Well-formed
2. Validate
3. Create validation constraints shall enable a meaningful sharing of XML-based schemas and related information.
4. Extract semantically-valid views from an XML document (e.g., XSL)
5. Disassemble hierarchical view to relational representation
6. Render

 

4. REGISTRY SERVICES EXTERNAL INTERFACE REQUIREMENTS

The Registry shall provide standard APIs as specified in Appendix B.

 

5. DATA ACCESS SERVICES INTERNAL INTERFACE REQUIREMENTS

The XS function shall provide standard APIs as specified in Appendix C.

 

6. DATA ACCESS SERVICES INTERNAL DATA REQUIREMENTS
1. The XS shall internally interface (transparent to the operator) with the existing data elements of the DBIF, DAC, and COTS RDBMS products.
7. REGISTRY SERVICES ENVIRONMENT REQUIREMENTS
1. The Registry software shall be portable and required to execute on COE-compliant platforms.
8. PERSONNEL-RELATED REQUIREMENTS

Not applicable. Personnel requirements shall be determined by the developers of the system in which the XS module is embedded.

 

9. TRAINING-RELATED REQUIREMENTS

Not applicable. Training requirements shall be determined by the developers of the system in which the XS module is embedded.

 

10. LOGISTICS-RELATED REQUIREMENTS

The XS developer is responsible for software maintenance, software support, and software updates. The DISA Configuration Manager (CM) is responsible for distribution of the XS product to system developers.

11. OTHER REQUIREMENTS

None.

 

12. PACKAGING REQUIREMENTS

The XS software shall be delivered in accordance with DII COE guidelines.

 

14. PRECEDENCE AND CRITICALITY OF REQUIREMENTS

The following table depicts the mapping of the requirements in Section 3 to their corresponding precedence and criticality code and to other related requirements within the XS SRS. The precedence and criticality codes are the following:

• 1 for Essential (E)
• 2 for Desirable (D)
• 3 for Optional (O).

2. QUALIFICATION PROVISIONS

COE Software will be qualified through formal validation tests of the SRS level requirements. The Qualification Methods applied to the software shall include test, demonstration, analysis, and inspection (T, D, A, I).

 

1. TEST

A qualification method that is carried out by operation of the item/component/I/F (or some part of the computer S/W configuration item, etc.) and that relies on the collection and subsequent examination of data.

 

2. DEMONSTRATION

A qualification method that is carried out by operation of the item/component/I/F (or some part of the computer S/W configuration item, etc.), and that relies on observable functional operation not requiring the use of elaborate instrumentation or special test equipment.

 

3. ANALYSIS

A qualification method that is carried out by the processing of accumulated data. An example of accumulated data is the compilation of data obtained from other qualification methods. Examples of the processing of accumulated data are interpretations or extrapolations made from the data.

 

4. INSPECTION

A qualification method that is carried out by visual examination, physical manipulation, or measurement to verify that the requirements have been satisfied.

 

4. REQUIREMENTS TRACEABILITY

Provided under separate document.

 

6. NOTES
1. ACRONYMS & ABBREVIATIONS

ACCS Army Command and Control Systems

GCCS-AAGCCS Army Global Command and Control System- Army

ANSI American National Standards Institute

API Application Programming Interface

ASCII American Standard Code Information Interchange

ASCII RTF American Standard Code Information Interchange Rich Text Format

ASRD AWIS Software Requirements Specification Document

ATCCS Army Tactical Command and Control Systems

AWIS Army WWMCCS Information System

CASS Common ACCS Support Software

CLI Client Library Interface

CM Configuration Manager

COE Common Operating Environment

COTS Commercial Off-The-Shelf

X-DA Data Access

DAC Discretionary Access Control

XS Data Access Service

DBIF Database Interface

DBMS Database Management System

DBs Databases

DATATWG Data Access Services Technical Working Group

DCE Distributing Computing Environment

DDL Data Definition Language

DDS Data Distribution System

DES Data Encryption Standard

DID Data Item Description

DII Defense Information Infrastructure

DISA Defense Information Systems Agency

DML Data Manipulation Language

DoD Department of Defense

DTG Date-Time-Group

FIPS PUB Federal Information Processing Standards Publication

FMWG File Management Working Group

GCCS Global Command and Control Systems

GOTS Government Off-The-Shelf

GUI Graphical User Interface

HP Hewlett-Packard

IAW in accordance with

ID Identification

I/F Interface

IF Intell Fusion

I/O Input/Output

JMCIS Joint Maritime Command Information System

JOBES Joint Operation Planning and Execution System

MAC Mandatory Access Control

Mbs Megabytes

MCG&I Mapping, Charting, Geodesy and Imagery

MIL-STD Military Standard

MSB Most Significant Bit

OS Operating System

PM Project Manager

POSIX Portable Operating System Interface for Computing Environments

RAID Redundant Array of Inexpensive Disks

RDA Remote Database Access

RDBMS Relational Database Management System

RISC Reduced Instruction Set Computer

RTF Rich Text Format

SECTWG Security Services Technical Working Group

SMM Systems Management Manual

SQL Structured Query Language

SRI Standing Request for Information

SRS Software Requirements Specification

SSDD Support Software Design Document

STACCS Standard Theater Army Command And Control System

S/W Software

TBD To Be Determined

WWMCCS World-Wide Military Command and Control System

 

2. GLOSSARY OF TERMS

Automatically: Indicates processing initiated during execution of other processes, but dependent on information and/or parameters to be generated or supplied to these other processes. The information / parameters may be data dependent, or application dependent, or dependent on a manual process/human intervention. It will include controls qualifying the processing involved.

Business Rule: A narrative description of policies, procedures, or principles within an organization. Business rules can be divided in to four categories: definitions, facts, constraints, and derivations.

Definitions are business rules that define entities and attributes.

Facts are either links (relationships) between entities or associations

between an entity and attributes

Constraints are conditions about the data that must always be true. They are the integrity rules that protect the data in the eventual database.

Derivations are business rules that materialize a new piece of information (often attribute values) from other pieces of information. For example, a mathematical derivation might specify that you can obtain a person's age by subtracting his or her birth date from the current date.

Commit/Rollback: An individual transaction is processed (commit) or discarded (rollback) by the proponent maintainer of the data items involved.

Discretionary Access Controls (DAC): A means of restricting access to objects based on the identity of subjects or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission on to any other subject.

Dynamically Generated Processing: Indicates processing initiated during execution of other processes, but dependent upon information and/or parameters to be generated or supplied to these other processes. The information/parameters may be data dependent, or application dependent, or dependent on a manual process/human intervention. It will include controls qualifying the processing involved.

Location Transparency: occurs when the physical location of data is transparent to the applications and users of the database system. For example, a view that joins table data from several databases provides location transparency because the user of the view does not need to know where the data originates from.

 

Mandatory Access Control (MAC): mediates access to an object based on the clearance level of the subject (user) and the sensitivity label of the object. (These controls are always enforced above any discretionary control implemented by users).

Mirrored Databases: Replication and maintenance of a database on a transaction basis for the purpose of rapid error or failure recovery as supported by the resident COTS RDBMS own system utilities and operating system.

Object: A passive entity that contains or receives information. Access to an object potentially implies access to the information it contains. Examples of objects are records, blocks, pages, segments, files, directories, directory trees, and programs, as well as bits, bytes, words, fields, processors, video displays, keyboards, clocks, printers, and network nodes.

Proponent Scheme: Describes the sites at which databases are replicated and also who owns and has update authority with respect to the data at each site. It refers to proponency at the source and record level.

Redundant Array of Inexpensive Disks (RAID): A RAID system appears as one very large, reliable disk to the CPU. The main reason for using RAID storage is its reliability. RAID has the same advantages as shadowing and striping at a lower cost. There are several types/levels of RAID implementations, including: RAID 0 (known as disk striping), RAID 1 (known as disk shadowing), RAID 3 (in which data is distributed in small increments across all data disks and adds a parity value to a separate disk for recovery if any disk fails, RAID 4 (in which data is distributed in large chunks across all data disks and also has a single parity disk. RAID 4 intended to overcome performance penalties of RAID 3 for small transfers. RAID 5 (in which parity over RAID 3 or RAID 4 implementations), and RAID 6 ( in which two parity disks in addition to data disks are used in an attempt to further improve performance). In a RAID 5 implementation, the data is stored as are check sums and other information about the contents of each disk in the array. If one disk is lost, the others can use the check sums and other stored information to recreate the lost data. Storage system vendors may provide additional enhancements to RAID level implementations to improve performance and reliability.

Remote Data Access (RDA): is an ISO (9579) application layer interoperability standard (protocol and formats) to support access by an application to a (remote) DBMSs over an OSI network. The goal of RDA is to allow interoperability between applications (clients) and databases (servers) of different manufacturers so that an application is able to read and update data in remote databases via well defined standards. RDA defines a set of client and server standards and a mapping of SQL commands to these services. RDA also defines an interface to ISO (transaction processing) two phase commit TP services in the case where updates to multiple remote databases need to be coordinated. RDA does not yet define interoperability between server databases (i.e. it is not yet a standard for distributed database management).

 

Replication Scheme: Information that precisely identifies DBs, or partitions of DBs, to be copied and/or distributed, replication schedules, and master/remote sites that are to receive the copies.

Spatial DBMS: Geographic information system that organizes and maintains spatial data (i.e. data with graphical attributes) in terms of type, scale, location(s), extent, topology and geometry. Supports queries of spatial data where the selection criteria are defined by spatial attributes.

SRI: A Standing Request For Information (SRI) is a capability in which CASS monitors for the occurrence of conditions established by an application program, and notifies the calling or establishing application program when the conditions are satisfied. An SRI may be one of three types: timer-based, data-based, or message-based.

Subject: An active entity, generally in the form of a person, process, or device that causes information to flow among objects or changes the system state. Technically, a process/domain pair.

Transaction Journalling: Individual messages or database transactions are stored in a journal file, which may be a linear log file or a circular file.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7. APPENDIX A

The metadata and procedures are described for the current Information Resource Submittal Package .

Metadata and Related Information
An XML tag may be described as any object and is easily created by anyone using a text editor. Although XML is a relatively new technology, many developers are already using XML in operational COE systems and have already created tags and specifications, many of which may be inconsistent with tags used in other systems. So far, the burgeoning sets of XML tags have created redundancy and irrelevancy, and they lack validity.

XML Registry.
To ensure interoperability, this registry provides a baseline set of tags developed through coordination and approval among the Community. The Registry allows a user to browse, search, and retrieve data that satisfy your requirements. The Registry has a substring search capability so that the user may easily find information resources that meet the criteria. The user may specify whether to search for the term within the name of the information resource or the definition or both.

Developer's Role.
Developers are urged to review the baseline tags, adopt them where possible, and subscribe to future notifications about the tags. If, after reviewing the tags in the Registry, you cannot reuse an existing specification (a.k.a. Document Type Definition (DTD)) or existing tags, you may submit your proposed tag to a Community of Interest (COI) and provide amplifying information for all to understand the semantics for its proper use.

COE Chief Engineer's Role.
The COE Chief Engineer will approve a single Point of Contact (POC) for a COI to manage the tags within that COI. The COE Chief Engineer will reserve ultimate authority to mediate any unresolved disputes within all COIs.

The COE Data Engineering Team's Role.
Tags and semantics will be analyzed to identify opportunities to consolidate tags towards a single or a minimal number of representations. A "market forces" model can also guide COE Data Engineering in identifying the weak candidates from the strong.

The Community of Interest's POC's Role.
(The information in the following section is current as of 17 May, 1999. Please consult the Registry for the most authoritative list of information resources types.) The POC responsibilities will include the transitioning of information resources from one status to another. Table 1 lists the valid types of information resources. The status levels are developmental, candidate, approved, rejected, and retired.

Table 1 Information Resource Types

For Developers may submit and use information resources within the Registry constitutes guidance in the generation and use of XML as an authoritative source for approved XML data and metadata components.

• Review Tags in Registry and decide what additions/modifications to submit (if any)
• Fill out one XML submission document to package multiple Tags
• Specify relationships among Tags, provide valid values, and add to submission package
• Include amplifying info associated with specific Tag(s)

Zip and attach submission package to e-mail message to: ____________________

Rules and Convensions.
Establishing a new Information Resource. Follow these conventions for creating new information resources for the Registry

1. Use "XML_Attributes" sparingly
   
   If the term is well recognized outside its container term, designate it as an element. Example: CTRY_CD, CTRY_NM, CTRY_ABBRD_NM, CTRY_OFF_NM, CTRY_SCP_NT_TX, and CTRY_PSTL_NM are all characteristics (ER-attributes) for the entity CTRY. In the relational world, they are columns within the table ctry, attributes of the entity ctry in er-modeling, and member attributes in object modeling. It would be expected that a submitter would identify them as attributes rather than elements. But if they were identified as attributes of the element ctry, then the additional baggage (other attributes) must be carried, or submitted as separate elements. We wish to limit the proliferation of tags, so we strongly urge folks to use XML_Attributes sparingly.
   

Include descriptive definitions AND synonyms for the Information Resource Definition.

Initially, the Registry will not have keyword, thesaurus, or ontology support but it will have a substring search for a number of fields, including definition. Therefore, we urge submitters to include enough expressive terms so that COE developers would easily find the term they might consider "natural" in the definition and find the desirable tag for expressing that concept. Example: If the registered tag is ORG_ID, the description that includes references

1. APPENDIX B

 

1. EXTERNAL PROGRAMMING INTERFACES

 

The External Interfaces for the XS SRS are defined as interfaces to non-COE components. Detailed information (as specified in paragraph 3.3 of the Data Item Description DI-IPSC-81433) defining these interfaces will be specified during the design phase of the COE XS architecture. At this time such detailed information is unavailable.

 

3. APPENDIX C

 

1. INTERNAL PROGRAMMING INTERFACES

 

The Internal Interfaces for the XS SRS are defined as interfaces to COE components. Detailed information (as specified in paragraph 3.4 of the Data Item Description DI-IPSC-81433) defining these interfaces will be specified during the design phase of the COE XS architecture. At this time such detailed information is unavailable.

The COE components identified to-date are listed below.

 

1. MANAGEMENT SERVICES API

It incorporates other interfaces to:

• Network Administration
• System Administration
• Security Administration

1. DISTRIBUTED SYSTEM SERVICES
1. COMMUNICATIONS SERVICES API

It incorporates other interfaces to:

• Communications
• Network Services

1. DISTRIBUTION AND OBJECT MANAGEMENT SERVICES

It incorporates other interfaces to:

• Distributed Computing Services
• Data Interchange Services

1. APPLICATION SUPPORT SERVICES
1. PRESENTATION SERVICES

It incorporates other interfaces to:

• Executive Manager
• Multi-Media Support

1. COMMON SUPPORT APPLICATIONS

It incorporates other interfaces to:

• Office Automation
• Message Processing
• Correlation
• MCG&I
• Alerts
• On-line Help

1. SOFTWARE DEVELOPMENT SERVICES

It incorporates other interfaces to:

• Developer’s Toolkit

2. APPENDIX C

 

1. INTERFACES TO COMMERCIAL PRODUCTS

The Interfaces to Commercial Products for the XS SRS are identified below. Detailed information (as specified in paragraph 3.3 of the Data Item Description DI-IPSC-81433) defining these interfaces will be specified during the design phase of the COE XS architecture. At this time such detailed information is unavailable.

The three commercial products or environments identified for the COE are the following Relational Database engines:

• Sybase
• Oracle
• Informix.