Offering SaaS as SOA Services

Transcription

1 Offering SaaS as 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 Abstract Software as a Service (SaaS) is an approach in which software applications are delivered on demand to users as services. Service Oriented Architecture (SOA) is a promising paradigm that allows companies that run their software on different platforms to interoperate among each other. The popularity of SaaS has been soaring since customers do not have to carry the burden of paying money upfront to purchase software licensing. The interest in using SOA to run different applications has been proliferating, especially since web services have started to implement SOA. Research is being conducted to observe how SOA can benefit SaaS. This paper presents an overview of SaaS, SOA and web services. Moreover, a new model is proposed to show how SaaS can be offered as SOA services. Furthermore, a real-life example is given to demonstrate the benefits of using the proposed model. Keywords: SaaS, SOA, Web Services, Migration from SaaS to SOA, Cloud Computing I. INTRODUCTION Web evolution has been visible right from its initiation in order to support several important services. These include social networking, entertainment and business applications. The term service has been widely used in the web to support people s demands in many activities. Amazon Web Services (AWS) and Google Apps offer a variety of services. Microsoft found that offering services to customers is inevitable and has introduced Microsoft Azure to compete with AWS and Google Apps. There has been a huge tendency and intrigue to turn conventional software into services by both vendors and customers. Software as a Service (SaaS) is a technology that offers software applications as services. SaaS is an online delivery of software to customers [1]. Rather than purchasing a software license (On-Premise software) for an application such as Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP) which might cost thousands of dollars, customers subscribe to applications from a SaaS provider and pay fees based on the usage of the application. In a SaaS environment, software becomes a collection of services. The service is deployed from a centralized datacentre and accessed through the Internet on a recurring fee basis [1, 2]. Demand for SaaS providers is increasing and the SaaS architecture should be improved to accommodate the substantial increase of new customers [3]. The advantages of SaaS are obvious as a SaaS provider is the one who manages the application and supporting infrastructure and not the customer. For the customer, the use of SaaS reduces costs of maintaining an infrastructure and the updating of Software. Many SaaS providers such as Salesforce.com (the top SaaS vendor in CRM), offer SaaS solutions in the form of editions. Each edition has a set of features. Reference [4] shows an example of Salesforce.com s editions and their features. The main drawback of most SaaS vendors such as Salesforce.com, is that customers cannot choose the features of the application that they are interested in. Instead, they have to subscribe to a specific edition and pay for that edition, even if only a few features of this edition are being used. Service Oriented Architecture (SOA) can be defined as a flexible set of design architectures that embodies a collection of services that communicate amongst each other [5]. SOA allows software functionalities to be available in a form of services to anyone who requests it, provided they are authorized to use these services. SOA is not new. People in the past used SOA for Object Request Brokers (ORBs) which were based on the CORBA mechanism. SaaS and SOA are completely different. The two terms can be confusing because they both contain the word service. SaaS can be summarized as the way that software is delivered and used, while SOA is concerned about how software is structured. SaaS applications might or might not rely on SOA. However, if the functionalities of SaaS applications can be converted into SOA services and deployed through SOA, the benefits of leveraging these services in business will be enormous. In this case, any enterprise can satisfy its own business needs by selecting the services they wish from different SaaS providers through SOA. The rest of the paper is structured as follows. Sections II and Section III present the principles and the architecture of SaaS and SOA respectively. Section IV introduces the relationship between SOA and web services. Section V illustrates the related work. Section VI demonstrates the proposed model to provide SaaS as SOA services. Section VII presents a real-life example to describe the model. Finally, Section VIII concludes the paper. II. SOA AND WEB SERVICES The terms SOA and web services could be confusing. SOA and web services are not the same. SOA is an

2 architecture, while web services can be seen as a technology. Web services can implement SOA but SOA can also be implemented by other technologies such as REST, CORBA, Distributed Computing Environment (DCE) and Java Enterprise Edition (Java EE) [6]. Although SOA can be implemented with service-based technologies other than web services, these technologies have been criticized for not being loosely coupled. Web services became highly acceptable as a standard for SOA implementation because they are pervasive, loosely coupled and are supported by most software vendors. In web services, messages are used for communication as opposed to using operations in older technologies. Web services can explicitly map the elements of SOA to form a reliable and unobtrusive solution of registering, discovering and executing services. Figure 3 depicts the mapping between web services and SOA technologies [7]. Figure 3, shows that the web service provider publishes its services with the web service broker using Web Services Description Language (WSDL). The web service requester searches for services registered with the service broker using Universal Description, Discovery, and Integration (UDDI). The role of the service broker is important as customers (service requesters) might search for multiple services and each might have a different service provider. Registering the services with a central broker provides the flexibility required for customers to send queries to find services. Finally, when a customer finds a service, the web service requester binds the web service provider through SOAP protocol. According to Sneed, there are four main sources for web services [8]. The first source of web services can be purchased from a web service supplier. Secondly, web services can be accessed from the open source community. The third source of web services can be developed from scratch and finally, the fourth source of web services can be extracted from existing applications. Sneed argued that if reliability, maintainability, cost, time and testability are taken into consideration, the fourth source which is extracting services from existing applications can be the smartest choice especially for companies who have been in the business for a long time, and thus they have a repository of software functionalities that can be converted to SOA services. III. RELATED WORK The related work in this area focuses on two main parts. The first part is how to offer On-Premise applications as SaaS. The second one is how to migrate legacy systems to SOA. The two approaches are different, since it is not necessary for SOA to be the infrastructure of SaaS. Fig. 3: Mapping between Web Services and SOA [7] A. Offering On-Premise Applications as SaaS There are several approaches to offer On-Premise applications as SaaS. These include: 1) Hosting the application with a third party server: If an application is written in a third generation language such as Java or C#, the application can be hosted with a third party provider [2, 9]. With little modification of the application (especially the interface), customers can access the software online. In this case, the application is offered to customers as a service. This is similar to the case of the Application Service Provider. This method has been criticized because the offered service is tightly coupled. For instance, customers do not have a lot of freedom to tailor the application to meet their needs. Furthermore, upgrading the application might be inconvenient to some customers. 2) On-Premise applications offered as Web services: In this case, the application can be transformed into a web service [9]. Web services can then be offered to customers through SaaS. Several technologies exist such as SOAP and REST to convert applications to web services. 3) On-Premise applications can be migrated to SaaS through Commercial tools: The application can be moved to a SaaS provider through commercial tools [10]. Some of these tools act as a mediator between the customer and the SaaS vendor. In this case, an enterprise might choose to migrate part of its business to SaaS and keep the other part on their servers. B. Migration From Legacy Systems to SOA Although SOA is not new, the demands for SOA have been rapidly increasing after the frills that have been added by web services to SOA environment. Many technologies exist to build SOA applications from scratch, but there is a substantial amount of legacy systems that have an enormous value to their business and consequently these legacy

3 systems cannot be ignored. This stimulated the search for techniques to migrate legacy systems to SOA. Zhang and Yang [11] defined three main categories to transform legacy system to services. The first category is called black-box approach. In this approach, legacy code is integrated into services through adapters. Adaptors are software layers which surround legacy code. The second category is called white-box approach. In this approach, a reengineering process is applied through investigating, analysing and modifying the legacy code to discover the business logic and then to obtain the code components that can be offered as web services. The third category is the - grey-box technique. This technique includes both the blackbox and the white-box techniques to integrate legacy systems to services. In this section, three approaches to migrate legacy systems to SOA are demonstrated. These approaches include: 1) Wrapping Legacy Software for Reuse in a SOA: This work was proposed by Sneed [8]. In this approach, legacy software is wrapped into an XML shell such that software functionalities can be proposed as web services. This can be achieved through three stages. These stages include salvaging the legacy code, wrapping the legacy code and linking the web services to the business processes. In the first stage, legacy code which is valuable to reuse is identified and business operations and functions are discovered. The second stage is to wrap the legacy code with a WSDL interface. This is achieved by transforming each entry into a method and each parameter into an XML data element. The legacy code is then packaged with SOAP framework. The final stage is to link the web services to the business processes and SOA. This is achieved through a proxy. 2) Architecture Transformation, From Legacy to Three- Tier and Services: This work was proposed by Heckel et al. to transform legacy systems to three-tier architecture to support SOA [12]. The methodology used in this approach is mainly composed of four steps. The first step is to annotate the legacy source code by code categories. This is to associate each code category with the elements of the target architecture (3-tier), e.g., as user interface, business logic or data. The second step is called Reverse Engineering. In this step, a source graph model is constructed from the annotated source code. This graph is also an instance of a metamodel graph. The third step is redesigning the source graph model to the target graph model to conform to the three-tier and SOA. The redesign state is done using graph transformation rules. The relation between the annotated code and the target model is also saved to support transforming target graph model into the target code. The last step in this methodology is called Forward Engineering. In this step, the target code is generated using the target graph model with the annotated source code. 3) A Wrapping Approach for Migrating Legacy System Interactive Functionalities to Service Oriented Architectures: This work was proposed by Canfora et al. [13]. The authors presented a black-box approach to integrate interactive functionalities of legacy software into services. Interactive systems are session-based systems where a user exchanges messages with a computer. This can be achieved through a browser or input forms when the user submits a query to the system. The system then processes the query and executes it by presenting an output to the user. The black-box approach is represented by a wrapper which encompasses the user interface and interacts autonomously during the execution of each query with the legacy system on behalf of the user. IV. TRANSITION FROM SAAS TO SOA In this section, a novel model is proposed as presented in Figure 4 to illustrate how SaaS applications can be offered as SOA services. This model is divided into six main stages. These stages include: A. Determination of SaaS Maturity Level (DSML): In this stage, the SaaS application is thoroughly investigated and analyzed to determine for example, the size, maturity level of the application, and programming language used to build the application. The goal of this stage is to determine the coupling level (loose or tight or in between) among the functionalities of the application. B. Nomination of Applications for SOA (NAS): This is the second step of the model. The goal of this step is to select a SaaS application, or mainly, the parts of an application that will be transformed to SOA services. In many cases, it is not required to transform the whole SaaS application to SOA. It is possible that parts of the application will be converted to SOA and the other parts will be kept as SaaS. For example, a SaaS vendor might choose to select a feature, which they believe is very competitive in the market, and offer it as SOA service. C. Feature Identification: Each SaaS software has a predefined set of features [14] [15] [16]. An example about the features of Salesforce.com CRM application is shown in reference [4]. For instance, Salesforce.com offers its CRM application as five editions: Contact Manager, Group, Professional, Enterprise, and Unlimited. Each edition has a collection of features. In this stage, we are concerned to define and list all the features of the SaaS application part which was nominated to be transitioned to SOA. D. Nomination of Features: In the previous stage, all features of an application part were listed. In this stage, some features will be selected to be candidates for SOA services. The selection of these features is based on the contribution which they may provide to business.

4 E. Services Extraction: In the previous stage (Nomination of Features), some features may not be candidates to become SOA services because they might be tightly coupled or depend on other features. In this stage, selected features will be offered as web services through SaaS. Not all web services are SOA services because some web services are not coarse grained and loosely coupled. This depends on the technology being used with web services, e.g. REST or SOAP. In this stage, services that are written with legacy code will be wrapped with XML shell. F. Services Enrichment: This is the final stage of the model and after this stage, services are ready to be engaged with SOA. In this stage, web services will be checked if they conform to SOA principles (reuse, loosely coupled, coarse grained, etc.). For instance, REST services are not loosely coupled as SOAP services. Here, some services might be redesigned to match SOA principles or standards. Another important point in this stage, is with regards to Salesforce.com; 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 divided into services that comply with SOA principles, the services are now ready to participate with SOA. As shown in Figure 4, the SaaS vendor can act as a service provider who publishes its services with a broker. The SaaS vendor can also be a service requester. In this case, the SaaS provider can acquire additional services from other providers and add them to its application. The main advantage of the proposed model is that any SaaS provider can offer services as opposed to offering features that are packaged within editions. Moreover, any customer can select the services that they are interested in from a service provider and also select different services from another provider to form a new business model or application. The new business application will be a collection of services supported by different providers that communicate with each other to provide business values to the company. Section VII provides a real-life example to demystify the premise of the proposed model. Fig. 4: Transition from SaaS to SOA

5 VII. REAL-LIFE EXAMPLE In this section, an example is presented to demonstrate the proposed model. The proposed model was evaluated using a SaaS company called TopCRM. TopCRM is a relatively small company that provides Customer Relationship Management (CRM) to their customers. Our proposed model was used to help TopCRM convert part of its application into SOA services. TopCRM underwent the five stages of the proposed model during the transition process. This included: A. Determination of SaaS Maturity Level (DSML): During this stage, an investigation was conducted thoroughly to study the characteristics of the application This included the requirements, architecture, design, programming language as well as the network and the hardware infrastructure. The results showed that the application was designed using UML models, implemented using C#. There were three main servers that were used to run the business and to store the database. The maturity level of the TopCRM was considered as medium. The database architecture used could be expressed as assigning a single instance and separate database for each tenant (customer). The reason behind using separate databases is that separate databases for each customer are easy to be managed. B. Nomination of Applications for SOA (NAS): In this stage, a preliminary study was performed to see whether or not the whole system or just a fraction of it would be converted to SOA services. TopCRM proposes CRM solutions through five main sections. These sections include Contact Manager, Sales, Marketing, Data Warehousing and Communications. At this stage, TopCRM recommended the Data Warehousing section to be offered as SOA services because TopCRM believed that this section could be competitive in the market. C. Feature Identification: During the Feature Identification stage, all features of the Data Warehousing section were identified. These include data_analysis, report_generator and data_storage. D. Nomination of Features: In this stage, the data_storage feature was selected to be a candidate to become an SOA service. This was because TopCRM believed that this feature can compete with similar features from other providers in the market. When this feature is offered as a service, users can seamlessly store their data securely at TopCRM s servers. E. Services Extraction: In this step, the data_storage feature was converted to a web service using SOAP, WSDL and UDDI. At this stage, the web service data_storage was not guaranteed to be a valid as an SOA service. F. Services Enrichment: In this stage, the data_storage service was tested using SOA principles. The service was found to be loosely coupled because of the characteristics of the SOAP protocol. However, there was an issue regarding the reusability of this service. SOA services must be reusable by multiple applications. To support 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 old database structure (single database per tenant) was not the best choice to support the new system because the old database would be very costly if it would be used for a larger number of customers. To resolve this problem, the old database was modified to become a shared database to support more users. After passing through the six steps of our proposed model, services could be extracted from SaaS applications and would be ready to be published with SOA brokers to be used by customers. Finally, TopCRM published its data_storage service with a broker and many customers are now enjoying the feature. VIII. CONCLUSION Software as a Service has been rapidly adopted because customers save the money needed to purchase software licensing and hardware infrastructure to run the software upfront. On the other hand, web services and Service Oriented Architecture (SOA) have been offering many benefits by allowing heterogeneous systems to communicate with each other. The benefits of offering software and hardware as services are enormous. Because legacy systems exist in almost any organization, several works have been conducted to transition legacy systems to SOA. On the flip side, SaaS applications exist and SaaS vendors are looking for techniques to merge SaaS with SOA. In this paper, a novel model was proposed to discuss how SaaS can be offered as SOA services. This model is mainly composed of six stages. First, the maturity level of the SaaS application will be determined. Second, applications or parts of these applications will be nominated for SOA services. Third, the features that belong to an application or to an application section will be listed. Fourth, features that are nominated to participate with SOA will be listed. Fifth, the nominated features will be converted to web services. In the last stage, web services will be modified to conform to SOA principles and finally these services become ready to be published through SOA. A real-life example was also presented to demonstrate the proposed model. References [1] F. Hoch and M. Kerr. Software as a service: Strategic backgrounder. Software & Information Industry Association. Washington, DC. 2001[Online]. Available: [2] F. Chong and G. Carraro, "Architecture strategies for catching the long tail," Microsoft Corporation, Tech. Rep. MSDN Library, 2006.

6 [3] M. Turner, D. Budgen and P. Brereton, "Turning software into a service," Computer, vol. 36, pp , October [4] Selecting the right sales edition. [Online]. 2010(March 18), 2009) Salesforce.com. Available: SalesCloud_EdCompare_ pdf. [5] 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 [6] S. Vinoski, "REST Eye for the SOA Guy," Internet Computing, IEEE, vol. 11, pp , [7] P. Amirian and A. Mansurian, " Potential of Using Web Services Technologies in Distributed GIS Applications," GIS Development, Middle East, [8] H. M. Sneed, "Wrapping legacy software for reuse in a SOA," AneCon GmbH, Wien, [9] W. Sun and K. Zhang, "Software as a service: An integration perspective," in Service-Oriented Architecture, D. Hutchison, Ed. Springer Berlin Heidelberg, 2007, pp [10] Cloud intelligent. [Online]. 2010(March 19), Available: [11] Z. Zhang and H. Yang, "Incubating services in legacy systems for architectural migration," in Software Engineering Conference, th Asia-Pacific, 2004, pp [12] R. Heckel, R. Correia, C. Matos, M. El-Ramly, G. Koutsoukos and L. Andrade, "Architectural transformations: From legacy to three-tier and services," in Software Evolution, T. Mens and S. Demeyer, Eds. Springer Berlin Heidelberg, 2008, pp [13] G. Canfora, A. R. Fasolino, G. Frattolillo and P. Tramontana, "A wrapping approach for migrating legacy system interactive functionalities to Service Oriented Architectures," J.Syst.Softw., vol. 81, pp , [14] A. B. Nassif and H. Lutfiyya, "Measuring the usage of SaaS applications based on utilized features," in The First International Conference on Cloud Computing and Services Science, 2011, pp [15] A. B. Nassif, Measuring SaaS Applications Based on Utilized Features. Köln, Germany: LAP Lambert Academic Publishing, [16] A. B. Nassif and M. A. M. Capretz, "Moving from SaaS applications towards SOA services," in Proceedings of the th World Congress on Services, 2010, pp