- Introduction
- DDS Standards
- DDS System Processes
- Decentralized Application Deployment Process
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
DDS System Processes
Because the best way to ensure the viability and stability of the production system is to ensure that no one has the right to disrupt it, most organizations don't want to give installation rights to local developers. For this reason, the core components of the production system should include distributed application support. Each corporate-wide development tool should include a runtime version. This means that all of the program components required to execute a program written by the development tool can be separated from the program and installed independently. These are the components that require installation rights on a Windows 2000/XP system because they must be integrated and registered in the system. These components can be included into the basic system, thus eliminating the need for decentralized installation. Files created for application enhancement can be copied to the system instead of installed on the system. And since all users have file copy rights to specific folders, decentralized applications can easily be installed without actually giving installation rights to developers.
For example, Microsoft Access and Microsoft Visual Basic for Applications both include runtime editions. These runtime versions must be included into the corporate system (see Figure 1). Like all other system components, they must be managed and updated as required. When developers create applications, they must ensure that the applications are designed to run with runtime components, instead of requiring the actual application to run. Thus when developers must "install" an application, all they need to do is copy the files to appropriate locations on the PC, since the runtime is already included into the system. They don't need to have elevated rights to do this.
)
Figure 1 A corporate production system should be designed to include the
installation of corporate runtimes.
Thus, the production system must make allowances for these types of applications. By including the runtimes into the system, the issue of installation is resolved. This must be complemented with special DDS folders within the system. These folders give copy and edit rights to both users and local developers.
In addition, local developers must be able to deploy their applications. Since they don't have access to traditional deployment tools and since they don't want to go from desk to desk to manually install their tools, they must use other means—means that fit within corporate standards.
Most organizations don't have complete inventories of their decentralized applications. Local developers often justify this by saying that their department is special and has needs that are not required by others. Developers prefer their own approaches. For this reason, many organizations have four or five timesheets, four or five corporate letter templates, and four or five expense sheets. This occurs because the corporation overlooks two processes: inventory and communication. If there is no inventory, it's difficult for the corporation to identify and manage its assets. It's also difficult for the corporation to communicate to decentralized developers all of the products that it owns.
Decentralized developers are a part of every network. They should be organized as a team that provides the same type of function at local levels. This team should be structured through standards and processes, just like every other part of the corporate network. These processes should include centralized systems for decentralized development support.
The centralized system should consist of an application depot that includes all of the elements required to make the application work properly. This should include a master directory for the application. This master directory is named after the application's asset number (four digits is usually sufficient). Subfolders should include the following (see Figure 2):
Clients. All client components that must be copied to a PC.
Documents. All product documentation or links to user documentation on the intranet.
Icons. The application's icon on the desktop.
Shortcut. The program's shortcut.
Source Data. If the application requires shared data, it should be located here.
UserGroups. This folder contains the list of authorized users.
)
Figure 2 DDS depot structure.
Each application folder always contains the same subfolders. Shared databases are stored centrally. Updates are applied centrally and downloaded to desktops automatically by the shortcut.
Users should be allowed read and execute rights on this deposit. Developers should be allowed read, write, and execute rights to their own particular application directories. New application directories should be created centrally through the inventory and asset management process. This process should automatically publish information on the application to the central intranet application inventory page. (Developers can also use this page to search for existing applications.)
An additional tool—a code-signed VBScript (VBS) that replaces the normal application shortcut on the desktop—supplements the central application deposit. This script performs the following steps:
Shortcut launch. Instead of launching the application, the VBS shortcut begins the authorization and update/installation process.
Authorize users. Is the user authorized?
The VBS shortcut reads the file GROUPS.TXT within the UserGroups subfolder to determine whether the user is authorized. If yes, it moves to the next step.
If no, it stops operation and displays an "unauthorized user" message.
Install/update verification. Is the application on the user's PC?
If yes, is there a new version of the application? If no, behave as a normal shortcut and launch the application.
If no, the shortcut copies itself to the PC and then proceeds with the next step.
Install/update/launch. Does the application include local or updated local components?
If yes, copy the contents of the Clients subfolder to the local PC, and then launch the application.
If no, launch the remote application.
Since core DDS components are already in the system, the DDS installation process is a simple file copy. This process is illustrated in Figure 3.
)
Figure 3 A DDS application "installation" process.
This simple program serves several purposes:
It validates user authorizations.
It automatically installs or updates local components (if local components are required).
It automatically performs an application validity check at startup.
Decentralized developers can use the VBS shortcut to manage all of their updates and installations. By properly placing all of their applications within the structure of the DDS depot, they can facilitate their application management process. They can use the VBS shortcut to automatically install applications on user systems. This can be done through a simple email message to the user. Before doing so, the developer must ensure that the user's name is included in the GROUPS.TXT file on the server. When users receive the email message, all they have to do is launch the shortcut and the VBS program will automatically install, and then manage the application through its lifecycle.
One single VBS shortcut program can manage all of the decentralized applications within a corporate network. The only object that developers need to modify is the VBS shortcut itself, through its properties. This must be done to ensure that it points to the appropriate application directory on the server. Figure 4 illustrates this modification.
)
Figure 4 Modifying the VBS shortcut properties.
Several other technologies can be integrated to this process as technology changes within the network. For example, the VBS shortcut could verify actual user groups within the security database (such as Active Directory) instead of user lists in text files. But this change would require central administrators to give DDS developers rights to manage their own distribution groups within the security database. This is not a very likely scenario today, because delegated management of distribution groups is a new concept brought about by directory-enabled networks (DEN) such as Windows 2000.