Dynamic Interoperability Between Multi-Tenant SaaS Applications Shijun Liu, Liwen Wang, Xiangxu Meng, and Lei Wu
Abstract Enterprise Interoperability has been becoming an important area of research to ensure the competitiveness and growth of enterprises. While Software as a Service (SaaS), the new service delivery model offers a set of advantages for enterprises in sharing software with lower cost, the loosely coupled and multitenant features of SaaS model bring new chanllenges of interoperability between two SaaS applications. This paper proposes a platform to delivery SaaS application for enterprises. Among the multi-tenant SaaS applications, service based interoperability is introduced by extending the SCA specification with interoperability interfaces. Then a method of service interoperability supported by ESB and a dynamic service routing mechanism is discussed in details. At last, an experiment is introduced to evaluate the dynamic routing mechanism and show the effectiveness. Keywords Interoperability • ESB • Multi-tenant • SaaS
1 Introduction Today an enterprise’s competitiveness is to a large extent determined by its ability to seamlessly interoperate with others. Enterprise Interoperability (EI) has therefore become an important area of research to ensure the competitiveness and growth of enterprises [1]. At the same time, with the rapid development of software and network technology, SaaS (Software as a Service) [2] has been widely accepted as a popular way to carry out the software service delivery. Many software corporations, including Salesforce, Microsoft and IBM, have done much research efforts trying to convert the traditional systems such as SCM, CRM, OA and ERP to SaaS
S. Liu (*) • L. Wang • X. Meng • L. Wu School of Computer Science and Technology, Shandong University, Jinan 250101, P.R.China e-mail:
[email protected] R. Poler et al. (eds.), Enterprise Interoperability V: Shaping Enterprise Interoperability in the Future Internet, Proceedings of the I-ESA Conferences 5, DOI 10.1007/978-1-4471-2819-9_19, # Springer-Verlag London Limited 2012
217
218
S. Liu et al.
application services, and SaaS applications have been adopted by more and more business partners, especially by small and medium enterprises (SMEs). SaaS offers a set of advantages for software customers: Instead of being forced to build and maintain large data centers and hosting a big amount of middleware to run applications, companies consume IT-Services in the SaaS model just like they would use any other utility such as electricity or water [3]. In contrast to traditional on-premise software that is deployed and run in a data center at the customer‘s premise, SaaS software is run at a SaaS hosting provider and must be accessed via the Internet. So the enterprises once accomplish their business through the interaction between traditional on-premise softwares must face with the interoperability issues between SaaS applications with different method now. SaaS is a new delivery model for software, which be comprised by loosely coupled services and support multi-tenants over the Internet. The feature of “multitenancy” refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants) [4]. Software delivered in a SaaS model is no longer run exclusively for one customer at a customer’s premise but run at a service provider and accessed via the Internet. The feature of “loosely coupled” means that interoperability bridge between two SaaS applications must be services with standard interfaces. It must be pointed that, the above two features are exactly two main challenges of interoperability between SaaS applications. In contrast to the multi-user model, multi-tenancy requires customizing the single instance according to the multi-faceted requirements of many tenants [5]. With a multitenant architecture, a SaaS application must be designed to virtually partition its data and configuration, and each client organization works with a customized virtual application instance. But, even drive cost efficiency for SaaS solution providers, multi-tenant architecture does not allow true customization of applications for large clients, prohibiting such applications from being used in scenarios (applicable mostly to large enterprises) for which such customization is necessary [6]. One possible solution for this problem is by using composition technique. The dynamic composition technique reuses existing SaaS services to build different applications according to dynamic business logics flow, which can fulfill the demands of users. Moreover, dynamic interoperability is implemented by rerouting the logics flow to link different SaaS tenant instances. Enterprise Service Bus (ESB) is a new application integration approach which can provide loosely coupled, highly distributed integration network based on SOA. Service-Oriented Application emphasizes on the dynamism and loose-coupling of integration, which requires ESB to supply dynamic and reliable routing method, and sustain the service selection and adaption based on service routing, so it can achieve the goal of supplying more convenient, swift and flexible business process transaction. Usually, we regard the ESB as the kernel of SOA [7], and it can manage mass services for different purposes, as well as the loosely coupled service requesters and service providers. Although these Service Buses are different from many levels, the main functions of them are almost the same. They both regard service routing as one key function in SOA.
Dynamic Interoperability Between Multi-Tenant SaaS Applications
219
Web service model, XML and component concepts are utilized to provide a good standard for building ESB. Web service has become the major technology in distributed application automatic interaction [8]. Developers need not write large number of codes, but integrate web service instead. The architecture and design discussed in this paper adopt the design pattern of ESB. After analyzing present multi-tenant SaaS and service interoperability research status, dynamic interoperability architecture and the method supported by ESB are discussed in this paper. The following parts of the paper are organized as follows: Section 3 describes the idea of service based interoperability among SaaS applications. Section 4 discusses the method to support dynamic interoperability by an ESB system. Section 5 introduces the evaluation of our method.
2 Related Works Interoperability is a key issue in the management of IT services. It is particularly important when a Service Provider’s services can not solely satisfy all customer requests due to technology or in some cases geographical limitations [9]. Kassel presents a service architecture for SaaS business model, which addressing explicitly interoperability issues, and aiming in automatic composition of reliable complex service offerings from well-known service components [10]. The multi-tenant solution needs to be able to use cross-tenant data and provide interoperability as well as other integrated capabilities such as tenant-targeted process management, reporting, monitoring and problem determination with cross-tenant analysis [11]. The key characteristics of multi-tenancy including 3 aspects: hardware resource sharing, high degree of configurability, shared application and database instance. Bezemer points out that Mixing multi-tenant with single-tenant code leads to increased code complexity because it is more difficult to keep track of where multitenant code is introduced. So to keep the impact on the code (complexity) low, the implementation of multi-tenant components should be separated from single-tenant logic as much as possible [12]. Variation points have been introduced [13][14] and are one of the key concepts for software product lines to express variability. Variation points allow the specification of points in a software design that can be customized in order to create new product line members. Similar to software product lines, SaaS applications have variability points where individual customers can customize the application to their needs. In a SaaS application, the variability points exist in several layers, like UI layer, process layer, data layer, etc. Reference [15] describes how these variability descriptors can be transformed into a WS-BPEL process model that can then be used to guide a customer through the customization of the SaaS application. Reference [13] shows how the service component architecture (SCA) [16] can be extended with variability descriptors and SaaS multi-tenancy patterns to package and deploy multi-tenant aware configurable composite SaaS applications.
220
S. Liu et al.
3 Service based interoperability among SaaS applications 3.1
A SaaS application delivery Platform for enterprises
Leveraging service computing technologies, we design and implement an servicebased collaboration supporting platform (New Utility platform & Tools for Service, Nuts [17]) which is used to deliver cheap, easy-to-use collaboration software to small and medium-sized enterprises in the form of SaaS. The architecture of Nuts is shown in Fig. 1. In Nuts, IaaS layer virtualizes computing power, storage and network connectivity of the data centers, and offers it as provisioned services. All these resources are gathered in to a resource pool, users can scale up and down these resources on demand dynamically. Built on top of the IaaS layer, PaaS layer often provides a set of supporting services to assist application development, testing, deployment, monitoring, hosting on the internet. On the basis of services in IaaS layer, PaaS layer, applications can be constructed and delivered in the form of SaaS, which require cooperative capability and interoperability with others.
3.2
Hierarchical Service Model for SaaS
To eliminate the incompatibilities among enterprise systems involved in a collaboration scenario, a standard interface is needed to interact with each other.
Fig. 1 Service-based Collaboration Supporting Platform Architecture
Dynamic Interoperability Between Multi-Tenant SaaS Applications
221
According to various business requirements of tenant applications, the service components of a SaaS system are divided into 3 levels: business-independent level (level 0), business-dependent level (level 1), and composite business level (level 2) in our research on service-oriented multi-tenancy SaaS application construction. We adopt a gradually abstracting approach to structure services: services of businessindependent level are basic functional services which are not relevant to business; services of business-dependent level are business services which are implemented by business-independent services; services of composite business level are generated by putting together interrelated business-dependent services. Therefore, the dependencies between services are existent. Above the three levels, a SaaS application is constructed and composed by 3 parts: an abstract SaaS application,the metadata file for specific tenant, and a set of service components. The structure of multi-tenancy applications is a top-down process: tenant applications use services in composite business level without knowing the specific implementation of these services; services of composite business level are generated by putting together interrelated business-dependent services; the business-dependent services invoke some business-independent service for implementation. Meanwhile, there are invoking relations between services at the identical level.
3.3
SCA-based Services interoperability Implementation
SCA entities are components which may provide interfaces (called services), require interfaces (called references) and expose properties. In order to implement the collaboration of services, we extend the SCA assembly model specification [18], where: The “function” element provides detailed function information of service, including “name”, “input” and “output” attributes. The “function”, “input”, ”output” and “refType” attributes of the “reference” element indicate particular interface information of requisite service and the relationship of services. Service providers register service components into service repository by parsing the XML-based configuration files in deployable packages. When service Si needs to collaborate with service Sj, first, the system will retrieve binding URI of reference in service repository. If the search succeeded, the system needs to match the conformity between the collaborated service and the search results. Otherwise, the system needs to match all services in service repository. Si matches with Sj, if: the function, input, output of reference in Si equals to the function name, input, output of service in Sj; the non-functional properties requires and policySets of reference in Si included in the requirements and policySets of service in Sj. For the interoperability often occurred in business layer. For example, among the applications of manufacturing enterprises, the data of orders, BOMs or inventory often need be transferred as the message of interoperability. In our SaaS system, the business-related components (Level 1 layer) undertake the task of interoperability, through the extended interoperability interfaces. As shown in Table 1,
222
S. Liu et al.
Table 1 Interoperability interfaces of a SBM service
in the Supplier Business Management service (SBM), which based on the SCA specification, the list of parts suppliers access interface SupplierPartsList, and the supplier inventory query interface SupplierInventory are designed to support interoperability with other business services.
4 Dynamic Interoperability Supported by ESB 4.1
Service interoperability supported by ESB
Generally, ESB is defned as the middleware of service provider and service consumer, which implements the service registration, basic conversion, routing and the interoperability of applications. It provides a event driven, documents oriented model and a distributed mechanism to process and operate. It supports routing, filter which can be based on the content and transmission complex data. There are many ESB products, some of which are open source. For example, Mule [19] is widely used. In this paper, we use Mule as the foundation of our system. For example, there are two SaaS applications in the delivery platform, one is supply business management system (SBM) and the other is user information management system (UIM). When the user login the SBM system, SBM can query the user’s role and privileges through ESB in UIM system. In order to realize this object, the following efforts should be done: At first, a Mule client program should be embedded into SBM. It will be used to send request message which contains user’s name to Mule ESB. Secondly, the userInfoQueryService contained in UIM system should be configured as one service component in the configuration file of Mule.
Dynamic Interoperability Between Multi-Tenant SaaS Applications
223
Fig. 2 SBM query user information through UIM
Thirdly, when ESB receives the request (Query user’s information) from SBM, in order to get the payload username, it will resolve the request according to the predetermined rules. Because the userInfoQueryService has been configured as a service component of mule in the second step, Mule ESB delivers the request to the pre-configured component directly whenever it is passed. As Fig. 2 shows that the userinfoQueryService be invoked directly.
4.2
A Dynamic Service Routing Method
Section 4.1 shows a static service routing method supported by ESB. Apparently, For service consumer, there is no other userInfo service to choose except UserInfoQueryService, which means the routing path is fxed once the ESB is initiated. The routing path and the service could not be changed according to consumer’s request and the runtime status. The concept of dynamic service routing means that the routing path is not fixed, and can be changed by selecting service from the a service set dynamically to meet the need of consumer. For example, when a query request needs to be executed, it is just send the request to ESB, and the ESB just return the query result to the requester. In the process of the request, consumers need not to know which specific service instance be invoked but just pass the request conditions including the service level to ESB. Necessarily, all the services must be published into Mule in advance, the function of the service and the relative interface should be described in its WSDL file. In our system, services are divided into three levels labelled by gold, sliver and copper according to its QoS properties, as shown in Table 2. Dynamic interoperability means a SaaS application interacts with another SaaS application through services routed dynamically. But Mule only deals with static routing by the routing rules declared in advance. To solve the problem of dynamic routing, we design a routing strategy which executes the routing in the implementation class of a set of services. For example, there are several service instances of a query service with the same functionality, for example, QueryServiceA, QueryServiceB and QueryServiceC, have different implement method, response time, cost, service reliability parameter.
224
S. Liu et al. Table 2 Service levels and its attributes
Fig. 3 The whole process to invoke stock service
All of these services are linked with a service proxy named QueryServiceProxy. Through a registration interface, these services can be registered into ESB, and their properties (response time, cost, reliability) can be configured and stored in a common implementation file named QueryServiceInstance. When the user sends a query request, which contains both the payload and the service level the user required to QueryServiceProxy. QueryServiceInstance will initiate the routing algorithm. For example, if the user wants to request a golden level query service, the algorithm will achieve all the information of service instances which belong to golden level. By synthesizing various factors, including the current load of every service instances, invoked times and other status, the service instance that satisfies the needs could be chose. Then the payload of request will be routed to this chosen query service instance, and the query result will be transmitted to QueryServiceProxy. Ultimately the QuerySerivceProxy will return the result to user. The whole process is illustrated by Fig. 3.
Dynamic Interoperability Between Multi-Tenant SaaS Applications
225
Table 3 The experiment results
5 Evaluation To evaluate the method mentioned above, six query services have registered with different attributes in Mule ESB, which are divided into three levels, and ten requests with different request parameter be sent to Mule ESB to invoke query service (shown in Table 3). As mentioned above, when the query service receives the requests, the routing algorithm in the implementation class of the service chooses different service instance accord to the request level and routes the payload to it. The experimental results show that all the different requests could be routed to an appropriate service instance.
6 Conclusion and Future Work This paper proposed a methodology that provides a guide on how to establish dynamic interoperability between multi-tenant SaaS applications. Under the guide of this methodology, the paper designed and realized an SaaS service platform to delivery SaaS applications for SMEs and enhance the interoperability of services. The architecture framework of the platform is introduced, as well as the SCA-based services interoperability by the extension of SCA specification with interoperability interface. A dynamic service routing method is designed on the base of Mule ESB. As for future work, we are looking into more elaborative studies to dynamic interoperability solution in multi-tenant SaaS applications delivery and provisioning areas. Meanwhile, we would like to expand the study to other service products and solutions and further refine the methodology for a business case on turnaround time and the quality.
226
S. Liu et al.
Acknowledgement The authors would like to acknowledge the support provided by the National High Technology Research and Development Program of China (2009AA043506, 2011AA040603), and the Natural Science Foundation of Shandong Province (ZR2009GM028, ZR2011FQ031).
References [1] Yannis Charalabidis, George Gionis, Karl Moritz Hermann, Cristina Martinez; Enterprise Interoperability Research Roadmap;Feb.2008 [2] Dubey, A. and Wagle, D (2007) Delivering Software as a Service, The McKinsey Quarterly, Web exclusive, May, http://www.mckinseyquarterly.com/Delivering_software_as_a_service_2006 [3] Yong Zhang, Shijun Liu, Lei Wu, Yuchang Jiao, Service-oriented Enterprise Interoperability in Automobile Supply Chain Management, Computer Science and Information Systems, Volume 07, Issue 01:31–49 (February 2010) [4] WikiPedia, http://en.wikipedia.org/wiki/Multitenant [5] Thomas Kwok, Thao Nguyen, and Linh Lam. A software as a service with multi-tenancy support for an electronic contract management application. In Proc. Int. Conf. on Services Computing (SCC), pages 179–186. IEEE, 2008. [6] WikiPedia,http://en.wikipedia.org/wiki/Software_as_a_service [7] Martin Keen, Amit Acharya, Susan Bishop, et.a1, “Patterns:Implementing an SOA Using an Enterprise Service Bus”, Redbooks, IBM Press, July 2004. [8] de Castro, V., Marcos, E. and Sanz, M. L. (2006) ‘Service composition modeling: a case study’, The Seventh Mexican International Conference on Computer Science, San Luis Potosi, Mexico, September, pp.101–108. [9] Shwartz, L.; Ayachitula, N.; Buco, M.; Grabarnik, G.; Surendra, M.; Ward, C.; Weinberger, S.; IT Service Provider’s Multi-Customer and Multi-Tenant Environments. The 9th IEEE International Conference on E-Commerce Technology and the 4th IEEE International Conference on Enterprise Computing, E-Commerce, and E-Services, 2007. CEC/EEE 2007. Page(s): 559 – 566 [10] Kassel, S.; An Architectural Approach for Service Interoperability. International Conference on Interoperability for Enterprise Software and Applications China, 2009. IESA ’09. Page(s): 212–218 [11] Shwartz, L.; Diao, Y.; Grabarnik, G.Ya.; Multi-tenant solution for IT service management: A quantitative study of benefits. IFIP/IEEE International Symposium on Integrated Network Management, 2009. IM ’09. Page(s): 721–731 [12] Cor-Paul Bezemer, Andy Zaidman. Multi-tenant SaaS applications: maintenance dream or nightmare?.Proceedings of the Joint ERCIM Workshop on Software Evolution and International Workshop on Principles of Software Evolution IWPSE-EVOL’10: 88–92 [13] R. Mietzner and F. Leymann. Generation of BPEL Customization Processes for SaaS Applications from Variability Descriptors. In IEEE International Conference on Services Computing, 2008 [14] M.Jaring and J. Bosch. Architecting product diversification- formalizing variability dependencies in software product family engineering. In QSIC ’04: Proceedings of the Quality Software, Fourth International Conference, pages 154–161,Washington, DC, USA, 2004. IEEE Computer Society. [15] Ralph Mietzner, Frank Leymann. Defining Composite Configurable SaaS Application Packages Using SCA, Variability Descriptors and Multi-Tenancy Patterns. The Third International Conference on Internet and Web Applications and Services.2008) [16] Beisiegel, M. et al, “Service Component Architecture,” Nov. 2007, www.osoa.org. [17] Nuts, http://www.nutsplatform.cn [18] Rui Wang, Yong Zhang, Shijun Liu, Lei Wu, Xiangxu Meng, A Dependency-aware Hierarchical Service Model for SaaS and Cloud Services, 2011 IEEE International Conference on Services Computing, Washington, DC, USA, 4-9 July 2011, pp: 480–487 [19] Mule, www.mulesoft.org
