Home page Home page Home page Home page
Pixel
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
Pixel
By Sprezz | Wednesday, 10 February 2010 10:45 | 2 Comments
From the Sprezz archives we dig out this venerable document as it still seems to have relevance to our customers in the marketplace today!

The new Universal Driver 3.0 from Revelation Software gives customers new methods of formatting and structuring the location of data files.

One of these methods is the ability to run OpenInsight applications in a thin client model. For the purposes of this document, “thin client” means storing the repository files (or REVBOOT) on a local workstation while storing the datafiles on a remote server. This relies on the hiding files concept of the Universal Driver, and requires some initial configuration of the local system and the registry on the server the UD is installed on.

This document will describe how to move a system from your local development system to a client’s site. During development, we will have everything stored in one path. For example, OpenInsight sits in the following directory path:

S:\APPS\TABLET\OINSIGHT\RELEASE

This is the directory that contains the OINSIGHT.EXE, which we’ll refer
to as REVBOOT. Underneath, we have all of our data volumes, stored in
the DATA volume.

S:\APPS\TABLET\OINSIGHT\RELEASE\DATA\CUSTS
S:\APPS\TABLET\OINSIGHT\RELEASE\DATA\PRODS
S:\APPS\TABLET\OINSIGHT\RELEASE\DATA\INVS

When the application gets installed at the client site, the client will install
this in two sections, on the client’s server, which we’ll call SVR1PHL, the entire application will be installed on the D:\WINAPPS\3RDPTY directory. (Installing the entire application allows for server side maintenance of the data, but is
optional.) This means that we’ll have paths like

D:\WINAPPS\3RDPTY
D:\WINAPPS\3RDPTY\DATA\CUSTS
D:\WINAPPS\3RDPTY\DATA\PRODS
D:\WINAPPS\3RDPTY\DATA\INVS


On each workstation, the user only needs a REVBOOT directory and single directory called DATA. Following standard Windows™ conventions for program installation, our client workstation would probably have installed this section as C:\Program Files\My Company\TabletApp

Everything up to this point gets installed and placed as would be expected. The data is on the server, the programs and windows are stored on the local workstation. What we need to do now is tell the workstation how to find the files.

There’s a new attribute of the REVPARAM file which allows the definition of a share name to store data. This attribute is called ShareName. This is used in conjunction with the ServerName attribute. What we need to do is create a DATA subdirectory underneath the REVBOOT of our workstation copy. This gives us

C:\Program Files\My Company\TabletApp\Data

In that subdirectory, we put in a single file, REVPARAM, with the following entries:

TcpIpPort = 777
ServerOnly = 1
ServerName = SVR1PHL
ShareName = DATA

Because of the path tree method of the UD driver, when we go to access any LH volume in this directory (or lower), the driver will find the REVPARAM and use that for instructions.

The UD driver finds the paired attributes ServerName and ShareName and determines that whenever the user wants anything from the DATA volume, it needs to go to the SVR1PHL server to get the files. This means if the user looks for DATA\PRODS, the UD driver will query the SVR1PHL server for the DATA\PRODS directory and use that as it’s file store.

We also need to tell the server how to find this data, and for this, we need to make some additional modifications on the server. The first step is to go into the server’s registry and create some additional keys. Go to the registry location for the Universal Driver settings, which is

HKEY_LOCAL_MACHINE\SOFTWARE\RevSoft\Revelation Universal Driver\3.0.

Underneath this location, we need to create a new subkey called “shares”. This gives us

HKEY_LOCAL_MACHINE\SOFTWARE\RevSoft\Revelation Universal Driver\3.0\Shares.

Inside this section, we need to create a new string value called DATA, with
a value of D:\WINAPPS\3RDPTY\DATA.

This tells the LH Service that when it gets a request for the volume named DATA to start at this location. Because this also cascades down the directory tree, if the LH service gets a request for the DATA\CUSTS directory, it will look for the files in D:\WINAPPS\3RDPTY\DATA\CUSTS.

There’s one more step, and that’s the creation of an additional REVPARAM file, this time in the D:\WINAPPS\3RDPTY\DATA directory. This REVPARAM file contains the following:

TcpIpPort = 777
ServerOnly = 1

No other REVPARAM file is needed on the server.

That’s all that’s needed to find and run OpenInsight in a thin client mode.

How did this all work? This is possible through the initial REVPARAM created on the workstation. As far as the local workstation is concerned, all the data files are stored in directories below REVBOOT. As this tree is traversed, the UD Driver comes upon a REVPARAM file. In this REVPARAM file, there are the ServerName and ShareName attributes. This tells the UD driver that there’s no point in trying to find the files at this location, but to send a message to ServerName and ask for the data in ShareName. When ServerName receives the request, it queries its registry for a ShareName matching ShareName, and finishes the directory traversal from that point.

By extension, using the volumes we defined above, we could have on the workstation, the following:

C:\Program Files\My Company\TabletApp\Data\CUSTS
C:\Program Files\My Company\TabletApp\Data\PRODS
C:\Program Files\My Company\TabletApp\Data\INVS


Each of these folders could have a revparam pointing to a share on different servers. This would allow the CUSTS volume to exist on SVR1PHL, the PRODS volume to exist on SVR2PHL and the INVS volume to exist on SVR1NHMP.

Labels: , ,

2 Comments:

  • Excellent information about the features of the Universal Driver. Also provides a great reminder of the technique to redirect different volumes to different servers.

    However, the usage of the term "thin client" is misleading. Normally thin clients are low power hardware devices designed to access a 2x/Terminal Server/Citrix desktop. The computer(or network device) boots, connects to the network, and brings up a desktop on the terminal server. All of the work is done on the server.

    The configuration example in this article requires oengine.exe execute on the client computer. Oengine is responsible for communication with the Universal Driver (Database I/O) and executing the stored procedures (symbolics, user functions). This requires more CPU resources than a normal thin client can provide.

    One last consideration, this doesn't scale well across a WAN. A remote desktop thin client is better suited for this type of setup.

    By Anonymous Jared Bratu, At 10 February 2010 at 13:19  

  • Wow someone read it!

    We agree and apologise for using the sloppy definition promulgated elsewhere of "A form of client/server architecture in which no data is stored and relatively little processing occurs on the client machine" because even then we're somewhat on the wrong side.

    What do you think we should call it to be more accurate - distributed? Not(SQL-Server)? Bring us solutions not problems!

    Installation Procedures for an OpenInsight Architecture Where the Executables Reside Locally and the Data Resides Centrally makes for a lousy acronym.

    Thanks for your much appreciated comments :)

    By Blogger Sprezz, At 10 February 2010 at 13:38  

Post a Comment

Subscribe to Post Comments [Atom]



<< Home

Pixel
Pixel Footer R1 C1 Pixel
Pixel
Pixel
Pixel