The DataNav portal application has a distributed client-server architecture with three primary components. On the server side is DataNav Server, a Java servlet application that runs within a Java servlet container, authenticates registered users, and manages access to the portal's content. It responds to all client requests to query or modify portal data, while protecting the integrity of that data in the face of intertwined read and write accesses from potentially many clients. To simplify that task, most modifications to portal content are restricted to the level of an entire archive: authors can upload and mount a new figure or data archive, unmount an existing archive, or mark an archive as private or public (private archives are visible only to registered portal users). The portal content itself is maintained on the server host machine's file system, and DataNav Server accesses it via standard file IO calls (there are currently no plans to replace the file-based repository with a database design).
On the client side are two applications, DataNav Builder and Viewer. Portal authors create, modify and review their own data and figure archives in Builder, a Java application which stores the user's own collection of archives -- the "archive vault" -- within his DataNav workspace on the client machine.Â
All the work involved in initially designing and constructing an archive happens in Builder. When the archive is ready for "publication", the user can logon to the target portal and "mount" the archive. The entire archive is removed from the user's local workspace, uploaded to the remote portal server and added to the portal's archive vault. The user requesting the mount is automatically designated the owner of the archive; only the owner can unmount the archive from the portal, or mark it as public (accessible to anonymous clients) or private (accessible only to registered users that have logged into the portal). Furthermore, only the archive owner can grant other registered users write access to the archive; doing so permits multi-user collaboration on the design, construction and maintenance of that archive. Down the line, if the mounted archive needs updating, its owner or any approved collaborator can "checkout" the archive for revision. At checkout, the server makes a private internal copy of the archive. Revisions are made to this private copy, which is "seen" only by the user that holds the "checkout lock" on the archive. That user may work on the checked-out archive for an indefinite period of time, over many login sessions. Meanwhile, the original archive remains "live" on the portal for others to explore. Once the revisions are complete, the user "checks in" the archive. Server replaces the old version of the archive with the internal copy containing all of the revisions, then releases the checkout lock. At this point the updated version of the archive is visible to all and is once again available for checkout. This "check out, revise, and check in" strategy is far easier to implement than allowing fine-grained modifications of any "live" archive on the portal. (However, it does not support editing the archive "offline"; the user must be logged into the portal in order to make changes to the checked-out archive.)
The third application component is DataNav Viewer, a web client by which anyone can explore portal content within the context of a web browser. It is currently implemented in Javascript + HTML, taking advantage of the open-source Yahoo UI framework and the HTML 5 canvas element to render polished views of portal content.
You can learn more about each of these DataNav application components in the subsections of this chapter. Before doing so, it is important to understand the conceptual design of the portal's fundamental structural units, the data and figure archives. Read on.