Sample Application: Document Editor

As a software developer you are often in the situation that you need to add functionality to an application for which it wasn't originally built. A typical example for extending an existing solution is remote communication functionality. Maybe you want your application to also be accessible from other machines in the network (or even across the internet). Or your local application isn't capable any more of satisfying the processing power you need, so you want to scale to other machines across the network.

The document editor is an example for such an application. With this example we want to show you how easy it is to extend such an application with different kinds aspects of remote communication functionality, using the application space. You can find the source code in the download section (contians both the original and the appspace-extended version).

Document Editor: Overview

The document editor is a somple application for locally storing text documents. It allows you to give a document a name and assign a certain text to it. It has functions for storing and loading documents, as well as for finding documents that contain a specified search text. When searching, the GUI shows a progress bar for the search progress. In the background, the documents are simply stored as files.

New Features

The following new features should be implented for the document editor:
  • Documents should be accessible from other machines in the network. Therefore, the application needs to be split into a server that hosts the documents, and a client that can access this server.
  • Documents should be shared with friends. Therefore, multiple users should be able to access documents at the document repository at the same time. Since the original document editor only had to deal with a single user, this point is especially interesting, because the current implementation is not thread safe. Since the document editor stores files using the file system, concurrent access to the same files can lead to errors, because of which access will need to be synchronized. But of course, concurrent access should still be possible as long as it doesn't lead to errors. This means that storing a document needs to be an exclusive operation, while loading and searching should be possible concurrently.
  • When a new document is stored, all users that are currently online should be informed about it.
  • It should be possible to give users either read or write privileges (read: allowed to load and search documents - write: allowed to store, load and search documents).

Solution using the application space

Although the list of features is not that big, there are some non-trivial things in it, which can be problematic with other middleware solutions, and/or lead to complicated and hard to understand code. Also, there are some tricky points which may not be visible in the feature list, but come to light once you start implementing. With the appspace you can easily deal with all of these problems:
  • Access across network: The appspace easily allows communication across the network, if needed even across the internet.
  • Multiple users: With appspace workers, you can define operations as either concurrent (load, find documents) or exclusive (store documents), needing no additional efforts for synchronization and thread safety.
  • Event for new Document: This is easily implemented with the application space using the publish/subscribe feature.
  • Security: Can be implemented with the appspace security service, allowing to define per worker port, which user roles are allowed, making it easily possible to define roles for read and write access.
  • Progress Bar: Although it may seem a simple feature, sending multiple responses to a single request is not that simple with other communication middleware (e.g. WCF). The message based communication paradigma makes the appspace perfectly suitable for this kind of communication.
  • Error Handling: The original implementation of the document editor just threw an exception when e.g. a document that should be loaded didn't exist. What to do with this exception in a distributed scenario? With the appspace you can use causalities to transport exceptions directly to the client - no need to handle this on the server side seperately.
  • No freezing GUI: Remote communication can take significantly longer that a local method call. In such a case of course we don't want the GUI to just freeze until the response is received. With the asynchronous messaging paradigm of the appspace, as well as methods especially designed for handling async gui operations, you get this problem solved easily.

See the download section for the source code of the appspace-extended document editor.

Last edited Mar 4, 2011 at 3:04 PM by thomass, version 3


No comments yet.