This chapter describes the architecture and components of Remote Data Service technology. It shows how the RDS client- and server-side components work together to:
This section contains information about:
The key to using Remote Data Service technology lies in understanding the three-tiered client/server model. This approach separates the various components of a client/server system into three "tiers":
These tiers don't necessarily correspond to physical locations on the network. For example, all three tiers may exist on only two machines. One machine could be a Windows 95 computer running Internet Explorer4.0 as its browser. The second machine could be a Windows NT Server computer running both Internet Information Server andMicrosoft SQL Server. Designing applications this way gives you greater flexibility when deploying processes and data on the network for maximum performance and ease of maintenance.
The following illustration shows how these tiers make up an RDS application.
When you create a Remote Data Service application, you can partition your application into two or three logical tiers. The following illustration shows how a Web-based RDS application handles a user request to display information from a database. The client-side components are typically hosted in an Internet Explorer browser,using HTTP to communicate with the server components. Internet Explorer 4.0 already includes the RDS client components, thus simplifying your deployment.
Once the user enters a request, the client-side RDS components send the query to the Web server. The server-side RDS components process the request and send it to the DBMS. The DBMS responds to the request, sending back the data. The RDS components on the Web server transform that data into an ADO Recordset object. The data is converted for transport to the client and sent back across the network to the client computer. It may be displayed ina data-aware control, such as a text box or grid, that is bound to the data by the RDSIE3.DataControl object. One RDIE3.DataControl can channel data to many data-aware controls.
The resulting 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 (such as updates to the data server or requests for new data).
To learn how to implement a simple scenario like this, complete the Address Book tutorial. You can also consult "Developing Remote Data Service Applications" for helpful code examples and task-oriented information.
The client tier provides the visual interface for presenting information and gathering data. In a Web-based RDS application, the client tier usually consists of the following components:
The following illustration shows how RDS client-side components communicate with each other and the middle tier of a Web-based application.
Data, in the form of Recordset objects, is made available to Web page bound controls, and can be transported via HTTP or DCOM to the middle tier as an update, through the OLEDB provider. The RDSIE3.DataControl is designed to consume Recordset objects, navigating to their underlying rowset.
The Web page represents a Remote Data Service 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 RDSIE3.DataControl object is the data-binding mechanism for displaying query results on a Web page in Internet Explorer. Each RDSIE3.DataControl object binds one Recordset object, representing the results of a single 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 RDSIE3.DataControl object on each page. Each RDSIE3.DataControl object can be connected to a different data source and contain the results of a separate query.
The Remote Data Service uses 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 data across process or machine boundaries.
If you use the RDSIE3.DataControl to obtain a disconnected Recordset, RDS calls the RDSServer.DataFactory object; you don't need to explicitly call RDSServer.DataFactory or RDSIE3.DataSpace. The business object proxy is dynamically created whenever an instance of its middle-tier business object counterpart is created.
See Also For more information about creating business object proxies to call a custom business object, see "CreateObject Method" and "Getting a Recordset to the Client."
There are two ways to pass a Recordset object back from your server to the client withthe Remote Data Service. You can:
û or û
RDS contains a server-side business object (ActiveX DLL) called RDSServer.DataFactory that sends SQL statements to a DBMS, and passes the results back across the Internet or an intranet. RDSServer.DataFactory is the default ActiveX DLL that you can use to provide live data on your Web page, with little programming.
If you don't want to use the RDSServer.DataFactory object to pass Recordset objects 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 aren't provided by the simple RDSServer.DataFactory ActiveX DLL. These methods don't have to be related to data access ù they could just encompass a business rule.
One of the most important features of the Remote Data Service is its in-memory data caching on both the client and middle tiers. The data cache:
Using disconnected Recordset objects eliminates the contention for OLE DB connections that occurs when multiple Internet clients simultaneously access a data source.
The client-side data cache is made up of:
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 RDSIE3.DataControl object to send a query to a database, the Remote Data Service 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 ù RDS handles this for you when you use the RDSIE3.DataControl object. RDS uses ADO as a programming interface between the code and the data exposed by the underlying OLE DB provider. Because RDS is already using ADO, extending RDS functionality with ADO is easy.
ActiveX Data Objects (ADO) is a collection of Automation objects that can retrieve, update, and create records in any OLE DB provider, which includes ODBC databases. The Remote Data Service provides client-side caching of Recordset objects that minimizes the amount of network roundtrips, and it also provides a data-binding mechanism to display Recordset objects in data-bound controls on a Web page.
RDS 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. RDS can also spare users from needing details about the data source.
ADO is suitable for applications that need a high degree of database programmability. With ADO, you specify what type of Recordset object to create, which provides more flexibility than using RDS. Also, because ADO can execute on the Web server in an ASP page, it doesn't require any particular set of components on the client in Web-based applications. Further, ADO can maintain database connections, while RDS always works with disconnected data.
When you create an application, decide which technology is most appropriate for you. You can use RDS, ADO, or a combination of both technologies in the same application. For example, your application can combine a custom business object that uses ADO to manage data manipulation with the data source, and RDS to transfer remote data to the middle tier where the user can interact with it.
ADOR vs. ADODB Recordset Objects
ActiveXÖ Data Objects (ADO) can exist in both the client and middle tiers. ADOR and ADODB are "ProgID's" or prefixes that indicate where the Recordset object will exist and be manipulated. If the Recordset exists on the middle tier, use the ADODB ProgID when writing code. If the Recordset exists and is manipulated on the client, use the ADOR ProgID. A Recordset on either tier behaves almost identically. There are slight differences in the availability and behavior of some Recordset methods and properties; these differences are noted in the relevant ADO method and property reference topics.
The Remote Data Service uses an OLE DB interface to communicate with any data source (including 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. Such data sources are known as providers.
A variety of providers are currently available, including the Microsoft ODBC Provider, which exposes any ODBC database through OLE DB, and the Microsoft Jet Database Engine Provider, which exposes Microsoft Access and other desktop databases through OLEDB.
Usually, you use Microsoft Visual Basic or VBScript to access ADO Recordset objects, so the OLE DB layer will be invisible. ADO and RDS use OLE DB "behind the scenes."
See Also For more information about using OLE DB, see the OLE DB Web site (http://www.microsoft.com/oledb/).
The Client Cursor Engine is a set of data structures that caches, in memory (or temporarily on disk for large sets of data), 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 Service 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 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.
In an RDS application, business objects on the middle tier handle the data request from the clientsent through a transport protocol such as HTTP. That request is sent to the data source tier through an OLE DB provider 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.
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 Service 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 theRDS Advanced Data ISAPI, or ADISAPI).
ADISAPI provides parsing, Automation control, Recordset object marshaling, and tabular data 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.
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, using a data format designed to marshal tabular (rowset) data, based on the OLE DB standard of exposing the metadata information. The proxy uses this format when marshaling rowsets across process or machine boundaries.
Internet Information Server (IIS) contains a feature, 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 Service 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/, or IIS 4.0 documentation.
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++®, etc.
The Remote Data Service supplies a default business object, the RDSServer.DataFactory 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 RDS, 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 "RDSServer.DataFactory vs. Custom Business Objects."
You can implement Remote Data Service applications on an intranet without using HTTP. If the client- and middle-tier components are on computers within a LAN (local-area network), you can use DCOM to marshal the interfaces and method arguments across the network.
In an intranet/LAN application using RDS, the business object proxy and the ADISAPI components are replaced, respectively, by COM proxies and stubs. Except for rowsets, the arguments being marshaled don't 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 (that is, an intranet).
See Also For more information on using Transaction Server, see "MTS Resource Dispensers" and "Running Business Objects inMicrosoft Transaction Server." You can also visit the Transaction Server Web site at http://www.microsoft.com/transaction/, or refer to the Microsoft Transaction Server documentation provided with Microsoft Windows NT 4.0 Option Pack.
The RDSServer.DataFactory object is a SQL query and update control used in coordination with the RDSIE3.DataControl object to retrieve and post data to back-end data sources that support OLE DB. When you use some of the RDSIE3.DataControl object's methods and properties, the Remote Data Service is calling RDSServer.DataFactory behind the scenes. You can use it as a utility object, or as a template to create business objects that are compatible with RDS applications.
The RDSServer.DataFactory object resides on a Web server and is instantiated by the ADISAPI component. The RDSServer.DataFactory object provides read/write access to specified data sources, but doesn't contain any validation or business rules logic.
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."
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 aMicrosoft SQL Server database,for example, 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 Service applications to suit different network and DBMS configurations.