Remote Data Services in Action

As companies around the world are jumping on the Web to do everything from advertising to e-commerce, client/server developers are frantically searching for technologies that will let them open Web windows within their existing information systems. Enter Microsoft Remote Data Services (RDS), a set of COM objects born from the ashes of Advanced Data Connector (ADC) and now part of Microsoft Data Access Components (MDAC) 2.0 and later. (See the sidebar "Making Sure MDAC Works," page 48, for information about MDAC setup and repair.)

RDS lets you build high-performing, interactive, Web-based solutions on the familiar client/server metaphor, letting the browser connect to the Web server, query for a record set, and have the record set downloaded for further client-side processing—all in one round-trip.

The Connectivity Puzzle
Web communication is based largely on HTTP, a stateless protocol. Thus, client/server developers can't apply the typical request/response pattern when asking a Web server for a block of data. In the familiar client/server world, the client issues a query and waits for a response. When the server has processed the query and sent back the requested data, the client simply refreshes its user interface (UI) to reflect the results. In the Web world, however, the client's (or browser's) request and the server's response are two distinct, one-way communications. The request and response aren't two parts of the same interactive conversation.

A browser and Web server converse through HTML pages. The page that issues the request terminates when the browser begins processing the request. The resulting page the user sees is new, despite looking and feeling like the page that issued the request. The client receives an HTML page (a stream of HTML bytes) ready to render, not data for further local processing.

A Web browser is a thin client, with the Web server containing and applying all necessary application logic. Although the browser doesn't contain the application logic to handle returned record sets, you can manage them on the server through Active Server Pages (ASP), which contains the presentation logic a typical fat client would use.

So what role does RDS play in this Web browser/Web server connectivity puzzle? Microsoft designed the set of COM objects to improve the performance of highly interactive Web applications, such as e-commerce sites and database front ends, that let users filter and sort long lists of records on the fly. Obviously, you can't have well-performing, highly interactive applications if all user operations must travel to the server and back again.

With RDS and an ActiveX-enabled browser such as Microsoft Internet Explorer (IE) 4.0, you can issue remote calls through HTTP to middle-tier business objects on a Web server. You simply script RDS objects from within client-side HTML pages, or Visual Basic (VB) or Visual C++ (VC++) programs, and ask the objects to retrieve data. You then use Dynamic HTML (DHTML) to update and refresh the UI. These capabilities bring the traditional client/server programming model into the land of Web browsers and give you modern, highly interactive Web applications.

ADO's Web Counterpart
RDS lets you access any data the invoked business objects return, including arrays, text, and Extensible Markup Language (XML) strings. However, Microsoft specifically designed RDS to send and work with entire record sets across the network. With RDS, you can consider the ADO record set a native data type for your Web applications.

RDS acts as ADO's Web counterpart, as Figure 1 shows. Table 1 describes RDS's three objects. RDS.DataSpace handles remote data connection. RDSServer.DataFactory, a free server-side utility that Microsoft provides with RDS, collects the main features of the typical business object you would invoke remotely to get a record set. You can write and use your own server-side components in place of DataFactory if you need something different. The third object, RDS.DataControl, handles data binding. (The Microsoft Developer Network—MSDN—Online Library and the Platform Software Development Kit—SDK—also document these objects.) Let's look closely at the three RDS components.

The DataSpace Object
RDS doesn't cancel HTTP's stateless nature but merely hides it behind a proxy object, RDS.DataSpace. In other words, RDS simulates synchronous communications between the browser and the Web server through an intermediate object, which processes the request. The proxy object routes any remote method invocation to the RDS server stub. The stub, in turn, creates an instance of the specified component, invokes the method, and returns the result to the proxy. On the server, the system destroys the instance of the invoked object as soon as the method terminates. Thus, a different instance of a server-side object processes each successive call to that object. Table 2 lists DataSpace's method and property.

The following JavaScript code shows how to use the DataSpace proxy object from within an HTML page:

server = "http://expoware";
sql = "select * from Employees";
rds = new ActiveXObject("RDS.DataSpace");
df = rds.CreateObject("RDSServer.DataFactory", server);
rs = df.Query("DSN=Northwind", sql);
RefreshPage(rs);