## 3 7R Data Value Framework in Practice
### Application Design, Development and Deployment
#### 3.3.2 R7 (Run): Running Scalable Data-Driven Apps  
The Fusepool platform and applications consist of a set of components and frameworks, some from existing Apache projects and Java frameworks. Fusepool added key technologies and integration to the existing features and contributed new open-source components. Some of the main frameworks include:  
* Apache Stanbol: The result from a previous project, Stanbol offers a wide range of tools to discover entities in unstructured text documents. The Stanbol enhancers provide an extensible mechanism to process and semantically enrich content, including components for transformation to text, as well as for natural language processing;  
Figure 3: Graphical user interface of the Fusepool Firstswim dashboard.  
Figure 2: Mockup of the graphical user interface dashboard.  
* OSGi component architecture: OSGi specifies component architecture for the local interaction within a Java virtual machine. OSGi promotes modularization of the application providing a model for versioned libraries, as well as service architecture. The Fusepool platform relies on the core OSGi specification, as well as on the declarative service specification of the OSGi compendium [25]. The latter allows it to easily build services extending platform functionality;
* Authentication and authorization: In effect, Apache Stanbol had no authentication or access control mechanisms. The adopted approach leverages existing security mechanisms built into the Java Platform and some libraries from Apache Clerezza. All security-related code was contributed to the Apache Stanbol project and accepted by the Stanbol community and part of the Stanbol distribution;
* Search and indexing: Apache Lucene and Apache Solr are fast and scalable indexing and search tools running on the Java platform. Lucene provides basic search and indexing. Solr frontends Lucene with an HTTP interface.  
The Fusepool platform and applications are running on a cloud infrastructure provided by Amazon Web Services. Installation was no different than on a local platform running the UNIX operating system. To estimate cloud infrastructure costs, a controlled testing environment is needed. A controlled testing environment allows performance measuring under predefined scenarios to test the application and evaluate run-time costs under realistic production scenarios and usage conditions.  
The test environment was set up early in the project on local servers that were later moved to cloud servers. The benefit of a controlled testing environment is that the project team exactly knows what versions, components and functionalities are running. Through Fusepool end user involvement and tasks assigned to them, the project team also knows how many users are using a particular functionality at a given point in time. If done over time, the project team learns how changes to the software affect performance and run-time costs. The closer the testing environment resembles the real-time conditions, the more valid are the results. The outline of cost measurement provides guidelines for measuring costs in a controlled testing environment.  
Typical cost drivers of cloud computing infrastructure:  
* CPU clock usage hours;
* Persistent storage levels;
* I/O requests, API requests;
* Data transfer (outbound).  
Typical questions to investigate when measuring cloud computing costs:  
* Cost of storing a document?
* Cost of one entity extraction?
* Cost of one entity interlinking? Figure 4 below shows a spike in costs during the high volume of interlinking activity on the Fusepool cloud platform hosted on Amazon Web Services.
* Cost of supporting one user?Controlled testing plan for Fusepool:  
* Functions and usage (e.g., interlinking);
* Components and services (e.g., SILK);
* Track cost factors over time (e.g., CPU, data store);
* Link resource usage (e.g., time, downloads) to cost factors (e.g., Amazon bill).