There are many advantages and disadvantages to the options described in "Choosing a Deployment Method ". For instance Option 1 is favorable because it requires the least amount of work, and provides instant access to remote data. However, it does not generally provide access to remote applications, so it is not desirable for organizations wishing to deploy their applications on the Web.
If you want your users to run your applications from a Web site, you can select between Options 2, 3, and 5. Which is best for you? Options 2 and 3 require less work than Option 5, because they work with your existing applications. Option 2 is probably the easiest method of Web application deployment, because it requires a one-time setup and uses the regular ACUCOBOL-GT runtime. However, if you want the application to run inside the user's browser window -- to give the user the added functionality of browser features -- you should use Option 3. Using Option 2, the application runs on the client with its normal COBOL interface, and does not run in a browser window. In addition, Option 2 does not include any security measures to protect the user's machine. Option 3 does.
Although it is the most difficult method of Web deployment, Option 5 can be considered the most powerful. Option 5 takes advantage of popular new Internet technologies such as HTML and CGI to communicate between front-end browsers and Web servers. The advantage of this is that your application would conform to perceived Internet standards, and the only user interface requirement is the existence of a browser. However, CGI programs can work on only one set of input parameters at a time, so Option 5 does not support multiple user interactions as standard COBOL does. In addition, using Option 5, applications run on the Web server. While this may be preferred to running on local clients in most cases, it does not provide the same flexibility as Option 3 (which allows you to choose where your applications run). Furthermore, the HTML Web page becomes your application's front-end presentation method. You cannot have an ACUCOBOL-GT user interface with Option 5.
Option 4 should be used if you want to provide remote access to your applications independently of the World Wide Web. In many ways, this is easier than deploying applications on the Web. You do not have to create a Web page. You do not have to learn HTML. You do not have to worry about distributing the ACUCOBOL-GT runtime. But this method may require additional coding. In some cases, this is as simple as embedding a few CALLs into your client application (if they are not already there). In other cases, this may require developing a whole new client-side application component (albeit in ACUCOBOL-GT). The beauty of this option is that you have complete control over where your application runs -- on the client or on the server. From a front-end point of view, your users will see an ACUCOBOL-GT interface, not a Web page and not a browser window. In some cases this may be desired. In others it may not be.
Another consideration is the location of data. Using Options 2, 3, or 4, data can reside either locally or remotely. (Remote data would utilize AcuServer data services, unless the data is on the same machine as AcuConnect.) Using Option 5, data cannot be accessed locally on the client; it is always remote (again, using AcuServer). The same applies to COBOL object code. Using Options 2, 3, or 4, object code can reside either locally or remotely. Using Option 5, object code is always remote.
Of course, you can always blend the options to create a hybrid, Internet solution. "Blending the Acucorp Family " is described at the end of this chapter.