MDAC 2.5 SDK - Technical Articles
The OLE DB Remoting Provider provides a transparent caching architecture. Internet data is frequently displayed in an HTML document: It's cached locally but it's static, and the data that you have isn't really live. You can work on it and then later send it back and say "Update it," but unlike traditional client/server applications, it is not interactive. By transparently caching data locally at the client side, the Remoting Provider minimizes round-trips to the server. The Remoting Provider brings the metadata and the data to the client so that a user can work on it at the client. When the client application is finished updating the data, the Remoting Provider will worry about the plumbing, getting the data to the server, and ensuring data integrity through optimistic concurrence.
The Remoting Provider transports the rich client experience, implemented by the Cursor Service component, to applications connecting over the Internet or other networks where it is difficult or expensive to maintain a consistent connection.
The Remoting Provider has some additional enhancements, such as a customization handler for the ADO RDS.DataFactory object. Server administrators can use the customization handler to control the operations that can be executed through the default RDS.DataFactory object. Also, the Remoting Provider has a cross-domain security feature that honors the security settings in the browser. Depending on the specified level of security, users are now restricted to connect to a database on the server from which the page was downloaded.
The following features are typical of distributed applications running over disconnected networks such as the Internet:
Scalability of Web or application servers is tested every day by users accessing applications over the Internet. Even when the servers can scale to handle large numbers of Internet users, network bandwidths often cannot. Client computers must be able to accomplish more with less support from the server and, at times, without even a server connection. Server resources need to be handled judiciously by new brands of applications.
To solve the scalability problem, the Remoting Provider moves the application logic (that is, the user interface and client-side data manipulation) and data to the client. It implements a "stateless" model, in which client and server can be disconnected between data access operations. The Remoting Provider marshals data efficiently between the middle tier or server and the client; it provides support for batch updates by using an efficient client-side Cursor Service component that can process data locally without constant server requests. The work done at the client can be saved locally and later uploaded to the server when a connection is available.
Some of the most important tasks that Web and application server administrators handle are data integration, security, and application management. Organizations deploy business components that run on the application servers behind the Web servers and control complete access to underlying enterprise data. These components implement business rules and validation logic, allowing client applications to read and update data. The client applications make requests to the components that are under central control of the system administrator. The Remoting Provider makes it easy to invoke these components over DCOM and HTTP and efficiently marshals input/output parameters, enabling effective distributed computing.
The Remoting Provider makes at least one interesting scenario possible: First, fabricate a recordset in a business object, and then, by remoting, return that data to the client to receive updates. The data is then remoted back to the Web server. The business object now has a recordset with all the information necessary to save the changes; that is, which rows changed, how they were changed, which rows were newly added. You can also set a Filter of adFilterPending to show deleted rows.