{"title":"面向服务的多租户(SO-MT):使用Docker为现有的服务组合引擎启用多租户","authors":"G. Nikol, Michael Träger, Simon Harrer, G. Wirtz","doi":"10.1109/SOSE.2016.40","DOIUrl":null,"url":null,"abstract":"In Web Services-based SOAs, BPEL 2.0 is the choice for defining services by composing existing ones. BPEL-based services can be directly executed on BPEL engines. With the rise of the cloud, companies aim to outsource service hosting to cloud providers. To achieve economies of scale, a cloud provider must host such services with minimal resources and keep the services from different tenants isolated. But BPEL engines typically do not support multi-tenancy. As a result, a vendor either has to extend the engine himself or host every service on its own (virtual) machine, thereby using either costly development or computing resources. Our approach solves this problem by hosting each service in its own isolated and minimal container which exposes the management functionality through APIs enabling complex multi-tenancy features or horizontal scaling on top. We aim to implement this by a) leveraging Docker container to isolate the services from each other, b) removing unused software from the container, c) starting the BPEL engine with minimal resources, and d) extracting management functionality while keeping management APIs. Our case study with Apache ODE shows that we can save significant runtime resources with only minor development effort. While this approach helps in moving SOAs into the cloud, it can also be leveraged to build resource efficient BPEL-based microservices cheaper.","PeriodicalId":153118,"journal":{"name":"2016 IEEE Symposium on Service-Oriented System Engineering (SOSE)","volume":"185 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2016-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"7","resultStr":"{\"title\":\"Service-Oriented Multi-tenancy (SO-MT): Enabling Multi-tenancy for Existing Service Composition Engines with Docker\",\"authors\":\"G. Nikol, Michael Träger, Simon Harrer, G. Wirtz\",\"doi\":\"10.1109/SOSE.2016.40\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"In Web Services-based SOAs, BPEL 2.0 is the choice for defining services by composing existing ones. BPEL-based services can be directly executed on BPEL engines. With the rise of the cloud, companies aim to outsource service hosting to cloud providers. To achieve economies of scale, a cloud provider must host such services with minimal resources and keep the services from different tenants isolated. But BPEL engines typically do not support multi-tenancy. As a result, a vendor either has to extend the engine himself or host every service on its own (virtual) machine, thereby using either costly development or computing resources. Our approach solves this problem by hosting each service in its own isolated and minimal container which exposes the management functionality through APIs enabling complex multi-tenancy features or horizontal scaling on top. We aim to implement this by a) leveraging Docker container to isolate the services from each other, b) removing unused software from the container, c) starting the BPEL engine with minimal resources, and d) extracting management functionality while keeping management APIs. Our case study with Apache ODE shows that we can save significant runtime resources with only minor development effort. While this approach helps in moving SOAs into the cloud, it can also be leveraged to build resource efficient BPEL-based microservices cheaper.\",\"PeriodicalId\":153118,\"journal\":{\"name\":\"2016 IEEE Symposium on Service-Oriented System Engineering (SOSE)\",\"volume\":\"185 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2016-03-01\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"7\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"2016 IEEE Symposium on Service-Oriented System Engineering (SOSE)\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/SOSE.2016.40\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"2016 IEEE Symposium on Service-Oriented System Engineering (SOSE)","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/SOSE.2016.40","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Service-Oriented Multi-tenancy (SO-MT): Enabling Multi-tenancy for Existing Service Composition Engines with Docker
In Web Services-based SOAs, BPEL 2.0 is the choice for defining services by composing existing ones. BPEL-based services can be directly executed on BPEL engines. With the rise of the cloud, companies aim to outsource service hosting to cloud providers. To achieve economies of scale, a cloud provider must host such services with minimal resources and keep the services from different tenants isolated. But BPEL engines typically do not support multi-tenancy. As a result, a vendor either has to extend the engine himself or host every service on its own (virtual) machine, thereby using either costly development or computing resources. Our approach solves this problem by hosting each service in its own isolated and minimal container which exposes the management functionality through APIs enabling complex multi-tenancy features or horizontal scaling on top. We aim to implement this by a) leveraging Docker container to isolate the services from each other, b) removing unused software from the container, c) starting the BPEL engine with minimal resources, and d) extracting management functionality while keeping management APIs. Our case study with Apache ODE shows that we can save significant runtime resources with only minor development effort. While this approach helps in moving SOAs into the cloud, it can also be leveraged to build resource efficient BPEL-based microservices cheaper.