## 3 The SciFlow Approach to Scientific Writing
### Four Guiding Principles
#### 3.2.1 Scalability  
The SciFlow concept is based on a distributed cloud architecture, using web services (e.g., for PDF creation, backups or review) to outsource what does not have to be computed on the author's machine. For each of these web services multiple instances may be launched to cope with high work load. While the distributed structure keeps the SciFlow writing client slim and quick to install, it also raises the question of scalability; _i.e._, the constant availability to all users.  
SciFlow uses a service directory to accomplish loose coupling between all connected services. This directory holds references to all instances a web service. For the directory not to become a bottleneck itself, it is hosted on a distributed system, ensuring high availability (e.g., Amazon Web Services [25]).  
While distributing the directory onto several machines may be sufficient to implement a simple service directory, more complicated web services require a greater effort to scale. It is vital to the scalability of the concept that three conditions hold true.  
1. When the work load a web service experiences, depends on the number of people who use the system, it has to be possible to _instantiate this service an arbitrary number of times_ without manualintervention. An example for such a service would be the document publishing service, which creates PDF files from a document and a given document template. In this case, the demand for the service will rise with the number of authors, thus more instances will have to be made available.
2. To manage an arbitrary number of services, communication between components, e.g., the client and the services, has to be robust. This calls for an asynchronous communication structure, so messages may be delivered when a service is available and held back when it is unresponsive. Such a communication structure will also allow to handle multiple instances of a service: Addressing a message to an arbitrary service allows for service instances with free capacities to accept the message, instead of letting the message sender choose the instance. If no such service is available, the message will wait until the situation changes or more instances of the particular service are launched. This calls for monitoring as we shall now explain.
3. To ensure scalability, the number of services within the SciFlow system has to reflect the number of requests, made to a particular service. For the asynchronous communication structure this means that the number of messages requesting a specific service has to be monitored. Since (1) all services can be launched an arbitrary number of times and (2) the asynchronous communication structure allows for launching and stopping of services without interrupting ongoing operations, a high number of messages may be dealt with by launching an appropriate amount of new services.  
Implementation To honor the three conditions we have just introduced, each component of SciFlow has been implemented to be started autonomously. Additionally, services like the document publishing service may be run on most linux environments with the _dblatex_ packages and _DocBook XSL templates_ templates installed. This makes the use of cloud computing possible (e.g., Amazon EC2).  
With _Amazon Simple Queue Service (SQS)_ we have found an implementation of an asynchronous message structure, that was built with high load in mind [26]. SQS allows us to monitor the number of messages at any given moment [26] and to also handle a high number of read and write requests to the message queue. SQS accomplishes this by sacrificing data consistency. It is run on a distributed system, meaning that there are multiple instances of the message queue that synchronize themselves. While this may cause for two simultaneous read requests to differ from each other, all instances of the message queue will be consistent eventually. For SciFlow, this is sufficient.