Pattern - Deploy by Copy

In Deploy by Copy, the application is deployed by a simple copy. Usually it is demonstrated by drag and drop in the file manager, as someone manually copies a file over.

After the twenty-fifth time, boredom sets in and someone ends up trying to automate this. Fortunately, deploy by copy is easy to automate, compared to installation GUIs.

Features

• The application server/container polls/monitors the a directory
• When files of a specific type are added there (example Tomcat looks for WAR files, JBoss for WAR, EAR, SAR and others), the file contents are deployed.
• When the file is deleted, the contents are undeployed.
• When the file is updated, the previous contents are undeployed and the new version rolled out.
• Usually, the contents of the file are copied somewhere, so that they will be available during undeployment.
• On Unix systems, symbolic links may be used instead. This offers a rapid way to deploy files

Advantages

• The normal OS GUI provides a drag and drop interface for deployment.
• Easy deployment/undeployment from the command line.
• Easily scripted in shell scripts, Makefiles, Ant. etc.
• Secure remote deployment supported via SCP.
• Integrates with RPM and .deb installations.
• IDEs/build tools can be set up to build the target files in situ, for rapid deployment cycles.
• Integrates with the operating system's security model: only users with write access to the target directory can deploy or undeploy files.
• No need for proprietary installation GUIs, and the testing and documentation that goes with them.
• If the target file is managed under SCM, you can have [SCM-managed filesystem deployment].

Disadvantages

• The bigger the file, the longer the copy.
• The filename is often used to determine the name of the deployed application. In Java Web application servers, the WAR file determines the path of the application -part of the full URL. What is really an internal artifact is exposed to the end user.
• No atomic deployment of more than one file, without a transacted file system.
• Hard to implement for applications that want to adjust the Registry or other aspects of the OS.

Compared to other ways of deploying applications, deploy by copy is a wonderful way to deploy applications. It is much better than web based upload and other custom approaches that the early application servers used to use -and it offers better security too.

SmartFrog support

We have a DeployByCopy component in the sf-www package. This component will copy a file on startup, and delete it when terminated. This can be used to deploy to any of the mainstream Java application servers.

We don't yet support Deploy By Copy of SmartFrog components itself. It is something that is on our todo list (SFOS-149); the vision being that a component would watch a directory for changes; when a link to a directory is added, a .sf file in that directory will be loaded. Why the separate file? Because we could add dynamic classloading and other features, features of interest in an [OGSi runtime]