Review of Client Server Foundation
by
Shawn M. Gordon
President
S.M.Gordon & Associates
Introduction
Client/Server has been a very popular topic for the last couple of years, but a lot of people are still confused as to what is involved in actually making it work. There are basically 3 components to Client/Server, they are the Client, the Server, and the middleware that let’s them talk to each other. Client Server Foundation, or CSF, is a middleware product from LeeTech Software in Cupertino California, that serves as a very robust middleware product, and that product will be the subject of this review.
System requirements to be able to use CSF in a Client/Server model between a PC and the HP-3000 are as follows;
Client – 386 or better CPU, 2MB of memory min, TCP/IP, WINSOCK.DLL or HP/WSOCKETS.DLL, LeeTech/CSF API/DLL, and some development environment such as Visual Basic, C++, Access, Excel, etc.
HP-3000 Server – MPE/iX 4.0 or later, NETIPC and SOCKETS, ThinLAN or HP/NS, LeeTech/CSF Listener, RL, XL, and utilities, a development language like COBOL, C, Pascal, etc., TurboIMAGE, IMAGE/SQL, ALLBASE/SQL, KSAM, MPE File, Oracle, Sybase, etc.
Features
There are a couple of approaches that can be taken when designing middleware. They can try to guess all the different commands that you are going to want to issue, and then implement them in both the client and server software. The other method is to give you a facility for sending and receiving a block of data, and it is up to your applications to decipher and implement the commands. While the second method may sound like it is more difficult for you, the programmer, in reality this is what you will end up doing most of the time anyway. The first approach would tend to limit your server platforms due to the complexity of trying to implement potentially hundreds of commands for each server platform.
It just so happens that Client-Server Foundation is implemented in the second fashion. There are only four commands on both the client and the server that you are concerned with, they are;
lt_msg_enter(buffer, error)
usage – to establish the virtual circuit connection between Client and your Server program, and register server program in LAN-MONITOR’s registry. It should be called only once at the beginning of your Server program.
buffer – server program description registered to LAN-MONITOR’s registry for operation to uniquely identify a specific server program. The MAX length is 35, which is from the first character to the NULL character.
– must terminate with a NULL character (%0)
error – 0 value means successful
lt_msg_leave()
usage – to disconnect the virtual circuit connection between Client and your Server program and drop server program off the LANUTIL’s registry. It should be called at the end of your Server program.
lt_msg_recv(buffer, length, error)
usage – to receive request from the Client.
buffer – receiving buffer from Client’s request
length – the expected receiving buffer length, must be the same length as the incoming Client request size.
lt_msg_send(buffer, length, error)
usage – to send the response back to Client.
buffer – response data to Client
length – the response data length, the Client receiving buffer size must be set to the same as the Server response data length.
That’s all there is to it, these four commands are the same in your host based COBOL program, as they are in your client based Visual Basic program. I had just a little trouble understanding how the communication was taking place until I though of the ‘lt_msg_recv’ command as replacing ACCEPT in your COBOL program, and ‘lt_msg_send’ replacing the DISPLAY statement. You could basically take a working application program and turn it into a server by following that methodology, and just add the ‘lt_msg_enter’, and ‘lt_msg_leave’ commands to the program.
What you get here is essentially a different server program for each application instead of one generic server program. You could write your own generic server program for the dozen or two commands that you thought would be useful, but for most applications that have any sort of heavy processing, you are going to want to leave that on the server, hence the specialized server program per application.
Now I mentioned LAN-MONITOR and the LAN-MONITOR registry when I was describing those calls, so I should probably explain what LAN-MONITOR is. LAN-MONITOR is actually a program on the HP host (although there is also a windows version, see figure 1 for a sample) called LANUTIL. This program allows you to get a list of users that are connected to the LISTENER process (this is the process that manages all your server programs, and client connections). From here you can kill a single user that is accessing, or stop everyone and terminate LISTENER. It is critical to have this type of a process because in a network environment you will typically have just a few background processes that could be managing hundreds if not thousands of users that are connected through the network. As an operator or system manager you really have no way of looking at who, how many, and what is connected, LANUTIL gives you this functionality
Before you ever stream the listener job you will first need to set up to host files, these are HOSTS, and SERVICES. The HOSTS file contains those node names that your applications may access programmatically via SOCKET. The SERVICES file contains your application name and its associated port_id, which must be unique to the specific HP-3000 machine, and is used to establish the initial connection between Client and Server(know as the SOCKET NAME). Once these are set up the listener must be started before any client connection attempts are made.
The debugging facility is quit robust, and allows you to set up from the bare minimum trace, to more information than you will probably want to look at. It will be up to you however to make debugging call’s in your code that are meaningful to you.
There is a very unique aspect to CSF that I don’t think anyone else has addressed in their middleware software. Say that you have developed a client interface that is being used in your company by just five people, and you come up with a new version. Well, it’s easy enough to walk around with a diskette and load the people up. Now say you have hundreds of users connected throughout the world. How do you get that same update out in a quick and effecient manner? Well LeeTech has already thought of this, and they provide you with a version control system. Basically, you can set up the software so that it will sign in with a version number, the server will check to see if the version is current, if it’s not, then the current version will be downloaded to you.
This one aspect alone is amazing, and it also isn’t covered in my current manual.
Most people don’t think about distribution after the fact, they are just thrilled to get an application on their desk that is working for the first time.
CSF also has various options built in for enforcing different types of security. It is also important to note that CSF doesn’t use ODBC which makes it up to 500 times faster than an application using ODBC. The downside to this is that you don’t have ODBC support, but since you code your own server it doesn’t really matter.
The included CSF console can manager and monitor your entire enterprise Client/Server from a central location. This Windows based utility allows you to connect to anywhere on your network, to diagnose any application and user problems and fix them remotely.
Usability and Installation
Installation requires software on both the Client and the Server. For the sake of argument we will say the Client is MS Windows, and the Server is the HP 3000. On the HP 3000 side you will restore a job from tape, stream the job, reload the tape, and then purge the installation job (I wish they purged it themselves). On the PC side you will have a standard Windows installation program that will create the necessary directories and load the software to the appropriate places.
All installations went very smoothly.
As far as usability, what can you say. The LeeTech CSF does it’s job very well, it passes the messages back and forth, and monitors your applications, it is up to you to write an application that works correctly.
Reliability
The Client Server Foundation product proved itself to be quite reliable in the tests that I did, at least I never got any failures from the Client or the Server programs due to a failure in the middleware layer, which is all you can really go by. The debug and trace facility provided by CSF is very robust, and provides quit a bit of information to help you fine tune and debug your application. This is important since, as far as I know, there is really no software that will let you measure these kinds of things from the outside world.
Performance
It is virtually impossible to find what the actual performance level of Client/Server is, other than the subjective “it seems fast”, or “it seems slow”. CSF seems to perform very quickly, but it is hard to judge, even if the middleware is fast, what if the Client or Server applications are written badly? there isn’t much you can do to see where the problem is. While I didn’t observe any performance problems, it is going to depend on how well you write your applications
Support and Documentation
The current version of the documentation is rather weak. It covers the basics of the product, and it covers it pretty thoroughly, but that is all it covers. The product is so much more robust and powerful than the documentation indicates. I am told that this is an early release of the documentation, and probably by the time you read this it will be much more complete.
The manual does provide full COBOL and Visual Basic examples, and looking at these will give you a pretty complete idea of what is required for coding.
The support and training from LeeTech is very good, these guys really understand their product. I mean they have 8 engineers working on this one product alone, and it is the basis for all their own Client/Server products like DBA/Query and DB/Advisor, so virtually everyone there knows how it works, and how to use it. My only real complaint is the voice mail, sometimes you can never actually get a live person no matter what, and I found that a bit frustrating. It only happened to me once, so I don’t know how often this can be a problem, but hopefully that will change soon.
Summary
At first glance I didn’t think a whole lot of CSF, but the more I got into it, the more I realized it could do, and while you might think the lack of a dedicated Server process is a drawback, it really isn’t for the most part. You will almost always end up writing your own Server if you are going to be doing custom processing anyway. The ability for all platforms other than MS Windows, to act as both a client and a server is unique as far as I can tell. The multi platform server support also seems unique on the HP 3000. There is quit a bit of server support currently, various UNIX flavors, IBM CICS, Windows NT, HP 3000 or 9000 (UNIX). This gives you a lot of freedom for designing and keeping your client interface and middleware, then you can change the underlying data repositories and hardware, and never impact the users familiarity with the system.
My only real complaint is the skimpiness of the manual , it’s pretty light at 34 pages, and while it does cover what you will need to do to use it, it doesn’t get into any major detail on some of the setup, and I couldn’t find any detail on the revision control, I had to trust LeeTech that this feature existed. Since Client/Server is such a new thing, and a lot of work, you will no doubt want to invest in some training as well if you are going to commit to CSF.
I have to say that if you are looking at doing serious Client/Server, and are looking for the glue to tie it together, then CSF is something you should give a serious look at, it is going to be much more cost effective than trying to write your own, and it is going to be more solid due to it’s maturity, and the fact that LeeTech has nine engineers on this product, they have to make it solid since they use it in some of their own products as I mentioned earlier. LeeTech has taken a very forward thinking approach to their middleware, and have tried to anticipate how Client/Server technology will continue to evolve. I was pretty darn impressed, and I think you will be too.
At-a-Glance
Client Server Foundation (CSF) version #.##
LeeTech Software Inc.
20410 Town Center Lane, suite 220
Cupertino, CA 95014
Phone : 800-995-1987 or 408-253-1987
FAX : 408-253-4008
Call, write or FAX for information. Most magnetic media’s are supported for software distribution, one 34 page manual. Software price is $, support is $ first year, $ per year after,