software applications as services through an online delivery of software to customers [1]. ... Moreover, the function and the business value of each feature are ...
2010 IEEE 6th World Congress on Services
Moving from SaaS Applications towards SOA Services Ali Bou Nassif and Miriam A. M. Capretz Department of Electrical and Computer Engineering Faculty of Engineering, the University of Western Ontario London, Ontario, Canada {abounass, mcapretz}@uwo.ca
Abstract— This paper presents a brief introduction of Software as a Service (SaaS) and Service Oriented Architecture (SOA). Specifically, the paper introduces a five-step model to show how SaaS can be offered as SOA services. Furthermore, a real-life scenario is provided to demonstrate the benefits of using the proposed model.
B. Investigation: During this stage, the SaaS application is thoroughly analyzed and investigated in order to determine application characteristics such as its maturity level, its size, and its programming language. Specifically, the goal of this stage is to determine the dependency level of the application’s functionalities.
Keywords: SaaS, SOA, Transition from SaaS to SOA
C. Feature Identification: Each SaaS application has a predefined set of features. For instance, the largest SaaS vendor, Salesforce.com, offers its CRM application in five editions: Contact Manager, Group, Professional, Enterprise, and Unlimited [3]. Each of these editions has a collection of unique features; however, this work will identify the features of the Unlimited Edition, because it contains all the possible features. During this stage, features that are candidates to become services are identified. Moreover, the function and the business value of each feature are identified.
I. INTRODUCTION Recently, there has been a strong tendency by both vendors and customers to turn conventional software into services. Software as a Service (SaaS) is a technology that offers software applications as services through an online delivery of software to customers [1]. Customers who traditionally purchased a software license (On-Premise software) for an application, such as Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP) paid thousands of dollars for this license. With SaaS, customers can subscribe to applications from a SaaS provider and pay fees based on their usage of the application. Service Oriented Architecture (SOA) can be defined as a flexible set of design architectures with a collection of services that communicate amongst each other [2]. SOA allows software functionalities to be available in the form of services to anyone who is authorized to use these services. In this paper, Section II demonstrates a new model to provide SaaS as SOA services. Subsequently, Section III presents a real-life scenario to describe the model. Finally, Section IV concludes the paper.
D. Services Extraction: In the previous stage, certain features may be deemed ineligible to become SOA services because they might be tightly coupled or dependent on other features. In the Services Extraction step, the selected features will be converted to services, most commonly, to Web Services. At this stage, Web Services are offered to customers through SaaS. However, there is no guarantee that these Web Services are generic and independent, as it depends on the technology being used with the Web Services, such as REST or SOAP. E. Services Enrichment: At this final stage of the model, services are nearly ready to be involved with SOA. The conformity of Web Services to SOA principles is verified, especially in terms of their potential for reuse, their independence and their generic nature. For instance, REST services are not as independent as SOAP services. As a result, some services might be redesigned to match SOA principles or standards. For instance, instead of offering five different editions, each containing a group of features, Salesforce.com can now offer more than fifty services, each with a different price. After the SaaS application is compartmentalized into services that comply with SOA principles, the services are ready to participate with SOA. As shown in the model, the SaaS vendor can act as a service provider who publishes its services with a broker. Additionally, the SaaS vendor can also be a service requester.
II. MOVING FROM SAAS TO SOA In this section, a new model is proposed in order to illustrate the way in which SaaS applications can be offered as SOA services. The model, depicted in Figure 1, is divided into five main stages. These stages include: A. SaaS Allocation: In this first step, a SaaS application, or a part of an application, which will be transformed to SOA services, is allocated. The entire SaaS application does not necessarily need to be migrated to SOA; rather, some parts of the application will be converted to SOA while other parts will be kept as SaaS. For example, a SaaS company might wish to provide specific features, which they believe are very competitive in the market, as SOA services.
978-0-7695-4129-7/10 $26.00 © 2010 IEEE DOI 10.1109/SERVICES.2010.63
187
C. Feature Identification: During this stage, all features of the Communications Section were identified. After the business value of each feature was analyzed, the voicemail feature was selected as a potential SOA service because the voicemail feature of SmartCRM can compete with similar features from other providers in the market. D. Services Extraction: In this step, the voicemail feature was converted to a Web Service by using SOAP, WSDL and UDDI. However, the voicemail Web Service was not guaranteed as a valid SOA service. E. Services Enrichment: In this stage, the voicemail service was tested using SOA principles. The service was found to be loosely coupled because of the SOAP protocol characteristics. However, there was an issue regarding the reusability of this service. SOA services must be reusable by multiple applications, and thus, the voicemail service needed to be supplemented. To support the reusability of the service, new servers were added to handle the large number of users that will use the service. Virtualization technology was involved in the new system to support maintenance and security. Furthermore, the existing database structure, with a single database per customer, was not the best choice for supporting the new system. To resolve this problem, the old database was modified to become a shared database that supported additional users. After SmartCRM transitioned through the five stages of our proposed model, the services could be extracted from SaaS applications and were ready to be published with SOA brokers for customer use. Finally, SmartCRM published its voicemail service with a broker.
Figure 1: Moving from SaaS to SOA
III. REAL-LIFE SCENARIO In this section, a fictional example is presented to demonstrate the proposed model. We will assume that there is a SaaS company called SmartCRM, which is a relatively small business that provides Customer Relationship Management (CRM) to their clients. Our proposed model was used to help SmartCRM convert their application, or part of their application, into SOA services. Accordingly, SmartCRM underwent the five steps of the proposed model during the transition process; the results of this process are discussed below.
IV. CONCLUSION In this paper, a new model was proposed to examine the way in which SaaS can be offered as SOA services. This model is mainly composed of five stages. First, a SaaS application that is required for migration into SOA will be located. Second, a thorough investigation will be performed on this SaaS application to study its maturity level. Subsequently, the features of the SaaS application will be identified. Then, these features will be converted to Web Services. In the last stage, the Web Services will be modified to conform to SOA principles, and finally, these services will be prepared for publication through SOA. A real-life scenario was also presented to demonstrate the proposed model; future work will focus on implementing and evaluating this model.
A. SaaS Allocation: In this step, an initial study was conducted to determine whether the whole system or only part of it would be converted to SOA services. SmartCRM proposes CRM solutions through four main sections, including Contact Manager, Sales, Marketing, and Communications. At this stage, SmartCRM recommended the Communications Section to be eligible for SOA services, because it believed that this section could be competitive in the market. B. Investigation: During the second stage, a thorough investigation was conducted to study the characteristics of the application, including the architecture, the design, the programming language as well as the network and hardware infrastructure. The investigation revealed that the application was designed using UML models and was implemented through C#. There were three main servers that were used to run the business and to store the database. SmartCRM was evaluated as having a medium maturity level. Since SmartCRM had a limited number of customers prior to offering SOA services, the database architecture was configured to assign a single instance and a separate database for each customer. This configuration was used because it was easy to manage separate databases for each customer.
REFERENCES [1] F. Hoch and M. Kerr. (2001) Software as a service: Strategic backgrounder. Software & Information Industry Association. Washington, DC. [2] E. Newcomer and G. Lomow, "Introduction to SOA with web services," in Understanding SOA with Web Services, , Ed. Upper Saddle River, NJ: Addison-Wesley, 2005, pp. 1-50. [3] (2009) Salesforce.com, Selecting the right sales edition.
188
