Published on ONJava.com (http://www.onjava.com/)
 See this if you're having trouble printing code examples

Replace those Shared Drives with Space Drives

by Robert Flenner

Shared drives have been popular for some time in business departments and workgroups. You can easily set up a share on your local network and begin swapping content. Typically, an administrator or the department "techie" defines the share and announces its availability. You know the drill -- the email is sent out proudly announcing:

"We now have a shared drive. Please start putting all of your templates, docs, manuals, forms, etc. on the S: drive."

Usually an enterprising team member defines a straw man directory structure for the department. In addition, each team member is free to use a certain amount of space for his or her innovative and entrepreneurial purposes -- e.g., fantasy football team rosters.

Any number of version control mechanisms and techniques are demonstrated on the share and probably not well documented. For instance, Joe uses the increasing file number technique, Sally uses the alphabet soup approach, John uses a best guess date, and Fred, well, Fred is always a problem. No one in the department quite understands Fred's techniques, but then that's another story.

Before long, the drive becomes filled with files and directories. Periodically a grooming process is required. Oh, yes, and then the next email:

"Would the owner of directory 'My-Important-Stuff' please let us know if this can be deleted?"

And so the story goes. All is well in "share-land" for awhile, but then the fateful day occurs. The network server is having a bad day. The shared drive is not accessible. No one can work. You guessed it: the next email (when the system is up again):

"Don't just depend on the shared drive. Make sure you copy needed files to your local machine, so you can continue working when the server is not available."

Everyone in the department proceeds to copy the files they need from the share to their local PC. Of course, ensuring synchronization of content in this environment is impossible.

OK, you say, if it is that bad, why have shared drives proliferated?

Truth is, they are extremely valuable. They provide the underpinning to sharing and simple collaboration. They are easy to use, require no training or procedures, and quickly become an instrument for team cooperation and departmental organization. They help the group function with minimal investment.

Technically and functionally, shared drives do have shortcomings and limitations. They are based on a client-server model. Files copied to the central server are pulled from the server when needed and pushed back in an ad hoc fashion. Multiple copies of the same information tend to flourish despite central controls. Synchronization and versioning are problematic.

Figure 1. Shared drive scenario.

Shared drives support a limiting single view to the information, usually nothing more than the directory structure. Often, this becomes out of date and quickly bypassed by share members. Finding the correct file can become difficult in the directory maze. As noted, a single point of failure can bring the entire system to a halt. In addition, security and permissions are wide and broad for all group members. This makes it impossible to keep any type of audit trail.

Table 1. Strengths and weaknesses of share drives.

Easy to learnConstantly pushing and pulling content
Promotes sharingMultiple copies/versioning difficult
Single view
Broad permissions
Single point of failure
Yet another administrator

What are Space Drives?

Space drives provide an alternative or complementary technology to shares. They reflect the flow of information within your departments. Simply stated, a space drive is an index to content on the network, wherever it resides. It follows the natural flow of information from user to user; however, it does not attempt to force location or permanent ownership of content on a single entity. Space drives can go far beyond simply knowing where information is. They can be used to generate events and proactively alert you to changes in information or critical moments in the life cycle of a project or initiative. They are more "active" than simple shares. They create the foundation for building a collaborative workspace.

There are three primary components to the architecture of a workspace using space drives -- content, messaging, and workflow -- as shown in Figure 2.

Figure 2. Elements of space drives.

Content Index

The indexing component provides a simple mechanism to name and locate information on your network. Any member of the group can add an entry to the index. This will usually be a filename and a URL that points to the file on a server or your PC.

The content component allows you to download and view files in a peer-to-peer style of content exchange. You can publish a portion of your computer's directory to a shared space that is managed by the content service; therefore, you can add files -- although they remain on your PC -- to a shared repository. The content service maintains an index to all shared space drives. If you have given access to a file to another member in your group, that member can transfer your file to his local machine from your machine. In addition, all group members can share and exchange files located within the group shared space. The important point to note is the current version remains on the owner's PC, unless ownership is transferred. Therefore, the most recent changes to the file are always available. You can even monitor the progress of work as it's happening!

Content indexing involves recording the owner, the location, and the detailed shared space definition. A ContentMap captures the user ID, space ID, and location, defining a mount point on your local machine. The space ID is simply a name given to the space drive. A space drive is defined by a simple content map.

public class ContentMap implements Serializable {

    public String userId;
    public String spaceId;
    public String localPath;

    public ContentMap(String userId, String localPath, String spaceId) {
        this.userId = userId;
        this.localPath = localPath;
        this.spaceId = spaceId;

A user may define one or more space drives on their PC or any network-accessible machine. A share index maintains a list of content maps by user. Every shared space definition is added to the share index for that user. Every shared space has an owner. An owner is the user that initially defines or creates the shared space definition. A share index is also maintained for non-owned shares. These are the shares that you have been given access to by another share owner.

Content, such as files, images, etc., is assigned a content ID. Files are organized into sets. A combination of userId/spaceId defines a unique file set. A combination of userId/spaceId/contentId defines unique content in the workspace. Clients use the Content interface to identify and locate content. A simple interface is defined as:

public interface Content extends Serializable
   public String getLocation() throws RemoteException;
   public String getId() throws RemoteException;

The getLocation method returns a String URL and the getId returns a unique identifier. HTTP can be used to view and transfer files from any machine associated with a group member. Ownership is based on definition, and data can reside at the point of most recent use.

The following ContentAdapter interface is implemented to transfer any object implementing the Content interface to your local machine.

public interface ContentAdapter {

  public void transfer(Content from, Content to) throws 
                                 RemoteException, IOException;

  public URL createSource(Content content) throws 
                                 RemoteException, IOException;

  public FileOutputStream createDestination(Content content) throws 
                                 RemoteException, IOException;


Meta data can be associated with the space index entry to provide descriptive information and improve search capabilities. Default meta data can be generated to keep the system at an acceptable content-knowledge level. For example, many of the elements of Dublin Core Meta Data can be created programmatically, if not entered manually.


Shared drives are common in organizations; shared spaces are not. A shared space goes beyond simple file sharing because it is integrated into the messaging and notification structure of the workspace backbone. For instance, you can create departmental shares for each department with which you exchange documents and communication. All of the marketing group would be given access to the marketing space, and all of the sales group would be given access to the sales space. You can also define a shared "marketing - sales - development" space. In effect, you are linking and segmenting user machines along logical boundaries, not only for content, but also for communication. Alternatively, you can define shares that map to workgroup processes. The status of work artifacts can be equated to physical location.

When you are added to a shared space, you are automatically registered for shared space events. Members of the space can be notified when changes to the shared space definition occur, e.g. when member additions/removals or content additions/deletions. Clients receive notification of the change through the content service and update their views appropriately. Views can be built using asynchronous notification or using polling techniques. Instant messaging, as opposed to email, is the norm in the space drive environment. Attachments can often be eliminated or dramatically reduced. Space messaging builds on the concept of loosely-coupled communication using a "space channel." A space channel is a named ordered set of messages. Therefore, you can define content shares that map to communication channels.

Figure 3. Space drives are event-driven.

All elements (share, channel, and group) can be referenced by the same logical name. Groups can be defined around shares and channels. This is similar to defining share drives and email groups for departments. However, there is no explicit relationship between these technologies. Space drives assume the relationship between content and communication and leverage that relationship for messaging and notification. For instance, channels are automatically established with members of shared spaces.

In addition, users register to receive messages from specific channels. This can be equated to a "buddy list" or a roster in instant messaging products. Messages written to your user id/channel can be read with a simple "receive" request.

public interface MessengerInterface {   

    public void send(ChatMessage message) throws RemoteException; 

    public ChatMessage receive(String channel) throws RemoteException; 

    public void register(String channel, RemoteEventListener subscriber) 
                                                 throws RemoteException;

The ChatMessage simply contains the To: and From: user IDs, which may reference single users, groups, or the entire workspace.

You can belong to one or more groups. The group ID is used to segment the group workspace.


Messages sent to a group channel are available to every member of that group. This provides a group, or "multi-casting," type of messaging within the workspace. Finally, the broadcast channel is used to identify the global workspace. Every user is a member of the global "WorkSpace" channel. A message of the day and timely information can easily be delivered to an entire workspace group. Space messaging provides a simplified approach to dynamic communication, coordination, and sharing of objects between network resources.


Finally, the workflow component of a workspace provides the scheduling and event notification process in the space drive environment. This allows participants to exchange tasks and requests, and monitor the progress of work processes.

Your workflow process definition is composed of a collection of work items. Work items model specific tasks in the workflow system. Of course, workflow applications can use any number of approaches. For example, you could use XML to define process templates and task execution policy.

Figure 4. Workflow process definition.

Every work item in a process has an associated task. A task is modeled to reflect the current state of the work item. Each task defined in the workflow component implements the ActivityState interface. This interface is implemented to provide task-specific, state-change processing for the activities under workflow control.

public interface ActivityState extends Serializable
    public static final String TASK_INIT = "inactive";
    public static final String TASK_READY = "ready";
    public static final String TASK_START = "start";
    public static final String TASK_COMPLETE = "complete";
    public static final String TASK_SUSPEND = "suspend";
    public void start() throws RemoteException;
    public void terminate() throws RemoteException;
    public void suspend() throws RemoteException;
    public void resume() throws RemoteException; 

A workflow component can also use the messaging component to deliver warning messages to users assigned to tasks in trouble. An alert event can be used to trigger asynchronous notification to owners of processes and users assigned to specific workflow tasks.

Improved communicationMore complex to set up
Improved collaborationAdditional software required
Selective membership/permissions
Workflow- and task-oriented
Multiple views
Minimal Administration


The coordination and integration of content indexing, messaging, and simple workflow using space drives can go a long way towards improving the coordination of activities that most workgroups engage in daily. Many of the shortcomings of share drives can be eliminated and a new level of automated communication is easily in reach.

The growing Internet economy will mandate improved coordination and automation of processes both internal and external to an organization. Efficiencies are gained by integrating internal systems with users, partner systems, and external customers. Coordination of activities and dissemination of information within and across organizational boundaries are essential factors to improving effectiveness.

Space drives are a first step in creating an effective platform for content, community, commerce, and collaboration.

You can test an example space drive implementation at www.jworkplace.org.

Robert Flenner is an active author, software developer, and independent contractor who is actively involved with emerging B2B technologies.

Return to ONJava.com.

Copyright © 2009 O'Reilly Media, Inc.