Problem:
Your company now has some number of leased lines that are used by remote offices to access your corporate database computer. Applications are written in UniVerse and involve typical business and some proprietary functions. The monthly cost of the leased lines is significant, and you would like to eliminate these in favor of using the Internet to access this system. What do you do?
Solution:
Provide a PC with browser at the remote office. Provide Internet access to your applications by installing a server with adequate security in your office. Make the required changes to your UniVerse programs to service the Internet via the Pulsar Systems' WebKit product for UniVerse.
Implementation:
First, consider how each remote office will access your computer. Typical Internet access is via dial up or DSL connection to a local provider. Each remote office would require a PC with a web browser, a high speed or DSL modem, and an Internet access account. Internet dial up access charges range from hourly to unlimited for a flat fee, depending upon whom you choose to use. If available, a DSL connection is preferred. If the nature of the data and transactions these remote offices will conduct is considered confidential or proprietary, then you will want to make sure their web browser will handle a secure protocol. Also, a Virtual Private Network (VPN) is an alternative.
Considering your corporate office, you must first address the issue of security. Internet security is such that you can spend more money on securing your site alone, than on the balance of the entire project. However, a practical approach on what to do and therefore how much to spend, can typically be had by answering a single question. How long could you afford to be without your corporate database server if a hacker were to trash it and the data? If we assume you do regular backups, and have to reinstall the operating system and all software and data from backup tapes, then this is your planned down time in response to such an attack. If you can live with this, your protection can be minimal (perhaps only a filtering router). Otherwise, now is the time to design the required security. This can include a proxy server, a separate firewall system, and more. The right answer is based upon experience and what you are willing to spend. Let us assume you have made the decision to use router filtering, and continue.
To have access to your corporate database system from the Internet you will need several things: an Internet connection from a provider, an Internet server, LAN connection for the systems involved, and probably a UPS to back up the server and firewall system where used. Obtaining an Internet provider means you will commit to a monthly fee for typically a year, and the associated lease line charges from the local telephone company. The speed of this line is dependent upon the amount of traffic you expect to receive. For example, if you have only one or two remote offices and do not expect a significant amount of traffic from any home (WWW) page you might host, then a 56KB line is sufficient. However, if you have 20 remote offices and will describe a product on your site that everyone will want to see, then a full T1 might be the right choice. These are only two of the many possibilities you will have to choose from. To host your site you must have a lease line or DSL connection, not a dial up. You may also have a choice of the CSU/DSU and router to be used.
For our example, we now assume you have picked an Internet provider and security implementation. Our example security implementation will involve a second computer (not your corporate database server) as the Internet server. We will not use firewall software or a proxy server but assume the router filtering is sufficient. This is obviously not the right answer for everyone, but simply one of the many possibilities.
The second computer to become our Internet server must be sized to handle the expected amount of traffic. That is, it must have sufficient disk, memory and processing capacity to service the number of expected hits. The system can be any make or model that supports UniVerse, but most sites prefer it to be the same brand UNIX system as the database server. You must provide a minimum (4) user license copy of UniVerse on this system. In addition, the licensed copy of WebKit will also run here. If you plan to use this system for anything else, you might want it to be larger, or support more UniVerse users. But keep in mind that the system will be on a public network, and therefore subject to compromise. You only need a minimum user license for UniVerse since WebKit creates all of its tasks as phantoms, which do not count as a UniVerse user. This computer will also need a piece of software called an Internet Server, which is not the same as a browser on a PC. Internet servers are available from people like IBM and Netscape. Please remember that if you previously decided your remote office will be doing secure (private) transactions, then the server you get must be capable of serving this protocol (a secure server).
The Internet Server system and your host database server should be connected by an Ethernet TCP/IP LAN, preferably one that does not also serve any other internal traffic. Therefore, both systems must have or have added the hardware and software to provide for this LAN connection. The only other remaining piece of software that could be required is uvnet. Depending upon the type of transactions to be performed (serving static data, updating files, running programs etc.), would determine if uvnet is necessary. If required, uvnet would run on the database server, not the Internet server. uvnet is licensed by the number of concurrent users, the same as UniVerse, and therefore requires you to decide how many users you expect (how much concurrent traffic) before ordering.
Now that this is all out of the way we can concentrate on the applications themselves. First, consider what type applications you will be providing access for via the Internet. For sake of our example, let us assume we are going to present an order entry function for our remote offices. These UniVerse based tasks now run on the leased line network via dumb terminals or PC emulators, using character mode input/output. These same UniVerse applications screens cannot be used in the Internet implementation, but must be replaced with web browser screens that will appear on the remote PC. Our first task is to design and program these screens in a language called HTML. HTML is an English like language that is reasonably easy to learn, with many reference books available. Since our UniVerse screens now do input and checking by field, we must realize the difference that will be seen via the Internet. On the Internet, a browser screen presents the same programming consideration as a block mode terminal. That is, nothing typed is seen by the receiving computer until it is explicitly sent. Given this, our redesign of the applications screens for the Internet should be reasonably smart, taking into consideration the desire to minimize the number of times a screen is sent, and how the actual functional input is designed to work.
For example, consider the current application in which we present a screen where the customer number and then each item of the order is entered. On our character mode terminal implementation, each field is validated as the carriage return is hit. It would not make sense to present a complete Internet browser screen, where the first field to be entered could be wrong when it is validated. A possible redesign of this form could be to present a first order entry browser screen that contains nothing but a place to enter the customer number and a submit button. Upon validation, a full order entry form is presented with the customer name, address, and other pertinent information filled in. When completing the balance of this form, we must be careful to present a page that will permit the balance of the information to be filled in properly. Consider that we only permit product number and amount to be entered per line item, then submit, and upon validation display the description and a line item and order total. In this case the page (form) should not permit the user to fill in the fields that will be calculated or displayed by the program. This is a very brief example, and other input programs will require much different solutions to be considered.