Overview of a Three-tiered Application
Go Up to Understanding Multi-tiered Database Applications
The following numbered steps illustrate a normal sequence of events for a provider-based three-tiered application:
- A user starts the client application. The client connects to the application server (which can be specified at design time or runtime). If the application server is not already running, it starts. The client receives an IAppServer interface for communicating with the application server.
- The client requests data from the application server. A client may request all data at once, or may request chunks of data throughout the session (fetch on demand).
- The application server retrieves the data (first establishing a database connection, if necessary), packages it for the client, and returns a data packet to the client. Additional information (for example, field display characteristics) can be included in the metadata of the data packet. This process of packaging data into data packets is called "providing."
- The client decodes the data packet and displays the data to the user.
- As the user interacts with the client application, the data is updated (records are added, deleted, or modified). These modifications are stored in a change log by the client.
- Eventually the client applies its updates to the application server, usually in response to a user action. To apply updates, the client packages its change log and sends it as a data packet to the server.
- The application server decodes the package and posts updates (in the context of a transaction if appropriate). If a record can't be posted (for example, because another application changed the record after the client requested it and before the client applied its updates), the application server either attempts to reconcile the client's changes with the current data, or saves the records that could not be posted. This process of posting records and caching problem records is called "resolving."
- When the application server finishes the resolving process, it returns any unposted records to the client for further resolution.
- The client reconciles unresolved records. There are many ways a client can reconcile unresolved records. Typically the client attempts to correct the situation that prevented records from being posted or discards the changes. If the error situation can be rectified, the client applies updates again.
- The client refreshes its data from the server.
Using DataSnap to create three-tiered applications
DataSnap offers the possibility to create Client-Server applications that communicate through the Internet, the local network, or the local host. DataSnap automatically generates the necessary interface for the Client to communicate with the Server, containing the prototypes of the Server methods. When using a three-tier application developed with DataSnap technology, the Client user can call all the Server methods.
For an example of how to create an application using DataSnap, go to the following page:
Deploying Multi-tiered DataSnap Applications
DataSnap provides multi-tier database capability to Delphi applications by allowing client applications to connect to providers in an application server.
See the DEPLOY document (found in the main Delphi directory) for details on the files that need to be redistributed with an application. Also see the REMOTE document for related information on what DataSnap files can be redistributed and how.