Remote Data Access and ADO 

ADO can be used in a whole range of ways, with any language that can instantiate and use COM objects. Its advantage is that the basic principles of using ADO are the same, irrespective of the type of application you are building or the programming language you use to build it. However, there is one specific application of ADO that is a core part of the technology. Remote Data Access is intended to broaden the appeal of ADO in scenarios where the client and server are disconnected - in the sense that there is no permanent physical connection between them. This is very much the case with Internet-based applications, where (until the new HTTP proposals are universally supported), the client and server cannot maintain state between connections. Each request from a single client is entirely separate from all other requests before and after the current one, and the server and client must create state artificially.

In this article, we'll look at what we mean by disconnected applications and state in more detail. We'll also see how one particular aspect of Remote Data Access, the Microsoft Remote Data Service (RDS), is such an important new technology.

Introduction to Remote Data Services

With the help of Remote Data Access, the ASP developer gets an opportunity to create an application that will, from the client's point of view, working over the internet (and more particularly over the web), work in pretty much the same way as traditional client-server applications over a local area network (LAN).

Applications That Work Over the Internet

In a traditional LAN-based environment, a client logs on to a server by identifying itself to that server. The server then authenticates the client using their username and password (or through another method such as a smart-card or fingerprint recognition.) However it's done, the result is that the server identifies the client as a valid user, and can then maintain a connection between itself and that client over the network. When data is sent to the server from the client, the server can automatically identify that particular client, and then send the appropriate data back to it.

This connection is effectively a permanent link between the client and the server during the time that the client is logged on. It provides state, in that the client and server can identify each other through the protocols supported by the network that connects them.

Once an application is moved to the Internet, or more specifically to the Web, this process fails. The HTTP protocol is stateless, in that it cannot automatically identify the client to the server. Once the server has created the return page and sent it back to the client, it effectively 'forgets' about that client. Instead, we have to rely on special extra layers within the application to handle this. It can be done in a range of ways - such as with ASP sessions or certificates, through custom techniques that use cookies, or by adding identification information to the request as part of the query string or the content of a form submission.

The Remote Data Service (RDS)

Having looked earlier at an overview of what remote data access is designed to achieve, we'll take a more detailed view of how it's implemented in RDS. The major limitation is that, once we move the 'working parts' out from the server to the client, we rely on a far more specific environment to be in place. What this means, at present, is that only custom Windows applications, and/or Microsoft Internet Explorer 4 (or higher) browser, can be used as the client with RDS.

The RDS Object Structure

The provider or driver supplies data to either the special RDS DataFactory object or to a custom component running on the server. The DataFactory object provides a default method of marshalling the data into a form suitable for transmission across the Internet.

The data is then passed to the Web server software and out across the Internet to the RDS DataSpace object on the client. This object implements the connection to the DataFactory object or custom component through a proxy and stub (the normal COM/DCOM communication method), and handles marshalling of the data across the network, and it also recreates it as a recordset on the client.

Once received by the client, the recordset is cached locally and passed to the client-side DataControl object. Finally, if required, the Data Binding Agent object takes the data and binds it to controls on the client. This last step is usually specific to a Web page, where the client is a browser or a custom application, which hosts an instance of the browser interface. The bound controls on the page then reflect the data content from the recordset. This is not mandatory, as script or other objects within the page can use the data directly, rather than binding it to controls in the page.

Now we see how RDS works:

<OBJECT classid="clsid:BD96C556-65A3-11D0-983A-00C04FC29E33"

	ID=SControl

	WIDTH=1 HEIGHT=1>

	<PARAM NAME="SERVER" VALUE="http://Servername">

	<PARAM NAME="CONNECT" VALUE="dsn=DsnName;">

</OBJECT>

The above code is used to connect to your server and the correct DSN. The ID is used to data-bind in the table, and how to bind data is shown below:

<TABLE border="1" datasrc="#Scontrol">

<TR>

<TD><span datafld="ID"></TD>

<TD><span datafld="NAME"></TD>

<TD><span datafld="DESIGNATION"></TD>

<TD><span datafld="TECHNOLOGY"></TD>

<TD><span datafld="PDETAILS"></TD>

<TD><span datafld="PTITLE"></TD> 

<TD><a datasrc="#Scontrol" datafld="URL" target="_top"><span datafld="URL"></A></TD>

</TR>

</TABLE>

In previous code block, we have given the ID as ID="Scontrol", and in the code immediately above I bind the object to this table by datasrc="#Scontrol". To display properly formatted data in the table, we have to write <span datafld="Fieldname"> between the <TD> tags. Datafld displays the data. In a last <TD>, I have given a link so that when data comes here, it automatically becomes a link.

The above code is for displaying data on to a page, but to fetch data from the table we have to write some VBScript code. I will explain below how to add a record to a database.

SUB Insert_OnClick



	myQuery = "INSERT INTO plptable(NAME,DESIGNATION,TECHNOLOGY,PDETAILS, 

PTITLE,URL) VALUES('" + SName.value + "' , '" + SDesig.value + "','" + STech.value + "','" + 

SDet.value + "','" + STit.value + "','" + SUrl.value + "')"



	SControl.SQL = myQuery

	SControl.Refresh

	

END SUB

The above function works when you click on a button, Insert function, which writes a query that adds a record into database. With SQL, we can execute the queries, like the Insert in RDS, there are other queries that Get the record(s) and then displays the data on a page. The Find button will find a record in the table, as you have requested; Clear will clear the content from within the textboxes.

In short, if you have to delete, modify, find, etc., then you just write the appropriate function that does that; as in the above SQL write query.

RDS works on a three-tier application - it's worth looking at the 3-tier articles on ASPToday (DNA for ASP and Building a Banking Application with the 3-tier Model), but just to briefly re-cap:

Client Tier

The Client Tier is the tier where the application interacts with the human. This is a necessary tier because humans do not have the capacity to comprehend the bits and bytes on the hard disk in an efficient manner. At this tier, we have either a web browser, displaying a web page where we can display and manipulate data from a remote data source, or we have a stand-alone compiled front-end application.

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:

• A Web page that has a RDS.DataControl object and one or more data-aware controls.
• Business object proxies and the RDS.DataSpace object for instantiating middle-tier objects.
• A client-side data cache.

The Web page represents the Remote Data Service front end. One can bind data aware controls to data from remote servers and view, edit and update data from the Web page.

The client-side data cache is made up of:

• ActiveX Data Objects
• Client Cursor Engine

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 RDS.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 RDS.DataControl object. RDS uses ADO as a programming interface between the code and the data exposed by the underlying OLE DB provider

Client Cursor Engine

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. 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:

• Create and delete temporary tables.
• Populate tables.
• Manage updates to the data values.
• Provide schema information (such as base tables, key columns, updateable columns, special columns, and computed columns).

Provide the mechanism to send batched updates to the server with minimum network traffic, by sending only the modified records.

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.

The Middle Tier is also known as the Business Logic Tier; it processes and manipulates the data. The business rules and workflow procedures handle this. This tier is important because most of your time will be spent programming and designing it. On this tier, things that you will be interested in are high-volume processing, transaction support, large-scale deployment, messaging, and possibly the web.

The middle tier has three major services, COM+, MSMQ, and IIS. Each service performs a specific task. IIS (Internet Information Server) is responsible for Internet services, such as SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol), and HTTP (Hyper-Text Transfer Protocol). MSMQ (Microsoft Message Queue) is responsible for messaging. Each of the services may use other services to create new services. An example would be queued components. They use both COM+ and MSMQ to create a new service.

Now we will see all three services in brief:

COM+

COM provides the framework for components. To enable COM components to have transaction capabilities, additional services are required. This is the purpose of COM+.

IIS

When a request is made to the IIS, it is a transaction request. By using transactions as a basis for handling requests, all the benefits of COM+ can be realized. This also makes COM+ more flexible when it needs to be dynamically load-balanced or optimized.

To build content for the IIS, it is possible to use ISAPI (Internet Server API) or typically ASP. The ASP technology is a scripting environment in which logic is executed from scripts. The script language is neutral and totally dynamic. It is used in conjunction with COM+ objects to provide a full-featured business application. ASP can be used to generate DHTML or XML.

Messaging Services

MSMQ (Microsoft Message Queue Server) is an event-driven architecture. The data is pushed to the server, and the server must react to the event being called. Being event driven is nothing new since Windows, itself, is event driven.

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-designed 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 that may reside on multiple platforms and combinations of servers and mainframe computers.

The Pros and Cons of Remote Data Access

Remote Data Access provides us with an opportunity to extend our data management applications over the Internet. The primary benefit of RDS is that it gives developers a method of creating dynamic web interfaces that give users the appearance of a more interactive and higher performance application. Remote Data Access can help to avoid the heavy network traffic that arises from even the most simple data manipulation tasks.

For example, a remote user is viewing a list of clients from a database and wishes to sort the list in a different order. The traditional method of using ADO with ASP, or a custom application on the server, means that the entire recordset must be transferred over the web for each sort. Using Remote Data Access however, the recordset is cached locally and can be sorted, filtered and viewed in a range of ways, with no further requests to the server and no network traffic.

However, this has to be balanced with the requirements of the application. The customer list may contain several thousand records. If the client is searching for a single record, it makes more sense to use the traditional technique of building a recordset, containing just this record, on the server with ADO and sending it to the client as a pure HTML page, rather than sending the whole set of records over the Internet. In many applications, you will need to consider a mixture of techniques, depending on the way in which the data will be used.

One of the factors influencing the decision you make is the level of support for RDS in the various browsers. At the present, only Internet Explorer 4+ fully supports RDS.

XML is a relatively new area, many browsers don't support the handling of XML data; indeed, Internet Explorer 5.0 is really the only browser of any good for it. So, as an ASP developer, you may want to send the XML data to the browser, or to keep the XML in your ASP pages and then to send the pure HTML up to the browser. Of course, this depends upon your target audience, but whichever method you choose, it's useful to know how to use the DOM and how to get access to the XML objects.

XML can also be used as a mode of data exchange with RDS, since XML provides a way of defining structured data that is independent from the application that reads it. The tags used in XML documents are not predefined; any descriptive string can be used. Moreover, the data defined by these tags can be displayed in any way you like.

XML adds a new, intermediate level of abstraction between the data source and the user interface. This layer lets you access cross-platform data from any system that supports XML. Since the data is completely separate from the user interface, you can perform client-side processing before displaying the data.

Click here to download this article's support material.