DataSnap supports a three- tier technology, which in its classic form consists of the following:
A database server on one (server) machine
An application server on a second (middle-tier) machine
A thin client on a third (client) machine
The server should be a tool such as InterBase, Oracle, MS SQL server, and so on. The application server and the thin client should be built in C++Builder. The application server will contain the business rules and the tools for manipulating the data. The client will do nothing more than present the data to the user for viewing and editing.
In some situations, more than one tier can exist on the same machine (similar to the database server and the application server). However, as long as they are separate executables, they can still be considered separate tiers. N-tier computing refers to the fact that all these tiers can be spread out across multiple machines. For instance, you might have the employee server on one machine and the payroll server on another machine. One of these application servers might access Oracle data from a third machine, and the other server might access InterBase data from a fourth. Hence, you don't have three tiers, but n tiers.
NOTE
The term n -tier can be a bit misleading, at least from some perspectives. No matter how you break up your database servers, application servers, and clients , you still end up with a maximum of three tiers of computing. Just because you have the middle tier spread out over 10 machines doesn't really change the fact that all 10 machines are involved in middle-tier computing.
DataSnap is based on technology that enables you to package datasets and send them across the network as parameters to remote method calls. It includes technology for converting a dataset into a Variant or XML package on the server side, and then unbundling the dataset on the client and displaying it to the user in a grid. The latter is done with the aid of the TClientDataSet or TINetxPageProducer (previously called the TMidasPageProducer ) component.
Seen from a slightly different angle, DataSnap is a technology for moving a dataset from a TTable or TQuery object on a server to a TClientDataSet object on a client. TClientDataSet looks, acts, and feels exactly like a TTable or TQuery component, except it doesn't have to be attached to the BDE (Borland Database Engine) or any other database driver for that matter ”apart from the DataSnap middleware DLL itself. In this particular case, TClientDataSet gets its data from unpacking the variant that it retrieves from the server.
DataSnap enables you to use all the standard C++Builder components , including database tools, in your client-side applications. However, the client side is a true thin client: It does not have to include or link any database drivers apart from the MIDAS.DLL itself (but at least you're relieved from BDE or ODBC installation scenarios). Installing MIDAS.DLL on the client is sometimes referred to as a zero-configuration thin client. And, although it's not exactly zero-configuration, it's indeed very simple to set up a DataSnap client, as this chapter will show.
The two different layers of the DataSnap technology are as follows :
The components found on the Component Palette and built in the VCL ( TDataSetProvider , TClientDataSet , and TXMLBroker ). The first two are found on the Data Access tab, and the last one on the InternetExpress tab of the Component Palette.
The protocol used to send messages over the Internet. This layer might be DCOM, HTTP, or just plain-old TCP/IP (sockets). With C++Builder 6 we can even use SOAP over HTTP. Different connection components can be found on the DataSnap tab of the Component Palette, and will be covered in more detail in the next chapter.
The built-in C++Builder components enable you to easily connect two machines and pass datasets back and forth between them. In the simplest scenarios, they make it possible for you to build middle-tier and client applications with just a few clicks of the mouse.
Top |