... comparison with the other works and through showing the performance tests of ...... component such as Apache ODE, BizTalk, Oracle BPEL Process Manager, ...
Cairo University
Cairo University Institute of Statistical Studies and Researches (ISSR) Department of Computer and Information Sciences
Improving Cloud Computing Reusability Using Service Oriented Architecture
Submitted by
Areeg Samir Ahmed El-Gazazz
Under the Supervision of
Prof. Dr. Abdelaziz Khamis
Dr. Ashraf Shahin
Computer and Information Sciences Institute of Statistical Studies and Research Cairo University
Computer and Information Sciences Institute of Statistical Studies and Research Cairo University
A Thesis Submitted to the Department of Computer and Information Sciences In Partial Fulfillment of the Requirements for the Degree of MASTER OF SCIENCE In Information Systems
2014
Abstract This thesis addresses the reusability of SaaS applications in Cloud Computing (CC) and proposes a Service Oriented Architecture (SOA) based approach to improve cloud computing reusability by providing an understandable customization model together with a technique to validate customizations made by tenants. It has been shown that the current SOA-Based approaches used to improve the reusability of SaaS applications in Cloud Computing don’t provide SaaS application developer with a simple and understandable reusable and customizable model. This leads SaaS application developer to: a strict model that can’t be customized easily to meet each tenant’s unique requirements, and can’t be stored in a database to be reused in the future. Another issue with SOA-Based approaches is a complex SaaS application that supports hundreds, even thousands of tenants could have hundreds of customization points with each of them providing multiple options. This could result in a huge number of ways to customize the SaaS application. This in turn needs a way to manage and check the correctness of each tenant customizations’. One more issue with SOA-Based approaches is the dynamic adaptability for each tenant customizations during runtime. Although customization can be deployed at runtime, there is no dedicated way to apply it. This reduces the services customization which in turn reduces the reusability of that customization across SaaS applications. It has been shown that in SOA-Based approaches, the focus during software analysis and design stages is on identifying reusable functionality that is candidate for modeling as services. This leads to save the required time and effort for re-creating functionalities of the services and applications from scratch. This thesis proposes an aspect-oriented approach to improve the SOA-Based SaaS applications reusability. This approach solve the previous mentioned problems through using: first, Orthogonal Variability Model (OVM) to provide the tenants with a simple I
and understandable reusable and customizable model. Using OVM the complexity of the variability model will be decreased. Only the variability and not the commonalities will be documented and separated in a separate model. This in turn will enhance customization reusability, understandability, and maintainability. Second, a Metagraphbased algorithm has been developed to validate tenants’ customizations to be reused in the future. Using the developed Metagraph-based algorithm the customization security will be increased by avoiding the security threats that may occur through tenant customization. Only the valid customizations will be stored in the database, this in turn will enhance and speed up the customization retrieval and the reusability of that customization. Third, an Aspect oriented workflow language called Aspect Oriented for Business Process Execution Language (AO4BPEL) is used to apply tenant customizations during runtime. This language associate and disassociate customization from/to customization set on the fly. Using AO4BPEL, the customization reusability, maintainability, upgradability and adaptability will be enhanced and increased. In addition, the proposed approach will be demonstrated through an example from the Travel Agency Domain. The thesis concludes with an evaluation of the proposed approach by providing a detailed comparison with the other works and through showing the performance tests of the proposed approach with and without applying aspect.
II
Acknowledgment I dedicate this thesis to my family. I am so grateful to my loving parents whose words of encouragement and push for tenacity ring in my ears. Without their love, and encouragement, I would not have finished this thesis. There are no proper words to convey my deep gratitude and respect to professor Abdelaziz Khamis who was willing to help me despite his many other academic and professional commitments. His expertise, understanding, and patience, added considerably to my academic experience. I appreciate his valuable assistance and support during my research. My thanks must also go to Dr. Ashraf Shahin. He provided me with valuable directions and technical details through my thesis work. I am so grateful to him for his cordial support that helps in finishing this work.
III
List of Publications Areeg S, Abdelaziz K, Ashraf S. "An Aspect-Oriented Approach for SaaS Application Customization". 48th Annual Conference on Statistics, Computer Sciences and Operations Research. Institute of Statistical Studies and Research (ISSR), Cairo University. December 2013.
IV
Table of Contents 1
Chapter 1 Introduction 1.1 Problem Definition
3
1.2 Research Objective
3
1.3 Thesis Organization
3
Chapter 2 Cloud Computing and Software as a Service
5
2.1 Introduction
5
2.2 Cloud Computing Service Delivery Models
6
2.3 Architecture Model of SaaS
9
2.4 Quality Model of SaaS
12
2.5 Summary
17
Chapter 3 Service Oriented Architecture
18
3.1 Introduction
18
3.2 Service Oriented Architecture Core Elements
19
3.3 SOA Interaction Model Entities
22
3.4 Service Oriented Development and Design
25
3.5 Service Oriented Architecture Layers
29
3.6 Business Process Execution Language
31
3.7 Summary
34
Chapter 4 Aspect Oriented Paradigm
35
4.1 Introduction
35
4.2 Aspect Oriented for Business Process Execution Language
36
4.3 AO4BPEL Joint Point Model
37
4.3.1
38
AO4BPEL Scopes
V
4.3.2
AO4BPEL Architecture
38 41
4.4 Summary
42
Chapter 5 Variability Modeling 5.1 Introduction
42
5.2 Hierarchical Workflow Template Design
43
5.3 Orthogonal Variability Modeling
43
5.4 Metagraphs Modeling Tools
47
5.4.1
The Metagraph Modeling
47
5.4.2
Metagraph Incidence and Adjacency Matrices
49
5.4.3
Attributed Representation in Metagraph
50 53
5.5 Summary
54
Chapter 6 Related Work 6.1 Introduction
54
6.2 Source-Code based approach
54
6.3 Composition based approach
56
6.3.1
Mietzner Approach
56
6.3.2
Tsai Approach
57
6.3.3
Moens Approach
58
6.3.4
Sun Approach
58
6.3.5
Lizhen Approach
59
6.3.6
Tsai and Sun Approach
59
6.3.7
Jegadeesan Balasubramaiam Approach
60
6.3.8
Park Approach
60
6.3.9
Qian Approach
61 62
6.4 Summary
VI
Chapter 7 Aspect Oriented Approach for Reusable Service Oriented SaaS
63
Applications 7.1 Introduction
63
7.2 Modeling Customization in Business Process Layer
63
7.2.1
Hierarchical Workflow Template Design
64
7.2.2
Mapping OVM to Metagraph
69
7.2.3
Metagraph Adjacency Matrix
75
7.2.4
Metagraph Incidence Matrix
80
7.3 Modeling Customization in Business Service Layer
81
7.4 Customization Validation Algorithm
82
7.5 Runtime Customization using AO4BPEL
84
7.5.1
Mapping Customization Points and Customization Variants to 85 Processes and Aspects
7.5.2
Waving the Mapped Customizations
88
7.6 The Framework of the Proposed Customization SaaS Approach
92
7.7 Summary
94
95
Chapter 8 Evaluation 8.1 Introduction
95
8.2 Evaluation with the Other Approaches
95
8.3 Evaluate the Performance of the Proposed Approach
100
8.3.1 Test Case 1: Without Aspect
101
8.3.2 Test Case 2: With Aspect
103 109
8.4 Summary
Chapter 9 Conclusion and Future Work
110
9.1 Thesis Contribution
111
9.2 Future Work
112
VII
Glossary
114
References
116
VIII
List of Figures Figure 2.1:
Cloud Computing service delivery models
7
Figure 2.2:
SaaS application architecture
10
Figure 2.3:
Key Features of SaaS
12
Figure 2.4:
Mapping from Features to Quality Attribute
15
Figure 3.1:
SOA Core Elements
20
Figure 3.2:
Core Elements of a Service
21
Figure 3.3:
SOA interaction model entities
22
Figure 3.4:
Service Based Development
27
Figure 3.5:
The Layers of Service Oriented Architecture
31
Figure 4.1:
An Aspect Example: Execution time measurement
36
Figure 4.2:
AO4BPEL 2.0 architecture
40
Figure 5.1:
Graphical notation for OVM
44
Figure 5.2:
OVM Example: Travel agency industry
45
Figure 5.3:
Development artefact and artefact dependency in the variability Meta 46 model
Figure 5.4:
A Travel agency business process Metagraph
48
Figure 5.5:
The adjacency matrix for the Metagraph
49
Figure 5.6:
The incidence matrix for the Metagraph
50
Figure 5.7.a:
Edge representation of the qualitative attribute
51
IX
Figure 5.7.b:
Vertex representation of the qualitative attribute
51
Figure 5.8:
The adjacency matrix for the Metagraph
52
Figure 7.1:
A customizable workflow
65
Figure 7.2.a:
Sub-workflows for Reservation
65
Figure 7.2.b:
Sub-workflows for View
66
Figure 7.2.c:
Sub-workflows for Payment
66
Figure 7.2.d:
Sub-workflows for Reservation Option
66
Figure 7.2.e:
Sub-workflows for Confirm Reservation
67
Figure 7.3:
OVM of customizable travel agency workflow
68
Figure 7.4:
Metagraph representation of the OVM
70
Figure 7.5.a:
Vertex representation of qualitative attributes for mandatory part
71
Figure 7.5.b:
Vertex representation of qualitative attributes for optional part
72
Figure 7.5.c.i:
Vertex representation of qualitative attributes for requires part
72
Figure 7.5.c.ii:
Vertex representation of qualitative attributes for requires part
73
Figure 7.5.c.iii
Vertex representation of qualitative attributes for requires part
73
Figure 7.5.d:
Vertex representation of qualitative attributes for excludes part
74
Figure 7.6:
OVM of customizable service customization
81
Figure 7.7:
Customization validation algorithm
83
Figure 7.8:
Payment process
87
Figure 7.9.a:
E-Check Payment Aspect
87
Figure 7.9.b:
Credit Card Payment Aspect
88
X
Figure 7.10.a:
Payment process WSDL file
89
Figure 7.10.b:
Payment process file descriptor
89
Figure 7.11.a:
Credit Card Payment Aspect WSDL file
90
Figure 7.11.b:
Credit Card Payment Aspect file descriptor
90
Figure 7.12.a:
Customer service WSDL file
91
Figure 7.12.b:
Customer service file descriptor
91
Figure 7.13:
The Framework of the Proposed Approach
93
Figure 8.1:
The Payment process without aspect separation
102
Figure 8.2:
Response times for the different numbers of concurrent requests without 103 aspect
Figure 8.3:
The Payment process with the aspect separation
104
Figure 8.4:
Credit Card Payment aspect
105
Figure 8.5:
Credit Card Payment aspect input parameters
106
Figure 8.6:
Response times for the different numbers of concurrent requests with 107 aspect
XI
List of Tables Table 3.1:
The characteristics and features of software architectural models
26
Table 6.1:
Comparison between various works based on Comparison
57
based Approach Table 7.1:
The cardinality matrix
74
Table 7.2:
The elements and edges of the Metagraph
75
Table 7.3:
The invertex and outvertex in the Metagraph
75
Table 7.4.a: The adjacency matrix of the Metagraph in Figure (7.5)
76
Table 7.4.b: The adjacency matrix of the Metagraph in Figure (7.5)
77
Table 7.4.c: The adjacency matrix of the Metagraph in Figure (7.5)
78
Table 7.4.d: The adjacency matrix of the Metagraph in Figure (7.5)
79
Table 7.5:
The incidence matrix of the Metagraph in Figure (7.5)
80
Table 8.1:
The previous approaches and the proposed approach comparison
97
Table 8.2:
Load test parameters
101
XII
List of Abbreviations
AO4BPEL
Aspect Oriented for Business Process Execution Language
AO4ODE
Aspect Oriented for Orchestration Director Engine
AWS
Amazon Web Services
BPEL
Business Process Execution Language
CC
Cloud Computing
CRM
Customer Relationship Management
ERP
Enterprise Resource Planning
GAE
Google Application Engine
HaaS
Hardware as a Service
HTTP
Hyper Text Transfer Protocol
HWTD
Hierarchal Workflow Template Design
IaaS
Infrastructure as a Service
IDL
Interface Definition Language
ODE
Orchestration Director Engine
OVM
Orthogonal Variability Model
PaaS
Platform as a Service
XIII
QoS
Quality of Service
ROI
Return Of Investment
SaaS
Software as a Service
SLAs
Service Level Agreements
SO
Service Orientation
SOA
Service Oriented Architecture
SOAP
Simple Object Access Protocol
UDDI
Universal Description, Discovery, and Integration
UI
User Interface
V
Variant
VP
Variation Point
WSDL
Web Service Description Language
WSRP
Web Services for Remote Portlets
WWW
World Wide Web
XML
eXtensible Markup Language
XPath
XML Path Language
XSD
XML Schema Definition
XIV
CHAPTER 1 INTRODUCTION Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly delivered with a minimal management effort or service provider interaction [Mell P. & Grance T., 2011]. Software as a Service (SaaS) is a software delivery model in which software resources are accessed remotely by clients [Lee W. & Choi M., 2012]. The SaaS delivery model is focused on bringing down time and cost by offering the same instance of an application to many customers, i.e. supporting multi-tenants. Multi-tenancy is one of the most important concepts for any SaaS application. SaaS applications have to be customizable to fulfill the varying functional and quality requirements of individual tenants [Mietzner R., 2009]. The elements of an application that need to be customized include: Graphical User Interface (GUI), workflow (business process logic), service selection and configuration, and data [Tsai W., 2010]. Several researches have attempted to support customization of these elements [Lee W. & Choi M., 2012], [Aghera P., 2012], [Pathirage M., 2011], [Lee J., 2012], and [Moens H., 2012]. In SaaS applications, there can be places where customization occurs, called customization points. Each customization point is associated with a set of values which can fill in, called variants. Therefore, SaaS application with high customizability will yield higher reusability [La H. & Kim S., 2009]. Reusability is one of the mostly emphasized principles and benefits of service oriented architecture (SOA). SOA is a group of principles for developing new applications from the integration and interconnection of services and software components that are building up the fundamental of business applications [Ershad E., 2013]. SOA provides the possibility to reuse functionality of existing services and applications rather than creating them from scratch. Reusing application components and services prevents enterprises from reworking to produce new services, and provides the possibility to reuse services which are already 1
being used and interconnects them to the new information systems. For service to be of reuse in many SaaS applications, attempt is made to keep service free from the information about state or context in which the service can be called upon. In SOA-based approach [Jyoti N. & Archana G., 2009], the focus during software analysis and design stages is on identifying reusable functionality that is candidate for modeling as services, defining service interfaces, designing components that would deliver service functionality, and designing software architecture in terms of layers of identified services and composite services formed by their aggregations. In other words, maximization of services reuse improves flexibility of business and return of investment. However, if a complex SaaS application that serves multitenant tenants have a huge number of customizations with their complicated relationships, the customization complexity will be increased which in turn decreases the reusability of that customization. One of the most prominent approaches for achieving the tenant-specific customization is providing an application template with unspecified parts that can be customized by selecting components from a provided set of components [Moens H., 2012] and [Sun W., 2008]. These unspecified parts are called customization points of an application [Lizhen C., 2010]. In order to enhance the reusability of SOA-Based SaaS applications in Cloud Computing, SaaS application customization research literature points out that there are four key concerns that need to be addressed: first, how to model the customization points and variations, second, how to describe the relationships among variations, third, how to validate customizations performed by tenants, and fourth, how to associate and disassociate variations to/from customization points during runtime [Pohl K., 2005]. Consequently, achieving these key concerns will achieve developer satisfactions, reduce customization complexity, and improve customization reusability across SaaS applications.
2
1.1
Problem Definition The current SOA-Based approaches used to improve the reusability of SaaS
applications in Cloud Computing don’t completely achieve developers’ satisfactions. In addition complex SaaS application that serves significant number of tenants could have a huge number of customizations with complicated relationships, which increases the customization complexity and reduces the customization reusability and understandability. Therefore modeling and reusing that customizations, validating each tenant’s customization, and adapting SaaS applications on the fly based on each tenant’s requirements become urgently required tasks.
1.2 Research Objective The main objective of this research is to improve the SOA-Based SaaS applications reusability. This objective will be achieved through the following tasks: Providing tenants with an understandable customization model. Providing a technique to validate customizations made by tenants. Providing a technique to apply each tenant’s customization during runtime.
1.3 Thesis Organization The thesis is divided into nine chapters as the following: Chapter 1: presents the problem definition and the research objective.
Chapter 2: presents an overview on the Cloud Computing and Software as a Service.
Chapter 3: presents and discuss the Service Oriented Architecture.
Chapter 4: provides an introduction to the Aspect Oriented Paradigm. 3
Chapter 5: explores the Variability Modeling and The Metagraph modeling tools.
Chapter 6: presents various related work which done in the area of the master thesis research topic. It also provides a comparison between the previously proposed works.
Chapter 7: provides a modeling stages of the proposed Aspect Oriented Approach for Reusable Service Oriented SaaS Applications. The proposed approach will be presented through a complete case study of a travel agency domain. It also presents the framework of the proposed approach.
Chapter 8: presents an evaluation for the proposed approach by comparing it with the other approaches, illustrates the usefulness and the drawbacks of the proposed approach, and discusses the results of the tests that compare the performance of the proposed approach with and without applying aspect.
Chapter 9: provides the conclusion and the future work for this thesis.
4
CHAPTER 2 Cloud Computing and Software as a Service
2.1
Introduction
Clouds are large pools of easily usable and accessible virtualized resources. These resources can be dynamically reconfigured to adjust to a variable load (scale), allowing optimum resource utilization. It’s a pay-per-use model in which the Infrastructure Provider by means of customized Service Level Agreements (SLAs) offers guarantees typically exploiting a pool of resources. Organizations and individuals can benefit from mass computing and storage centers, provided by large companies with stable and strong cloud architectures. Cloud computing incorporates virtualization, on-demand deployment, Internet delivery of services, and open source software. From one perspective, cloud computing is nothing new because it uses approaches, concepts, and best practices that have already been established. From another perspective, everything is new because cloud computing changes how we invent, develop, deploy, scale, update, maintain, and pay for applications and the infrastructure on which they run. Cloud computing is a technology that uses the internet and central remote servers to maintain data and applications. Cloud computing allows consumers and businesses to use applications without installation and access their personal files at any computer with internet access. This technology allows for much more efficient computing by centralizing storage, memory, processing and bandwidth [Pankaj A., 2014]. Cloud computing provides several features [Qi Z., 2014], which are: A) Multi-tenancy: In a cloud environment, services owned by multiple providers are co-located in a single data center. The performance and management issues of these services are shared among service providers and the infrastructure provider. The layered architecture of cloud 5
computing provides a natural division of responsibilities: the owner of each layer only needs to focus on the specific objectives associated with this layer. However, multi-tenancy also introduces difficulties in understanding and managing the interactions among various stakeholders. B) Service oriented: cloud computing adopts a service-driven operating model. Hence it places a strong emphasis on service management. In a cloud, service providers offer their services according to the Service Level Agreement (SLA) negotiated with their customers. SLA assurance is therefore a critical objective of every provider. C) Dynamic resource provisioning: One of the key features of cloud computing is that computing resources can be obtained and released on the fly. Dynamic resource provisioning allows service providers to acquire resources based on the current demand, which can considerably lower the operating cost. D) Self-organizing: Since resources can be allocated or de-allocated on-demand, service providers are empowered to manage their resource consumption according to their own needs. Furthermore, the automated resource management feature yields high agility that enables service providers to respond quickly to rapid changes in service demand. In cloud computing, service providers develop and deploy services with common and reusable features among various applications, service consumers locate and reuse them in building their applications. Hence, reusability is a key intrinsic characteristic of cloud services. Services with high reusability would yield high return-on-investment. The following sections will handle: the different service delivery models of the cloud computing, Software as a Service (SaaS) delivery model, and SaaS key features. In this thesis the proposed approach has been built based on SaaS delivery model therefore SaaS will be the anchor point in this thesis.
2.2
Cloud Computing Service Delivery Models
As promoted by the vision of “everything as a service” many products are now offered as services under the umbrella of cloud computing [Motahari-Nezhad H., 2009]. Cloud 6
Computing is broadly classified into three service delivery models as depicted in Figure (2.1) [Qi Z., 2014]: "Software as a Service (SaaS)", "Platform as a Service (PaaS)", and "Infrastructure as a Service (IaaS)". Each service serves a different purpose and offers different products for businesses and individual people around the world. In other words, Cloud services are delivered by the specific service providers and are consumed by consumers in real time over the World Wide Web (WWW) [Anirban K., 2010].
Figure (2.1). Cloud computing service delivery models [Qi Z., 2014] The first type of service in Cloud Computing is Infrastructure as a Service (IaaS). This service consists of two layers [Qi Z., 2014]: Hardware Layer and Infrastructure Layer. A) Hardware Layer which is responsible for managing the physical resources of the cloud, including physical servers, routers, switches, power and cooling systems. In practice, the hardware layer is typically implemented in data centers. A data center usually contains thousands of servers that are organized in racks and interconnected through switches, routers or other fabrics. Typical issues at hardware layer include hardware configuration, fault tolerance, traffic management, power and cooling resource management. B) 7
Infrastructure Layer, also known as the virtualization layer, which offers virtualized resources (computing, storage, and communication) on demand as a service. A cloud infrastructure enables on demand provisioning of servers running several choices of operating systems and a customized software stack. IaaS model is considered to be the bottom model of the cloud computing systems. Amazon Web Services (AWS) is one of the pioneers of such an offering. It offers virtual machines with a software stack that can be customized similar to how an ordinary physical server would be customized [Rajkumar B., 2011]. The second type of service in Cloud Computing is Platform as a Service (PaaS). It built on top of the infrastructure layer and it consists of operating systems and application frameworks [Qi Z., 2014]. It offers an environment on which developers create and deploy applications and do not necessarily need to know how many processors or how much memory that applications will be using (e.g., data access, authentication, and payments) are offered as building blocks to new applications. Google App Engine (GAE) is an example of PaaS, offers a scalable environment for developing and hosting web applications, which should be written in specific programming languages such as Python of Java [Rajkumar B., 2011]. The third type of service in Cloud Computing is SaaS which resides at the highest level of the hierarchy. It provides an application on the basis of users’ requirement resides on the top of cloud stack. It is a type of model for software deployment in which an application is hosted as a service provided to the user across the network. There is no need to install and run the application on the user’s own computer. User does not have to purchase resources; just has to pay for what he/she uses during a particular session. SaaS reduces the user’s burden of software maintenance and support [Anirban K., 2010]. Services provided by this model can be accessed by end users through web portals. An example of SaaS is Salesforce.com, which relies on the SaaS model, offers business productivity applications such as Customer Relationship Management (CRM). These applications are reside completely on their server [Rajkumar B., 2011].
8
2.3
Architectural Model of SaaS SaaS is a technology that first came of age during the 1990s. However, it was nearly
lost in obscurity like many other new technologies that were emerging at that time, due to the dot com bubble bursting. Fortunately, SaaS was able to recover and it is now a software methodology that is widely used across the Internet [Ivanka M. & Gerard B., 2010]. The great thing about SaaS for software vendors is that multiple users can access the same instance of a software service from anywhere in the world as long as they have an Internet connection. Each user will see his/her own instance of a software service and his/her own data, without interfering with any other user’s data. This means that software vendors can save a lot of money and resources by running just a single instance of a software service, which can then be accessed by many users. Using SaaS, there are many different ways that a client can pay for software. For example they could pay a monthly fee, they could be charged based on the features that they use or on how much they used a particular software service, i.e. using a pay-as- yougo model. The good thing about this flexibility in pricing models is that the needs of many different users can be accommodated for. For example, larger companies could pay bigger upfront fees to save their money in the long run, while individual users could use a pay-asyou-go payment model to save their money in the short term and avoid paying large upfront fees. SaaS completely eliminates the amount of money and time which are spent by businesses on the deployment, management and updating of their software applications on the customer’s side. It is now the software vendor who deals with these issues when a SaaS solution is used. This is much better for both parties because software vendors are better equipped to deal with the management issues for their software applications while customers have one less strain on them. Using SaaS, users do not need to change their existing operating environment or infrastructure in any way. All incompatibility issues are dealt with on the software vendor’s 9
side of things and they are the ones who will ensure that the software services they are providing run stably within their data centers. Software vendors can immediately offer their updated software solutions to clients online in a cost-effective and efficient way. This means that clients can benefit from software innovations on an ongoing basis, because as soon as software vendors make changes or offer new and improved features, their customers can begin using them right away. SaaS customers can customize provider software application services by using point and click customizability options that their providers provided with, so that these software application services can meet customer specific needs. Architecturally, SaaS applications are largely similar to other applications built using service-oriented design principles. Most of the components depicted in Figure (2.2) should be familiar to most SaaS application architects. These components as shown in Figure (2.2) are [Chong F. & Carraro G., 2006]:
Figure (2.2). SaaS application architecture [Chong F. & Carraro G., 2006] 01
The first component is, the Metadata service(s) which provides customers with the primary means of customizing and configuring the application to meet the customer needs. Customers can make changes in four areas: The user interface by modifying the user interface such as graphics, colors and fonts. The business process by configuring the way in which the application's workflow aligns with the customers’ business processes. The extensible data model which gives customers the freedom to make an application work their way, instead of forcing them to work its way. The access control which is responsible for creating individual accounts for end users, and for determining which resources and functions each user should be allowed to access. The second component is, Security service(s) which is responsible for controlling access to end-user and back-end software services. It manages data security and access control of each tenant organization. The third component is, Directory Service(s) which is a software system that stores, organizes and provides access to information in a directory. Consumers query the directory service to find service providers. The fourth component is, Smart Client which describing an application environment that delivers applications over a web connection. It does not require installation automatically updates without user action and it has the look and feel of desktop applications. The fifth component is, Process Service(s) that provides customer with a rich user interfaces in which smart client or (and) web application can invoke. It produces a workflow that invokes business services. Business services, which interact with the stored data in order to read and write business data. Finally, File system and Database(s) which provide a way of organizing computer files and their data into a database for the storage, organization, manipulation, and retrieval. All customers are sharing single DB and are able to extend the data model. Process, Business services and smart clients interact with the metadata services in order to retrieve information that describes configurations and extensions that are specific to each tenant. 00
Process services exposes interfaces that smart clients or the Web presentation tier can invoke.
2.4
Quality Model of SaaS In order to define a quality model for evaluating SaaS, it is a prerequisite to identify
SaaS key features [Lee J., 2009]. These features as shown in Figure (2.3) are:
Figure (2.3). Key Features of SaaS [Lee J., 2009]
The first feature is the Reusability: In software engineering, reusability is the ability of software elements to serve for the construction of many different applications. The fundamental underlying of Cloud Computing is to reuse various types of internet based services. In case of SaaS, software itself is a target of reuse and it is delivered to service consumers over the Internet. That is, one-to-many relationships are often used when delivering SaaS services. For example, Google map service provides a set of operations to utilize shared information on map and local, which can be used by various customers. There are many issues involved in software reuse: whether to reuse parts, how to store and retrieve reusable parts in a library, how to certify parts, how to maximize the economic value of reuse, how to provide incentives to engineers and entire companies to reuse parts rather than reinvent them. That reusable software has certain characteristics that need to be considered to facilitate the reuse of the software parts: as mentioned in [Goos G., 1995], these characteristics are: A) Reusable parts must be understandable. A reusable part should 01
be a model of clarity. The requirements for commenting reusable parts are even more stringent than those for parts specific to a particular application. B) Reusable parts must be of the highest possible quality. They must be correct, reliable, and robust. An error or weakness in a reusable part may have far-reaching consequences, and it is important that other programmers can have a high degree of confidence in any parts offered for reuse. C) Reusable parts must be adaptable. To maximize its reuse potential, a reusable part must be able to adapt to the needs of a wide variety of users. D) Reusable parts should be independent. It should be possible to reuse a single part without also adopting many other parts that are apparently unrelated. The second feature is the Data Managed by Provider: SaaS is a model of software deployment whereby service providers license applications to customers for use as a service on demand. Thus service providers are responsible for service installation and data management on their own server. Therefore, most data which service consumers produce is stored on provider’s data center and managed by provider. Thus service customers do not perceive two things in detail; where is their data stored and how can be the data managed. So that, the service customers may distrust the services and then service utilization becomes lower, if service providers do not provide data security and reliability function. The third feature is the Service Customizability, Service customizability means the ability for services to be changed by service consumers based on the individual requirements. This characteristic allows service providers to meet the different needs of each customer. According to the characteristics of cloud services, various consumers, who can access the Internet, can become potential users of the cloud services. Because of that, it is impossible that service providers customize their cloud services for all service consumers. Thus service consumers need to customize their services for their own purposes. If the service providers do not provide customizable SaaS services, the only thing service consumers can do is to simply utilize the services. This will limit the usage of SaaS services.
01
The fourth feature is the Availability, in CC, the service consumers are able to access SaaS service from a Web browser via the Internet. Also, the consumers do not have any ownership for the SaaS which is deployed and runs on the provider’s server. Because of these natures, many SaaS vendors focus their attentions to achieve high availability of services. If a SaaS is not available, service consumers cannot use the functionality of the SaaS. For example, Gmail service was down completely at September 1st, 2009. Because of that, many Gmail users could not use the service which the users read or write email. The fifth one is Scalability, in software engineering, scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work or to be readily enlarged. Due to the black-box nature of CC services, service consumers cannot control resources which are utilized by the services, such as memory, network, or CPU utilization. That is, a service provider is a responsible for rescaling the resources according to consumer’s requests without notifying the consumers in detail. The final feature is the Pay per Use, The expenses for SaaS are estimated not about purchasing an ownership of services, but about using services such as the number of service invocations or duration which services are utilized. That is, service consumers can connect and use the service each time they want, and then pay for just amount of usage such as a utility like electricity or water. Therefore, the customer takes an activity for using the service. Derived from the SaaS key features, and based on ISO/IEC 9126, there are quality attributes that can be produced from the SaaS key features [Lee J., 2009]. Figure (2.4) shows a mapping relationship between the key features of SaaS and the quality attributes. For each attribute, its definition and the rationale for defining it as shown in Figure (2.4):
01
Figure (2.4). Mapping from Features to Quality Attribute [Lee J., 2009] Reusability: This attribute measures if functionalities provided by services are common to the requirements defined by service consumers. The rationale for defining this attribute is explained by both service provider’s view and service consumer’s view. Typically, SaaS providers have the business model, pay per use. If SaaS provides functionalities which meet requirements, then the number of service consumers and return on investment (ROI) is consequently increased. Hence, the reusability is treated as an indicator which can reveal ROI of service providers. Service consumers want to use better services. When service consumers evaluate the services, they typically consider two factors; the number of subscribers and the number of provided features required by service consumers. These factors indirectly show that quantitative values, which reveal supporting commonality, are important to service consumers. Availability: This attribute measures the ratio of the total time to the time which a SaaS service is capable of being operable. Typically availability objectives are specified either in decimal fractions or percentage. The rationale for defining this attribute is that SaaS to be available is a prerequisite for the successful execution of the SaaS. Especially, a SaaS is deployed and runs on the service provider’s server. Service consumers can discover, subscribe, and utilize the SaaS which they want through internet-based invocation. Also, 05
the service consumers cannot have the control of the services which are on the service provider side. Unless high availability of services is not ensured, service consumers cannot use the services on demand. Scalability: This attribute measures the ability to either handle growing amounts of resources, used for SaaS, or to be readily enlarged. The rationale for defining this attribute is that a cloud computing is a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet. SaaS should support functionality that the amounts of resources used for the SaaS are grown whenever service consumers request, since SaaS is a kind of application which provides a set of functionalities as a whole. Also, service providers cannot predict how much the amount of resources will be utilized. For example, Google doc’s service provides functionality of word processor. When service consumers finish writing the first page, the service creates the second page as a blank automatically and allocates more resources for the page. Therefore, service providers can get more benefit in terms of ROI, if they provide their application which can scale resources flexibly. Reliability: This attribute measures the ability of a SaaS to keep operating with specified level of performance over time. Several aspects of reliability are important within a cloud computing, particularly the reliability of the messages that are exchanged between the service consumers and the services, and the reliability of the services themselves. Efficiency: This attribute measures the amount of resource used for SaaS when providing the required functionality and the level of performance, under stayed condition. That is, it is a measure of how well SaaS utilizes resources. The motivation for defining this attribute is that the expense for SaaS is estimated not about purchasing an ownership of the service, but about the amount of usage of the service. That is, a typical business model of cloud computing depends the amount of utilized resource or time-use.
06
2.5
Summary Cloud Computing is a pay-per-use model in which the service providers offers a pool
of resources by means of customized SLA. It provides several features that support Multitenancy, Dynamic resource provisioning, Self-organizing, and Service oriented. Cloud Computing is classified into three service delivery models which are SaaS, PaaS, and IaaS. SaaS is the anchor point in this thesis. SaaS provides an application as a service to users across the network. SaaS provides an architectural model that supports multiple components such as Metadata, Security services, Directory services, Process services, Smart client, File systems, and Databases. It defines some kay features in order to define a quality model that is used to evaluate SaaS applications.
07
CHAPTER 3 Service Oriented Architecture
3.1
Introduction Service Oriented (SO) is the natural evolution of current development models. Early
the concept of structured design has been introduced. After that the, 80s saw objectoriented models. Next, the component-based development model appeared in the 90s. Finally, Service Oriented Architecture (SOA) came along with web services, to provide a solution to all of the above models [Sean S., 2006] as mentioned in details in the next subsections. SOA provides an evolutionary approach for building distributed software that facilitates loosely coupled integration and resilience to change. It is independent of technology and its architectural patterns can be used to connect with legacy systems as well [David L., 2014]. SOA is an approach that models and packages software as a set of services that can be discovered by software consumers at run time. For service to be of reuse in many diverse situations, attempt is made to keep service free from the information about state or context in which the service can be called upon [Jyoti N. & Archana G., 2009]. In SOA based approach, the focus during software analysis and design stages is on identifying reusable functionality that is candidate for modeling as services, defining service interfaces, designing components that would deliver service functionality, and designing software architecture in terms of layers of identified services and composite services formed by their aggregations. Some of the services are designed for integration of heterogeneous applications and data stores [Jyoti N. & Archana G., 2009].
81
The following sections will discuss: the Service Oriented Architecture Core Elements, Service Oriented Architecture Interaction Model Entities, Service Oriented Development and Design, Service Oriented Architecture Layers, and Business Process Execution Language.
3.2
Service Oriented Architecture Core Elements SOA is a software architecture that is based on the key concepts of an application
frontend, services, a service repository, and a service bus. A service consists of a contract, one or more interfaces, and an implementation. Figure (3.1) below shows the elements that form the core of an SOA [Hssp-infrastructure.wikispaces., 2006]. Application frontends are the active elements of a SOA. Although they are not services themselves, they initiate all business processes and ultimately receive their results. Typical application frontends are Graphical User Interfaces (GUIs) or batch processes. A service bus connects all participants of a SOA – services and application frontends with each other. A service repository captures all essential information about the service so that the enterprise can be aware of its existence and capabilities. The service repository contains the service contract and additional information such as physical location, information about the provider, contact person, technical constraints, security issues, and available service levels.
81
Figure (3.1) SOA Core Elements [Hssp-infrastructure.wikispaces., 2006]
Service, the fundamental building block of SOA is a service. A service is a reusable functionality such as travel reservation or security authentication that has large potential consumers and can be interacted with through well-defined message exchanges [Jyoti N. & Archana G., 2009]. In SOA, services are business software components created to function just by themselves, regardless of specific underlying technology. This allows the programmers to reuse the code and maintain the functionality of components within an application and share them with other applications [Sean S., 2006]. As shown in Figure (3.2), a service
02
consists of a contract, one or more interfaces, and an implementation [Hsspinfrastructure.wikispaces., 2006].
Figure (3.2). Core Elements of a Service [Hssp-infrastructure.wikispaces., 2006]
Service Contract, the service contract provides an informal specification of the purpose, functionality, constraints and usage of the service. It is important to understand that the service contract provides more information than a formal specification such as IDL (Interface Definition Language) or WSDL (Web Services Definition Language). The contract can impose detailed semantics on the functionality and parameters that is not subject to IDL or WSDL specifications. Interface, the functionality of the service is exposed by the service interface to the service clients that are connected to the service using a service bus. Although the description of the interface is part of the service contact, the physical implementation of the interface consists of service stubs, which are incorporated into the clients of a service and a dispatcher. Implementation, the service implementation physically provides the required business logic and appropriate data. It is the technical realization that fulfills the service contract. 08
The service implementation consists of one or more artifacts such as programs, configuration data, and databases. Business Logic, the business logic is encapsulated by a service as part of its implementation. It is made available through service interfaces. Data, a service can also include data as part of its implementation. In particular, that is the purpose of a data-centric service.
3.3
SOA Interaction Model Entities Service Oriented Architecture is an architectural style that defines an interaction model
between three main functional entities, in which the consumer of the service interacts with the service provider to find out a service that matches its requirements through searching registry. Figure (3.3) shows these entities [James M., 2003]:
Directory Service UDDI
Query for service Find
Service Contract
Service Consumer
Bind and Invoke HTTP
Get service provider Publish
Service Provider Web services
Figure (3.3). SOA interaction model entities [James M., 2003]
Services consumer, it can be an application, another service, or some other type of software module that needs the service and interacts with the service by exchanging messages with it. It is the entity that initiates the locating of the service in the registry, binding to the service over a transport, and executing the service function. The service consumer executes the service by sending a formatted request according to the contract of the service, after the consumer retrieves the service description, which specify the way, the 00
request and the response format in which a service consumer will interact with the service provider. Service provider, it can be a component, network addressable entity, or other type of software system that fulfills the service consumer’s requirements by accepting and executing requests from consumers. It provides the definite service description and the implementation of the service where service provider publishes its services and interface contract to the registry. Service Registry, it is a directory like catalog or inventory of services which can be accessible through network and contains available services. It accepts and stores contracts from service providers and provides those contracts to interested service consumers [James M., 2003]. The directory service is an intermediary between providers and consumers where providers register with the directory service and consumers query the directory service to find service providers. Consumers can then use the directory services' search capabilities to find providers. Most directory services organize services based on criteria and categorize them [Simone A., 2007]. It also contains all the information about a service, including the physical location, information about the service provider, contact people, usage fees, technical constraints, security issues, access rights and the available service levels [Hssp-infrastructure.wikispaces., 2006]. A service contract is the description that clarifies the way of interaction between the service consumer and provider. It contains information about request-response message format, the conditions in which the service should be executed, and quality aspects of the service. A service contract may require a set of preconditions and post-conditions. The preconditions and post-conditions specify the state that the service must be in to execute a particular function.
SOA reflects specific principles and characteristics that need to be applied when building service-oriented application infrastructures, which are described as follows [Güner S., 2005]:
02
Services are discoverable and dynamically bound, services need to be discoverable dynamically at run-time. The consumer of the service finds the required service through searching of registry and gets all the information necessary to execute the service. There is no compile-time dependency to bind to the service, apart from the service contract that the registry provides. Services are self-contained and modular, a service supports unified and functional interfaces aggregated to perform specific and concrete business logic. These interfaces are related to each other in the context of a module and contain sufficient information to be authentic without any dependency to other software modules or applications. Services are interoperable, services express the ability to communicate with each other without any platform and language dependencies. Because each software module might have proprietary and tightly coupled structures, service based architecture utilizes interoperable technologies that support the protocols and data formats of the service’s current and potential consumers. Services are loosely coupled, coupling describes the level of dependencies between software modules. Loosely coupled modules are flexible and have well-defined dependencies, on the contrary, tight coupled software systems are difficult to configure because of unknown requirements of modules within the software structure. Service Oriented Architecture stress the development of loosely coupled services as the software construction unit. Loosely coupled is achieved by usage of service registries. The service requires no other system specific information to be executed autonomously. However, tight coupling cannot be avoided at the interface definition level or binding to a specific protocol. Services have a network-addressable interface, a service should publish its interface on the network to conform Service Oriented Architecture design principles, so that the consumer is able to invoke the service in a distributed manner over the network. In this way it is probable to use the service at any time with different consumers. A service can also be accessed through local interface without usage of network. However, one of the main aims in building SOA is to allow the consuming of services in a location-independent manner. 02
Services can be composed into new applications, another key characteristic of SOA is to enable building new applications composed from existing services. Composition is an effective design which mainly focuses on service modularity and reuse of service functionality without having pre-knowledge of which applications will use the service in the future.
3.4
Service Oriented Development and Design Software development has passed through certain stages and architectural models until
to enable the development of platform independent, reusable services [James M., 2003]. Each architectural model provides a better means of dealing with software difficulties than the previous approaches in order to accomplish enhanced software structures that fit realworld requirements as shown in Table (3.1) [Güner S., 2005]. The early architecture of software is based on structured design, which has been introduced to write subroutines and functions and reuse 'modules' [Sean S., 2006]. It has rigid rules for the development of software constructs and limited support to enable robust and sophisticated application development. Structured design couldn’t provide a simple way to manage data within the application, because different functions act on much of the same data [Güner S., 2005]. When a code problem or a 'bug' was discovered in a function somewhere, every single application that used that function had to be tracked down to modify the code to reflect the fix. After the fix, the deployment nightmare began [Sean S., 2006]. It also does not hide details of the data within the program. After that the, 80s saw Object oriented development that came to solve modular design problems. It allows developers hiding their program behavior and data inside objects, These ‘objects’ sections of code allowed to be moved around and copied from one program to another without changing its usage. But the developers started to see that developing and maintaining software was too complex and they wanted a way to reuse and maintain functionality, not just code. Object oriented development result in flexible software development that supports encapsulation of business logic through more coarser-grained 02
functions and classes [Sean S., 2006]. However, a large number of interconnected objects create dependencies that can be difficult to manage. In a large system, objects tend to know a lot about each other's structures and internal states. Objects are relatively fine-grained. Although interfaces control access to object internals, a large number of fine-grained objects make dependencies difficult to control in large applications. [James M., 2003] Next, the Component-based development model appeared in the 90s as a good solution for reuse and maintenance [Sean S., 2006]. It helps construct large object-oriented applications. Components are larger and coarser grained than objects and do not allow programs to access private data, structure, or state. Component-based development allows developers to create more complex, high-quality systems faster than ever before, because it is a better means of managing complexities and dependencies within an application. However, the protocols used to access components cannot easily pass through a firewall, making these protocols less interoperable. In addition, components are composed into applications at the time the developer compiles the program (compile time). An application that uses a component must have the interface definition at compile time, so the interface can be bound to and executed at runtime. Therefore Service-based development, which is Service Oriented Architecture, helps to solve these problems [James M., 2003]. Table (3.1). The characteristics and features of software architectural models [Güner S., 2005]
Reusability degree Coupling type
Structured Development
Object Oriented Development
Component Based Development
Service Based Development
Low
Low
Medium
High
Tight
Tight
Loose
Module
Individual classes
Loose Several classes (components)
Building Blocks
Functionality description
Hiding Data
No
Components
Class declarations
Interface declarations
Network addressable component interface declarations
Yes
Yes
Yes
02
Services in Service-based development are usually components wrapped in a service layer as shown in Figure (3.4). A service tends to aggregate multiple components into a single interface to perform a specific function and is thus coarser-grained. Also, the consumer of a service does not know the location or the interface of the service until runtime [James M., 2003]. Service based development advances component based development in a way that services involve development of distributed, cooperating components realized in different programming languages, but also service orientation supports the features such as platform independence, dynamic discovery of services and improved level of reusable application modules [Güner S., 2005].
Figure (3.4). Service Based Development [James M., 2003] 02
Services in Service Based Development are designed and developed to support the following characteristics [Güner S., 2005]: A) Each service defines a specific business function and can match to real-life activities. B) A service may have various procedures and operations. C) Services interact with other services and system components in a loosely coupled, message-oriented environment to accomplish business goals. D) Services has clearly defined interfaces and can be used by many different other services and applications. E) Services do not need to be in a distributed environment. In Service Based Development, Service Orientation reinforces general software architecture principles such as encapsulation, modularization and separation of the interfaces from their implementations, in addition to introducing concepts such as service choreography, service repositories and message-oriented and event-driven interactions. Service-based development has solved the interoperability issue by adopting Web-based interoperability standards. Web services use the HTTP protocol to transfer data and XML for the data format. This allows service requests to easily pass through firewalls. Servicebased development has been enabled through the advent of the Internet, the World Wide Web, and the ubiquitous technologies they have promoted. In addition, the potential for reusing services in applications has greatly increased, because of the use of standard technologies, which have also enabled broader inter-organization service use [James M., 2003]. To build a system that conforms to Service Based Development principles, the different pieces of business logic and work items should be broken out into services. These services encapsulate the capabilities of a software system; they communicate with each other using the different message exchange patterns (one-way, synchronous and asynchronous). The following list enumerates the steps that should be followed to implement a service-oriented system [Srinivasan L. & Treadwell J., 2014]: Identify the different units of business logic and units of work to be performed. Describe the functionality of the various units of work in terms of services. Implement stateful or stateless services as required by the functionality.
01
Identify the core infrastructure services that each service needs to use, and decide if they are readily available or need to be implemented. Identify the major pieces of common functionality, if any, between the various services, and ensure that the common functionality is captured as reusable, modular services, using subtyping and other extension techniques. Capture the different pieces of functionality exposed by a service in terms of operations modeled on the message exchange pattern, and assign meaningful names to the services to convey the functionality exposed. Define events of interest that the services would be producing or consuming. Create orchestration scripts or workflows to enable service choreography. Publish the services in a registry, or in multiple registries, so that they can be discovered by other entities.
3.5
Service Oriented Architecture Layers SOA is based on n-tier application development in which services are layered on top
of components that are responsible for providing certain functionalities and maintaining quality of service requirements for services. Each layer in SOA as depicted in Figure (3.5) has specific architectural characteristics, as described below [Güner S., 2005]: Operational Systems Layer: This layer contains existing applications including CRM and ERP packaged applications, object-oriented systems, and business intelligence applications. These applications provide the background for services and each of them has its own proprietary structures, databases and other system resource access. Enterprise Components Layer: These are specialized components to provide certain functions and requirements for services. They are the business assets for service implementations, and other system necessities such as management, availability and load balancing of services. Services Layer: This layer contains the actual services which can be discoverable and invoked by other applications to provide a specific business function for enterprises. 01
Services realize and deploy enterprise component interfaces as service descriptions and are published on the network. These services can be reused by multiple business processes. Business Process Composition Layer: This layer is responsible for managing the overall execution of the business process [Kevin G., 2006]. The services can be composed into a single application through service orchestration or choreography, which supports specific use cases and business processes. These business processes can be implemented using a specialized composition language such as Business Process Execution Language (BPEL) as show in the next subsection. Presentation Layer: It provides user interfaces for services and composite applications. Although presentation layer is not a straight concern for SOA, because of the objective of using services as user interface bring about the development of standards such as portlets and Web Services for Remote Portlet (WSRP) specifications. Other concern for SOA is the integration of services and composite applications within the enterprise by supporting the features such as reliability, proper routing and coordination of services, and managing other technical details including protocol and integrating party agreements. QoS (quality of service) requirements, security, management and monitoring of services are also other requirements that need to be clarified when designing service based application architectures.
22
Figure (3.5). The Layers of Service Oriented Architecture [Güner S., 2005] As has been shown in SOA layers, there are a linkages established between business processes, its associated services, and all the software components that participate in delivering that service functionality. When the business requirements change, the software components getting impacted can be traced, and being modular in nature, changes can be made to them locally, minimizing the ripple effect of change [Jyoti N. & Archana G., 2009].
3.6
Business Process Execution Language A business process is a group of related activities that uses the resources of the
organization to provide defined results in the form of products or services, often to an external party such as a customer or partner. Each business process is modeled as a set of individual processing tasks. These tasks are typically implemented as business services within the enterprise [Mike R., 2008]. The goal of SOA is to expose an organization’s computing assets as reusable business services, implementing basic business capabilities, which can be (re)used and integrated more readily using business processes. The relationship between business services and 28
business processes paves the way to a flexible enterprise: business services support stable business artifacts, incorporating processing and rules whose interfaces change fairly rarely. While business processes support fairly fluid business procedures and rules, which can change every few months or even weeks. This separation of responsibilities enables business analysts and IT architects to reuse IT capabilities, encapsulated in business services, through the composition of business processes. This simplifies the creation of new processes and optimization of the existing ones. More importantly, once designed, processes can be quickly modified in response to market conditions. All this translates into increased business flexibility and competitiveness, while reducing the incremental costs of making frequent process changes [Mike R., 2008]. The SOA approach for efficient automation of business processes requires: Standardized way to expose and access the functionality of applications as services. Enterprise bus infrastructure for communication and management of services, including message interception, routing, transformation, etc. Specialized language for composition of exposed functionalities of applications into business processes such as BPEL [Matjaz B., 2006]. The BPEL, which is an XML based language models business process as a composition from a set of elementary web services [Mendling J., 2014], has become one of the most important technologies of SOA because it introduces a new concept into application development. This concept enables process designer to develop processes quickly by defining the order in which services will be invoked. This way, applications become more flexible and can better adapt to the changes in business processes [Matjaz B., 2006]. For example, a business process for planning business travels will invoke several services. In a simplified scenario, the business process will require to specify the employee name, destination, dates, and other travel details. Then the process will invoke a web service to check the employee status. Based on the employee status, it will select the appropriate travel class. Then it will invoke web services of several airline companies (such as Egypt Airlines, Alitalia Airlines, etc.) to check the airfare price and buy the one with the lowest price. For the clients, the BPEL process will expose its functionality in the same 20
way as any other Web service. This is important and useful, as it allows composing services into simple processes, simple processes into more complex processes, and so on. This also means that each BPEL process will be described with a Web Service Description Language (WSDL). To be able to execute BPEL process, a BPEL engine, which is a dedicated software component such as Apache ODE, BizTalk, Oracle BPEL Process Manager, etc., is needed. It provides control over processes that are executing and those that have finished. Each BPEL process can be accessed as a web service of the BPEL engine, too. The BPEL specification depends on the W3C standards WSDL for web service description, XML Schema for the definition of data structures, and XML Path language (XPath) for retrieval of XML elements [Mendling J., 2014]. There are some of BPEL’s most important concepts are briefly presented as follow [Mendling J., 2014]: Partner link which provides a communication channel to remote web services which are used in the BPEL process. Variables that are used to store both message data of web service interactions and control data of the process. Activities which perform the basic steps of a BPEL process such as: sending and receiving messages from web services (receive, invoke, reply), changing the content of variables (assign), waiting for a certain period or up to a certain point in time (wait), terminating the process (exit, formally called terminate), specifying parallel execution (flow), conditional branching based on data (if-else), sequential execution (sequence), and different loops (while, repeatUntil, forEach).
22
3.7
Summary In SOA services are the main building block of SOA which consist of contract,
implementation, and Interfaces. SOA is approach that package and model software as a set of services that can be discovered by consumers at runtime. It is based on the key concepts of an application frontend, service repository, and service bus. SOA define an interaction model entities that facilitate the interaction between service consumers and service providers. In order to build SOA application infrastructures, SOA defines specific principles and characteristics that need to be applied on the SOA applications. SOA has passed through certain stages and architectural modes to enable the development of an independent platform and reusable services. It also has a specific architectural layers that are responsible for providing certain functionalities and maintaining quality of service requirements for services. The goal of SOA is to produce organization computing assets as a reusable business services that can be integrated to compose a business process. In order to provide an efficient automation of business process, SOA requires a specialized language for composing applications functionalities into business processes such as BPEL. BPEL is an XML based language that models business process as a composition from a set of elementary web services. It introduces a new concept into application development therefore it has become one of the most important technologies of SOA. BPEL requires a dedicated software engine to be executed. It also provides a set of concepts such as Partner link, Variables, and Activities. These concepts provide specific functionalities that control the execution of the BPEL.
22
CHAPTER 4 Aspect Oriented Paradigm 4.1
Introduction A workflow language provides two types of modules. A process module that is used
for encapsulating the core business logic of the workflow process, which is the main concern. An aspect module that is used for crosscutting concerns and workflow changes, because it is necessary to specify when and where the execution of the respective activities should be triggered during the execution of the workflow process [Anis C., 2007]. However, due to the workflow process lacks means: to modularize crosscutting concerns (e.g., logging, persistence, and security) that cut across the structure of processes, and to support the dynamic adaptation of the composition at runtime [Anis C., & Mira M., 2007] a workflow languages that support process modules and aspect modules are needed such as aspect-oriented workflow languages [Anis C., 2007]. Aspect-oriented workflow languages provide language constructs for crosscutting concern modularity such as aspect, pointcut, and advice. These languages support a concern-based decomposition of workflow specifications, the business logic, as being the main concern, can be specified in a modular way within a workflow process module, whereas crosscutting concerns and workflow changes can be specified in a modular way within workflow aspect modules. However, most workflow languages [Anis C., 2007] and [Look A., 2011] do not offer mechanisms for the modularization of crosscutting concerns, and it has been observed that this can lead to complex workflow specifications that are hard to reuse, change, understand, and maintain. The first Aspect-Oriented Workflow Language that has been developed is called AO4BPEL.
53
The following sections will discuss: the Aspect Oriented for Business Process Execution Language, AO4BPEL Joint Point Model, AO4BPEL Scopes, and AO4BPEL Architecture.
4.2
Aspect Oriented for Business Process Execution Language AO4BPEL [Anis C., 2007] and [Look A., 2011] is an aspect-oriented extension to
BPEL, in which aspects can be plugged and unplugged into the composition process at runtime. Aspects enable the modularization of concerns that cut across multiple objects. Such concerns are often termed crosscutting concerns. An aspect uses join points, point cuts and advices in the modularization process. A join point is a point during the execution of a program. A Pointcut is a predicate that matches join points. An advice is an action taken by an aspect at a particular join point. Figure (4.1), is an example of an aspect. The point cut of this aspect selects the flight search activities in the flight process and in the travel package process. The advice of this aspect contains an activity for starting a timer, which is executed before the join point as well as an activity for stopping a timer, which is executed after the join point [Anis C., 2007].
Figure (4.1). An Aspect Example: Execution time measurement [Anis C., 2007] 53
4.3
AO4BPEL Joint Point Model AO4BPEL [Anis C., 2007] and [Look A., 2011] uses a join point model that defines
what kind of join points are exposed, how they are specified using a pointcut language, and what kind of actions can happen at a join point. The join point model of AO4BPEL is based on activities. Additionally to these activity join points (or process-level join points), another class of join points, called internal join points (or interpretation level join points), exists. While activity join points capture the execution of BPEL activities at the process level, internal join points are lower-level and capture internal points during the execution of an activity, e.g. the sending or receiving of SOAP messages. The pointcut language in AO4BPEL uses XML Path Language (XPath), which is a query language for selecting nodes from a XML document. Using XPath, activities are selected based on the structure of the process, the activity names, and their attributes. In addition pointcut can use a Prolog query that evaluates to true or false based on the static and dynamic facts in a Prolog database. AO4BPEL supports variable-oriented pointcuts can be used to select activities that operate on variables (informational perspective), and partner-oriented pointcuts (operational and organizational perspective) can be used to select activities based on the partner they interact with. In addition multiple pointcuts can be combined using the XPath union operator. The advice in AO4BPEL is a BPEL activity. It can be executed before, after or instead (around advice) of the activity that has been matched by the associated pointcut. The type of the advice is defined using the type attribute of the pointcut element. Within the advice activity some special keywords and variables are available to get access to the join point runtime context, such as the current values of variables, and Meta information, such as the name of the current process. Those special variables are: ThisJPInVariable, it is the input variable of the join point activity (invoke and receive). ThisJPOutVariable, it is the output variable of the join point activity (invoke and receive). ThisJPActivity, it is a Meta information about the join point activity: process name, activity name, activity type, partner 53
link, port type, and operation name. ThisProcess(x), it gives access to the activity or partner link named x of the parent process. In the case of cross-layer pointcuts soapmessage/newsoapmessage variables can be used to get access to the matched SOAP message and to replace it with a modified version. is a special activity that can be used to execute the join point activity within the advice. In the case of an around-advice without a proceed activity, the execution of the join point activity is suppressed.
4.3.1 AO4BPEL Scopes AO4BPEL defined two types of aspect scopes [Anis C., 2007] and [Look A., 2011]. A statically scoped aspect always affects the same parts of the program, while the application of a dynamically scoped aspect depends on some kind of dynamic condition. The scope of an aspect can implicitly be either global, process level or instance level. By default the scope of an aspect is global. The global scope affects every process in the system, including the ones that are already active. The scope of an aspect can be restricted to a certain process (process level), by directly declaring its name within a pointcuts XPath expression. When one wants to deploy multiple aspect at process level, the process name has to be included in every single pointcut definition. When the same aspect shall be used for a different process, or whenever the process name changes, all pointcut definition will have to be modified. The instance level uses a condition attribute for pointcuts. It can contain a BPEL expression that is evaluated at possible join points during runtime. Thus, it can be used to constrain the execution of an advice, based on the value of a BPEL variable.
4.3.2 AO4BPEL Architecture Using AO4BPEL, aspects can be manually deployed and undeployed at runtime, without a service disruption. To deploy and undeploy aspects, there is two facts AO4BPEL support Figure (4.2) [Look A., 2011]. The static facts that is the static structure of a BPEL process. It contains the name of the process and two sets. One set contains fact for every activity, and the other set contains fact for every invoke activity within the process. The 53
dynamic facts is a trace of events generated during process execution. It contains seven facts that define: the starting and the ending of a process, the activity information such as (ActivityInstanceID, ActivityID, ActivityName, and ActivityType), and the starting and the ending of an activity. Based on the static and dynamic facts AO4BPEL defined a variety of pointcut designators in the form of Prolog rules such as: activity (NAME), activity_id (ID), partner (partnerlink)…etc. Aspects in AO4BPEL are deployed in terms of aspect deployment units. An aspect deployment unit contains an optional deployment descriptor, a number of aspects and the associated artifacts, such as WSDL documents. In addition processes in AO4BPEL are also deployed in the process deployment units and its deployment descriptor and WSDL are stored in this unit. Every aspect and process are compiled in order to be used in the deployment process by the aspect store which is responsible for decompressing, compiling and storing all aspects. It invokes the aspect compiler on every aspect it finds within the deployment unit directory. At specific points during the execution of a process, the BPEL runtime calls the aspect manager to check, if there are any active aspects with a matching pointcut for the current activity. If matching aspects are found, the aspect manager is responsible for wrapping the different advices and the join point activity into one structured activity. The resulting advice activity is returned and will be executed by the BPEL runtime.
53
Figure (4.2). AO4BPEL 2.0 architecture [Look A., 2011]
04
4.4 Summary Aspect oriented workflow language is a language that supports process modules and aspect module. It modules the crosscutting concerns into aspect, pointcut, and advice. AO4BPEL is one of the aspect oriented workflow language that support the modularization mechanism and apply it dynamically. AO4BPEL is an aspect extension to BPEL in which aspects can be deployed and undeployed at runtime. It also supports a join point model which defines the kind of join points that is exposed, specifies the using of the pointcut language, and determines the kind of actions that can happen at a specific join point. AO4BPEL uses XPath and Prolog Query as a pointcut language. It defines advice that allows aspect to be executed before, after, around the main process. In addition the scopes of AO4BPEL helped aspect designers to apply aspects either at global level, process level, or instance level. AO4BPEL architecture allow aspect to be deployed depending on facts. These facts can be static or dynamic. All aspects are deployed in the Aspect Deployment Unit and stored in the Aspect Store to be executed by the BPEL runtime engine.
04
CHAPTER 5 Variability Modeling 5.1
Introduction Variability is the ability of a system to be efficiently extended, changed, customized
or configured. Building variability in web service can make the service developed with more adaptability and reusability. When a variability model is given, there are some basic elements that a model should contain: they are variation point, variants, and dependencies. The variation point and variants capture the variability of service; and the dependencies constraint these variability [Xingyu L., 2008]. Numerous variability modeling approaches exist today to support domain and application engineering activities. Most are based on: feature modeling (FM) which captures features that is in shape of the end user’s understanding of the general capabilities of systems in the domain, and the relationships among them. Decision modeling (DM), which captures decisions that are adequate to distinguish among the members of an application engineering product family and to guide adaptation of application engineering work products [Krzysztof C., 2012]. However these models suffer from the following: the variability information is spread across different models and it is almost impossible to keep the information consistent. The modeling using them is complex, as they get overloaded by adding the variability information. Hardly determine which variability information in requirements has influenced which variability information in design, realization, or test artefacts. Therefore, Orthogonal Variability Modeling (OVM) came to solve the drawback with these models by defining the variability information in a separate mode [Pohl K., 2005] The following sections will discuss: Hierarchical Workflow Template Design and Orthogonal Variability Modeling 24
5.2
Hierarchical Workflow Template Design In SOA development, a workflow refers to how two or more web services interact
[Tsai W. & Sun X., 2013]. Workflow design often follows the template design pattern. The core idea of template design [Goderis A., 2005] is to use a template to define the program skeleton of an algorithm and one or more of the algorithm steps can be overridden subclasses to allow different behaviors. Hierarchical workflow template design (HWTD) is an application of template design for SOA software development, in HWTD the application designers who design workflows need to define variable places ‘abstract methods’ where the variation is possible. Each variable place can be replaced by one or more sub-workflow templates ‘concrete methods’. Each sub-workflow in SOA contains an atomic or a composite web service, and it can still have variable places. Each variable workflow or variable sub-workflow that fits tenants’ purpose can be reused [Pohl K., 2005].
5.3
Orthogonal Variability Modeling OVM is a proposal for documenting software product line variability [Areeg S., 2013].
In OVM only the variability of the product line is documented. In this model a variation point (VP) documents a variable item and a variant (V) documents the possible instances of a variable item. All VPs are related to at least one V and each V is related to at least one VP. Figure (5.1) shows for the graphical notation used in OVM [Pohl K., 2005].
24
Figure (5.1). Graphical notation for OVM [Pohl K., 2005]
In OVM, optional variants may be grouped in alternative choices. This group is associated to a cardinality [min…max]. Cardinality determines how many Vs may be chosen in an alternative choice, at least min and at most max Vs of the group. The constraints between nodes in OVM are defined graphically. A constraint may be defined between Vs, VPs, and Vs and VPs. A constraint may be either excludes or requires constraint. An excludes constraint specifies a mutual exclusion, for instance, a variant excludes a VP means that if the variant is chosen to a specific product then the VP must not be bound, and vice versa. A requires constraint specifies an implication, for instance, a variant requires a VP means that always the variant is part of the product, and the VP must be also part of that product. In OVM, there are five principles can be used to address variability in services or in workflow based systems [Pohl K., 2005]: First, defining the variation points within and across SaaS application. Second, addressing the variants in SaaS application and defining them as variants of the variation point. Third, after defining the variation points and the variations in SaaS applications, it is essential to identify variability dependency between 22
the variation points and variants in a systematic manner. The variability dependency could be an Optional Variability Dependency which states that a variant can be a part of the application, or Mandatory Variability Dependency which defines that a variant must be selected for an application if and only if the associated variation point is part of the application. Fourth, define all the possible alternative choice in the application by defining the minimum and the maximum number of optional variants to be selected from a given group of variants. Finally, specify the dependency constraint between variations, variation points, and between each one of them whether it is excludes or requires. Figure (5.2) depicts a simple example of an OVM inspired by the travel agent industry. This example is a part from the application model in this thesis.
VP
VP
Payment
Reservation [1…3]
[1…1]
V
V
CreditCard
E-Check
V
V Hotel
V Car
Flight
Figure (5.2). OVM Example: Travel agency industry
The basic elements of the OVM model are defined in the Meta model in Figure (5.3) The ‘VP’ class is an abstract class is specialized into the two classes ‘internal VP’, which is an associated variants that are only visible to developers but not to customers and ‘external VP’, which is an associated variants that are visible to developers and customers. This specialization is complete and disjoint [Pohl K., 2005].
24
Figure (5.3). Development artefact and artefact dependency in the variability Meta model [Pohl K., 2005]
To relate the variability defined in the variability model to software artefacts (e.g., requirements, design, realization, and test artefacts) specified in other models (e.g., feature models, use case models, and design models, etc.), the variability Meta model has been extended by a relationship which called “artefact dependency” as in the above Figure (5.3). The means to document such relationships is to define traceability links between the variability model and other development artefacts. A development artefact is the output of a sub-process of domain or application engineering. It represents requirements models, architectural models, software components, test plans, and test designs. There are cases in which a development artefact needs to represent a VP. For instance, in design, an abstract class may realize the common behavior of several Vs. In other cases, developers may want to anticipate that there are Vs, which are not yet defined [Pohl K., 2005].
24
5.4
Metagraphs Modeling Tools A Metagraph [Basu A., 2005] and [Basu A. & Blanning R. W., 2007] is a graphical
structure in which edges are used to denote directed relationships between two sets of elements. Each set of elements in the Metagraph are connected by edge(s). The tail of an edge is the invertex and the arrow head of it is the outvertex. Each edge denotes a relationship from its invertex to its outvertex. Connectivity features of Metagraph are very useful. For instance, two kinds of paths can be defined on Metagraphs. The first type is a simple path which represents a sequence of edges linking two individual elements h(x, y). The second type is a metapaths which defines connectivity between two sets of elements [Basu A. & Blanning R. W., 2007].
5.4.1 The Metagraph Modeling The set of elements in Metagraph is defined as X = {x1, x2, . . . , xn}, which represent variables of interest, and which occur in the edges of the Metagraph. An edge e in a Metagraph is a pair e = ∈ E (where E is the set of edges) consisting of an ‘invertex’ Ve ⊂ X and an ‘outvertex’ We ⊂ X, each of which may contain any number of elements. The different elements in the invertex (outvertex) are coinputs (cooutputs) of each other [Basu A. & Blanning R. W., 2007]. A Metagraph S = is a graphical construct specified by its generating set X and a set of edges E defined on the generating set. The coinput of x in the path (denoted coinput(x)) is the set of all other invertex elements in the path’s edges that are not also in the outvertex of any edges in the path, and the cooutput of y (denoted cooutput(y)) is the set of all outvertex elements other than y [Basu A. & Blanning R. W., 2007]. The number of edges in the path is the length of a simple path where x ∈ invertex (e1), y ∈ outvertex (en), and for all ei, i = 1, . . , n-1, outvertex (ei) ∩ invertex (ei+1)≠ ∅ [Deepti G., 2009]. Simple path does not describe all of the connectivity properties of Metagraphs
24
so metapaths is specific to the Metagraph due to its ability to describe edges, source, and target as a set not as a sequence as in simple path. An example of a Metagraph is shown in Figure (5.4), this example is a part from the application model in this thesis. This Metagraph describes the activities and information elements in a travel agency business process. It contains two edges (labeled e1 and e2) that relate various information elements of concern in terms of specific activities. The edge e1 represents the payment activity based upon the customer record; it results in either Credit Card Payment or E-Check Payment. The edge e2 represents the reservation activity based on the customer record; it results in Flight Reservation, Hotel Reservation, or Car Reservation.
e2
e1 C
FR
HR
CR
CCP Legend: C: Customer Record FR: Flight Reservation HR: Hotel Reservation CR: Car Reservation CCP: Credit Card Payment ECP: E-Check Payment
ECP
Figure (5.4). A Travel agency business process Metagraph
Using the above rules, the Metagraph in Figure (5.4) can be represented as follows: S = , where X = {C, CCP, ECP, FR, HR, CR}, and E = {, }, Invertex for e1 = {C}, for e2 = {C}, 24
Outvertex for e1 = {CCP, ECP}, for e2 = {FR, HR, CR}, Coinput for e1 = {∅}, for e2 = {∅}, Cooutput for e1 = {CCP}, {ECP}, for e2 = {FR, HR}, {HR, CR}, {FR, CR}.
5.4.2 Metagraph Incidence and Adjacency Matrices In order to define an algebra for Metagraph manipulation, two matrix representations of a Metagraph are needed. These are the adjacency matrix and incidence matrix, each of these matrices is a complete representation of a Metagraph, and can be derived from the other [Basu A. & Blanning R. W., 2007]. The adjacency matrix A for a Metagraph S = is an I ×I matrix (where I = |X|), such that for all i, j ∈ {1, . . . , I }, 𝑎𝑖𝑗 =
∪ (𝛼 ) 𝑘 𝑖𝑗 𝑘
where: 𝑖𝑓 𝑥𝑖 ∈𝑉𝑘 ⋀ 𝑥𝑗 ∈𝑊𝑘 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒.
(𝛼𝑖𝑗 )𝑘 = {∅
The adjacency matrix A of a Metagraph is a square matrix with one row and one column for each element in the generating set X. The ijth element of A, denoted aij, is a set of triples, one for each edge e connecting xi to xj. Each triple is of the form , in which CIe is the coinput of xi in e and COe is the cooutput of xj in e. For example, the adjacency matrix for the Metagraph in Figure (5.4) is shown below in Figure (5.5).
Figure (5.5). The adjacency matrix for the Metagraph in Figure (5.4) 24
The incidence matrix G of a Metagraph has one row for each element in the generating set and one column for each edge. The ijth component of G, gij, is −1 if xi is in the invertex of ej, it is +1 if xi is in the outvertex of ej, and it is ∅ otherwise. The incidence matrix for the Metagraph in Figure (5.4) is shown in Figure (5.6) below.
e1
e2
C
-1
-1
CCP
+1
ECP
+1
FR
+1
HR
+1
CR
+1
Figure (5.6). The incidence matrix for the Metagraph in Figure (5.4).
5.4.3 Attributed Representation in Metagraph Metagraph edges [Basu A., 2005] are set-to-set mappings with no further information attached. However, it is possible to attach attributes to Metagraph edges. A qualitative attribute is essentially a label that is added to each Metagraph edge in addition to the edge identifier (name) label. An example of such an attribute is a color, like ‘Blue’ or ‘Red’. For example, consider the example in Figure (5.7). Both Figures (5.7.a) and (5.7.b) represent the same Metagraph, with the edges assigned a constraint dependency attribute. The first representation, in Figure (5.7.a), is visually more informative where it represents the constraint dependency ‘Requires’ and ‘Optional’ as a labeled attribute in e1 and e2 sequentially. On the other hand, the representation in Figure (5.7.b) shows each constraint
45
dependency attribute as an additional element of the generating set, and then included in the invertex of the edges to which it applies. e2 FR
HR
CR
e1 C
Optional
Requires
CCP Legend: C: Customer Record FR: Flight Reservation HR: Hotel Reservation CR: Car Reservation CCP: Credit Card Payment ECP: E-Check Payment
ECP
Figure (5.7.a). Edge representation of the qualitative attribute for Figure (5.4)
Legend: C: Customer Record FR: Flight Reservation HR: Hotel Reservation CR: Car Reservation CCP: Credit Card Payment ECP: E-Check Payment O: Optional R: Requires
R
e1
FR
CCP
HR
C
e2 CR
ECP O
Figure (5.7.b). Vertex representation of the qualitative attribute for Figure (5.7.a) 45
There are two important implications of this feature in Metagraphs [Basu A. & Blanning R. W., 2007]. First, while the edge representation is easier to interpret visually, the advantage of the vertex representation is that each attribute value needs to appear only once, and all edges with that attribute value are immediately identifiable (since that value is in their invertex). So in a large Metagraph, finding all the optional or require edges is easy in the vertex representation. But, it will be very difficult to draw this Metagraph, once it has a large number of edges. The second implication is that it is possible to use the edge representation in graphical visualization of attributed Metagraphs, while using the vertex representation for analysis. The addition of qualitative attributes in the vertex representation does not force any significant change to the basic algebraic constructs and operations in Metagraphs, unlike other graph representations. The added attributes are treated simply as a subtype of element from the generating set, and are included in the adjacency matrix as shown in Figure (5.8).
Figure (5.8). The adjacency matrix for the Metagraph in Figure (5.7.b)
44
5.5
Summary Variability is the ability of a system to be extended or changed. In order to model
variability in a workflow, a HWTD is required to provide a template design pattern to be customized by tenant developers. The variable parts will subtracted from the rest of application into a separate model by using OVM. OVM is a model in which variability of the product line is documented as VPs and Vs. It used in the thesis to solve the shortage of HWTD. OVM can’t validate the variability made by the tenant developers therefore this thesis used the Metagraph to ensure that the specifications made by developers are correct and to store developers’ specifications in a storage to be used in the future.
44
CHAPTER 6 Related Work 6.1
Introduction SOA is a flexible set of design principles used during the phases of systems
development and integration. A deployed SOA-based architecture will provide a looselyintegrated suite of services that can be reused within multiple business domains. SOA separates functions into several distinct services which is developed and accessible over network allowing users to reuse them in the production of applications. These services and their corresponding consumers communicate with each other by passing data in a welldesigned and shared format, or by coordinating an activity among two or more services [Becerra C., 2010]. Customizability is an efficient solution to support service's reuse in Service Oriented SaaS applications. Building customizability in web service and business process can make the service and the process developed with more adaptability and reusability. Customization could be performed in two different approaches [Areeg S., 2013]: SourceCode Based or Composition Based.
There are many works have addressed the
customizability of business processes and services depending on the source-code and composition approaches. The following sections will handle both approaches in details, and will compare the proposed approach with other works.
6.2
Source Code Approach SaaS applications that based on source-code customization are customized by adding
and integrating new source code with the customizable application. The source-code based customization approach although it provides tenants with flexibility in the customization process, it suffers from some drawbacks including: (A) The tenant administrator should be aware of the implementation details of the SaaS application, (B) Allowing the tenant 54
administrator to add and integrate source code may violate the security regulations of the application, (C) The source code added by the tenant should be revised and maintained when the SaaS application developer upgrades the application, (D) Customizing SaaS application requiring people with higher skills and wages to work on Customization, and (E) Application developer will face much longer lifecycle brought by code development, debugging, testing and deployment. All these drawbacks may lead to lose business opportunity from those clients who cannot accept the Customization complexity and cost. There are several research works that handle customization using this approach, [Lee W. & Choi M., 2012] proposed the multi-tenant web application framework for SaaS. The framework provides an effective customization method for user interfaces and business logics. They used source-code approach in providing customization method that supports various levels of customization through the use of file-level namespaces, inheritance, and polymorphism. A tenant can use various JavaScript libraries by uploading libraries into the tenant’s namespace. The authors of [Lee J., 2012] described multitenant supportive customization architecture by proposing the web-based development framework to generate custom business logics of SaaS applications and the runtime engine to process the changes based on the multi-tenant execution environment. Their work allow multitenant to customize code level content based business logics and make relationship with the specific UI component in order to be invoked from that UI component. The work in [Zhou X., 2011] presents a collaborative requirement technique, which keeps each potential client of a SaaS application aware of the requirements raised by other clients or the SaaS vendor and allows a client to vote on existing requirements or raise new requirements. Individual clients can create and evolve their requirements model, while the SaaS vendor can automatically get a combined requirements model that reflects all clients' common and variant requirements. The SaaS vendor can then develop a SaaS application according to the combined requirements model, so that individual client's requirements can be satisfied by self-serve configuration. The work used a center repository to record all
55
requirements about the to-be developed SaaS application and all collaboration related information. In [Lanju K., 2010] a multi-level customization model has been proposed for SaaS applications based on the strategy and present a mathematical analysis of the multi-level customization model. The authors allow tenants make a high-level virtualized application with the common customization parts. Tenants can customize out of lower-level ones inheriting high-level one by modifying an object that can be customized in a SaaS application. Each object has a certain degree of customizable capability. Tenants can use a custom operation that allows tenants customizing SaaS application in order to implement a customization feature. The authors provide a mathematical analysis to evaluate the efficiency of their model.
6.3
Composition Approach SaaS applications in the composition based approach are customized by composing
variant components, selected from a provided set of components, to the customizable application. The proposed approach in this thesis following this approach. There are also other works that follow composition based approach as show in Table (6.1). These works are:
6.3.1 Mietzner Work The authors in [Mietzner R., 2009] describe a variability modeling techniques ‘external and internal variability’ from software product line engineering in managing the variability of SaaS applications and their requirements. They designed two variability models to systematically derive customization and deployment information for individual SaaS tenants. They use OVM to define the variability in SaaS applications. They provides potential configuration options to allow tenants decide which variants should become part of their SaaS application and to bind tenants’ variability with the SaaS application. They provided a prototype which allows plugging in different algorithms that are used to determine which infrastructure resources across different infrastructure providers can be 56
used to deploy the application. However, the work didn’t apply each tenant’s customization on the fly. In addition, the guided customization process that the authors provided to avoid unpredictable customizations made by tenants is not helpful to guide tenants in large SaaS applications with thousands of variants. Tenants can’t determine which variant should be part of their variation point. Table (6.1). Comparison between various works based on Comparison based Approach Modeling Customizations
Validating Customizations
Describing Relationships
Runtime Customizations
[ Mietzner R., 2009] [ Tsai W., 2010] [ Moens H., 2012] [Sun W., 2008] [ Lizhen C., 2010] [ Tsai W. & Sun X., 2013] [Jegadeesan H. & Balasubramaniam S., 2009] [ Park J., 2011] [ Qian L., 2012]
6.3.2 Tsai Work The work in [Tsai W., 2010] proposes a multi-layer Ontology-based Intelligent Customization (OIC) framework to support and manage the variability of SaaS applications and tenants specific requirements. Their framework used ontology as a way to derive customization and deployment information for tenants cross layers. Their framework focused on supporting new tenants to deploy using information from existing deployed 57
SaaS applications using intelligent recommendation engine. It predicts new tenant’s preference using a classification algorithms. The tenant’s preference stored in a repository and used as an input for the recommendation in the future. The framework allows customers to customize and modify components in a template according to individual requirement. They stored the template in order to be retrieved if it does fully fulfill customer’s specific demands. However the authors didn’t provide tenants with an understandable customization model. They didn’t model the relationship between variants. They also didn’t validate customizations made by tenants. In addition they didn’t allow each tenant’s customization to be applied on the fly.
6.3.3 Moens Work The authors of [Moens H., 2012] propose an architecture for the development and management of customizable SaaS applications, built using Software Product Line Engineering (SPLE) and feature modeling techniques. They modeled variability in applications as a collection of features. All features are linked to a code module and a placement configuration. The placement configuration can be used to add additional restrictions that are to be taken into account when placing the service on infrastructure. They modeled the relationships between variations. Their provided architecture enables developers to define significantly less features, while limiting the amount of automatically generated features in the application runtime stage. However the work didn’t validate tenant developer customizations. It also doesn’t allow variants to be unplugged during runtime.
6.3.4 Sun Work The authors in [Sun W., 2008] provide a competency model and a methodology framework that have been developed to help SaaS vendors to plan and evaluate their capabilities and strategies for service configuration and customization. They provide five levels of competencies to be used in the assessment of SaaS application to identify improvement goals around configuration and customization. Their framework consists of 58
a methodology and supporting analysis tools to: analyze customer requirements, help SaaS vendors determine how they plan to support the required configuration and customization requirements in the targeted customer segment, assess the competency of the existing SaaS application from configuration and customization aspect, and identify gaps in the competency model. However the work didn’t check tenant developer customization choices. It didn’t enable runtime adaptability for tenant customizations. Also the work didn’t model the variability nor its relationships in SaaS applications.
6.3.5 Lizhen Work The authors of [Lizhen C., 2010] propose variability modeling based on Metagraph support SaaS providers in managing the variability for configuration and customization of SaaS applications. A Metagraph tool is used to model customization points in a multitenancy application and to facilitate customers to perform application configuration and validate the configuration inputs made by the customers using Metagraph algebra structure. The authors didn’t allow each tenant customization to be applied on the fly. Also they only handle one type of variation relationship which is ‘requires’ relationship. In addition using Metagraph to model SaaS application variability, produce complex and un-understandable model especially in large applications. The more variants were chosen by tenants in SaaS application, the more complex model will be produced by Metagraph.
6.3.6 Tsai and Sun Work The work in [Tsai W. & Sun X., 2013] proposes an innovative customization approach that studies existing tenant’s customization choices. They applied hierarchical template design philosophy by modeling the customization process using orthogonal variability model, combined ontology for variants definition, organization or and discovery, and they checked tenant’s customization plan using soft and hard rules mined existing customization decisions. However the work didn’t allow each tenant customization to be applied on the fly. It didn’t model relationships between customizations nor validate tenant customization.
59
6.3.7 Jegadeesan and Balasubramaniam Work The work in [Jegadeesan H. & Balasubramaniam S., 2009] used an aspect oriented software development principles to modularize variability in the business process and in the industry specific requirements concerns at the implementation level. The authors provided an aspect specification schema to specify these concerns, and proposed an approach to separate variant concerns that affect the service interface and implementation in aspect centered on a service kernel ‘core business’ to form a common service core across tenants. They weaved aspect into kernel to derive heavyweight service variants that can serve multiple tenants. They used a language independent aspect specification that is an XML schema to support the provider implementation with pointcut, joint points, and advices. The inputs and outputs of a service interface are the message data types. The authors didn’t provide tenants with customization model nor address customization relationship. Also they didn’t provide a way to validate customizations made by tenants.
6.3.8 Park Work The work in [Park J., 2011] generating various service variants. The authors modeling variability at two levels. The composition level which handles the variability of composition and the flow of domain services that fulfill business processes, and the specification level which deals with a domain service that is an abstract service with variability. The work focused on modeling variability that can be used to support the development of service-oriented applications. By designing and developing domain services that have common and variable features. They achieved service reusability through the reuse of existing common features and domain services to generate various services, and through modeling variability at both the composition level and the specification level. They defined a common variability model that can be reused as a core assets which are the services and the loose coupling of these services. They can construct new types of concrete service-oriented applications by combining the variability concept with these two types of core assets. However the work only model the customization. It
60
didn’t model the relationships between customization, it didn’t validate tenant customization, and it didn’t adapt runtime customization.
6.3.9 Qian Work The work in [Qian L., 2012] proposes a cooperative construction approach based on multilevel abstraction for SaaS applications, in which the tenant instance of a SaaS application will be abstracted into different levels according to its customization requirements, and then be constructed from different components and through different constructing routes with the collaboration of different participants in a SaaS system. The authors work customizes SaaS application by allowing service providers register and upload a service component. They add the component information to a service repository by parsing the XML-based configuration file of the package uploaded. However, from a higher-level perspective, developers are code less but have less freedom in creating new functions. So if the new instance of a SaaS application has many individualized needs, especially in functional, developers should construct it from the base level. Although the work only modeled the variability, it didn’t model the relationship between customizations nor it validate tenant developer customizations. Also the authors didn’t provide a way to apply tenant developer at runtime. .
61
6.4
Summary Various related work has been proposed for source code and composition-based
customizations. The proposed approach in this thesis follows the composition approach due to the limitations in the source-based customization. However all the work in the composition-based customization didn’t address all the SaaS key concerns which are model customizations, model the relationships of that customizations, validate tenant developer customization, and apply tenant customizations during runtime. They only addressed some of these concerns in their work.
62
CHAPTER 7 Aspect Oriented Approach for Reusable Service Oriented SaaS Applications
7.1
Introduction As have been mentioned in the background chapter, SOA is based on five main layers
which are Operational Systems Layer, Enterprise Components Layer, Services Layer, Business Process Composition Layer, and Presentation Layer. SaaS applications are built following a Service-Oriented Architecture (SOA) as it offers a flexible way for building new composite applications out of existing building blocks [Mietzner R., 2009]. The layers of a SaaS application that need to be customized are: Graphical User Interface (GUI), business process logic (workflow), service, and data [Tsai W., 2010]. To customize SaaS application, there are four key concerns that need to be achieved: first, how to model the customization points and its customizations, second, how to describe the relationships among customizations, third, how to validate tenants’ customizations, fourth, how to associate and disassociate variations to/from customization points during run-time. The proposed approach in this thesis will be concerned only with two layers of SaaS application which are workflow Layer and service layer. The next sections will discuss: modeling customization in business process layer, modeling customization in business service layer, customization validation algorithm, runtime customization using AO4BPEL, and the framework of the proposed customization SaaS approach.
7.2
Modeling Customization in Business Process Layer This section will customize SaaS application business process layer by modeling the
customization points and its customizations, and describing the relationships among them. 36
The following sub sections will achieve business process customization by discussing: the Hierarchical Workflow Template Design (HWTD), Mapping OVM to Metagraph, Metagraph adjacency matrix, and Metagraph incidence matrix.
7.2.1 Hierarchical Workflow Template Design The application to model in this thesis is taken from a travel agency domain. It contains some activities which are Customer Information activity, Reservation activity, Payment activity, Reservation Option activity, Confirm Reservation activity, and Retrieve Reservation Details. In the proposed approach, each variable place will be modeled as a customizable place. The aim from using HWTD is to define all the customizable places in our SOA-Based SaaS application. Figure (7.1) shows a customizable workflow for this application. It contains four customizable places which are Reservation, Payment, Reservation Option, and Confirm Reservation. Each customizable place in the workflow of our application can be replaced by sub-workflows and can be reused in other application. Each sub-workflow can contains a customizable place such as the reservation has four subworkflow, one of them is the View which is considered a customizable place has two subworkflow, one has View Tour and the other has View Offers of the trips. These subworkflows are given in Figure (7.2).
36
CP
Customer Information
CP Reservation Option
CP
CP
Reservation
Payment
CP
Confirm Reservation
Figure (7.1). A customizable workflow
The customizable place for Reservation has three sub-workflows Figure (7.2.a): some customer will reserve a flight; some might do the hotel reserving, some might reserve a car or just view the available offers or tours of trips Figure (7.2.b). There are some customers who reserve car, hotel and flight.
CP
View
Hotel Reservation
Car Reservation
Flight Reservation
Figure (7.2.a). Sub-workflows for Reservation
36
View Tour
View Offer
Figure (7.2.b). Sub-workflows for View The customizable place for Payment has two sub-workflows Figure (7.2.c): one can pay using Credit Card Payment, the other can use E-check Payment.
E-Check Payment
Credit Card Payment
Figure (7.2.c). Sub-workflows for Payment
The Reservation Option is a customizable place has three sub-workflows as depicted in Figure (7.2.d): each customer made a reservation can do one of a three available option: Cancel Reservation, manage the booked reservation by choosing the Check Reservation, or do a Complaint.
Check Reservation
Cancel Reservation
Complaint
Figure (7.2.d). Sub-workflows for Reservation Option 33
After the customer do a Reservation and Payment, the Confirm Reservation which has one sub-workflow allows the customer to retrieve all the reservation details of the booked trip as depicted in Figure (7.2.e).
Retrieve Reserve Details
Figure (7.2.e). Sub-workflows for Confirm Reservation In SaaS applications, to provide tenants with understandable customization with constraint dependencies, the customizable workflow in HWTD will be modeled into OVM. The main reasons from using OVM are: decreasing the complexity and the size of the variability models by documenting the variability and not the commonalities in a separate model. Allowing the developer to relate customizations defined in the customization model to other software development models. Communicating variability to the stakeholders is simplified, only the variability model and not design models must be understood by the customers. HWTD can’t express neither the constraint nor the variability dependencies between the variable places ‘VPs’ and its set of allowable variable instances ‘Vs’. In the proposed approach, in OVM, each Variation Point ‘VP’ will be modeled as a Customization Point ‘CP’, and each Variant ‘V’ will be modeled as a Customization variant ‘C’. The purpose from using ‘CP’ and ‘C’ instead of ‘VP’ and ‘V’ is to give developers the ability to express the variations and the customizations in their applications separately. The variations will express all the Variation Points and all its Variants that can be used by the developers while the customizations will define all the Customization Points and all its allowable Customization variants that can be made by tenants in the application 36
that the developer offered to them. Figure (7.3) illustrates the OVM of a customizable workflow for the travel agency application. The customizable places in the previous mentioned workflow are modeled as customization points, and each sub-workflow is modeled as customization variant.
Figure (7.3). OVM of customizable travel agency workflow 36
7.2.2 Mapping OVM to Metagraph The proposed approach mapping the customization model constructed using OVM to Metagraph because of OVM does not provide tools to validate tenant’s customizations. In addition, a suitable way is needed to store each tenant validated customizations in the database which can be done by using the Metagraph tools. All variables of interests in OVM (Customization Points and Customizations) compose the generating set of the Metagraph that models OVM. Thus, all customization points and customization variants in OVM are mapped to vertices in the Metagraph. The variability and constraint dependencies in OVM are mapped to edges, labeled with qualitative attributes, defined on the generating set. Following this mapping procedure, the OVM shown in Figure (7.3) is mapped to the Metagraph as shown in Figure (7.4). In order to use the Metagraph in Figure (7.4) in the provided validation algorithm, a representation of the attributes that are represented visually in the Metagraph is needed. This done by adding each attribute as an additional element to the generating set, and then includes that element in the in-vertex of the edges to which it applies. Applying this procedure to the Metagraph in Figure (7.4), an equivalent Metagraph will be produced in which the qualitative attributes are represented as vertices, but for the simplicity, the Metagraph with the qualitative attributes will be partitioned into four parts: mandatory, optional, requires, and excludes as shown in Figures (7.5).
36
Figure (7.4). Metagraph representation of the OVM in Figure (7.3) 67
Figure (7.5.a). Vertex representation of qualitative attributes for mandatory part
67
Figure (7.5.b). Vertex representation of qualitative attributes for optional part
Figure (7.5.c.i). Vertex representation of qualitative attributes for requires part
67
Figure (7.5.c.ii). Vertex representation of qualitative attributes for requires part
Figure (7.5.c.iii). Vertex representation of qualitative attributes for requires part
66
Figure (7.5.d). Vertex representation of qualitative attributes for excludes part
The cardinality associated with the alternative choices in OVM will be represented as a matrix called the cardinality matrix as shown in Table (7.1). In our approach, this cardinality has been separated into the cardinality matrix to provide a simple Metagraph which in turn produces an uncomplicated matrix.
Table (7.1). The cardinality matrix
e22 e7 e9 e19 e18
Max
Min
1
1
3
3
1
1
3
1
2
1
66
7.2.3 Metagraph Adjacency Matrix To manipulate the Metagraph, in Figure (7.5) in the previous subsection, an adjacency matrix representation of the Metagraph will be constructed. The proposed approach will use the adjacency matrix to store all the valid customizations, and to keep the possible simple paths of different customizations. Table (7.4) shows the adjacency matrix A of the Metagraph in Figure (7.5). In the proposed approach, the matrix will be partitioned into parts for the simplicity. In order to construct the adjacency matrix the X, which contains the available elements and the E which is a set of all edges will be declared as shown in Table (7.2). Each edge in the Metagraph in Figure (7.5) contains invertex and outvertex as depicted in Table (7.3). Table (7.2). The elements and edges of the Metagraph S = < X, E> X = {C, P, RE, RO, CR, V, RRD, TV, OV, CCP, ECP, CRE, HRE, FRE, CORO, CRO, CRRO, CID, CE, CP, CN, O, R, M, E}
E = {e1, e2, e3, e4, e5, e6, e7, e8, e9, e10, e11, e12, e13, e14, e15, e16, e17, e18, e19, e20, e21, e22}
Table (7.3). The invertex and outvertex in the Metagraph e1 = ,
e2 = ,
e3 = ,
e4 = ,
e5 = ,
e6 = ,
e7 = ,
e8 = ,
e9 = ,
e10 = ,
e11 = ,
e12 = ,
e13 = ,
e14 = ,
e15 = ,
e16 = ,
e17 = ,
e18 = ,
e19 = ,
e20 = ,
e21 = ,
e22 =
66
Table (7.4.a). The adjacency matrix of the Metagraph in Figure (7.5) C
P
RE
RO
CR
V
RRD
TV
OV
C
φ
φ
φ
Φ
φ
φ
φ
φ
φ
P
φ
φ
Φ
φ
φ
φ
φ
φ
RE
φ
φ
φ
Φ
φ
φ
φ
φ
RO
φ
φ
φ
φ
φ
φ
φ
φ
φ
CR
φ
φ
φ
φ
φ
φ
φ
V
φ
φ
φ
φ
φ
φ
φ
RRD
φ
φ
φ
φ
φ
φ
φ
φ
φ
TV
φ
φ
φ
φ
φ
φ
φ
φ
φ
OV
φ
φ
φ
φ
φ
φ
φ
φ
φ
CCP
φ
φ
φ
φ
φ
φ
φ
φ
φ
ECP
φ
φ
φ
φ
φ
φ
φ
φ
φ
CRE
φ
φ
φ
φ
φ
φ
φ
φ
φ
HRE
φ
φ
φ
φ
φ
φ
φ
φ
φ
FRE
φ
φ
φ
φ
φ
φ
φ
φ
φ
φ
φ
φ
φ
φ
φ
φ
φ
φ
CRO
φ
φ
φ
φ
φ
φ
φ
φ
CRRO
φ
φ
φ
φ
φ
φ
φ
φ
CID
φ
φ
φ
φ
φ
φ
φ
φ
φ
CE
φ
φ
φ
φ
φ
φ
φ
φ
φ
CP
φ
φ
φ
φ
φ
φ
φ
φ
φ
CN
φ
φ
φ
φ
φ
φ
φ
φ
φ
O
φ
φ
φ
φ
φ
φ
φ
φ
φ
φ
φ
φ
φ
COR O
, R
φ
φ
,
M
φ
φ
φ
φ
φ
φ
φ
E
φ
φ
φ
φ
φ
φ
φ
φ
φ
63
Table (7.4.b). The adjacency matrix of the Metagraph in Figure (7.5) CCP
ECP
CRE
HRE
FRE
C
P
φ
φ
φ
RE
φ
φ
RO
φ
φ
φ
φ
φ
CR
φ
φ
φ
φ
φ
V
φ
φ
φ
φ
φ
RRD
φ
φ
φ
φ
φ
TV
φ
φ
φ
φ
φ
OV
φ
φ
φ
φ
φ
CCP
φ
φ
φ
φ
φ
ECP
φ
φ
φ
φ
φ
CRE
φ
φ
φ
φ
φ
HRE
φ
φ
φ
φ
φ
FRE
φ
φ
φ
φ
φ
COR
φ
φ
φ
φ
φ
CRO
φ
φ
φ
φ
φ
CRR
φ
φ
φ
φ
φ
CID
φ
φ
φ
φ
φ
CE
φ
φ
φ
φ
φ
CP
φ
φ
φ
φ
φ
CN
φ
φ
φ
φ
φ
O
R
φ
M
φ
φ
φ
φ
φ
E
φ
φ
φ
φ
O
O
66
Table (7.4.c). The adjacency matrix of the Metagraph in Figure (7.5) CORO
CRO
CRRO
CID
C
φ
P
φ
φ
φ
φ
RE
φ
φ
φ
RO
CR
φ
φ
φ
φ φ
V
φ
φ
φ
φ
RRD
φ
φ
φ
TV
φ
φ
φ
φ
OV
φ
φ
φ
φ
CCP
φ
φ
φ
φ
ECP
φ
φ
φ
φ
CRE
φ
φ
φ
φ
HRE
φ
φ
φ
φ
FRE
φ
φ
φ
φ
COR O CRO
φ
φ
φ
φ
φ
φ
φ
CRRO
φ
φ
φ
φ
CID
φ
φ
φ
φ
CE
φ
φ
φ
φ
CP
φ
φ
φ
φ
CN
φ
φ
φ
φ
O
φ
R
φ
φ
M
φ
φ
φ
,
