This FIPS for SQL Environments envisions an integrated data processing environment in which SQL and non-SQL processors are able to comunicate with each other and provide shared access to data and data operations and methods under appropriate security, integrity, and access control mechanisms. Application processors will then have protected access to all data using the full power and flexibility of Database Language SQL.

Standard communication among cooperating systems is possible at the present time using either OSI protocols [16] or Internet Society protocols [7]. Efforts are underway within both of these arenas to provide cross-protocol mappings for interoperability. Application services in both protocol environments provide for association control, file transfer, virtual terminal, and electronic mail. Future versions will contain extensions of these facilities as well as enhancements for remote database access (RDA), document management, and electronic data interchange (EDI). Near-term extensions to these protocols should make it possible for user-defined objects at various remote sites to communicate their existence and provide access to their methods to application processors. Objects at remote sites may be able to "show themselves" to users at local workstations by using emerging specifications and standards for graphical user interfaces.

The RDA component of both OSI and Internet Society communication protocols provides the basis of distributed access to remote data repositories and "standard" access to the data they manage. With implementation of an External Repository Interface (ERI), discussed in Section 3 below, it is possible for non-SQL data repositories to be "self-describing" in terms of SQL facilities so that they can be accessed and manipulated by all other sites using standard SQL language and RDA protocols. With longer-term emerging data management standards that support object-oriented and knowledge-based features, an ERI interface can evolve into a "seamless" integration of complex, structured data and supporting application services.

Begin with an Application Processor that wishes to communicate with and access data at a number of different data repositories, some local and some remote. The Application Processor could use existing communication protocols to connect to external processes or transfer files, but it would prefer not to have to manage its own communications links or worry about integrity, access control, remote transactions, or any number of different data manipulation functions; instead, it would rather communicate with a single, "familiar" data manager for both schema data and actual data occurrences. The "familiar" data manager could then connect itself to remote sites and access the desired data and data definitions, returning them to the accessing processor in a standard format. A remote object would still be able to use windowing protocols to "show itself" to the accessing process or use file transfer protocols to transfer objects or object definitions not under the control of the communicating data managers.

This architecture assumes the existence of any number of heterogeneous data repositories, some at the local site and some at distributed sites. It also assumes a full-function SQL processor at all sites, but not necessarily as the manager of the most important data. The non-SQL processors may control the maps, documents, graphics images, or complex engineering structures that the Application Processor wishes to access. The local SQL processor conforms to Database Language SQL and has two integrated client components, one conforming to the RDA/SQL Specialization and one conforming to the SQL/ERI interface proposed in Section 3 of this specification. Communications among the three SQL components are likely to be proprietary. The local site may have any number of non-SQL data repositories each controlled by a non-SQL Processor having a component that conforms to the SQL/ERI interface. Communications among the internal components of the non-SQL Processor are also proprietary. The local site has a proprietary local procedure calling mechanism and a proprietary local inter-process communications capability. Using these proprietary mechanisms and one of the standard local binding styles identified in Section 6 (e.g. SQL/CLI), the Application Processor issues standard SQL calls to the local full-function SQL processor, and the SQL/ERI Client component of the SQL processor is able to communicate, using an ERI specified subset of standard SQL, with the SQL/ERI Server of the non-SQL Processor.

The local site is connected to one or more remote sites via a standard OSI or Internet communications network ([16], [7]) that allows "messages" or "calls" to be exchanged among processes. Some messages may be sent directly from the Application Processor to processes or file stores at the remote site, but ideally, some local repository manager makes a connection and sends messages on behalf of the Application Processor. The Generic RDA and RDA/SQL Specialization standards [9] specify protocols that allow the RDA Client component of the local SQL processor to send SQL statements to the RDA Server component of a remote SQL processor, or the SQL/ERI Server component of any Non-SQL processor, and receive data in return. All protocols and data formats are defined in the RDA standards and are transmitted as ASN.1 (ISO 8825) packages. If the Application Processor is operating, interactively, on behalf of a human user, then any of the data repositories may use a local graphical user interface (GUI), or non-local windowing protocols, to present status information or a "menu of choices" to the human user. In this way an interactive "browsing" or "navigational" capability is provided to the human user without losing the standard RDA/SQL communications used by the non-human processors.

At the remote site there exists a full-function SQL Processor as well as any number of non-SQL Processors. Components of the SQL Processor conform to the SQL and RDA standards, and satisfy the proposed SQL/ERI Client requirements. Each non-SQL Processor has a component that conforms to the SQL/ERI Server specification. The remote site handles internal communications and procedure calls in the same proprietary manner as does the local site.

At the present time the RDA standards specify interchange protocols for transmitting records of data from a server site to a client site, provided that the data items in the records are either numbers or character strings. Near term RDA follow-on specifications will extend the data types handled to all of those specified in the SQL'92 standard [8], i.e. fixed and variable length character strings, fixed and variable length bit strings, fixed and floating point numerics, dates, times, timestamps, and intervals. Later RDA follow-on specifications will provide interchange mechanisms, in terms of ASN.1 elements, for the user defined abstract data types (ADTs) specified in the emerging SQL3 working draft [12]. RDA protocols do not by themselves provide interchange mechanisms for other data objects, so interchange standards for images, motion pictures, maps, topologies, or other complex objects will remain critical for transmitting object instances among various sites.

SQL and RDA provide the basis for standardized communication. An SQL external repository interface (SQL/ERI) makes it possible for non-SQL data repositories to share their data with user applications. With emerging SQL3 enhancements for object-oriented and knowledge-based data management and emerging RDA extensions for distributed database, the ERI can evolve to support "seamless" data integration.