UniVerse has been available since 1984, and has been used as the database of choice to implement applications at many sites. As the product was improved and offered on a more diverse selection of hardware platforms, UniVerse became popular for implementing both packaged products and legacy applications. Most UniVerse application systems have been implemented to use dumb terminals, typically direct-connected to the host system. Some sites use dialup or leased lines as the method of access for remote users.
Now, the Internet is everywhere, and businesses are clamoring to take advantage of it. If yours is a typical UniVerse site, you have developed or purchased software some years ago, and run it on a minicomputer. If you were a user of proprietary hardware (Prime, VAX etc.), you probably made the move to a UNIX hardware platform in the not too distant past. Given this, you are a prime candidate to take advantage of WebKit, and all that it can offer to Internet enable your UniVerse applications software.
Many organizations are realizing the importance of bringing their UniVerse database and applications software to new users via the Internet. The following is a typical scenario for a business that offers a product for sale. Currently, all the software to support this business is run on a UNIX host. UniVerse based software is used for normal processing such as inventory control, order entry, shipping, accounting, etc. When an order comes in via telephone or on paper, the inventory is checked, the order entered, and the customer informed of a ship date. When a new product is offered, or prices change, a new catalog or mailing is sent. The information used by the customer is never quite up to the minute, and they are never sure about stock status or when shipment will be made when they place an order. Office and sales staff time is required to respond to the telephone, mail, or fax to accept and process orders. The ideal situation would be for the customer to directly check inventory, pricing, place the order, and get a ship date all by themselves, any time of any day. At the same time this takes place, they could be informed of new products, specials, and have the opportunity to correspond with anyone at your company via email.
Enter the Internet solution. You have a significant investment in your current software and database, are happy with it, and don't want to start over. The solution is to use some or all of your current UniVerse applications and database, and make it available to your customers and prospects via the Internet and WWW. This does not happen instantly, but the work required is far less expensive and time consuming than creating an entirely new system. The typical site configuration has a UNIX host system, with terminals connected via a LAN or directly wired. All data and applications exist and run on this single system. We will use this as the model for our discussion
What is a "Web Based Application" and what is required to implement it with your UniVerse database and applications? In order to build an application with a web browser user interface you must create and administer HTML documents, handle GCI argument string decoding, dynamically create HTML documents, and interface with reporting and administration of the server. In our case, all these tasks are handled by WebKit. A web based application can collect information, control access to any part of it, and generate HTML documents dynamically from data stored in database files. These dynamic documents are then returned to the calling browser. A browser such as Firefox makes a request for a document on a web server running httpd. The browser interprets a URL, uses the http protocol to contact the httpd software on the specified server machine, and passes httpd the path of the requested document. The httpd process translates the URL path to a real path on the local server, retrieves the document, and sends it back to the browser. A special case of this uses CGI to execute programs. The server administrator configures the httpd server to recognize certain pathnames as a request for program execution rather than a "get" document request. This in turn begins a sequence of events that will execute a specified program and return the output to the browser.
Things to be considered in establishing a website include: an Internet provider and the service, the system to be used as the web server, the web server software, security and firewalls, the software programs and modifications necessary, and support.
First, the hardware. To establish a website and connect to the Internet you will require a leased telephone line to an Internet provider and a service contract. The line is supplied by the local telephone company and runs to the closest POP (point of presence) of the Internet Provider. The provider handles your access to the Internet, and is normally selected based upon the type of service required, and the best deal in your area. With most providers, one contract will get you the telephone line, the required telecommunications equipment, and the service. They will also register your domain (the name you are known to the world as; for example, pulsarsystems.com) for a fee.
Next, what web server software to use? A web server is the piece of software that serves up pages and other information to people who visit your site with a browser. There are many web servers available, but the most well known are provided by NetScape and IBM. web servers come in several flavors, but normally you would only be concerned about whether or not it must serve secure (SSL or S-http) documents to your visitors. A non-secure server sends its information in the cloud.
Next, we must choose where to run the web server software. Now there is only one computer, but one is not sufficient for these requirements. From a security standpoint, keep in mind that the computer you run the web server on is going to be connected to the Internet, a public network. This is the equivalent of leaving your front door open each day when you go to work, and hoping no one will come and take anything. Given that this system contains your corporate database and applications software, and that you would be devastated at its loss or loss of use, you can see why it would be a good idea to segregate your database server system from your web server. With this said, the choice can be even more difficult.
Consider the following. A hacker attacks your system and deletes everything, including your root directory and operating system. How long would it take you to put it all back, and how much would that time cost in terms of person time and lost business? Now consider this. The hacker attacks your site but is more cunning than the obvious scenario above. This hacker doesn't delete anything, but changes some balances, modifies prices, depletes inventory, ships himself that new TV with no record of it, or something else along these lines. How long will it take you to discover this, and how much would it cost you in terms of lost business and good will? As you can see, leaving the front door open invites all kinds of disasters you could easily do without. Therefore, before you leap onto the Internet, be prepared to spend what it takes to do it right. The choices for security are many, can be expensive, and can involve up to two new computers for a site. For our discussion we shall assume the correct solution for this company is to run the web server on the database system and provide a second front end system that will serve only as a firewall. For our purposes here we define a firewall system as one that keeps out the bad guys, has alarms to warn you of those trying your front door, and logs all activity so you can find out what happened. This can go much further in terms of shutting down access if serious violations occur, calling or paging you, and more.
Now that we have the Internet software, services and hardware items out of the way, we can concentrate on the applications and database you want to make available. Since the software currently has a front end designed for access by dumb terminals, something must be done to make it work with an Internet browser. Since the data and programs were created with UniVerse, these must also be made available for access. The Pulsar Systems WebKit product is used to access UniVerse programs and data from the WWW. WebKit translates the requests made by a visitor's browser into commands that can be executed in a UniVerse environment, and subsequently does the same for the resulting information to be returned. Not only can you simply read data in files and display it, but you can also run UniVerse programs that read from and can update your database. Therefore, you could permit someone to enter specifications for something you sell, then run a program to gather the data and return it to them. For example, if you sold buttons, you might permit the person to enter (select) size, color, and material. You use this specification to look in your product file, and perhaps inventory file, and display a list of what you sell, have available, and the cost. If we had decided to do so, we might also permit the visitor to enter an order.
The programming necessary to make all this happen includes the following: HTML (an English like language) programs that specify what the visitor sees when they come to your site via an Internet browser. In the old dumb terminal technology this would be the functional equivalent of a screen layout. With the WWW, we design and build these once, and it works everywhere (well almost) for everyone. In the past you had to worry about terminal types and the like. These front end pages must access UniVerse programs on your database server to make everything happen. WebKit provides the means to execute UniVerse commands and programs, but you might have to provide the programs. I say "might", in that if the request is simply to read a file and display the results, WebKit can do this without a program. However, when it comes to searching your product and inventory files, making a selection from the result, and doing any calculations, a program is necessary. If you have a program that does the required task (order entry?) in your current host based software, then that is where to start. The only difference between this program and the one required for use with WebKit is how the data is passed in and out. It makes sense to take a copy of this program and modify the IO portion as opposed to starting over. You don't have to do anything at all to your database to use it with WebKit! Depending on what we want to offer on our Internet site, determines the amount of programming required. Remember, all the programming will be done on the host, in the familiar UniVerse BASIC development environment.
Now, the web pages were completed using HTML (or one of the many tools that create HTML for you), and we created new/modified programs on the database server to service these pages. Except for the testing, you're done. Earlier we said we would use two computers, one is the firewall system which provides the secure access, the other the database server. Both the web server and our WebKit run on the database server system. Only the security functions run on the firewall system. The two systems are connected via an Ethernet LAN, with the leased line Internet connection going to the firewall, and a separate LAN going to the database server. There are a few more tasks to be performed, but basically we have created a web site that talks to your UniVerse applications and data, and provides immediate access to your business.