Your SlideShare is downloading. ×
0
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
 Cloud Computing Automation: Integrating USDL and TOSCA
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Cloud Computing Automation: Integrating USDL and TOSCA

918

Published on

-- Presented at CAiSE 2013, Valencia, Spain -- …

-- 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
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
918
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
54
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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.
  • Transcript

    • 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. 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. 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. 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. 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. 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. 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. Approach2013 Genessiz: Center for Large-Scale Service System Research 8DISCOVERYANDSELECTIONDEPLOYMENTANDMANAGEMENTUSDL/Service DescriptionTOSCA/Service ManagementUse Case
    • 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. 2013 Genessiz: Center for Large-Scale Service System Research 10USDL:CoreMaster Schema
    • 11. Linked USDL2013 Genessiz: Center for Large-Scale Service System Research 11http://www.linked-usdl.org/ https://github.com/linked-usdl/
    • 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. 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. 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. 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. 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 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. 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. 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 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. 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. 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. Thank Youfor Listening
    • 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. 2013 Genessiz: Center for Large-Scale Service System Research 28
    • 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. Lifecycle2013 Genessiz: Center for Large-Scale Service System Research 3012 steps towards creating a cloud service
    • 28. 2013 Genessiz: Center for Large-Scale Service System Research 31challengers leadersniche players visionariesComplexity of the modelCompletenessofthemodelOWL-SWSDLSAWSDLhRESTWSMO-LiteUSDL v1USDL v2Linked USDLUSDL v3microWSMOREST
    • 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. 2013 Genessiz: Center for Large-Scale Service System Research 33ClassesProperties
    • 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. 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. 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. 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. 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. 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

    ×