15.5 Deployment Considerations

Some WebDAV tools or proven approaches can be used to deploy a new WebDAV-based application or to maintain an existing WebDAV system.

15.5.1 Migrating Existing Repositories

Many custom applications evolve from previous systems. Over time, these systems tend to become out of date or strain at the seams, and eventually the system may need to be redesigned to take advantage of new technology such as WebDAV.

There are three major variations in this kind of task. The simplest is a pure migration, where all the data is moved to a WebDAV system, and the old access methods are no longer available. When a pure migration is not feasible because the old access methods must still be available, there are two choices. First, the data can be moved to a WebDAV-based system and the new repository exposed using the old access method. Second, the data can remain in the non-WebDAV repository, and a WebDAV "wrapper" or access layer can be added.

Migrating Data

If it's feasible to migrate data to a WebDAV solution, the job ought to be simpler in the long run. The migration can be challenging, but the resulting system is less complex and should be easier to maintain than a dual-access system.

Content can be migrated to the WebDAV repository all at once, but it doesn't need to be. A large insurance company used WebDAV for its new underwriters repository. Because the existing repository was so large, in-house developers wrote some migration tools to transfer documents "on demand" (see Figure 15-1).

Figure 15-1. Migrating data to a WebDAV repository.

When the WebDAV system was asked for a document, if it hadn't already been migrated the requested document was immediately moved to the WebDAV system so the request could be answered. When the system had some spare cycles, unused documentation was also moved to the WebDAV repository. The old access methods continued to work, and the gateway provided old-style access to documents that had already migrated to the WebDAV repository.

Wrapping an Existing Repository

This can be the hardest and the least reliable method, but sometimes it's the only choice. The reason it's so hard is that existing repositories rarely have compatible functionality to support WebDAV, if the functionality is there at all. It may only be worth doing if there are compelling reasons to support WebDAV authoring applications.

If the old access method (e.g., FTP, HTTP, proprietary protocols, or APIs) must still be available but WebDAV locking must also be supported, the data must be in a repository that truly supports locking. Otherwise, locks are hard to make work correctly through a gateway (see Figure 15-2).

Figure 15-2. WebDAV shim or gateway.

Here are the major challenges:

• Properties/metadata. Most existing repositories do not have unlimited space, if any, allocated for metadata. Most existing Web servers could quickly support DAV level 1 (no locking) if it weren't for the lack of metadata storage. Even if metadata storage is available, WebDAV can easily bump up against the limitations of that storage. The amount of storage may be limited, or access could be slow.

• Locking. If the existing repository does not support locks or has a different locking model, it can be difficult to support WebDAV locks. It can be fairly disastrous if WebDAV clients rely on locks but the old access method is allowed to circumvent locks.

• Versioning. If the existing repository does support versioning, and if versioning will be exposed using WebDAV and DeltaV, make sure the models are compatible, particularly checkin/checkout.

• Access controls. If the existing repository has poor access control or simply a different model, it may eventually become a serious security problem. A WebDAV layer that does support access control will be unable to enforce security for protocols that bypass WebDAV. It's hard to make users sufficiently aware of this complexity to use the system in a secure manner.

15.5.2 Synchronizing Sites and Collections

Some deployment and maintenance scenarios involve duplicating a large number of files one time or repeatedly synchronizing a large number of files:

• A new repository is being deployed. Synchronization may be used to transfer content. When the synchronizing software reports no differences between the repositories, the old repository can be phased out (made read-only, taken offline, or content deleted).

• A Web site developer works on a local copy of a large Web site. Files are changed and tested locally, and then when the Web pages are all consistent, local versions are synchronized with the server.

• A Web server used for development and verification (a "staging" server) may be synchronized with the public Web server when new pages go live.

• Two WebDAV servers host the same data but in two remote locations. Because users access the data frequently at both sites, the same data needs to be stored in both locations to be accessed quickly from each. However, changes are only made at one location, so the read-only location can synchronize from the master location.

• A one-time copy, import, or export (e.g., when a bunch of file system data is being loaded into a WebDAV repository for the first time) can behave like a synchronization task. The data is synchronized once, and then when the WebDAV repository is running, the file system copy of the data can be deleted or archived.

Often these situations can be handled nicely with simple synchronization software (made relatively easy by WebDAV servers' support for ETags and last-modified datestamps). Some of the tools that do synchronization include sitecopy for Linux and Xythos WebFile Client for Windows.