Cloud Computing Automation: Integrating USDL and TOSCA

1,468 views

Published on

-- 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.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,468
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
67
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • 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.
  • Cloud Computing Automation: Integrating USDL and TOSCA

    1. 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, Germanyjorge.cardoso@kit.edujcardoso@dei.uc.pt(3) Institute of Architecture of Application Systems, University of Stuttgart, Germany{lastname}@iaas.uni-stuttgart.deCloud Computing Automation:Integrating USDL and TOSCADepartamento de Engenharia InformáticaFCTUC FACULDADE DE CIÊNCIAS E TECNOLOGIA da UNIVERSIDADE DE COIMBRAInstitute of Architecture of Application Systems (IAAS)Universität Stuttgart, GermanyCloud 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. 2. Standardization2013 Genessiz: Center for Large-Scale Service System Research 2See also http://cloud-standards.orgBMWi: The standardisation environment for cloud computing. Technical report, GermanyFederal Ministry of Economics and Technology (Feb. 2012)
    3. 3. Interoperability• Standards are beingdeveloped in isolation• It is not clear to whichextend they can beintegrated• Lack of certainty as towhich standards can inter-operate• Streamline the lifecycle ofcloud applications2013 Genessiz: Center for Large-Scale Service System Research 3Standardizationdoes notimply interoperabilityDefinition (Interoperability): the ability of various systemsand organizations to work together (inter-operate)
    4. 4. Motivation (1)• Discovery, Selection andCustomization– Done manually by consumers• Keyword querying– No advanced mechanism• Multiple queries– Different marketplaces usedifferent query interfaces2013 Genessiz: Center for Large-Scale Service System Research 4AppDirectGoogle
    5. 5. Motivation (2)• After a purchase decision...– Customization– Deployment– Management• No …• Formalization of the executables• Management best practices• Etc.• Problem– Manual– Error-prone2013 Genessiz: Center for Large-Scale Service System Research 5Exceptions: Saleforce, Google Apps,Microsoft Office 365, etc.
    6. 6. 6BMWi: The standardisation environment for cloud computing. Technical report, GermanyFederal Ministry of Economics and Technology (Feb. 2012)“In the course of the sixmonths in which the studywas produced, a lot of newpublications appeared, notall of which could be takeninto account”(e. g. TOSCA,http://www.oasis-open.org/committees/tosca/)
    7. 7. Research Question2013 Genessiz: Center for Large-Scale Service System Research 7When used in conjunction, can they automate parts ofthe 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. 8. Approach2013 Genessiz: Center for Large-Scale Service System Research 8DISCOVERYANDSELECTIONDEPLOYMENTANDMANAGEMENTUSDL/Service DescriptionTOSCA/Service ManagementUse Case
    9. 9. Describes the structure of anapplication and its management(which is executable)Goal >>Portability and full-automatedmanagement of applicationsDescribes the functional and non-functional requirements, capabilities,and interactions of a serviceGoal >>Description of a cloud service to makeit searchable, comparable, andtradableTopology Management Plans…Interaction &functional capabilitiesOfferingsInteractionsProviders…Non-functionalcapabilitiesPricingLegalService LevelTopology and Orchestration Specificationfor Cloud Applications
    10. 10. 2013 Genessiz: Center for Large-Scale Service System Research 10USDL:CoreMaster Schema
    11. 11. Linked USDL2013 Genessiz: Center for Large-Scale Service System Research 11http://www.linked-usdl.org/ https://github.com/linked-usdl/
    12. 12. TOSCA2013 Genessiz: Center for Large-Scale Service System Research 12OsApache(OperatingSystem)VmApache(VirtualMachine)ApacheWebServer(ApacheWebServer)(HostedOn)(InstalledIn)SugarCrmApp(SugarCrmApp)PhpModule(PhpModule)(DependsOn)OsMySql(OperatingSystem)VmMySql(VirtualMachine)MySql(MySqlRDBMS)SugarCrmDb(SugarCrmDb)(HostedOn)(DbConnection)AcquireVMInstallOS onVMInstall &Start WebServerInstallPHPModuleDeployPHPApp EstablishDBConnectionInstallOS onVMInstall & StartMySQLRDBMSCreateSugarCRMDB ModuleBuild PlanTopologyAcquireVMSugarCRM
    13. 13. Solution• How to access service descriptions in a dynamic world?– Global service identification and service description access usingLinked USDL• What if the provider has ceased its operations and transferred itsobligations to some other provider? Who still handle the originalfunctions?• Intelligent routing of service requests• What would happen if the TOSCA descriptor associated with aUSDL description would no longer be valid?– Dynamic binding of deployment descriptors2013 Genessiz: Center for Large-Scale Service System Research 13WWW + Semantic web = Distributed, scalable, reliable, extensible,…[11]
    14. 14. Service Cloud14USDL-based MarketplaceUSDL-based Service OfferingsBilling / CRM SystemUI…Service 1Service NTOSCA-based ProviderTOSCA Service ArchivesTT…Service 1Service NTOSCA Runtime EnvironmentGlobalRoutingLayerLocalRoutingLayerCloud Management SystemUSDL URI … Provider Endpointhttp://sugarcrm.org?enterprise … 192.182.1.3http://redmine.org?professional … 147.11.4.79TOSCA Routing LayerUSDL URI … Plan Endpointhttp://sugarcrm.org?enterprise … 111.121.12.1/SugarCRMPlanhttp://redmine.org?professional … 111.121.12.1/RedminePlanSIOPPArchitectureReasoningEngineReasoningEngineRoutingTableRoutingTable5432167
    15. 15. Service Identification & Access2013 Genessiz: Center for Large-Scale Service System Research15CloudUSDL-complianthttp://rdfs.genssiz.org/SugarCRM?pricePlan=pricing_SugarCRM_Ultimate54321Query stringsare a W3C recommendationService offerings aremodeled with Linked USDLA. Simple way to create unique globalidentifiers for services. Compared to,e.g., a universally unique identifier(UUID), Linked USDL URIs are moreadequate to service distributionnetworks since they are managedlocally by service providersB. The HTTP URI also serves as endpointto provide uniform data access to theservice description. A Linked USDL URIcan be used by, e.g., RDF search engines,and web query agents looking for cloudservice descriptions6
    16. 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. 17. Intelligent Routing of ServiceRequests• 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 plans2013 Genessiz: Center for Large-Scale Service System Research 19Runtime EnvironmentTOSCA Routing LayerMarketplaceGlobal Routing LayerProviderLocal Routing LayerService 1Service 2…
    18. 18. Intelligent Routing of ServiceRequests2013 Genessiz: Center for Large-Scale Service System Research 2020TOSCA-based ProviderTOSCA Service ArchivesTT…Service 1Service NTOSCA Runtime EnvironmentLocalRoutingLayerTOSCA Routing LayerUSDL URI … Plan Endpointhttp://sugarcrm.org?enterprise … 111.121.12.1/SugarCRMPlanhttp://redmine.org?professional … 111.121.12.1/RedminePlanReasoningEngineRoutingTable5467AcquireVMInstallOS onVMInstall &Start WebServerInstallPHPModuleDeployPHPAppEstablishDBConnectionInstallOS onVMInstall & StartMySQL RDBMSCreateSugarCRMDB ModuleBuild PlanAcquireVMA SPARQL query to inquireabout the optionsinput message used by the build plan todeploy SugarCRM on Amazon EC2
    19. 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. 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 provisioningtime of the VMs at Amazon EC2• Conclusions– In our scenario, the overhead, even for peak demands, is negligible2013 Genessiz: Center for Large-Scale Service System Research 23
    21. 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 bedifficult if there is no description on how the values affect the deployment2013 Genessiz: Center for Large-Scale Service System Research 24
    22. 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 services2013 Genessiz: Center for Large-Scale Service System Research 25
    23. 23. Thank Youfor Listening
    24. 24. References• 10. Cardoso, J.; Barros, A.; May, N. and Kylau, U. Towards a Unified Service DescriptionLanguage for the Internet of Services: Requirements and First Developments. In IEEEInternational 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: Towardsa 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-basednetworking. In: Proceedings of IEEE INFOCOM 2004, Hong Kong, China (2004)• 15. Hohpe, G., Woolf, B.: Enterprise Integration Patterns: Designing, Building, and DeployingMessaging Solutions. Addison-Wesley, Boston (2003)2013 Genessiz: Center for Large-Scale Service System Research 27
    25. 25. 2013 Genessiz: Center for Large-Scale Service System Research 28
    26. 26. 29BMWi: The standardisation environment for cloud computing. Technical report, GermanyFederal Ministry of Economics and Technology (Feb. 2012)StandardizationFig 7. Involvement of thestandardisation organisationsin cloud computing
    27. 27. Lifecycle2013 Genessiz: Center for Large-Scale Service System Research 3012 steps towards creating a cloud service
    28. 28. 2013 Genessiz: Center for Large-Scale Service System Research 31challengers leadersniche players visionariesComplexity of the modelCompletenessofthemodelOWL-SWSDLSAWSDLhRESTWSMO-LiteUSDL v1USDL v2Linked USDLUSDL v3microWSMOREST
    29. 29. 2013 Genessiz: Center for Large-Scale Service System Research 32Complexity vs Acceptancehttp://craft.de/simplizitaet/WO IST WAS?WSDLOWL-SWSMOSAWDLWSMO LiteRESThRESTmicroWSMO„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 thesimplest things….“I‘m a looserMaximum Customer SatisfactionCOMPLEXITYACCEPTANCE
    30. 30. 2013 Genessiz: Center for Large-Scale Service System Research 33ClassesProperties
    31. 31. LINKED USDL MODULES• USDL-Core• USDL-Pricing• USDL-SLA22.05.2013 Service Oriented Computing II – SS 2013• Additional modules– USDL-Legal• Domain specific– USDL-EDU– USDL-Logistics
    32. 32. TOSCA2013 Genessiz: Center for Large-Scale Service System Research 35Service Structure Service Orchestration forDeployment & ManagementStart VMInstallTomcatOperatingSystem(Ubuntu 12.04 LTS)VirtualServer(AWS EC2 Server)WebServer(Tomcat)EC2
    33. 33. TOSCA Topology Concepts2013 Genessiz: Center for Large-Scale Service System Research 36Application(WAR)OperatingSystem(Ubuntu 12.04 LTS)VirtualServer(AWS EC2 Server)WebServer(Tomcat)EC2Node TemplateRelationship TemplateNode Typehosted-onubuntu.amiubuntu.amiapp.warDeployment ArtifactsAppSpecificDeployStart, StopinstallPkgTerminateCreateVMexecScriptManagement Operations
    34. 34. SugarCRM/Use Case/Silver2013 Genessiz: Center for Large-Scale Service System Research 37OperatingSystem(OperatingSystem)VirtualMachine(VirtualMachine)(HostedOn)ApacheWebServer(ApacheWebServer)(HostedOn)SugarCrmApp(SugarCrmApp)(HostedOn)PhpModule(PhpModule)(InstalledIn)(DependsOn)MySql(MySqlRDBMS)(HostedOn)SugarCrmDb(SugarCrmDb)(HostedOn)(MySqlDbConnection)
    35. 35. Intelligent Routing• Listing 1.3 shows an example of an inputmessage used by the build plan to deploySugarCRM on Amazon EC2 (described inSection 3.4).• The message contains credentials of theAmazon account to be used (line 2 and 3), thegeographic region where the virtual machinesshould be located (line 4), and a pointer to theUSDL offering (line 5).• The USDL URI is used by the plan to querythe Linked USDL offering by using SPARQLand adjust the deployment.• In our prototype, deciding between thedeployment options enterprise or ultimate isdone based on the selected USDL pricingplan.2013 Genessiz: Center for Large-Scale Service System Research 38AcquireVMInstall OSon VMInstall & Start WebServerInstall PHPModuleDeploy PHPAppEstablishDB ConnectionInstall OSon VMInstall & Start MySQL RDBMSCreateSugarCRMDB ModuleBuild PlanAcquireVM
    36. 36. Intelligent Routing• Listing 1.4 shows the SPARQLquery used by the build plan toinquire about the options whichare attached to the pricing planincluded by the (customized)USDL URI.• The options are then installedautomatically.2013 Genessiz: Center for Large-Scale Service System Research 39

    ×