RDA was published as a combined ANSI/ISO/IEC standard in 1993. It consists of two parts:
Part 1 -- Generic RDA ANSI/ISO/IEC 9579-1:1993 Part 2 -- SQL Specialization ANSI/ISO/IEC 9579-2:1993Part 1 specifies the generic model, service, and protocol for arbitrary database connection and Part 2 specifies additional protocols for connecting databases conforming to Database Language SQL. Both Parts are available in hard copy only from ANSI (Sales telephone: +1-212-642-4900); Part 1 is 151 pages and Part 2 is 59 pages. Further extensions and enhancements are under development (see RDA ENHANCEMENTS below).
RDA is not published as a separate FIPS; instead, it is recognized as a separate conformance alternative in the FIPS for SQL, FIPS PUB 127-2 (see Section 14.4), and in the FIPS for SQL Environments FIPS PUB 193 (see Section 6).
RDA protocols are defined in terms of ASN.1 abstract syntax notation (ISO/IEC 8824:1987) and ASN.1 basic encoding rules (ISO/IEC 8825:1987). The ASN.1 definitions of RDA/SQL Specialization protocols are available for use by emerging RDA implementations.
The RDA Service Interface consists of service elements for association control, for transfer of database operations and parameters from client to server, for transfer of resulting data from server to client, and for transaction management. Association control includes establishing an association between the client and server remote sites and managing connections to specific databases at the server site. Database operations are sent as character strings conforming to the SQL language. Resulting data and/or errors and exceptions are described and represented using the ISO ASN.1 standard. Transaction management includes capabilities for both one-phase and two-phase commit protocols.
The RDA standard describes RDA services in terms of an RDA Client, and RDA Server, and an RDA Service as follows:
An RDA client is an application-process, within an open system, that requests database services from another application-process called a database server. A database server is an application-process, within the same or another open system, that supplies database storage facilities and provides, through OSI communication, database services to RDA clients. An RDA client and a database server communicate by means of the RDA Service, supported by an RDA service- provider. The part of the database server that uses the RDA service-provider to communicate with an RDA client is called an RDA server. The RDA client has the ability to initiate RDA service requests, while the RDA server can only issue RDA service responses to reply to such requests. A data resource is a named collection of data and/or capabilities on the database server known to both the RDA client and the RDA server. The meaning of the data content and capabilities of a data resource depend upon the application of RDA, which is determined by each RDA specialization standard (e.g. the SQL specialization). The RDA client opens a data resource in order to gain access to the data content or capabilities of that resource through Database Language services (e.g. SQL). Data resources may be nested, with subordinate data resources grouped within their parent data resource. The RDA client is required to open a parent data resource before it can open subordinate data resources. An RDA transaction is a logically complete unit of processing as determined by the RDA client. Execution during an RDA transaction of a sequence of database access services that change data resources enables the set of changes to be handled as an atomic unit. When the RDA transaction is terminated, either the whole set of changes is applied to the data resources or no changes are applied. The RDA client requests termination of an RDA transaction by requesting the RDA server either to commit or to roll back the complete set of changes of that transaction. Changes made to the data content of data resources during an RDA transaction are not made available to other RDA clients until that RDA transaction is terminated at the RDA server. RDA provides a choice of two application- contexts for managing RDA transactions: 1) a basic application-context for one-phase commitment, and 2) a TP application-context for two-phase commitment. The RDA protocol for the basic application-context is completely specified in the RDA standard, whereas the protocol for the TP application context is dependent upon the ISO/IEC Distributed Transaction Processing standard (ISO/IEC 10026). An RDA operation models a request by an RDA client that is transferred to an RDA server for processing. RDA operations enable an RDA client to request any of five types of RDA services: a) RDA Dialogue Management services, to start and end RDA dialogues; b) RDA Transaction Management services, to start and end RDA transactions; c) RDA Control services, to report the status or cancel existing operations; d) Resource Handing services, to enable or disable access by RDA clients to data resources; e) Database Language services, to access and modify data resources. An RDA client may request RDA operations without waiting for the results of previously requested RDA operations. Thus an RDA server may have several RDA operations outstanding for a particular RDA dialogue. An RDA dialogue is a cooperative relationship between and RDA client and an RDA server. The RDA client initializes the RDA dialogue and requests RDA operations that are to be performed by the RDA server. An RDA dialogue is uniquely identified within the scope of the OSI environment, and all RDA operations occur within the bounds of an RDA dialogue. An RDA dialogue can exist only in the context of an established application-association, and ceases to exist if the association is released. A failed RDA dialogue cannot be recovered; the process of recovery after a failure is a local matter beyond the scope of the RDA 1993 standard, and recovery actions outside the RDA service-provider may be necessary. In the event of dialogue failure, it is a requirement that all changes made to data resources by any RDA transaction that is not already terminating when RDA dialogue failure occurs be rolled back by the database server during its recovery process. If an RDA dialogue is terminating when RDA dialogue failure occurs, then it may either be committed or rolled back.The OSE Implementor's Workshop (OIW) has specified implementation agreements for the Basic Application Context of the RDA standard, with profiles for: Immediate Execution, Stored Execution, Status, and Cancel. Future work is in progress by the OIW to specify corresponding profiles for the Transaction Processing (TP) Application Context. Only the Immediate Execution profile is required for all RDA conforming implementations; the other profiles of the Basic Application Context and the TP Application Context are optional enhancements to this basic requirement as follows:
RDA Stored Execution. Support for the Immediate Execution profile and, in addition, support for the RDA Stored Execution Functional Unit as specified in the RDA'93 standard.
RDA Status. Support for the Immediate Execution profile and, in addition, support for the RDA Status Functional Unit as specified in the RDA'93 standard.
RDA Cancel. Support for the Immediate Execution profile and, in addition, support for the RDA Cancel Functional Unit as specified in the RDA'93 standard.
RDA TP Application Context. Support for the Immediate Execution profile and, in addition, support for the RDA SQL TP Application Context as specified in the RDA'93 standard, and dependent upon ISO/IEC 10026 (Distributed Transaction Processing).
It is expected that RDA will be used for interconnection among SQL database management products from different vendors. Interconnection among database products from the same vendor will likely continue to use vendor specific communication and interchange forms.
SQL-92 data types not yet fully supported by RDA are: DATE, TIME, TIMESTAMP, INTERVAL, CHARACTER VARYING, NATIONAL CHARACTER, BIT, and BIT VARYING. Also, very long character and bit strings, e.g. blobs, are not yet fully supported. SQL-92 facilities for special Descriptor and Diagnostic areas are not supported implicitly in RDA. Amendment 1 to the RDA/SQL Specialization will provide data type encodings for the above types and may also include facilities for Descriptor and Diagnostics information to flow on each SQL statement. In most other cases, RDA simply carries an SQL statement from Client to Server, so additional RDA facilities are not needed.