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

Transcription

1 JTangCSB: A Cloud Service Bus for Cloud and Enterprise Application Integration Jianwei Yin 1, Xingjian Lu 1, Calton Pu 2, Zhaohui Wu 1, Hanwei Chen 1 1 College of Computer Science and Technology, Zhejiang University, Hangzhou, China 2 School of Computer Science, Georgia Institute of Technology, Atlanta, USA Abstract Cloud and Enterprise Application Integration (CEAI) is a new challenge as more enterprise applications migrate successfully to cloud environments. However, achieving CEAI properties such as multi-tenancy, cloud-level scalability, and environmental heterogeneity is non-trivial for enterprise applications originally built under the assumption of centralized management (e.g., EAI using Enterprise Service Bus - ESB). To bridge the gap, we outline the Cloud Service Bus (CSB) approach to address the above CEAI properties. A concrete implementation of CSB, called JTangCSB, demonstrates its feasibility in practice. An experimental evaluation of JTangCSB used in a realistic application scenario illustrates 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 software. 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 traditional 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, including multi-tenancy identification, multi-tenancy access control, multi-tenancy data storage, and multi-tenancy service executions. These challenges affect critical quality of service dimensions 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 accounts, 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 languages 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 software and cloud services, as well as among different cloud services. Specifically, various adaptors, unified integration semantic, and environment-aware management mechanisms are required to integrate these heterogeneous systems. 1

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, multitenancy aware mediation components and flows are designed to support integrations with software-asa-service in clouds. Distributed integration engine and service bus nodes are provided to make the architecture 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 Relationship 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 onpremises 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 evaluation 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 multitenancy, 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 discussion 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 multitenancy, Strauch [4] investigated the requirements for multi-tenant ESB solutions, proposed an implementation-agnostic ESB architecture that addresses these requirements, and discussed the prototype realization with performance evaluation [5]. In cloud-level scalability, Vaquero [6] discussed the initiatives, 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 address 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 concept, 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 federation of distributed ESB. The combination of scalability and multi-tenancy is illustrated by CloudScale [9], a prediction-driven elastic resource scaling system for multi-tenant cloud computing. The lightweight 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, scalable 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 service execution (for multi-tenancy) [4][5][10][11], distributed integration engine and service bus topology [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 2

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 Jitterbit developed various integration solutions for small to medium size enterprises (see 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 mechanisms 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 infrastructure for all three CEAI properties, demonstrates a promising approach to achieving the CEAI vision 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 represents 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, component instances, mediation flows and services are all stored in a global semantic space. Second, the mediation flows connect component instances. To support cloud-level scalability, components and mediation flows have a cluster implementation. Third, services represent the applications (cloud applications 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 tenants 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 contains 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: Distributed 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 runtime environment for mediation flows, including data transformation, message routing, flow orches- 3

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 component framework OSGi is used for the lifecycle management of the mediation components in all the containers. The load balancer is provided to evenly distribute workloads on these containers. The autoscaling 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 users, and manages all the authorized accesses transparently. It supports the Lightweight Directory Access Protocol (LDAP) and Single Sign-on services, which can be used to provide role-based access 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 component development kits and a mediation flow designer. The two tools are Eclipse plugins for component development and mediation flow design respectively. The Web-based console provides the administration, 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 database 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 adaptors and message processers were designed to be multi-tenancy aware by providing an identity distinguishing 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 implementation 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 balancer 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 cluster to adopt its own customized auto-scaling and load-balancing algorithms. 4

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 components (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 environment (Web Services, etc.). SEs provide business logic and transformation services to other components (XSLT, BPEL engine, etc.). A DistributedNMR implements messaging between components 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. 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 environment to handle the communications among local mediation components. The UltraBusNode is used to manage and coordinate the communications among PeerBusNodes based on Java Management Extensions (JMX) and the global message routing table. 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 automated container placement algorithm by reducing the amount of data being transferred. 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 bandwidth 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 addition, the actual topologies may include fork and join operators [13]. Thus, multi-class Fork-Join Queuing Network (FJQN) models are needed in the second and third steps. We have proposed an approximated 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- 5

6 neous) services. Assuming semantic compatibility, the various services connected to different adaptors become connected and integrated, despite different hardware and software platforms, different languages and APIs, and different tenants. JTangCSB also supports various communications styles, including 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 communication, sharing and exchanging of such types of data should be also supported. To make such heterogeneous 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 platforms 5. Experimental Evaluation 5.1 Application Integration Scenario & Evaluation Setup (a) (b) 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 financial system; and step 3, sending the registration result to the client using ECP s short message service. Figure 3 (b) illustrates the evaluation setup. 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 components (6 adaptors and 11 message processers). As a representative workload, we use the client registration 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 content 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 integration 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 services that simulate CRM and ECP. The simulated services were deployed on Amazon EC2 (VMs on Compute Optimized C1 Medium instances) to maintain their distributed nature. The workload generator (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 measured by last component of each running mediation flow. 6

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 invoking 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 multi-tenant support overhead compared the cases of 2, 10, and 50 tenants with the non-multi-tenant aware implementation. The overhead of multi-tenant support is unnoticeable until workload For workloads 1800 and higher, the average response time becomes too long (higher than 1sec) for realistic service 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 differences for the increasing number of tenants (2, 10, and 50) are quite small (less than 10%). These experimental results show that the overhead introduced by multi-tenancy in JTangCSB is acceptable, showing an effective support of multi-tenancy towards achieving the vision of CEAI. (a) Throughput (b) Response time Intelligent placement Random placement Intelligent placement Random placement Throughput [req/s] Response time [s] Message sizes [KB] Message sizes [KB] (c) Throughput (d) Response Time Figure 4 Experimental Results of Multi-tenancy Overhead and Placement Optimization 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 cloudlevel scalability, we compared its intelligent container placement method with a simple method (random 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 intelligent 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 performance than the random one. 7

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 building 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 J. Yin, H. Chen, S. Deng, Z. Wu, and C. Pu, "A dependable ESB framework for service integration," IEEE Internet Computing, vol. 13, no. 2, pp , Mar Baude, Françoise, et al. "ESB federation for large-scale SOA," Symposium on Applied Computing, ACM, Strauch, Steve, et al. "ESB MT: Enabling Multi-Tenancy in Enterprise Service Buses," IEEE CloudCom, 2012, pp Strauch, Steve, et al. "Implementation and Evaluation of a Multi-tenant Open-Source ESB," ESOCC 2013, pp Vaquero, Luis M, et al. "Dynamically scaling applications in the cloud," ACM SIGCOMM Computer Communication Review, 2011, 41(1): Georgantas, Nikolaos, et al. "A coordination middleware for orchestrating heterogeneous distributed systems," Advances in Grid and Pervasive Computing 2011, pp Georgantas, Nikolaos, et al. "Service-oriented Distributed Applications in the Future Internet: The Case for Interaction Paradigm Interoperability," ESOCC 2013, pp Shen, Zhiming, et al. "Cloudscale: elastic resource scaling for multi-tenant cloud systems," Proceedings of the 2nd ACM Symposium on Cloud Computing. ACM, Ni, Jiacai, et al. "Adapt: adaptive database schema design for multi-tenant applications," Proceedings of the 21st ACM international conference on Information and knowledge management. ACM, Pippal S K, Kushwaha D S. "A simple, adaptable and efficient heterogeneous multi-tenant database architecture for ad hoc cloud," Journal of Cloud Computing, 2013, 2(1): 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 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 H. Chen, J. Yin, and C. Pu, "Performance analysis of parallel processing systems with horizontal decomposition, " IEEE Cluster 2012, pp Jianwei Yin is a professor in the e-service Research Center at Zhejiang University, China. His research interests include service computing, cloud computing and healthcare IT. Contact him at zjuyjw@cs.zju.edu.cn. 8

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 interests 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 University. 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 services. Contact him at chw@cs.zju.edu.cn. 9