## 2 Motivating Scenario  
This section presents an enterprise cloud computing scenario developed for the EC's 4 CaaSt project. Several industrial IT companies like Telefonica, Telecom Italia, Ericson, 2 ndQuadrant and SAP have been involved in the definition of this scenario, which is presented as a simplified description of today industrial reality. The aim is to provide a case study that is sufficiently complex for capturing real problems and sufficiently simple for proposing and validating research solutions. The scenario promotes a uniform description for cloud service offerings to exist so that the design, configuration, and deployment of a cloud-based solution can occur. The scenario in Figure 2 is about developing a process-based application in the cloud that can receive an order for a taxi from the customer by SMS, check the current status of the taxi fleet, allocate a taxi, and finally confirm the order by SMS. It contains seven actors that collaborate in a marketplace where their cloud services can be offered and purchased. In the following, each actor is described. There are three actors in the scenario that provide complete monolithic PaaS and IaaS offerings hosted on their in-house infrastructure. **2 ndQuarant** is a PaaS provider specializing in storage services. It offers the relational PostgreQL Service (_PostgreQL-PaaS_) or the relational MySQL Service (_MsSQL-PaaS_) as two alternative solutions for relational database, where each consumer can request for up to five instances of a solution. Another PaaS provider is **TelecomItalia** that provides the native Context-as-a-Service offering for context information delivery (_CaaS-PaaS_) [11]. **JonasTeam** is another PaaS provider that has two offerings in the marketplace. The first one is a JOnAS server to host Java applications including a Tomcat container to support the execution of servlets (_Jonas-PaaS_). The second one is an IaaS offering for a 3 Gbit Ethernet network link (_Ethernet3 Gbit-IaaS_). **OrchestraTeam** is also a PaaS provider that offers an Orchestra BPEL Engine (_Orchestra-PaaS_). OrchestraTeam differentiates itself from other PaaS providers in a way that their offering _Orchestra-PaaS_ is not complete and relies on external cloud platform and infrastructure resources for the deployment. In particular, the binary implementation file of the Orchestra engine (_OrchestraBinary_) needs a Servlet container (_Servlet-Req_) for the deployment. It is also required that the _Servlet-Req_ is connected to two relational databases (_SQL-Req_) through a 2 Gbit network (_NetworkLink2 Gbit-Req_). To maintain the Quality of Service (QoS) promised in their offering, _i.e._, response time \(<=2\)s and throughput \(>=110\) request/s, OrchestraTeam requires the _Servlet-Req_ to be constrained by these QoS assertions as well. On the SaaS level, **Tele1** is a telecom company that provides a basic SMS Delivery SaaS (_SMS-Delivery-SaaS_) that is hosted on their in-house platform. In contrast, **AutoInc** is an established Medium Enterprise and has spotted a business opportunity providing fleet vehicle management in the Netherlands. They plan to deploy their business functions as a Taxi Management SaaS (_TaxiMgt-SaaS_), since this provides ubiquitous and common access for their prospective customers, e.g., taxi providers and car-hiring providers. To implement the solution, AutoInc has contracted a software consultancy who wrote the taxi management software in Java and BPEL. The software hence contains a number of war files, bpel files and other binary and configuration files (see Figure 2 for more details). The software hence requires a JEE Server (_JEE/Servlet-Server-Req_) including a Servlet v2.5 for deploying the war files for the web interface, a BPEL Engine (_BPEL-Engine-Req_) for deploying the core BPEL process files of the taxi application, and a context information provider  
Figure 2: The 4 caaSt Cloud Computing Scenario. (_Context-aaS-Req_) that is needed by the _CMF.war_ file.