The Big Picture: Understanding Remote Data Services Applications

This chapter describes the architecture and components of Remote Data Services technology. It shows how Remote Data Services's client- and server-side components work together to:

This section contains information on:

Three-Tiered Applications

The key to maximizing Remote Data Services technology is a thorough understanding of the three-tiered architectural approach to client/server solutions. This approach separates the various components of a client/server system into three “tiers” that come together to create an application:

These tiers do not necessarily correspond to physical locations on the network. Rather, they are conceptual layers, to aid in the design of robust component-based applications. For example, all three tiers may exist on only two machines. One machine could be a Windows 95 computer running Internet Explorer 4.0 as its browser. The second machine could be a Windows NT Server computer running both Internet Information Server and SQL Server. Designing applications in this way gives you great flexibility to deploy both process and data wherever is best on the network for maximum performance and ease of maintenance.

The following illustration shows how these tiers make up a Remote Data Services application.

How does a Remote Data Services application work?

When you create a Remote Data Services application, you will partition your application into three logical tiers. The following illustration shows how Remote Data Services handles a user request to display information from a database. The client-side components are hosted in an Internet Explorer browser, and HTTP communicates with the server components. (Internet Explorer 4.0 already includes the Remote Data Services client components, thus simplifying your deployment.)

Once the user enters a request, the client-side Remote Data Services components send the query to the Web server. The server-side Remote Data Services components located on the IIS Web server machine process the request and send it to the DBMS (for example, SQL Server), via a business object. The DBMS responds to the request, sending back the data (through its ODBC driver). The Remote Data Services components on the Web server transform that data into an ADO Recordset object. The recordset data is parsed for transport to the client and sent back across the network to the client computer. It is displayed in data-aware controls, such as a text or combo box, that are bound to the data by the AdvancedDataControl. One AdvancedDataControl object can channel data to many data-aware controls.

The resulting recordset data is cached on the client computer, reducing the number of connections to the Web and making it easier for a user to manipulate the data (the only calls requiring a trip to the server are calls to the business object or updates to the data server).

To learn how to implement a simple scenario like this, go through the Address Book tutorial. You can also consult "Developing Remote Data Services Applications" for helpful code examples and task-oriented information.

Client Tier

The client tier provides the visual interface for presenting information and gathering data. In a Remote Data Services application, the client tier usually consists of the following components:

The following illustration shows how the Remote Data Services client-side components communicate with each other and the middle tier.

Data, in the form of ADOR.Recordset objects, is made available to Web page bound controls, and for transport (via HTTP or DCOM) to the middle tier as an update, through the OLE DB layer. The AdvancedDataControl is designed to consume Recordset objects, navigating to their underlying rowset protocol layer and then creating an ADO layer over this for the benefit of data-aware controls.

Remote Data Services Web Pages

The Web page represents Remote Data Services application front end. You can bind data-aware controls to data from remote servers, and view, edit, and update data from the Web page. The Web page must:

AdvancedDataControl Object

The AdvancedDataControl object is the data-binding mechanism for displaying the results of a SQL query on a Web page in Internet Explorer. Each AdvancedDataControl object binds one ADOR.Recordset object, representing the results of a single SQL query, to one or more visual controls (for example, a text box, combo box, grid control, and so forth). There may be more than one AdvancedDataControl object on each page. Each AdvancedDataControl object can be connected to a different data source.

Business Object Proxies and the AdvancedDataSpace Object

Remote Data Services needs business object proxies so that client-side components can communicate with business objects located on the middle tier (IIS Web server). Proxies facilitate the packaging, unpackaging, and transport (marshaling) of the application's recordset data across process or machine boundaries.

If you use the AdvancedDataControl to obtain a disconnected recordset, Remote Data Services calls the AdvancedDataFactory object "behind the scenes" to create the business object proxy for you; you don't necessarily need to explicitly call AdvancedDataFactory or AdvancedDataSpace. The business object proxy is dynamically created whenever an instance of its middle-tier business object counterpart is created. Remote Data Services supports the following protocols: HTTP, HTTPS (HTTP Secure Sockets), DCOM, and in-process (client components and the business object reside on the same computer).

See Also For more information about creating business object proxies, see "CreateObject Method" and "Getting a Recordset to the Client."

AdvancedDataFactory vs. Custom Business Objects

There are two ways to pass a recordset back from your server to the client with Remote Data Services. You can:

Remote Data Services contains a server-side business object (ActiveX DLL) called AdvancedDataFactory that sends SQL statements to a DBMS, and passes the results back across the Internet or an intranet. AdvancedDataFactory is the default ActiveX DLL that you can use to provide live data on your Web page, but with little programming.

If you don't want to use the AdvancedDataFactory object to pass recordsets back to the client, you can create your own custom ActiveX DLLs that will run on the server. The custom DLLs could also contain methods that are not provided by the simple AdvancedDataFactory ActiveX DLL. These methods do not have to be related to data access — they could just encompass a business rule.

Client-Side Data Cache

One of the most important features of Remote Data Services is its in-memory data caching on both the client and middle tiers. The data cache:

Using disconnected recordsets eliminates the ODBC connection bottleneck that occurs when multiple Internet clients simultaneously access a data source. ODBC connection management occurs on the server, not on the clients, so you can take advantage of SQL Server 6.5 pooled connections, minimizing the time a pooled connection is in use.

The client-side data cache is made up of:

ActiveX Data Objects

You can use ActiveX™ Data Objects (ADO) to write a client application that can access and manipulate data in a database server through a provider (database interface). When you use the AdvancedDataControl object to send a query to a database, the Remote Data Services server-side components return an ADO Recordset object to the client. You don't necessarily have to write any ADO-specific code to make this happen — Remote Data Services handles this for you when you use the AdvancedDataControl object. Remote Data Services uses ADO as a programming interface between the Remote Data Services VBScript application code and the recordset data exposed by the underlying OLE DB provider. Because it's using ADO, it's easy to extend Remote Data Services functionality with ADO.

ADO vs. Remote Data Services

ActiveX Data Objects (ADO) is a collection of Automation objects that can retrieve, update, and create records in any OLE DB or ODBC database. Remote Data Services provides client-side recordset caching that minimizes the amount of network roundtrips, and it also provides a data-binding mechanism to display recordsets in data-bound controls on a Web page.

Remote Data Services is suitable for applications in which the client needs to browse records or connect to live data. Because the data is cached on the client workstation, a user can quickly scroll through the data.

ActiveX Data Objects is suitable for applications that need a high degree of database programmability. With ADO, you specify what type of recordset to create, which provides more flexibility than using Remote Data Services. ADO is also useful if you want to ensure that your application will work on any browser with any client.

When you create an application, decide which technology is most appropriate for you. You can use Remote Data Services, ADO, or a combination of both technologies in the same application.

ADOR vs. ADODB

ActiveX™ Data Objects (ADO) can exist in both the client and middle tiers. If your custom applications use ADO Recordset objects, ADO uses the ADOR.Recordset object unless ADODB.Recordset object is already registered on the client.

The ADOR.Recordset object is a lightweight implementation of the larger, more full-featured ADODB.Recordset object. ADODB.Recordset has more information associated with it, and therefore is less desirable to download ADODB to remote HTML pages.

The type of marshaling protocol you use determines which Recordset type is made available:

What this means is that when you use the DCOM or HTTP protocol, ADODB.Recordset objects can now be return values of method calls, without having to be converted to ADOR.Recordset objects first.

See Also For more information about using ADO, see the ADO Web site (http://www.microsoft.com/ado/).

OLE DB

Remote Data Services uses an OLE DB layer on top of the data cache (Client Cursor Engine). This makes it possible for Remote Data Services applications to communicate with any data source (relational and nonrelational databases, Microsoft Excel spreadsheets, mail, flat files, and so forth) that can communicate with OLE DB and expose its tabular data through the OLE DB standard.

Typically, you will use VBScript and access ADO Recordset objects, and the OLE DB layer will be invisible to you. ADO and Remote Data Services use OLE DB "behind the scenes."

The OLE DB layer implements an IRowset interface over the data in the Client Cursor Engine database, which allows for updatability either by using the updatable snapshot or keyset cursors. The data resides in Client Cursor Engine buffers, and the VBScript application running in Internet Explorer interacts with it through the ADOR.Recordset object.

On the middle tier, OLE DB exists in two layers:

See Also For more information about using OLE DB, see the OLE DB Web site (http://www.microsoft.com/oledb/).

Client Cursor Engine

The Client Cursor Engine is a set of data structures that caches, in memory, the set of query results retrieved from a DBMS, as well as client updates to those results. The Client Cursor Engine is an underlying technology that is invisible to you — Remote Data Services calls the Client Cursor Engine to perform various tasks for you automatically.

The Client Cursor Engine contains buffers for meta data such as tables, rows, columns, keys, and timestamps, as well as the actual table data itself. To manage the cache, the Client Cursor Engine can:

The Client Cursor Engine uses tablegram format to transfer the cached data across process or machine boundaries. Tablegrams are a MIME file type used to transfer (marshal) tabular data and its corresponding meta data between systems. It is designed to expedite the bidirectional transport of tabular data, between a Web browser and server using HTTP or DCOM. The tablegrams can transmit normalized data, which allows base table rows that occur multiple times in the resultset to be transported only once.

The Client Cursor Engine organizes its tables in a way that is similar to that found in the underlying database. As a result, the Client Cursor Engine's caching mechanism is efficient and optimized for use by the OLE DB layer and the data binding layer to implement client-side keyset cursors.

Middle Tier

The middle tier is the “bridge” between client computers and database servers. The components on the middle tier respond to requests from the user (or other business services) in order to execute a business task. They accomplish this by applying formal procedures and business rules to the relevant data.

In a Remote Data Services application, business objects on the middle tier handle the data request from the client through a transport protocol such as HTTP. That request is sent to the data source tier through OLE DB over ODBC to complete the requested transaction(s). The middle tier usually consists of the following components:

The following illustration shows the various components on the middle tier.

Internet Information Server

Microsoft® Internet Information Server (IIS) enhances the functionality of Windows NT® Server 4.0. IIS includes a complete set of tools for building server-based Web applications and creating rich and dynamic content. The underlying Remote Data Services code uses one of these tools, the Internet Information Server API (ISAPI), to help create server-side stubs to communicate with client-side business object proxies (through the Advanced Data ISAPI, or ADISAPI).

ADISAPI provides parsing, Automation control, recordset marshaling, and Advanced Data tablegram packaging, streaming, and unpackaging. This extension library performs the necessary work to instantiate business objects, invoke their services through Automation interfaces, and process the return parameters for transport back to the calling client through the tabular data streaming protocol. The AdvancedDataSpace object makes possible the marshaling of OLE DB rowsets from one computer to another over HTTP through the business object and ADISAPI.

Note The business object proxy and the ADISAPI components are responsible for marshaling data across the process or machine boundaries. The marshaled data is copied by value, rather than by reference, since accessing memory addresses across process or machine boundaries would be difficult. To marshal recordsets by value, Remote Data Services uses a format called the Remote Data Services tablegram. The Remote Data Services tablegram is designed to marshal tabular (rowset) data. It is based on the OLE DB standard of exposing the metadata information. The proxy uses this format when marshaling rowsets across process or machine boundaries.

Active Server Pages

Internet Information Server (IIS) contains a capability, called Active Server Pages (ASP), that allows server-side scripting. Whereas VBScript and the ActiveX controls on HTML pages are interpreted and rendered by the client-side browser, Active Server Pages scripting is processed by an engine on the Web server, before the HTML page is sent to the browser.

You can use Active Server Pages to write server pages (.asp files) that can be referred to as URLs from any Internet browser. These pages are composed of text, HTML tags, and script commands. The script commands consist of Visual Basic-like code embedded within the <% and %> tags.

You can use ASP pages as components of a Remote Data Services application, as in the Address Book example in Getting Started. The HTML and VBScript code for that example is written in an .asp file, and Active Server Pages script is used to request the name of a server.

See Also For more information about IIS and ASP, see the IIS Web site, http://www.microsoft.com/iis/.

Business Objects

The main application components on the middle tier are business objects that contain information such as application logic, business rules, and the data access code from underlying databases. The client-side components access these server-side business objects through business object proxies. Business objects can be any generic Automation objects created with Visual Basic®, Visual C++®, or server-side HTML pages with Active Server Pages scripting code.

Remote Data Services supplies a default business object, the AdvancedDataFactory object, that provides read and write access to data sources, but contains no business rules or application logic. You may use the methods of this default object in your own custom business objects that contain other business rules.

The ADISAPI component performs the actual communication with business objects for you, and is responsible for creating instances of objects, invoking methods, and releasing them. Your business objects can use ADO to query and update the underlying databases. In Remote Data Services, the lifespan of a business object is as long as the execution of a method call invoked by the client. Instances of the business objects are created with each method call, and no interim state is maintained.

See Also For more information about business objects, see "Getting a Recordset to the Client" and "AdvancedDataFactory vs. Custom Business Objects."

DCOM and Microsoft Transaction Server

You can implement Remote Data Services applications on an intranet without using HTTP. If the client- and middle-tier components are on remote computers (a typical LAN implementation), you can use DCOM to marshal the interfaces and method arguments across the network.

In an intranet/LAN implementation of Remote Data Services, the business object proxy and the ADISAPI components are replaced, respectively, by COM proxies and stubs. The arguments being marshaled do not need to be packaged in multi-part MIME packets. Instead, they are transported in the native DCE/NDR format, implemented by COM marshaling code.

When business objects on the middle tier are implemented as Microsoft Transaction Server components, they can use Transaction Server context objects to maintain their state across multiple client calls. This scenario is possible with DCOM, which is typically implemented between trusted clients and servers (an intranet). In this case, the AdvancedDataSpace object on the client side is replaced by the transaction context object, implemented by Microsoft Transaction Server.

See Also For more information on using Transaction Server, see "Using the MTS Resource Dispensers" and "Running Business Objects in Transaction Server." You can also visit the Transaction Server Web site at http://www.microsoft.com/transaction/.

AdvancedDataFactory Object

The AdvancedDataFactory object is a SQL query and update control used in coordination with the AdvancedDataControl object to retrieve and post data to back-end data sources that support ODBC. When you use some of the AdvancedDataControl object's methods and properties, Remote Data Services is calling AdvancedDataFactory behind the scenes. You can use it as a utility object, or as a template to create business objects that are compatible with Remote Data Services applications.

The AdvancedDataFactory object resides on a Web server and is instantiated by the ADISAPI component. The AdvancedDataFactory object provides read/write access to specified data sources, but does not contain any validation or business rules logic.

Server-Side Data Cache

The server-side data cache is similar to the data cache on the client tier. For more information on the data caching mechanism, see "Client-Side Data Cache.."

Data Source Tier

The data source tier defines, maintains, accesses, and updates data, and manages and satisfies middle-tier requests for data. Separating data source services from the other application components allows the data structure and access mechanisms to be maintained, modified, and even re-architected when necessary without affecting application components on the client or middle tier.

The data source services may be physically implemented in a particular database management system (DBMS), or by a heterogeneous collection of databases which may reside on multiple platforms and combinations of servers and mainframe computers. Your DBMS can be a SQL Server database, and you can use Microsoft ODBC and OLE DB technology to handle all data similarly on the client side, regardless of its source. This eliminates the need to use targeted client-side drivers for each data source. This also means you can easily modify Remote Data Services applications to suit different network and DBMS configurations.


© 1997 Microsoft Corporation. All rights reserved. Terms of Use.