JTangCSB: A Cloud Service Bus for Cloud and Enterprise Application Integration

Download (0)

Full text

(1)

JTangCSB: A Cloud Service Bus for Cloud and Enterprise Application

Integration

Jianwei Yin1, Xingjian Lu1, Calton Pu2, Zhaohui Wu1, Hanwei Chen1

1College of Computer Science and Technology, Zhejiang University, Hangzhou, China 2School of Computer Science, Georgia Institute of Technology, Atlanta, USA

Abstract

Cloud and Enterprise Application Integration (CEAI) is a new challenge as more enterprise appli-cations migrate successfully to cloud environments. However, achieving CEAI properties such as mul-ti-tenancy, cloud-level scalability, and environmental heterogeneity is non-trivial for enterprise applica-tions originally built under the assumption of centralized management (e.g., EAI using Enterprise Ser-vice Bus - ESB). To bridge the gap, we outline the Cloud SerSer-vice Bus (CSB) approach to address the above CEAI properties. A concrete implementation of CSB, called JTangCSB, demonstrates its feasi-bility in practice. An experimental evaluation of JTangCSB used in a realistic application scenario il-lustrates the effectiveness of CSB in meeting the CEAI challenge.

Keywords: Cloud and Enterprise Application Integration (CEAI), Cloud Service Bus (CSB), Multi-tenancy, Cloud-level scalability, Environmental Heterogeneity

1. Introduction

As more enterprise applications migrate successfully into cloud environments, the need to bridge the gap between traditional on-premises software and new cloud-based services is increasing. To offer maximum value to their users, enterprise applications in cloud environments need not only to cooperate with other cloud-based services, but also to keep data synchronized with on-premises soft-ware. According to a recent survey by Oracle [1], 81% of 1,355 surveyed business mangers cite such full integration as an important requirement for achieving the full benefits of cloud computing. That brings us to Cloud and Enterprise Application Integration (CEAI), where on-premises software works well with new cloud-based services.

CEAI is a significant challenge due to differences in the fundamental assumptions made in a tradi-tional enterprise-computing environment (centralized management) and a cloud environment (open and distributed management). Traditional enterprise application integration (EAI) and associated software tools such as enterprise service bus (ESB) [2] work well for a single company and stable workloads. As enterprise applications migrate to cloud environment, some important traditional EAI assumptions (e.g., single company and stable workload) no longer hold. Specifically, we will focus on the following three properties (called CEAI properties) that are relatively uncommon in traditional EAI, but considered critical in cloud environments in general, and CEAI in particular:

Multi-Tenancy. In this paper we mainly consider cloud services in the software as a service (SaaS) model, where the cloud services need to support multiple tenants running in the same cloud. This brings challenges related to sharing and isolation management for CEAI, includ-ing multi-tenancy identification, multi-tenancy access control, multi-tenancy data storage, and multi-tenancy service executions. These challenges affect critical quality of service dimen-sions such as performance, reliability, and security. For example, multi-tenancy applications require system methods and database tables to access and store data from different user ac-counts, which introduces significant security requirements in a multi-tenant environment. • Cloud-level Scalability. With the number and scale of cloud services constantly expanding

(e.g. the Salesforce Platform powers more than 3 million custom apps and Salesforce CRM delivers more than 1 billion transactions a day), CEAI needs to be scalable in many quality of service dimensions, including reliability, security, and performance. Efficient and proactive auto-scaling mechanism needs to be developed to ensure scalability not only for increasing number of cloud services, but also for each cloud service while integration needs grow. • Environmental Heterogeneity. Different hardware and software platforms, different

lan-guages and APIs, and different communications styles increase the pressure to integrations for CEAI. It is imperative but tough to provide seamless integration between on-premises soft-ware and cloud services, as well as among different cloud services. Specifically, various adap-tors, unified integration semantic, and environment-aware management mechanisms are re-quired to integrate these heterogeneous systems.

(2)

Towards achieving the vision of CEAI, we outline the Cloud Service Bus (CSB) approach, which builds on the concepts of Enterprise Service Bus (ESB) and Service-Oriented Integration (SOI) to bridge the gap between EAI and CEAI. CSB supports the provisioning, consumption and execution of the available integration services [3]. It also includes a marketplace to make global integration services available to CEAI components. CSB is designed to support CEAI properties that include multi-tenancy, cloud-level scalability, and environmental heterogeneity.

A practical implementation (JTangCSB) is developed as an integration platform to deliver efficient and cost-effective integration service towards the fulfillment of the CEAI vision. Specifically, multi-tenancy aware mediation components and flows are designed to support integrations with software-as-a-service in clouds. Distributed integration engine and service bus nodes are provided to make the ar-chitecture more scalable to adapt the increasing number of cloud services and their expanding scale. Auto-scaling algorithms and targeted performance optimization mechanisms are designed to support large-scale integration and ensure required quality of service. Various kinds of adaptors and integrated data semantics are developed to support environmental heterogeneity.

JTangCSB is tested in a realistic case study, where a company needs to integrate the Customer Re-lationship Management (CRM) service in a SaaS platform (Salesforce in this case), an Enterprise Communications Portal (ECP) system in a PaaS platform (offered by China Telecom), and some on-premises software. We have used JTangCSB successfully to achieve the properties of multi-tenancy, cloud-level scalability, and environmental heterogeneity in the completed system. A preliminary evalu-ation shows the integrated system with high performance running on JTangCSB.

2.

Related Work

To contrast a traditional EAI effort in an established company and CEAI properties of multi-tenancy, cloud-level scalability, and environmental heterogeneity, let us consider a CRM application. First, the market share growth of an established company is often predictable, leading to stable CRM workloads and controllable scalability. Second, other than merger and acquisitions (which would lead to CEAI challenges), an established company can (and often) dictate hardware and software standards to minimize or eliminate system heterogeneity. In contrast, a CEAI scenario such as the one outlined in Section 5.1 requires new approaches since these traditional assumptions of single company and stable workloads no longer hold. In this section, we will first outline related research results that address one of CEAI properties, then related work on combinations of two CEAI properties, leading to a brief dis-cussion of JTangCSB’s support for three CEAI properties and some related industry products.

Significant work has been done to address the challenges of individual CEAI properties in the context of service computing (in heterogeneous cloud environments). We outline some representative examples for illustration purposes since new papers are being published every year in conferences such as ICWS, SCC, IEEE CLOUD and ACM SOCC, as well as journals such as IEEE TSC. In multi-tenancy, Strauch [4] investigated the requirements for multi-tenant ESB solutions, proposed an imple-mentation-agnostic ESB architecture that addresses these requirements, and discussed the prototype realization with performance evaluation [5]. In cloud-level scalability, Vaquero [6] discussed the initia-tives, relevant efforts, pending challenges and trends towards whole application scalability in cloud environments. In environmental heterogeneity, Geograntas [7][8] introduced interoperability solutions based on abstraction and merging of the common high-level semantics of interaction paradigms to ad-dress interoperability issues for the Future Internet, where complex applications will be composed from extremely heterogeneous systems.

Additional research has been accomplished in combining two of the three CEAI properties. The combination of scalability and heterogeneity is illustrated by Baude [3], which presented the con-cept, architecture and prototype implementation of an Internet-wide service cloud, providing a fully transparent, distributed and federated means to access, compose and deploy services through a federa-tion of distributed ESB. The combinafedera-tion of scalability and multi-tenancy is illustrated by CloudScale [9], a prediction-driven elastic resource scaling system for multi-tenant cloud computing. The light-weight and application-agnostic properties make it suitable for large-scale cloud systems. In addition, an adaptive database schema design method is proposed for multi-tenant applications in Ni [10], to achieve good scalability and high performance with low space. The combination of multi-tenancy and heterogeneity is illustrated by Pippal [11], which implemented a simple, robust, query efficient, scala-ble and space saving multi-tenant database architecture for a heterogeneous environment.

To the best of our knowledge, JTangCSB is the first research product that explicitly addresses all three CEAI properties through a careful combination of multi-tenancy aware data storage and ser-vice execution (for multi-tenancy) [4][5][10][11], distributed integration engine and serser-vice bus topol-ogy [2][3][12], efficient auto-scaling algorithms and targeted performance optimization mechanisms (for cloud-level scalability) [6][9][13][14], and integrated data semantics as well as various kinds of

(3)

adaptors (for environmental heterogeneity) [7][8][11]. In industry, some companies and open source organizations also focus on CEAI, e.g. MuleSoft provided an iPaaS product called CloudHub (see http://www.mulesoft.org). Jitterbit developed various integration solutions for small to medium size enterprises (see http://www.jitterbit.com). Sun et al. [12] developed a public SaaS platform by using cloud service bus to compatibly support SOA based software and easily combine the primitive mecha-nisms of SaaS software. However, these products mainly focus on the connection problem, with partial support for the three CEAI properties. Thus JTangCSB, which provides completed integration infra-structure for all three CEAI properties, demonstrates a promising approach to achieving the CEAI vi-sion in cloud environments.

3. JTangCSB: A Concrete Implementation of CSB

We will use a concrete implementation to explain the CSB concept. JTangCSB (Figure 1)

consists of four layers: an Infrastructure layer, a Core Assets layer, a Business Logic layer, and a

Presentation layer.

Figure 1 The Architecture of JTangCSB

The first (Infrastructure) layer contains all the basic resources (computing, network, disk, etc.) to

support daily operation of JTangCSB. It consists of a number of JTC-Rendezvous, each of which

repre-sents a distributed resource center over the Internet. The basic unit of JTC-Rendezvous is JTC-VM,

which is used to host CSB containers.

The second (Core Assets) layer contains all the software resources: components, mediation flows,

and services. First, all the components are deployed on CSB containers, which are concrete processing nodes and provide runtime environment for the components. From the logical point of view, compo-nent instances, mediation flows and services are all stored in a global semantic space. Second, the me-diation flows connect component instances. To support cloud-level scalability, components and media-tion flows have a cluster implementamedia-tion. Third, services represent the applicamedia-tions (cloud applicamedia-tions or on-premises software) that are registered with mediation flows.

The component instances and mediation flows are multi-tenancy aware, i.e., they know which ten-ants are invoking them and can take appropriate tenant-specific actions. The multi-tenancy support consists of the registries for services, components and mediation flows, and the registry center that con-tains tenant information. A set of tenant and configuration registries stores configuration information of tenants, mediation flows, as well as the mappings to tenants and permissions of the roles.

The third (Business Logic) layer is responsible for the processing of management functions: Dis-tributed CSB Engine, Integration Controller, Container Manager, and Access Controller. First, by using distributed and scalable bus nodes (will be described later), the distributed CSB engine provides

(4)

tration, and pub/sub middleware. It also provides configuration management and runtime monitoring functionality to collect statistical information and logs.

Second, the integration controller is in charge of the management for integration related resources, to fulfill the defined integration logics. The mediation flow manager can be used to define and manage integration scenarios, by using other resource managers (service, component, tenant, and configuration managers) to generate multi-tenancy aware components and organize them to be multi-tenancy aware mediation flows.

Third, the container manager is responsible for the management of CSB containers, where compo-nent framework OSGi is used for the lifecycle management of the mediation compocompo-nents in all the containers. The load balancer is provided to evenly distribute workloads on these containers. The auto-scaling component is used to satisfy variable user demands by adjusting the number of CSB containers.

Finally, the access controller handles the identification and authentication of all the tenants and us-ers, and manages all the authorized accesses transparently. It supports the Lightweight Directory Ac-cess Protocol (LDAP) and Single Sign-on services, which can be used to provide role-based acAc-cess by login once in a session.

The fourth (Presentation) layer contains three components allowing utilizing, administration, and interaction with JTangCSB: the JTC-Toolset, the Web-based console, and the Web service API. The JTC-Toolset is developed to facilitate the development tasks for CEAI, by providing a mediation com-ponent development kits and a mediation flow designer. The two tools are Eclipse plugins for compo-nent development and mediation flow design respectively. The Web-based console provides the admin-istration, management and monitoring functionalities for the platform managers. And the Web service API enables the integration and communication of internal components and external services (cloud applications or on-premises software).

4. Implementation and Functionality of JTangCSB

JTangCSB supports the three CEAI properties through a variety of design and implementation techniques described in this section. Due to a careful choice of the specific design and implementation techniques being included, JTangCSB is able to support all three CEAI properties.

4.1 Multi-Tenancy Support

To create a multi-tenancy environment for CEAI, we developed a multi-tenancy management module in the tenant manager component based on the architecture proposed by Strauch [4]. First, the identification, access control and management functions for multiple tenants and their users should be supported. We deployed a shared Lightweight Directory Access Protocol (LDAP) service (based on OpenLDAP) to consistently manage the tenants’ and users’ information and provide the role-based access in the access controller component. Single sign-on is also implemented to allow a user to login once and then gain access to all the authorized assets based on corresponding configurations.

Then, multi-tenancy data storage and multi-tenancy service executions should be supported in the runtime after accesses have been authorized. In order to achieve data isolation, we used shared data-base with shared schemas to store multi-tenancy data as it supports highest sharing. By adding a tenant column for each resource table, the shared registry is multi-tenancy aware and provides isolation across tenants.

In order to support multi-tenancy service executions, tenant-based deployment and configuration for mediation flows were considered in the implementation of mediation flow manager. A tenant can create a new mediation flow instance or register himself with an existing shared instance. JTangCSB can also support the configuration for each tenant’s behavior by adding tenant-specific configurations to the registry center when required. Besides tenant-based deployment and configuration, all the adap-tors and message processers were designed to be multi-tenancy aware by providing an identity distin-guishing service before the core functionality. With this service, they can identify different tenants and users by their ID and then perform respective operations according to tenant-specific configurations.

An important consideration in multi-tenancy support is performance. To support the performance scalability as the number of tenants and requests increase, JTangCSB provides a cluster implementa-tion for each component instance (starting from one node). Since the component instances of a same mediation flow may have different workload intension, the more fine-grained cluster solution may be more efficient and cost-effective. For each component instance cluster, the auto-scaling module will dynamically adjust the number of nodes to adapt to changing workloads. Within a cluster, the load bal-ancer selects the node with shortest queuing length to serve a request. Due to a variety of workload patterns in a production environment, we also provide the interfaces for each component instance clus-ter to adopt its own customized auto-scaling and load-balancing algorithms.

(5)

4.2 Cloud-level Scalability Support

In JTangCSB, we use a distributed service bus architecture (see Figure 2) to extend traditional ESB functionality with a scalable hierarchical organization of bus node. Similar to the ESB runtime environment, each PeerBusNode is equipped with a Normalized Message Router (NMR) to handle local communication. NMR provides the mediated message exchange infrastructure to allow

compo-nents (adaptors and processers) to interoperate in a standard way by using the Binding Components

(BCs) and Service Engines (SEs). BCs provide connectivity between external services and CSB envi-ronment (Web Services, etc.). SEs provide business logic and transformation services to other compo-nents (XSLT, BPEL engine, etc.). A DistributedNMR implements messaging between compocompo-nents hosted in different PeerBusNodes. The DistributedNMR is a virtual cross-node NMR, connected with JMS (Active MQ). Thus a large number of messages can be handled by PeerBusNodes in a distributed manner, and the messaging capability of JTangCSB becomes highly scalable.

In the distributed service bus nodes, JTangCSB containers can be deployed in different Peer-BusNodes. Since different relative physical distances between containers often result in different data transfer rates, it is useful to choose the placement of these containers automatically to achieve high performance, especially for large-scale CEAI projects. This is achieved in JTangCSB with an automat-ed container placement algorithm by rautomat-educing the amount of data being transferrautomat-ed. This approach works as follows: Step 1, the average size of messages between any two adjacent nodes is determined based on system logs. Step 2, each possible container topology is modeled as a Queuing Network (QN). Here, the container is represented by a service center, while the Internet between containers is modeled as a load-dependent service center whose service time is based on the size of messages and the band-width of network. Step 3, the response time of each QN is calculated. Step 4, the topology with shortest response time is selected and the containers are re-deployed by using VM migration technique. In addi-tion, the actual topologies may include fork and join operators [13]. Thus, multi-class Fork-Join Queu-ing Network (FJQN) models are needed in the second and third steps. We have proposed an approxi-mated calculation method called horizontal decomposition to solve this kind of FJQN [14].

4.3 Environmental Heterogeneity Support

JTangCSB provides a variety of adaptors (which can be implemented by different languages with the component framework OSGi) to enable the communications with heterogeneous services, thus connecting cloud applications and on-premises software. For instance, the SOAP WS adaptor, Restful WS adaptor and Database adaptor are provided for above mentioned application integration scenario. These adaptors also translate data formats between web services within CSB and distributed

(heteroge-Figure 2 Distributed service bus architecture of JTangCSB. It is composed of a set of PeerBusNode and an UltraBusNode. Each PeerBusNode is a standalone runtime environ-ment to handle the communications among local mediation components. The UltraBusNo-de is used to manage and coordinate the communications among PeerBusNoUltraBusNo-des based on Java Management Extensions (JMX) and the global message routing table.

(6)

neous) services. Assuming semantic compatibility, the various services connected to different adaptors become connected and integrated, despite different hardware and software platforms, different lan-guages and APIs, and different tenants. JTangCSB also supports various communications styles, in-cluding message-based, pub-sub, and event-driven. These styles of communication can be handled by CSB engine, which integrates all the common communication components such as Apache Active MQ, Opensplice DDS, and Esper. Besides individual runtime environment support for these types of com-munication, sharing and exchanging of such types of data should be also supported. To make such het-erogeneous data understandable efficiently by the machine, we integrated semantics into the global storage space to support automatic sharing and exchanging for heterogeneous data by using the open source OWL API and Jena toolset. It is the global semantic space that makes automatic sharing and exchanging more efficient for heterogeneous data despite differences in languages, interfaces, and

plat-forms

5. Experimental Evaluation

5.1 Application Integration Scenario & Evaluation Setup

(a) (b)

The application scenario introduced in Section 1 is modeled after a realistic use case of JTangCSB to achieve CEAI. Using JTangCSB, the company defined 7 mediation flows with 17 mediation compo-nents (6 adaptors and 11 message processers). As a representative workload, we use the client registra-tion process (shown in Figure 3 (a)) to evaluate JTangCSB performance. Figure 3(b) illustrates the implementation, which includes a CRM adaptor, an ECP adaptor and a database adaptor, to connect with CRM, ECP and on-premises financial system, respectively. The adaptors use a broadcaster, a con-tent filter, and a data format transformer, to translate and exchange data among them.

For evaluation of the configuration shown in Figure 3(b), JTangCSB was deployed as a private in-tegration platform in our two JTC-Rendezvous located in Hangzhou and Suzhou (two cities in China, about 160km apart). Each JTC-Rendezvous consists of 48 Dell PowerEdge R710 servers. The physical servers within each JTC-Rendezvous were connected by 1 Gbit Ethernet, and the two JTC-Rendezvous were connected by 10 Mbit Internet. Due to publication restrictions on the production environment, we replaced the Salesforce CRM and China Telecom ECP services with equivalent request/response ser-vices that simulate CRM and ECP. The simulated serser-vices were deployed on Amazon EC2 (VMs on Compute Optimized C1 Medium instances) to maintain their distributed nature. The workload genera-tor (emulated clients) was also deployed in an Amazon EC2. The performance metrics such as response time are measured by the workload generator (from request to response) and the throughput is meas-ured by last component of each running mediation flow.

Figure 3 (a) illustrates the integration scenario for client registration: step 1, client creating an account in CRM; step 2, synchronization of client information with an on-premises finan-cial system; and step 3, sending the registration result to the client using ECP’s short mes-sage service. Figure 3 (b) illustrates the evaluation setup.

(7)

5.2 Multi-Tenant Overhead Evaluation

To evaluate the overhead of JTangCSB, we chose the multi-tenancy support and measured the system performance with the number of tenants at 2, 10, and 50. The workload ranged from 800 to 2000 clients. The benchmark consists of requests that invoke one of the 7 mediation flows. The invok-ing ratio among the 7 mediation flows is 3:7:10:12:13:20:35, derived from the logs of the company’s production system, which is deployed as a commercial application supported by JTangCSB. Figure 4(a) and (b) presents the measured throughput and response time from the experiments separately. The mul-ti-tenant support overhead compared the cases of 2, 10, and 50 tenants with the non-mulmul-ti-tenant aware implementation. The overhead of multi-tenant support is unnoticeable until workload 1200. For work-loads 1800 and higher, the average response time becomes too long (higher than 1sec) for realistic ser-vice level agreements. The cases between 1200 and 1600 show the multi-tenant support achieves the same response time, but a small throughput penalty (between 10% to 20%). The performance differ-ences for the increasing number of tenants (2, 10, and 50) are quite small (less than 10%). These exper-imental results show that the overhead introduced by multi-tenancy in JTangCSB is acceptable, show-ing an effective support of multi-tenancy towards achievshow-ing the vision of CEAI.

# &$#$ # &!&%#"$ # &!&%'$&# %$ &%ï%% &%ï%%%$ &%ï%%%$ &%ï%%%$ !$"!" " "" " "%"$!#" $#ï## $#ï###" $#ï###" $#ï###"

(a) Throughput (b) Response time

1 5 10 50 100 500 1000 0 50 100 150 200 250 Message sizes [KB] Throughput [req/s] Intelligent placement Random placement 1 5 10 50 100 500 1000 0 5 10 15 20 25 Message sizes [KB] Response time [s] Intelligent placement Random placement

(c) Throughput (d) Response Time

5.3 Container Placement Optimization Evaluation

The evaluation of a sophisticated software platform such as JTangCSB is an ongoing process and subject of active research. As illustration of JTangCSB performance potential to achieve cloud-level scalability, we compared its intelligent container placement method with a simple method (ran-dom placement). In this experiment, the workload is constant at 1000 clients and the client information message size in the client registration flow varied from 1 KB to 1000 KB. Figure 4(c) and (d) show the throughput and response time of client registration flow for the different message sizes. Using the intel-ligent placement method, the throughput remains high until the message size reaches 1000 KB. In comparison, the random method causes the throughput to decline, as the message size grows larger than 10 KB. The response time measurements show the same trend. The main reason of the response time (and throughput) difference is the overhead of message delivery through Internet. In this flow, the original message generated by clients will be sent to two paths: one for the ECP and the other for the on-premises financial system. The size of message for ECP is always small (less than 1 KB) because of the data transformation filter. However, the message for the financial system has almost the same size as the original message (only format has been changed). Thus, our intelligent container placement method, which can avoid large amount of data being transferred through Internet, has better perfor-mance than the random one.

Figure 4 Experimental Results of Multi-tenancy Overhead and Placement Optimization Some content may change prior to final publication.

(8)

6. Conclusion

The growing success in migrating enterprise applications to cloud environments also increases the pressure to integrate enterprise applications (both on-premises and services in the clouds) with other distributed services on clouds. This vision (cloud enterprise application integration – CEAI) bridges the gap between cloud services and on-premises software. We present three CEAI properties (multi-tenancy, cloud-level scalability and environmental heterogeneity) that distinguish cloud-based applications from traditional Enterprise Application Integration (EAI) environments. Then we outline the concept of Cloud Service Bus (CSB) to support the CEAI properties and bridge the gap, by build-ing on ESB on the EAI side and SOI on the cloud side. We describe a practical implementation (JTangCSB), an integration platform to deliver efficient and cost-effective integration and run-time service to achieve CEAI. An evaluation of JTangCSB using a realistic application scenario shows the feasibility and effectiveness of the CSB approach. Our future work on this topic is to evaluate JTangCSB in more detail by conducting extensive experiments, and then adapt it to more application domains, not only the enterprise computing environment.

7. References

1. Oracle Survey, "Cloud for Business Managers: the Good, the Bad and the Ugly," May 2013. 2. J. Yin, H. Chen, S. Deng, Z. Wu, and C. Pu, "A dependable ESB framework for service

integra-tion," IEEE Internet Computing, vol. 13, no. 2, pp. 26–34, Mar. 2009.

3. Baude, Françoise, et al. "ESB federation for large-scale SOA," Symposium on Applied Computing, ACM, 2010.

4. Strauch, Steve, et al. "ESB MT: Enabling Multi-Tenancy in Enterprise Service Buses," IEEE CloudCom, 2012, pp. 456-463.

5. Strauch, Steve, et al. "Implementation and Evaluation of a Multi-tenant Open-Source ESB," ESOCC 2013, pp. 79-93.

6. Vaquero, Luis M, et al. "Dynamically scaling applications in the cloud," ACM SIGCOMM Com-puter Communication Review, 2011, 41(1): 45-52.

7. Georgantas, Nikolaos, et al. "A coordination middleware for orchestrating heterogeneous distrib-uted systems," Advances in Grid and Pervasive Computing 2011, pp. 221-232.

8. Georgantas, Nikolaos, et al. "Service-oriented Distributed Applications in the Future Internet: The Case for Interaction Paradigm Interoperability," ESOCC 2013, pp. 134-148.

9. Shen, Zhiming, et al. "Cloudscale: elastic resource scaling for multi-tenant cloud systems," Pro-ceedings of the 2nd ACM Symposium on Cloud Computing. ACM, 2011.

10. Ni, Jiacai, et al. "Adapt: adaptive database schema design for multi-tenant applications," Proceed-ings of the 21st ACM international conference on Information and knowledge management. ACM, 2012.

11. Pippal S K, Kushwaha D S. "A simple, adaptable and efficient heterogeneous multi-tenant data-base architecture for ad hoc cloud," Journal of Cloud Computing, 2013, 2(1): 1-14.

12. A. Sun, J. Zhou, T. Ji, and Q. Yue, "Csb: Cloud service bus based public saas platform for small and median enterprises," ICCSC, 2011, pp. 309–314.

13. H. C. Zhao, C. H. Xia, Z. Liu, and D. Towsley, "A unified modeling framework for distributed resource allocation of general fork and join processing networks, " SIGMETRICS'10, pp. 299–310. 14. H. Chen, J. Yin, and C. Pu, "Performance analysis of parallel processing systems with horizontal

decomposition, " IEEE Cluster 2012, pp. 220-229.

Jianwei Yin is a professor in the e-Service Research Center at Zhejiang Uni-versity, China. His research interests include service computing, cloud compu-ting and healthcare IT. Contact him at zjuyjw@cs.zju.edu.cn.

(9)

Xingjian Lu is a PhD student in the e-Service Research Center at Zhejiang University, and is the corresponding author for this article. His research inter-ests include service computing, and performance engineering. Contact him at zjulxj@zju.edu.cn.

Calton Pu is the John P. Imlay Jr. Chair in Software at the Georgia Institute of Technology. His research interests include cloud computing and Internet data management. Contact him at calton@cc.gatech.edu.

Zhaohui Wu is a professor in the e-Service Research Center at Zhejiang Uni-versity. His research interests include service computing, embedded system and pervasive computing. Contact him at wzh@cs.zju.edu.cn.

Hanwei Chen is a PhD student in the e-Service Research Center at Zhejiang University. His technical interests include event-based system and Web ser-vices. Contact him at chw@cs.zju.edu.cn.

Figure

Updating...

References