I*net Data Server

---

Pervasive Software's I*Net Data Server (IDS) is a revolutionary way to connect users to information stored in Pervasive.SQL files regardless of whether they are using an intranet or the Internet (thus, I*net). The IDS is a multi-threaded server using Windows NT domain security which provides for data compression and virtual sites. The technology employed by the IDS eliminates many of the preconditions for end-user connectivity, allowing you to choose your development environment as well as the type of product to enable across TCP/IP. The single-user I*net Data Server (IDS) test server is included in the Pervasive.SQL SDK installation.

The current state of database connectivity lies in two camps. You can either choose wide-area connectivity and write a Web application, or you can choose network connectivity and write for the local network. In any case, a developer who wants full database connectivity in all situations is forced to make difficult choices: either write for the Web exclusively, or maintain two separate sets of source code in (very likely) two different programming environments.

The first choice, developing new applications exclusively for the Web, is initially appealing to many IS departments. It is not until the effort is made to create the actual sites that the difficulties arise. First, there is the learning curve of the new development environment, which is followed closely by discovery of the limitations of that environment. Then, there is the inevitable workaround of built-in HTML limitations.

Finally, the application is ready to be deployed and the first user logs on. All of a sudden, the same application the user has been running successfully in a browser-less mode is several times slower because of the resources allocated to the browser and the virtual machine running inside of it. This is nothing that upgrading every machine in the office will not fix - until the next browser release.

This is not to say that the Web does not have useful applications. There are times when the advantages of a Web-based application outweigh the disadvantages, such as when end-user browsing is essential (for example, online catalogs) or platform independence is a high priority. However, an optimal solution would provide the ability to not only write Web applications when needed, but also to develop an Internet application using the same development and end-user skills that already exist in the organization.

The IDS can provide Pervasive.SQL access in both of these situations. By combining complementary clients, the IDS provides Internet connectivity to the Web as well as to most 32-bit Windows development environments. ActiveX is the tool of choice for applications developed with Rapid Application Development (RAD) tools, such as Visual Basic, Delphi, C++ Builder, and Visual C++. Additionally, for Web applications, platform-independent applications, or Java gurus, there is a Java class library that provides IDS client services.

The IDS runs on a Windows NT machine and processes Pervasive.SQL requests made by both LAN and Internet clients. It can handle requests from all types of clients simultaneously, and compresses data using the algorithm used by each client request, so compression can be turned on and off on a per-request basis. The server acts as a proxy between Pervasive.SQL and the IDS clients, passing information as depicted in the following illustration.

 
Figure 4-1 IDS as Proxy Server

The IDS adds services in addition to straight-through Pervasive.SQL services. It is optimized to use bandwidth efficiently, as demonstrated with optional data compression. Likewise, DDF handling can be performed in only two calls: one to read the list of tables and one to read all the field information for a given table. These calls are processed internally in both clients. Furthermore, the send and receive buffers are not necessarily the same length.

This architecture optimizes calls across the I*net that have significantly different amounts of information in the send buffer and the receive buffer. For example, a GetDirect operation only needs to send four bytes of information yet may need to receive a 2-KB record. The IDS allows the client to send a data buffer of only four bytes while retrieving the full record.

Another advantage of the IDS that makes it ideal for an intranet is its easy configuration. While other Pervasive.SQL clients depend on a particular constellation of Pervasive.SQL settings (and as a result may even be incompatible with other, equally needed, Pervasive.SQL clients), the IDS clients do not need Pervasive.SQL settings at all. In fact, Pervasive.SQL does not need to be installed on a computer accessing Pervasive.SQL data via the IDS. This has the potential for dramatically reducing the number of support calls and making for much simpler installation programs.

The IDS can be used to provide access to an unsecured site or to any number of virtual sites. Virtual sites are implemented whenever security is enabled; a basic, secured installation would have only one virtual site-called database sets in the server - but a more complex installation could maintain any number of sites. Each site/database set has its own set of permissions which use Windows NT domain users and groups to validate logon access, and each site/database set can provide one of three levels of access: full access, read-only access, and write-only access.

Finally, each access level in each site/database set can have its own virtual root directory - all Pervasive.SQL calls are processed relative to this root, and none are allowed to traverse back up the directory tree (although any may go down the tree as shown in Figure 4-2). These virtual roots may actually exist on other machines on the local network, if desired. Because users and groups are established at the domain level, maintaining IDS security is only a small add-on to normal Windows NT domain maintenance.

 
Figure 4-2 Examples of Different Configurations for IDS Database Sets