Cloud Computing Automation: Integrating USDL and TOSCA
•Als PPTX, PDF herunterladen•
2 gefällt mir•1,732 views
-- Presented at CAiSE 2013, Valencia, Spain -- Standardization efforts to simplify the management of cloud applications are being conducted in isolation. The objective of this paper is to investigate to which extend two promising specifications, USDL and TOSCA, can be integrated to automate the lifecycle of cloud applications. In our approach, we selected a commercial SaaS CRM platform, modeled it using the service description language USDL, modeled its cloud deployment using TOSCA, and constructed a prototypical platform to integrate service selection with deployment. Our evaluation indicates that a high level of integration is possible. We were able to fully automatize the remote deployment of a cloud service after it was selected by a customer in a marketplace. Architectural decisions emerged during the construction of the platform and were related to global service identification and access, multi-layer routing, and dynamic binding.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (12)
Ähnlich wie Cloud Computing Automation: Integrating USDL and TOSCA
Ähnlich wie Cloud Computing Automation: Integrating USDL and TOSCA (20)
Mehr von Jorge Cardoso
Mehr von Jorge Cardoso (11)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Cloud Computing Automation: Integrating USDL and TOSCA
- 1. Jorge Cardoso (1,2), Tobias Binz (3), Uwe Breitenbucher (3), Oliver Kopp (3) Frank Leymann (3) (1) CISUC/Dept. Informatics Engineering, University of Coimbra, Portugal (2) Karlsruhe Service Research Institute, Karlsruhe Institute of Technology, Germany jorge.cardoso@kit.edu jcardoso@dei.uc.pt (3) Institute of Architecture of Application Systems, University of Stuttgart, Germany {lastname}@iaas.uni-stuttgart.de Cloud Computing Automation: Integrating USDL and TOSCA Departamento de Engenharia Informática FCTUC FACULDADE DE CIÊNCIAS E TECNOLOGIA da UNIVERSIDADE DE COIMBRA Institute of Architecture of Application Systems (IAAS) Universität Stuttgart, Germany Cloud Computing Automation: Integrating USDL and TOSCA, J. Cardoso, T. Binz, U. Breitenbucher, O. Kopp, F. Leymann, CAiSE 2013, Springer, LNCS 7908, pp. 1—16.
- 2. Standardization 2013 Genessiz: Center for Large-Scale Service System Research 2 See also http://cloud-standards.orgBMWi: The standardisation environment for cloud computing. Technical report, Germany Federal Ministry of Economics and Technology (Feb. 2012)
- 3. Interoperability • Standards are being developed in isolation • It is not clear to which extend they can be integrated • Lack of certainty as to which standards can inter- operate • Streamline the lifecycle of cloud applications 2013 Genessiz: Center for Large-Scale Service System Research 3 Standardization does not imply interoperability Definition (Interoperability): the ability of various systems and organizations to work together (inter-operate)
- 4. Motivation (1) • Discovery, Selection and Customization – Done manually by consumers • Keyword querying – No advanced mechanism • Multiple queries – Different marketplaces use different query interfaces 2013 Genessiz: Center for Large-Scale Service System Research 4 AppDirect Google
- 5. Motivation (2) • After a purchase decision... – Customization – Deployment – Management • No … • Formalization of the executables • Management best practices • Etc. • Problem – Manual – Error-prone 2013 Genessiz: Center for Large-Scale Service System Research 5 Exceptions: Saleforce, Google Apps, Microsoft Office 365, etc.
- 6. 6BMWi: The standardisation environment for cloud computing. Technical report, Germany Federal Ministry of Economics and Technology (Feb. 2012) “In the course of the six months in which the study was produced, a lot of new publications appeared, not all of which could be taken into account” (e. g. TOSCA, http://www.oasis- open.org/committees/tosca/)
- 7. Research Question 2013 Genessiz: Center for Large-Scale Service System Research 7 When used in conjunction, can they automate parts of the lifecycle of cloud applications, namely discovery, selection, deployment, and management? Can USDL and TOSCA be integrated seamlessly? How can interoperability be achieved? What are the challenges?
- 8. Approach 2013 Genessiz: Center for Large-Scale Service System Research 8 DISCOVERY AND SELECTION DEPLOYMENT AND MANAGEMENT USDL/Service Description TOSCA/Service Management Use Case
- 9. Describes the structure of an application and its management (which is executable) Goal >> Portability and full-automated management of applications Describes the functional and non- functional requirements, capabilities, and interactions of a service Goal >> Description of a cloud service to make it searchable, comparable, and tradable Topology Management Plans … Interaction & functional capabilities Offerings Interactions Providers … Non-functional capabilities Pricing Legal Service Level Topology and Orchestration Specification for Cloud Applications
- 10. 2013 Genessiz: Center for Large-Scale Service System Research 10 USDL:Core Master Schema
- 11. Linked USDL 2013 Genessiz: Center for Large-Scale Service System Research 11 http://www.linked-usdl.org/ https://github.com/linked-usdl/
- 12. TOSCA 2013 Genessiz: Center for Large-Scale Service System Research 12 OsApache (OperatingSystem) VmApache (VirtualMachine) ApacheWebServer (ApacheWebServer) (HostedOn)(InstalledIn) SugarCrmApp (SugarCrmApp) PhpModule (PhpModule) (DependsOn) OsMySql (OperatingSystem) VmMySql (VirtualMachine) MySql (MySqlRDBMS) SugarCrmDb (SugarCrmDb) (HostedOn) (DbConnection) Acquire VM Install OS on VM Install & Start Web Server Install PHP Module Deploy PHP App Establish DB ConnectionInstall OS on VM Install & Start MySQL RDBMS Create SugarCRM DB Module Build Plan Topology Acquire VM SugarCRM
- 13. Solution • How to access service descriptions in a dynamic world? – Global service identification and service description access using Linked USDL • What if the provider has ceased its operations and transferred its obligations to some other provider? Who still handle the original functions? • Intelligent routing of service requests • What would happen if the TOSCA descriptor associated with a USDL description would no longer be valid? – Dynamic binding of deployment descriptors 2013 Genessiz: Center for Large-Scale Service System Research 13 WWW + Semantic web = Distributed, scalable, reliable, extensible, …[11]
- 14. Service Cloud 14 USDL-based Marketplace USDL-based Service Offerings Billing / CRM System UI … Service 1 Service N TOSCA-based Provider TOSCA Service Archives T T … Service 1 Service N TOSCA Runtime Environment Global Routing Layer Local Routing Layer Cloud Management System USDL URI … Provider Endpoint http://sugarcrm.org?enterprise … 192.182.1.3 http://redmine.org?professional … 147.11.4.79 TOSCA Routing Layer USDL URI … Plan Endpoint http://sugarcrm.org?enterprise … 111.121.12.1/SugarCRMPlan http://redmine.org?professional … 111.121.12.1/RedminePlan SIOPP Architecture Reasoning Engine Reasoning Engine Routing Table Routing Table 5 4 32 1 6 7
- 15. Service Identification & Access 2013 Genessiz: Center for Large-Scale Service System Research 15 Cloud USDL-compliant http://rdfs.genssiz.org/SugarCRM? pricePlan=pricing_SugarCRM_Ultimate 5 4 3 2 1 Query strings are a W3C recommendation Service offerings are modeled with Linked USDL A. Simple way to create unique global identifiers for services. Compared to, e.g., a universally unique identifier (UUID), Linked USDL URIs are more adequate to service distribution networks since they are managed locally by service providers B. The HTTP URI also serves as endpoint to provide uniform data access to the service description. A Linked USDL URI can be used by, e.g., RDF search engines, and web query agents looking for cloud service descriptions 6
- 16. Benefits • Global service identification and remote description access – Unique service identification schema using Linked USDL URIs – Uniform data access [12] to service descriptions using Linked USDL HTTP URIs – Decentralized management of unique service identifiers is scalable • Intelligent routing of service requests – SPARQL for the content-based routing [14] – Flexible querying mechanism (cf. web APIs) – Full access to the service specifications is possible remotely • Dynamic binding of deployment descriptors – Publish-subscribe pattern [15] – Scalable by distributing USDL requests to TOSCA Runtime Environments – Higher degree of decoupling (cf. BPM or integration by web services) 2013 Genessiz: Center for Large-Scale Service System Research 16
- 17. Intelligent Routing of Service Requests • Separation of Concerns (routing logic) – GRL -- high level information • e.g., information about the country of the provider for legal aspects – LRL -- lower level aspects • e.g., load balancing information – TRL -- management actions • e.g., implementing security aspecTOSCA ts directly in management plans 2013 Genessiz: Center for Large-Scale Service System Research 19 Runtime Environment TOSCA Routing Layer Marketplace Global Routing Layer Provider Local Routing Layer Service 1 Service 2 …
- 18. Intelligent Routing of Service Requests 2013 Genessiz: Center for Large-Scale Service System Research 20 20 TOSCA-based Provider TOSCA Service Archives T T … Service 1 Service N TOSCA Runtime Environment Local Routing Layer TOSCA Routing Layer USDL URI … Plan Endpoint http://sugarcrm.org?enterprise … 111.121.12.1/SugarCRMPlan http://redmine.org?professional … 111.121.12.1/RedminePlan Reasoning Engine Routing Table 5 4 6 7 Acquire VM Install OS on VM Install & Start Web Server Install PHP Module Deploy PHP App Establish DB Connection Install OS on VM Install & Start MySQL RDBMS Create SugarCRM DB Module Build Plan Acquire VM A SPARQL query to inquire about the options input message used by the build plan to deploy SugarCRM on Amazon EC2
- 19. Benefits • Global service identification and remote description access – Unique service identification schema using Linked USDL URIs – Uniform data access [12] to service descriptions using Linked USDL HTTP URIs – Decentralized management of unique service identifiers is scalable • Intelligent routing of service requests – SPARQL for the content-based routing [14] – Flexible querying mechanism (cf. web APIs) – Full access to the service specifications is possible remotely • Dynamic binding of deployment descriptors – Publish-subscribe pattern [15] – Scalable by distributing USDL requests to TOSCA Runtime Environments – Higher degree of decoupling (cf. BPM or integration by web services) 2013 Genessiz: Center for Large-Scale Service System Research 21
- 20. Performance • Settings – Win7-64bit, JRE 1.7, Intel i5-2410M, 2,3GHz. – GRL: hash table with 500,000 entries and looked up 5,000 entries – LRL: hash table with 10,000 entries and looked up 1,000 entries • GRL: 3 ms • LRL: 2 ms • Build plan adaptation: 289 ms (σ = 76) • Deployment: 4-7 min – Depends on the provisioning time of the VMs at Amazon EC2 • Conclusions – In our scenario, the overhead, even for peak demands, is negligible 2013 Genessiz: Center for Large-Scale Service System Research 23
- 21. Limitations • Scalability – Adopt a peer-to-peer architecture using an overlay network • e.g., use the Simple Knowledge Organization System (SKOS) – Network partitioned according to service domains • e.g., healthcare, finance, and logistics – Route requests domain to domain/subdomains using SKOS • e.g., skos:narrower and skos:member • Customization – The customization string works well with simple customization – Inadequate for condition-based based customization • i.e. if logical conditions need to be sent along with service requests • Inputs to build plans – Associating USDL URIs with concrete input values for build plans has been found to be difficult if there is no description on how the values affect the deployment 2013 Genessiz: Center for Large-Scale Service System Research 24
- 22. Conclusion • We explored the interoperability of two cloud specifications – Linked USDL and TOSCA • Solution – Open and decentralized – Semantic web and Linked Data technologies – Link description/customization with deployment/management • Results – Interoperability is possible – End-to-end solutions can be developed – Engineered solution – Support the lifecycle of cloud services 2013 Genessiz: Center for Large-Scale Service System Research 25
- 24. References • 10. Cardoso, J.; Barros, A.; May, N. and Kylau, U. Towards a Unified Service Description Language for the Internet of Services: Requirements and First Developments. In IEEE International Conference on Services Computing, IEEE Computer Society Press, Florida, USA, 2010. • 11. Hors, A.L., Nally, M.: Using read/write Linked Data for Application Integration: Towards a Linked Data Basic Profile. In: Linked Data on the Web (2012) • 12. Ziegler, P., Dittrich, K.: Three decades of data intecration – all problems solved? In: Jacquart, R. (ed.) Building the Information Society. IFIP, vol. 156, pp. 3–12. Springer, Boston (2004) • 14. Carzaniga, A., Rutherford, M.J., Wolf, A.L.: A routing scheme for content-based networking. In: Proceedings of IEEE INFOCOM 2004, Hong Kong, China (2004) • 15. Hohpe, G., Woolf, B.: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, Boston (2003) 2013 Genessiz: Center for Large-Scale Service System Research 27
- 25. 2013 Genessiz: Center for Large-Scale Service System Research 28
- 26. 29BMWi: The standardisation environment for cloud computing. Technical report, Germany Federal Ministry of Economics and Technology (Feb. 2012) Standardization Fig 7. Involvement of the standardisation organisations in cloud computing
- 27. Lifecycle 2013 Genessiz: Center for Large-Scale Service System Research 30 12 steps towards creating a cloud service
- 28. 2013 Genessiz: Center for Large-Scale Service System Research 31 challengers leaders niche players visionaries Complexity of the model Completenessofthemodel OWL-S WSDL SAWSDL hREST WSMO-Lite USDL v1 USDL v2 Linked USDL USDL v3 microWSMO REST
- 29. 2013 Genessiz: Center for Large-Scale Service System Research 32 Complexity vs Acceptance http://craft.de/simplizitaet/ WO IST WAS? WSDL OWL-S WSMO SAWDL WSMO Lite REST hREST microWSMO „Ok, but I need more…“ „Nice improvement.“ „Cool“ „I‘m a hero“ „I have to look it up in the manual…“ „Where the heck do I find it?“ „I can‘t even do the simplest things….“ I‘m a looser Maximum Customer Satisfaction COMPLEXITY ACCEPTANCE
- 30. 2013 Genessiz: Center for Large-Scale Service System Research 33 Classes Properties
- 31. LINKED USDL MODULES • USDL-Core • USDL-Pricing • USDL-SLA 22.05.2013 Service Oriented Computing II – SS 2013 • Additional modules – USDL-Legal • Domain specific – USDL-EDU – USDL-Logistics
- 32. TOSCA 2013 Genessiz: Center for Large-Scale Service System Research 35 Service Structure Service Orchestration for Deployment & Management Start VM Install Tomcat OperatingSystem (Ubuntu 12.04 LTS) VirtualServer (AWS EC2 Server) WebServer (Tomcat) EC2
- 33. TOSCA Topology Concepts 2013 Genessiz: Center for Large-Scale Service System Research 36 Application (WAR) OperatingSystem (Ubuntu 12.04 LTS) VirtualServer (AWS EC2 Server) WebServer (Tomcat) EC2 Node Template Relationship Template Node Type hosted-on ubuntu.amiubuntu.ami app.war Deployment Artifacts AppSpecific Deploy Start, Stop installPkg Terminate CreateVM execScript Management Operations
- 34. SugarCRM/Use Case/Silver 2013 Genessiz: Center for Large-Scale Service System Research 37 OperatingSystem (OperatingSystem) VirtualMachine (VirtualMachine) (HostedOn) ApacheWebServer (ApacheWebServer) (HostedOn) SugarCrmApp (SugarCrmApp) (HostedOn) PhpModule (PhpModule) (InstalledIn) (DependsOn) MySql (MySqlRDBMS) (HostedOn) SugarCrmDb (SugarCrmDb) (HostedOn) (MySqlDbConnection)
- 35. Intelligent Routing • Listing 1.3 shows an example of an input message used by the build plan to deploy SugarCRM on Amazon EC2 (described in Section 3.4). • The message contains credentials of the Amazon account to be used (line 2 and 3), the geographic region where the virtual machines should be located (line 4), and a pointer to the USDL offering (line 5). • The USDL URI is used by the plan to query the Linked USDL offering by using SPARQL and adjust the deployment. • In our prototype, deciding between the deployment options enterprise or ultimate is done based on the selected USDL pricing plan. 2013 Genessiz: Center for Large-Scale Service System Research 38 Acquire VM Install OS on VM Install & Start Web Server Install PHP Module Deploy PHP App Establish DB Connection Install OS on VM Install & Start MySQL RDBMS Create SugarCRM DB Module Build Plan Acquire VM
- 36. Intelligent Routing • Listing 1.4 shows the SPARQL query used by the build plan to inquire about the options which are attached to the pricing plan included by the (customized) USDL URI. • The options are then installed automatically. 2013 Genessiz: Center for Large-Scale Service System Research 39
Hinweis der Redaktion
- Nowadays, the discovery and selection of cloud applications, such as a SaaSSugarCRM system, is still mainly carried out manually by consumers. It is not possible to effectively query services offered by different marketplaces (e.g., AppDirect, Appcelerator, and the Service Delivery Broker from PortugalTelecom), because they are not publicized using computer-understandable formats. Marketplaces need to be searched manually. This is a first limitation we want to address.After a purchase decision is made, and from the provider side, contracting and billing is negotiated by the sales and procurement divisions, the selected cloud application and its customization is given to an IT provider or department without any formalization of the executables, technical requirements, management best practices, and so on. Operators invest considerable efforts to learn how to setup and manage the application. Customization is done manually and often research or consulting is required to make a cloud solution work in a particular environment. This manual and error-prone process is not suitable to address fast changing markets and dynamic business requirements. Apart from solutions such as Saleforce, Google Apps, or Microsoft Office 365, this is still the way software is provisioned. This is the second limitation we want to address.To solve these limitations, USDL is aiming to formalize, structure, and simplify the discovery and selection of services, and TOSCA to automate their management. When used in conjunction, they can automate parts of the lifecycle of cloud applications, namely discovery, selection, deployment, and management.
- Nowadays, the discovery and selection of cloud applications, such as a SaaSSugarCRM system, is still mainly carried out manually by consumers. It is not possible to effectively query services offered by different marketplaces (e.g., AppDirect, Appcelerator, and the Service Delivery Broker from PortugalTelecom), because they are not publicized using computer-understandable formats. Marketplaces need to be searched manually. This is a first limitation we want to address.After a purchase decision is made, and from the provider side, contracting and billing is negotiated by the sales and procurement divisions, the selected cloud application and its customization is given to an IT provider or department without any formalization of the executables, technical requirements, management best practices, and so on. Operators invest considerable efforts to learn how to setup and manage the application. Customization is done manually and often research or consulting is required to make a cloud solution work in a particular environment. This manual and error-prone process is not suitable to address fast changing markets and dynamic business requirements. Apart from solutions such as Saleforce, Google Apps, or Microsoft Office 365, this is still the way software is provisioned. This is the second limitation we want to address.To solve these limitations, USDL is aiming to formalize, structure, and simplify the discovery and selection of services, and TOSCA to automate their management. When used in conjunction, they can automate parts of the lifecycle of cloud applications, namely discovery, selection, deployment, and management.
- To solve these limitations, USDL is aiming to formalize, structure, and simplify the discovery and selection of services, and TOSCA to automate their management. When used in conjunction, they can automate parts of the lifecycle of cloud applications, namely discovery, selection, deployment, and management.
- To solve these limitations, USDL is aiming to formalize, structure, and simplify the discovery and selection of services, and TOSCA to automate their management. When used in conjunction, they can automate parts of the lifecycle of cloud applications, namely discovery, selection, deployment, and management.
- The integration of USDL and TOSCA required a loosely coupled platform to account for the dynamic nature of service advertisements and service provisioning. Three main challenges emerged during the construction of the SIOPP prototype: (i) global service identification and remote description access,(ii) intelligent routing of service requests,(iii) and dynamic binding of deployment descriptors. We were able to exploit USDL features (inherited from linked data principles) to achieve an unique service identification schema using Linked USDL URIs and a uniform data access [12] to service descriptions using Linked USDL HTTP URIs. In contrast to using, e.g., web APIs, it enabled a simpler integration of the marketplace and service providers’ platforms responsible for service deployment and management. The use of a decentralized management of unique service identifiers was a scalable solution for the Internet of services. The use of SPARQL for the content-based routing [14] of service requests enabled a more flexible querying mechanism when compared, here again, with the access to web APIs to retrieve service data, since a full access to the service specifications is possible remotely. The dynamic association of a specific TOSCA deployment descriptor with a USDL service offering was achieved using a publish-subscribe pattern [15]. This enables cloud providers to quickly adapt to peak demand by distributing service requests to different TOSCA Runtime Environments. Compared to other approaches, e.g., which use business process management or integration by web services, the platform achieved a higher degree of decoupling, certainly more suitable for large scale deployments.
- The GRL receives an USDL URI from a marketplace, looks up appropriate providers and selects one of them. This selection may take into consideration further conditions defined by the user such as pricing, payment method, or security requirements. However, these aspects are out of scope for this paper. Each provider is referenced by an endpoint implementing an interface used by the GRL to pass requests to the Local Routing Layer of the respective provider in order to trigger the provisioning of the application.
- The Local Routing Layer uses the Linked USDL URI and a (local) routing table to select the corresponding TOSCA archive and TOSCA container, which brings us to the TOSCA Routing Layer.The installations are referenced by a TOSCA service id which can be used to trigger the provisioning of the service by the Local Routing Layer via the TOSCA-Runtime Environment. In addition, the routing table stores the input message used to invoke the build plan. This input message contains provider-specific information, for example, IP ranges or credentials, as well as field to pass the Linked USDL URI to the build plan. The plan may use the URI to configure the application based on the information represented by the URI or, in addition, may inspect the Linked USDL service description to gather more information, e.g., details of the selected price plan. Thus, the third TOSCA Routing Layer executes and configures the actual provisioning of the service.
- The distributed multi-layer routing logic enables the separation of concerns: * The GRL reflects high level information, e.g., the global routing table may store information about the country of the provider for legal aspects. * The LRL handles lower level aspects such as load balancing information, e.g., new service instances can be registered in the local routing table for peak demands. * The TRL enables, for example, implementing security aspects directly in management plans. This separation allows providers to focus on configuration and subscription and to design their own strategies based on individual aspects such as pricing.There is no need to understand the application’s management.
- The Local Routing Layer uses the Linked USDL URI and a (local) routing table to select the corresponding TOSCA archive and TOSCA container, which brings us to the TOSCA Routing Layer.The installations are referenced by a TOSCA service id which can be used to trigger the provisioning of the service by the Local Routing Layer via the TOSCA-Runtime Environment. In addition, the routing table stores the input message used to invoke the build plan. This input message contains provider-specific information, for example, IP ranges or credentials, as well as field to pass the Linked USDL URI to the build plan. The plan may use the URI to configure the application based on the information represented by the URI or, in addition, may inspect the Linked USDL service description to gather more information, e.g., details of the selected price plan. Thus, the third TOSCA Routing Layer executes and configures the actual provisioning of the service.Listing 1.3 shows an example of an input message used by the build plan to deploy SugarCRM on Amazon EC2 (described in Section 3.4). Listing 1.4 shows the SPARQL query used by the build plan to inquire about the options which are attached to the pricing plan included by the (customized) USDL URI. The options are then installed automatically.
- The integration of USDL and TOSCA required a loosely coupled platform to account for the dynamic nature of service advertisements and service provisioning. Three main challenges emerged during the construction of the SIOPP prototype: (i) global service identification and remote description access,(ii) intelligent routing of service requests,(iii) and dynamic binding of deployment descriptors. We were able to exploit USDL features (inherited from linked data principles) to achieve an unique service identification schema using Linked USDL URIs and a uniform data access [12] to service descriptions using Linked USDL HTTP URIs. In contrast to using, e.g., web APIs, it enabled a simpler integration of the marketplace and service providers’ platforms responsible for service deployment and management. The use of a decentralized management of unique service identifiers was a scalable solution for the Internet of services. The use of SPARQL for the content-based routing [14] of service requests enabled a more flexible querying mechanism when compared, here again, with the access to web APIs to retrieve service data, since a full access to the service specifications is possible remotely. The dynamic association of a specific TOSCA deployment descriptor with a USDL service offering was achieved using a publish-subscribe pattern [15]. This enables cloud providers to quickly adapt to peak demand by distributing service requests to different TOSCA Runtime Environments. Compared to other approaches, e.g., which use business process management or integration by web services, the platform achieved a higher degree of decoupling, certainly more suitable for large scale deployments.
- Regardless of using SIOPP or not, the application has to be setup using a build plan. Thus, we measured the performance of each component separately, to analyze the added runtime. For the GRL we used a hash table with 500,000 entries and looked up 5,000 entries with a total lookup time of 3ms.To measure the LRL we used a hash table with 10,000 entries and looked up 1,000 entries which resulted in a total lookup time of 2ms.The measurement setting was Win7-64bit, JRE 1.7, Intel i5-2410M, 2,3GHz. The build plan was adapted to return immediately after executing the SPARQL query, i.e., before the actual deployment at Amazon started, has an average runtime of 289ms (σ = 76).The runtime of the plan deploying SugarCRM varies between 4 and 7 minutes, depending on the provisioning time of the VMs at Amazon EC2.Thus, the overhead caused by SIOPP, even for peak demands, is negligible in our scenario.
- Since our routing approach has only three fixed routing components, it is not scalable for a global operation. One way to address this limitation is to adopt a peer-to-peer architecture using an overlay network organized with, e.g., the Simple Knowledge Organization System (SKOS). The network can be partitioned according to service domains (e.g., healthcare, finance, and logistics). Requests can be routed from domain to domain/subdomains linked using SKOS properties (e.g., skos:narrower and skos:member). The customization string (see Section 4.2), works well with simple customization. However, it is inadequate for condition-based based customization, i.e. if logical conditions need to be sent along with service requests. Also, associating USDL URIs with concrete input values for build plans has been found to be difficult if there is no description on how the values affect the deployment.
- Listing 1.3 shows an example of an input message used by the build plan to deploy SugarCRM on Amazon EC2 (described in Section 3.4). The message contains credentials of the Amazon account to be used (line 2 and 3), the geographic region where the virtual machines should be located (line 4), and a pointer to the USDL offering (line 5). The USDL URI is used by the plan to query the Linked USDL offering by using SPARQL and adjust the deployment. In our prototype, deciding between the deployment options enterprise or ultimate is done based on the selected USDL pricing plan.
- Listing 1.4 shows the SPARQL query used by the build plan to inquire about the options which are attached to the pricing plan included by the (customized) USDL URI. The options are then installed automatically.