Understanding Universal Data Access and Remote Data Service Applications

by Susie Adams

Microsoft's Remote Data Service (RDS) architecture allows you to create disconnected recordsets that can be marshaled across machine boundaries between client applications and server components. RDS addresses several important performance issues present in the existing ADO model. In this article, we'll discuss the Remote Data Service and its contribution to Web application development.

The evolution of thin-client, Web-enabled applications has created a new set of data-access requirements not previously addressed by the Microsoft suite of data components. Web application developers needed a faster, easier-to-use data access interface that would support not only relational data, but also data housed in a variety of non-traditional formats. To accommodate this demand, Microsoft created what is known as the ActiveX Data Object (ADO).

ADO is the object-based interface to OLE DB. OLE DB, the newest low-level object-based interface, introduces the "universal" data access paradigm, and is designed to provide access to almost any type of data—regardless of the data's format or storage method. OLE DB allows client applications to access and manipulate data in a data store through any OLE DB provider, providing a simple, high speed, low memory overhead solution to data access.

To round out the Web developer's database tool set, Microsoft recently released what is now known as the Universal Data Access (UDA) architecture. The UDA architecture provides a simple programming interface to a variety of data formats on multiple platforms.

Developers can take advantage of UDA by using one or more of the Microsoft Data Access Components (MDAC). The MDAC consists of four main components: the ActiveX Data Object (ADO), OLE DB, ODBC, and Remote Data Services (RDS). Now, let's take a closer look at the RDS component of this development toolkit.

The Remote Data Service is a service of ADO that, appropriately enough, allows data remoting—the housing of data on a remote system. Previously released as the Advanced Data Connector 1.0, RDS facilitates data remoting within the same programming model as ADO. The Remote Data Service provides client-side and middle-tier caching of recordsets, and thus improves overall performance by minimizing the number of network round trips.

To simplify the programming process, RDS also provides a data-binding mechanism that allows the developer to bind recordsets to data-bound controls on a Web page. This facility means that you can move data from a server to a client application or Web page, manipulate the data on the client, and then return the updates to the server—in a single round trip.

The RDS client-side components run under an ActiveX-enabled Web browser and use HTTP to communicate with the Web Server. When a client enters a request, the client-side RDS component sends a query to the Web server. The server-side RDS component processes the request and then sends it to the DBMS. The DBMS responds to the request, sending back the data.

After the RDS component on the Web server transforms the data into an ADO recordset, it transports the data back across the network to the client-side RDS component. The client then displays the data in data-aware controls bound to the RDS component. The only calls requiring a round-trip to the server are the calls that update or execute SQL queries. Figure A illustrates the RDS architecture.

Figure A: RDS minimizes the number of data calls to the server.

There are three RDS objects: the RDS.DataControl, RDS.DataSpace, and RDS.DataFactory. The RDS.DataControl is responsible for binding data-aware controls to an ADO Recordset object. The RDS.DataSpace object creates client-side proxies to custom business objects located on the middle tier. The RDS.DataFactory object is the default server-side business object that provides communication between the client and server objects.

The Remote Data Service uses business object proxies to facilitate the communication between client-side components and business objects located on the middle-tier. Consequently, the proxy packages, unpackages, and then transports or marshals application recordset data across process and machine boundaries. Figure B shows the RDS Object Proxy model.

Figure B: With the RDS Object Proxy, your client-side components can communicate more smoothly with middle-tier objects.

You can either use the default business object proxy named RDSServer.DataFactory or write a custom business object to pass a recordset object between a server and a client. If you're going to use the default DataFactory component, you have two implementation choices. You can choose the RDS.DataControl object, which automatically instantiates the RDSServer.DataFactory; or you can manually call the RDSServer.DataFactory object. Now, let's look at each of these methods in greater detail.

The RDS.DataControl object is the data-binding mechanism for displaying query results on a Web page. Each RDS.DataControl object binds a Recordset object to one or more visual controls. There can be more than one RDS.DataControl object on a page and each of the objects on a page can be connected to a different data source.

When you use the RDS.DataControl to create a disconnected Recordset, RDS calls the RDSServer.DataFactory object automatically. You don't need to explicitly call the RDSServer.DataFactory object. In the example in the following article, we'll create an ASP page that demonstrates the use of the RDS.DataControl.

Before you read the following article and begin the application, you need to make sure you've installed the RDS Client and Server components. The components are part of the Microsoft Data Access Components (MDAC) and can be found on the OLE DB Microsoft Web site. The Client components are also automatically installed with Internet Explorer 4.0. If you're running IIS 4.0, the server components should also already be installed. Please refer to the appropriate Microsoft documentation if you have any installation questions.

Copyright © 1998, ZD Inc. All rights reserved. ZD Journals and the ZD Journals logo are trademarks of ZD Inc. Reproduction in whole or in part in any form or medium without express written permission of ZD Inc. is prohibited. All other product names and logos are trademarks or registered trademarks of their respective owners.