| Previous | Table of Contents | Next |
Wrappers are custom startup scripts for applications, and have been used for quite some time. Many application vendors, such as Frame Technology, use wrappers to tailor their application startup.
Vendors cannot, however, anticipate the full range of startup decisions and settings that will be needed in every customer environment. You can add value by developing wrappers that are truly customized to your own end-user environment. It may be worth writing your own wrapper—even to front end an application vendor-designed wrapper. Wrappers can leverage your system administration expertise and hard-won knowledge of the application requirements in a consistent way, to the benefit of all your users.
Ordinarily, user dot files (for example, .login and .cshrc for the C shell or .profile for the Bourne shell) try to provide for what users may do after they log in. The goal is to define a comprehensive environment that supports all requests to access applications. It is not only difficult, but in some cases impossible, to provide for all cases: Some applications need a different value for an environment variable than do other applications that use the same variable name.
For example, to run a given Sybase application, the users may need to set the DSQUERY variable to identify the back-end database server for the application. If this variable is set from dot files at login time, it extends throughout subsequent shell environments. However, other Sybase applications may require different DSQUERY values. If DSQUERY is set, instead, by a wrapper for the Sybase application, the DSQUERY value applies only to the application, and may be set to different values by other wrappers for other applications.
When you use wrappers, the environment for each application is set up as needed. Wrappers construct the needed environment at runtime, before executing the application. In addition, the settings are visible to the resulting application process only; they do not interact with the rest of the user’s environment. This encapsulation of runtime environment is a significant advantage of wrappers.
Likewise, users’ paths frequently must be updated as applications come and go, in an effort to provide for what the user may decide to run.
Consider this analogy: In a given year, you plan to go running, hiking, skating, scuba diving, and snow skiing. (Forget for a moment that, as a system administrator, you’re too busy.) Doesn’t it seem more practical to don the special equipment for each activity just before you need it (and take it off when you’re done), rather than trying to put it all on at the beginning of the year, “just so you’ll be ready”? Clearly, the latter approach can generate conflicts. And in choosing where to go skiing, for instance, you probably would prefer to choose your destination based on where the snow is at the time you are ready to go.
With wrappers, you can provide sensible default values for variables, while still allowing users the option to override those settings. You can automate user installation steps that some applications require when first run, and know that you are producing consistent results. You can also generate usage information about the application.
Some administrators question whether the merits of a wrapper approach justify the overhead imposed each time an application starts up. After all, an additional shell script runs ahead of the normal application startup. Several years of experience with complex wrappers at Sun have shown that the delay in startup time is trivial and the benefits overwhelming.
The biggest cost to consider is the flip side of the greatest benefit—wrappers are powerful, so they require care. Wrappers present consistent behavior to large numbers of users. If wrappers are well produced and maintained, they deliver gratifyingly reliable service and prevent many problems. On the other hand, if wrappers are broken, service to large numbers of users may be impacted.
One of the great advantages of wrappers is that you can introduce them immediately into almost any application environment. Once you develop a wrapper for a given application, if the command names that link to it are installed in a location already in the users’ paths (for example, /usr/local/bin), you can make the application immediately available without needing to do anything to set up the user environment.
To provide a limited implementation, you can decide how many wrappers you want to provide, and for which applications. You can write wrappers as you add new packages, and you can write wrappers for older applications as well. You can create links to the wrappers in a directory already in the users’ paths. Alternatively, you can create a new directory that contains the links to the wrappers.
The tasks involved in setting up a limited implementation of an application server with wrappers include the following:
| Previous | Table of Contents | Next |