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.