Detailed Control Flow

Contents  Index  Topic Contents

Appendix B: Detailed Control Flow

This section contains a control flow description of the programming events that occur when the Remote Data Service processes a user event.

The following illustration shows the detailed control flow of a simple RDS application that uses the default RDSServer.DataFactory business object. The numbered labels correspond to processes in the control flow and are described as follows.

The user enters query text in a visual control. That query text will eventually be sent to the Web server for processing.

When a user event occurs on the Web page (such as an OnClick event on a Search button), the RDS creates a business object proxy on the client. If you use the default business object, RDSServer.DataFactory, you will get a generic proxy for the RDSServer.DataFactory object.

The business object proxy translates the request into an HTTP sendable format. The parameters to the method are passed across the Internet via HTTP to the Web server (Internet Information Server, or IIS) specified in the RDS.DataControl object's Server property. IIS then passes the HTTP request to a server extension called the Advanced Data Internet Server API (ADISAPI).

ADISAPI examines the contents of the call. It creates an instance of the business object and makes the requested method call. (If you use the RDSServer.DataFactory object, it calls the Query method.)

The remaining steps describe the process flow when the Query method of the RDSServer.DataFactory object is called. A similar process happens when methods on a custom business object are called.

The RDSServer.DataFactory object executes the user's query via OLE DB (and ODBC) by passing in the SQL statement and DSN information. It sets the properties for the requested rowset so that OLE DB uses the Client Cursor Engine as its buffering component.

OLE DB passes the rowset containing the results of the query to the Client Cursor Engine. The Client Cursor Engine populates its buffers with the rowset data and stores all of the meta data information for all base tables that are part of the result set. It also implements the marshaling interfaces for the rowset.

The Client Cursor Engine passes the marshalable rowset back to the RDSServer.DataFactory object.

The RDSServer.DataFactory object creates an instance of an ADO Recordset and passes it the Client Cursor Engine marshalable rowset. ADO wraps the rowset into a Recordset, which is then returned as the return value of the original Query method call from Step 4.

The RDSServer.DataFactory passes the Recordset back to ADISAPI, which packages the return value of the Recordset into MIME format by calling the Client Cursor Engine.

ADISAPI sends the Recordset over HTTP as multi-part MIME packets to the business object proxy on the client side.

The client-side business object proxy unpacks the results of the method call from HTTP format, and recreates the Recordset in the client-side Client Cursor Engine.

The RDS.DataControl object binds the data in the Client Cursor Engine to the visual controls.

After the preceding steps have taken place, the user now has access to the Recordset object, representing the results of the query (displayed through the visual controls). He or she can perform tasks such as examining the record data, making changes, inserting new records, or deleting existing records.

When the user makes an update request, only the changed records are sent back via a process similar to that described previously. When an attempt is made to save the updated data, either all the changes will be written back to the data source, or, if any individual change cannot be saved, none of the changes will be saved.

For a custom business object, one difference to the steps outlined previously is that an RDS.DataSpace.CreateObject method is called on the client page to instantiate the business object proxy (Step 2). Also, if you write your business object in Visual Basic or Java, it cannot communicate directly with OLE DB, so the business object sends a request to ADO, which then sends the request to OLE DB (Steps 5 and 6). Business objects created with Visual C++ can access OLE DB directly.