## 7 Empirical Evaluation and Prototype Implementation  
The empirical evaluation for the blueprinting approach aims to understand how well the proposed blueprint template can support the industry companies in describing their cloud service offerings. It started with a collaborative case study design with our industry partners in the 4 caaSt project such as Telefonica, TelecomItalia, 2 ndQuadrant and SAP, which resulted in the _Taxi Order Process Scenario_ introduced in Section 2. Then, we implemented the proposed Blueprint Template in XSD and distributed it to the 4 caaSt community to get feedback. We organized a \"blueprint training\" virtual workshop to explain the concept of blueprint and train our industry partners how to use the XSD blueprint template. As the cloud service offerings identified in the case study are the real industrial offerings of our partners, we requested them to use the provided XSD blueprint template to describe their blueprints in XML and submit them to our blueprint repository. Figure 10 presents a snippet of the instantiated XML document of the \"unresolved\" target blueprint _AutoInc-Blueprint_ from our case study. The VA section in the _AutoInc-Blueprint_ blueprint can be visualized by the \"unresolved\" VA graph on the left side of the Figure. As mentioned in Section 6.2, resolving a target blueprint means to replace the requirement IDs in its VA template section with the IDs of the offerings of the newly retrieved source blueprints. We used XQuery [29] for accessing and modifying data inside the XML document of the _AutoInc-Blueprint_ blueprint. Our evaluation has shown that the proposed blueprint template is capable to capture all the necessary aspects of an industrial cloud service offering and simple enough to be used by our industry partners. Following our guidelines during the blueprint training workshop, a TelecomItalia representative was able to design a blueprint \"on-the-fly\" for his offering. We experienced just a little amount of emails exchanged for the blueprint template support, which confirms its simplicity of use. Apart from the evaluation of the blueprint template, we have worked towards a comprehensive blueprint tool for supporting the application developers during the entire SBA development lifecycle introduced in the previous Section 6. Figure 11 depicts the prototype architecture of the blueprint tool. The Blueprint Headquarter (BlueprintHQ) server provides the SOAP API for the following three operations: _getBlueprint(BlueprintID)_ to retrieve a blueprint from the repository based on its unique ID, _getBlueprints([property, value]*)_ to retrieve several blueprints based on their property values, and _resolveBlueprint(BlueprintID)_ to resolve a blueprint by invoking the Blueprint Resolution Engine [30]. This API is consumed by the marketplace component provided by our 4 caaSt partners Telefonica and SAP to produceize a blueprint and advertise it in a marketplace. The API is also consumed by the BlueprintEXE server that supports a web-based user interface for visualization purpose. Figure 12 illustrates the VA graph visualization of the sample \"resolved\" _AutoInc-Blueprint_ blueprint on the web interface of the BlueprintEXE. All the components of the blueprint prototype, _i.e._, the BlueprintEXE, BlueprintHQ, blueprint repository and blueprint resolution engine, are currently hosted on a Flexiscale virtual machine [31] (supported by our 4 caaSt partner Flexiant). Figure 10: XML implementation of the sample _AutoInc-Blueprint_. Figure 11: Blueprint Prototype Architecture. Figure 12: The web interface of our blueprint prototype showing a resolved blueprint. The blueprint prototype has shown the feasibility of implementing a tool for the blueprinting approach. In particular, we have merely focused on the blueprint support for the first three phases of the SBA development lifecycle described in Section 6, namely the design and reuse of blueprints for SBA development.