Data Access Service

The relationship of a data graph and a data source (for example, a relational database) is made easier by a specialized Data Access Service (DAS). Chapter 2 described the general idea of a data-access service, but in this case we're referring specifically to a service that works with SDO data graphs.

The nature of an interaction between a DAS and a data source is called optimistic concurrency. In response to your request for data, the Data Access Service connects to the data source, retrieves data without locking the source, converts the data into a data graph, disconnects from the source, and returns the data graph to your code. Your code can use the data without interacting again with the Data Access Service; or your code can modify and return the data to the Data Access Service, which uses the change-tracking facility mentioned earlier.

In response to a request to update data, the Data Access Service accepts the data graph that you send, connects to the data source, creates a lock, compares the locked data and the expected data, stores the data (if appropriate), releases the lock, and disconnects from the Data Access Service.

Optimistic concurrency increases the number of users that can be supported and is especially appropriate if multiple users only rarely overwrite the same data. This kind of disconnected processing also reduces your service's dependency on network connections and on the availability of data-storage systems.

The SDO change-tracking facility gives Data Access Services the information necessary to throw a fault when overwriting would occur. The service that invoked the DAS would respond to the situation, usually by repeating the transaction - in other words, by

1. reading and processing the changed data

2. submitting another request to revise the stored content

A Data Access Service may be coded by an individual or provided by a vendor. Commercial Data Access Services are available, and a set of open standards is in development.

We expect that by early 2008, open standards will guide the details of interaction between your code and any SDO-related Data Access Service. Data Access Services will use a combination of SQL and XQuery to interact with XML documents stored in a relational database, and you'll be able to use a single query to access data not just from columns in specific rows but from XML elements in those columns. In addition, you'll be able to configure a Data Access Service so that you can query a database, not only by writing code into your service implementation (as is now possible) but also by simply using the name of a command that is defined in a configuration file. In this way, the trend in SDO reflects the general SOA trend toward easier coding and toward deferring decisions from development time.