Client/Server using MiddleMan, a case study
by
Shawn M. Gordon
President
S.M.Gordon & Associates.
Let me start with a little background on what Client/Server is, and why you would use a product like MiddleMan. The idea of Client/Server at it’s most basic, is to use a seperate computer to handle the user presentation layer, than is used to hold the data. In recent times this has come to mean using a PC running Microsoft Windows as the computer that will provide the Graphical User Interface (GUI) to the user. The data repository computer can be anything from an
HP 3000, to a UNIX box, to an IBM mainframe, whatever it is you need. The idea here is that a mini or mainframe computer is much better at storing large amounts of data than a PC is. And the PC can do a much better job of displaying a pleasing interface than the mini or mainframe computer will. Also by offloading the overhead of user interface graphics to the PC, you increase the ability of the host computer to process data, and you take more advantage of that PC that is on everyones desk.
All of this is well and good, but the one part we didn’t talk about was how to get the data from the host computer (or Server) to the users PC (the Client). This piece is typically called middleware, and Middleman is a middleware product. Now middleware can be implemented in a variety of scenarios. It can support a standard serial connection, but this is usually to slow to be useful. Or it can support some network connection such as TCP/IP, Sockets, etc. Middleman takes advantage of your network connection to provide maximum performance, and ease of setup.
Over the last few years I have tried a variety of middleware products, and found that most were either much to confusing and difficult to use, or didn’t provide a robust enough environment. Even the original version of Middleman was a bit difficult to use since it was implemented using DDE (Dynamic Data Exchange) conversations, and DDE is less than straight forward to use. Now the latest version of Middleman has been implemented using OLE (Object Linking and Embedding) Automation, and it is so easy to set up and use that I kept thinking something must be missing from the puzzle, but nothing was.
Now anyone that knows me, knows that I am a COBOL hound, so my first project with Middleman was using Microsofts Visual Basic 3.0 under Windows for the Client layer, and a COBOL program running on an HP 3000 as the server layer. Figure 1 shows an example of using Visual Basic to declare the Middleman objects, start up Middleman, connect to the host, connect to the server, and then receive data back from the server.
In Figure 2 you will see an example of the COBOL code that I used to send and receive messages to the Client. An easy way to think of the server program is that your reads and writes to the network basically replace your DISPLAY and ACCEPT statements in your COBOL code. Actually, since I implement the NET_READ and NET_WRITE as COBOL macros, it is a simple step to substitute DISPLAY and ACCEPT and then run the server interactivly to test it.
Another thing you will notice in my COBOL Macros is that I use the pseudo intrinsic .LEN. to determine the length of the variable that is being passed to the NET_READ or NET_WRITE call. This is what makes the macro so generic, I never need to hard code the length of the parameter I am passing, and you must provide the length of the variable to the call. This makes set up and maintainence much easier.
The NET_READ and NET_WRITE on the client side or known as ‘streaming’ commands. Basically you just send a buffer, and a length for the buffer. I found that the performance cut off was around 6k for a data buffer. After that you may
start to take a performance hit. In this scenario you only need to use four command. NET_OPEN, NET_CLOSE, NET_READ, and NET_WRITE. If you want to do file transfers then Middleman also includes a file transfer object, and if you
look at figure 3 you will see how simple this is to use. Depending on your WINSOCK stack, you can get around 200k per second transfer rate, which is really amazing.
Middleman will also allow you to create a client application without having to write a custom server. It includes commands to read and write to databases and files, and I believe even take advantage of Third Party Indexing. This is a good option for you in my opinion, if you have simple applications, or just want to test the process. I find that I always need to write my own server just so I feel I have complete control.
As you can see, it is actually a very easy now to code a Client/Server application. You will probably spend more time fiddeling with the user interface than you will with the actual code behind the scenes. I have to say that bye using
OLE Automation, Middleman has designed the easiest middleware application that I have yet used. I don’t see how it could be made any easier. This also ties you in with Microsofts vision of the future, so you will be compatible with Windows 95, and Windows NT, as well as current Windows 3.1 and Windows for Workgroups.