Keywords: Web service, Service reuse, SOA, SBS, Performance, Ontology, Risk, Maturity, Dynamicity, Decision support Web service, Service reuse, SOA, SBS, Performance, Ontology, Risk, Maturity, Dynamicity, Decision support

Reuse of services in supporting new business processes, in addition to alignment of IT with business functions, is a key motivation in using Service-Oriented Architecture (SOA) for developing business solutions. In a service-oriented architecture, it is important to smooth the selection, configuration and composition of existing services to deal with the runtime changes or the evolution of End User requirements. In contrast to other traditional software systems, the dynamic behavior of service-based systems requires up-to-date quality of service (QoS) information for its proper management in the different stages of the lifecycle. Organizations need to know the performance of Web services and business processes to maintain their sustainability for reuse of services. The three key benefits of service reuse are improving agility of solutions by quickly assembling new business processes from existing services to meet changing marketplace needs, reducing cost by not developing new services for enabling similar business functions across multiple business processes, but also spanning service deployment and management in runtime environments throughout the SOA lifecycle. However currently, there are many challenges related to the sustainability and governance of service behavior during its lifecycle. Among those challenges, one can mention level of performance, persistence of the requirements and adaptability of the service. Moreover, there are some limitations of monitoring tools. They lack of anticipation in problem detection, and they are passive and neither reactive nor predictive. This thesis focuses on providing assessment and recommendations for performance and governance of information systems for suggesting service reuse during its evolution. The aim is to maintain sustainability, robustness, adaptability, reusability and evolvability of information systems.

For this purpose, we evaluate the performance of service-oriented architecture. There are several existing monitoring solutions designed to support a specific layer of SOA. Particularly, BAM is a business activity monitoring tool for monitoring the flow of data for business processes. However, BAM monitoring do not provide the performance evaluation for recommending services and processes to reuse. There are very few approaches that support monitoring of SOA layers together. Furthermore, the solutions are partially dynamic with limited decision support. Therefore, we propose performancebased decision support for service-oriented architecture. It consists of four layers as specification, data management, data mining and decision layers. The specification layer identifies the requirements from the End User and process through the proposed ontology. The data layer analyzes technical indicators that are compliant to the latest quality standard, ISO 25010. Quality characteristics are related to performance efficiency, reliability and reusability. The data mining layer generates specific decisions based on service instances by applying the machine learning algorithms. It uses the proposed ontological concepts and semantic inference rules of service, business process, server and integration layers. The data mining layer returns to ontologies with these specific decisions where more refined rules have been generated from new ontological concepts. The decision layer processes these results and generates a global decision in terms of recommendations. It provides multi-viewpoints decision to reuse existing services or suggesting their composition.

To motivate the proposition of this approach, we illustrate the implementation of the proposed algorithms for all the four layers by a business process use case and data set of public repositories of shared services. Validation has been made based on the evaluation of cost, confidence, precision and support. As a result, we recommend reuse of atomic service, composite service and resource allocation provisioning. In this way, we ensure the sustainability, adaptability, reusability and evolvability of service-based systems by handling new business requirements, performance efficiency, reliability in terms of availability, maturity and risk, resource management and dynamicity issues.

Table of Contents

List of Figures

List of Tables

List of Abbreviations

Research Context

Enterprise performance can be improved only by providing reactive and predictive monitoring tools which anticipate in problem detection. It requires advanced approaches for creating more agile, adaptable and sustainable information systems that are able to adapt themselves to new trends.

Service oriented architecture (SOA) is one such approach that has received sig ifi a t attention among information system practitioners. SOA is emerging as a powerful paradigm for organizations that need to integrate their applications within and across organizational boundaries [START_REF] Arsanjani | Service-Oriented Modeling and Architecture[END_REF]. It has to be noted that the advanced organizations are more likely adopting SOA because of its several advantages like loose coupling, modular, non-i t usi e a d sta da d s ased. Web services provide a functionality following web standards such as Simple Object Access Protocol (SOAP) [START_REF]Simple Object Access Protocol (SOAP) 1.2, Part 0, Primer[END_REF], Web Service Description Language (WSDL) [START_REF] Chinnici | Web services description language (wsdl) version 2.0 part 1: Core language[END_REF]. Figure 1 introduces a set of logical layers of the SOA reference architecture [START_REF] Arsanjani | Design an SOA solution using a reference architecture[END_REF]. The five horizontal layers are the main functional layers that describe the functionality of the SOA solution. The four vertical layers define non-functional support that is produced across the functional layers. The five horizontal layers are operational layer, service components layer, services layer, business process layer and consumers layer. Operational layer contains existing software application systems.

This includes customer applications, transaction processing system, legacy system, database and packaged applications and solutions. Service components layer provides software components that are the implementation of services or service operations. Service components reflect the definition of services, both functional and non-functional properties. Services layer contains all the services inside the SOA. A service is defined by its operations. A service specification describes the invocation information about a service and description of the abstract functionality. A service specification may include also a policy document, SOA management description and a document about service dependencies. Business process layer defines compositions and choreographies of services exposed in the service layer. Services are combined or choreographed into flows that create composite services from atomic services. This layer defines the process representation, composition methods, and building blocks for aggregating loosely coupled services as a sequence of processes associated with business goals. Consume s la e provides interfaces that allow the communication between applications. It can also provide the capabilities required to deliver IT functions and data to End User.

The four vertical layers are integration, quality of service, information architecture and governance layers. Integration layer transports service request from a service requester to the service provider. Guidance and policies for making decisions about SOA solution are provided in this layer.

A system following SOA is known as service-based system (SBS). This system is composed of several services. Services are self-contained functional entities with well-defined interfaces that contain their functional and non-functional specifications. Interfaces are of two types: provided to and required from other services. Functional specifications are related to the service operations while non-functional specifications are related to Quality of Service (QoS). One specific type of service is Web service. Web services can be combined as building blocks for the composition of larger SBS s [START_REF] Kyusakov | Integration of Wireless Sensor and Actuator Nodes with IT Infrastructure Using Service-Oriented Architecture[END_REF]. The advances in modern technology and the constantly evolving requirements implied by dynamic business environments imposes new challenges for engineering and provisioning SBS. SBS should be able to operate and evolve in highly dynamic environments to identify and react to various changes or new requirements. Moreover, they require up-to-date QoS information for their proper management at the different lifecycle stages starting from the construction until decommission [START_REF] Wang | An Automatic Self-Adaptation Framework for Service-Based Process Based on Exception Handling[END_REF]. SBS rely on SLA provided by service providers to ensure that the services comply with the agreed QoS [START_REF] Sachan | Qos Aware Formalized Model for Semantic Web Service Selection[END_REF].

QoS is usually structured in the form of a quality model. Quality models are useful for specifying requirements, establishing measures and performing quality evaluations. There exist many proposals of general-purpose quality models for software systems. They differ on the terminology that they use, the set of quality attributes they define, and the structure of the quality model. ISO/IEC series of quality standards, 25010 is the recent quality model as shown in Figure 2 ua titati e easu e e t of the deg ee to hi h a ite possesses a gi e ualit att i ute [START_REF] Omb | Federal Enterprise Architecture Framework (FEAF)[END_REF]. An example of quality metric is the average response time during a time interval. This can be ensured by analyzing the associated risks and providing some mitigation actions against risks. Different notions related to risks exists in the literature such as threats, vulnerabilities, threat probabilities and their impacts on the organization. Threats related to the technical problems are service failure, network failure, loss of service and specification changes. After mitigating the associated risks, system re-establish its stable state and recover the data. This is called recoverability. Maturity is another important quality sub characteristic that affects performance of an enterprise. It is used to evaluate that systems or services are reliable under normal operation. However, it is not widely used in the existing research as quality attribute to evaluate performance. Different maturity models have been proposed to date. Capability maturity model integration (CMMI) [START_REF]CMMI for Development, Version 1.3[END_REF] is most commonly used because of its efficient framework for assessing and providing guidelines. Existing maturity models lack p es ipti e p ope ties to dete i e the le el of atu it f o o e le el to a othe fo "B" s.

Reusability is a very important sub characteristic for SBS to analyze reuse of service or process. Reuse of services helps in achieving business agility to meet changing marketplace needs. It can be achieved by quickly assembling new business processes from existing services and even creating new business processes from existing services [START_REF] Linthicum | Core Value of a SOA is the Ability to Reuse Services? Not a Chance[END_REF]. There is very less concrete data on service reuse in current SOA engagements. Rather, a lot of recent writings have pointed out the challenges in achieving service reuse [START_REF] Chappell | Service Reuse -Fact or Fiction?[END_REF][START_REF] Mckendrick | Pouring cold water on SOA 'reuse' mantra[END_REF].

ISO/IEC 25010 lists quality characteristics but we need to store them with respect to SBS. QoS attributes are stored in ontologies in general. Ontologies are used because of their several advantages.

The first advantage is the modelling and structuring of performance knowledge related to SBS.

Ontologies offer a formal expressive description of concepts and their existing relationships in a coherent way. So, it is important that the stored QoS information is structured, managed and reused in a reliable and standardized manner. The second most important advantage is to infer new knowledge by reasoning on ontologies. Reasoners are used to check the uniformity of ontologies that whether some classes are inadequate, and to manage the order of classes and relations. The third very important advantage is the dynamic nature of ontologies. They have the ability to evolve over time by accumulating new classes, concepts and instances. Ontologies also support the decision by generating decision rules and interacting through queries. Rules are developed using Semantic Web Rule Language (SWRL) [START_REF] W3c | Semantic Web Rules Language[END_REF], and queries are published by using SPARQL [START_REF] Prud'hommeaux | SPARQL query language for RDF[END_REF]. Several ontologies have been proposed to date in order to store Web service properties, both functional and non-functional.

However, to our knowledge, no complete QoS ontology exists. Existing QoS ontologies are neither formulated to infer new knowledge nor evolve with the evolution of service life cycle. Yet, service life cycle evolves at run time with changed or new business requirements.

Monitoring all component services and processes constantly and inspecting the entire SBS during runtime is difficult due to excessive resource and time consumption required, especially in large-scale scenarios [START_REF] Bucchiarone | Design for Adaptation of Service-Based Applications: Main Issues and Requirements[END_REF]. SOA has been extended with Oracle fusion middleware to provide more technological solutions, and to that end monitor component plays an important role to monitor performance of SBS, as shown in Figure 3 [START_REF]Using Services Oriented Architecture to Extend JD Edwards EnterpriseOne[END_REF]. Gateway is a set of modules that encompasses Web service interfaces to allow routing, transformation and security. Orchestrate deals with composite applications and orchestration of business process. Interact and access provides a common interface for multiple dissimilar applications. Monitor and optimize provides access to critical business performance indicators in real time. The most commonly used toolsets for monitoring applications and serviceoriented networks are Java Management Extensions (JMX) [START_REF]Sun Microsystems, version 1.4[END_REF]. JMX is a Java technology that supplies tools for managing and monitoring applications, system objects, devices and service-oriented networks while Business Activity Monitoring (BAM) [START_REF] Defee | Business Activity Monitoring and Simulation[END_REF] is widely used to monitor business activity.

BAM tools allow managers to monitor the status of their business processes and the global business, all from the same point. It is a toolset that allows the monitoring of Key Performance Indicators (KPI).

The indicators that BAM tools monitor are mainly related to the payload such as real time tracking of number of transactions, number of process events, number of changes in records, and velocities.

However, there is a need of maximizing QoS by providing more key performance indicators such as time behavior, resource utilization, capacity, availability, maturity, reusability and risk. Evolution of these indicators in the form of quantitative and qualitative with time dimension along SOA layers is very important to measure in order to ensure the sustainability of information system. As stated previously, QoS represents the non-functional properties of a Web service. Along with QoS, se i es eputatio , se i e p o ide s i fo atio a d se i e s a essi g i fo atio a e also ofunctional properties of a Web service. The functional properties of a Web service define its operations that are specified by input and output parameters [START_REF] Lee | Qos for Web services: Requirements and possible approaches[END_REF]. QoS can be integrated in the Web service descriptions. Web services can be syntactically described by using Web service description languages such as WSDL. WSDL allows syntactic matching when searching for Web services [START_REF] Oh | Algorithms for Web services Discovery and Composition Based on Syntactic and Semantic Service Descriptions[END_REF].

In order to create information systems-based solutions for respective business needs, The Open Group Architecture Framework (TOGAF) provides a well-defined set of guidelines [START_REF]TOGAF® Version 9.1[END_REF]. TOGAF is shown in Advances in computer technology are dynamic, and they impact information system applications including Decision support systems (DSS) [START_REF] Laskey | Decision Making and Decision Support[END_REF]. Any application that involves decision making in any mode, is often named as a DSS. The consequence is a set of DSS applications that is dynamic and constantly evolving. This phenomena highlights that information systems will evolve accordingly into various directions. The dynamic nature of information systems makes it difficult for information practitioners and other managers to provide a stable set of DSS applications. However, the selection of DSS applications plays an important role in forecasting organizational policies for the deployment of information technology. Most common DSS applications are artificial intelligence, machine learning, and business intelligence. "e e al D"" s ha e ee p oposed to date o e i g diffe e t domains.

However, no DSS has been provided to cover the performance of SBS and evolving nature of service lifecycle.

In order to provide efficient DSS applications, data mining concepts play an important role. The key perspective of data mining is to extract useful information from the data [START_REF] Han | Data Mining Concepts and Techniques[END_REF]. Data mining involves six common classes of tasks such as anomaly detection, association rule learning, clustering, classification, regression and summarization. In terms of data analytics, machine learning is a method used to create complex models and algorithms that impart themselves to prediction. Machine learning is also combined with data mining and it is called as unsupervised learning. In machine The definition of a more comprehensive and holistic approach is crucial for delivering high performance, robust, reusable, and highly adaptable SBSs [START_REF] Mirandola | Adaptation Space Exploration for Service-Oriented Applications[END_REF]. Moreover, no decision mechanism for handling new or changing business requirements, anticipating problem detection and suggesting reuse of service or process have been provided so far.

Research Objective

With reference to the above context, this research aims to create a support system for accelerating monitoring of Web services and decision making for their reuse. Developers usually prefer to develop new Web services for answering End User requirements. The End User requirements here refer to new requirements and modified requirements. In addition, developing new Web services costs money and time. Therefore, reusing available Web services is a better solution for developers than to create new Web services.

Our objective is to provide assessment and recommendations for service reuse during the evolution of the service while preserving acceptable performance and conforming governance rules. For this purpose, we aim to provide dynamic decision support for SBSs while considering the performance of service, business process and integration layers of SOA. In this way, we will be able to ensure sustainability, evolvability, reusability and adaptability of SBS. The End User of the system are the business organizations that are motivated to SOA concepts.

Scientific Problems

I o de to a hie e the a o e stated o je ti e, the e a e se e al halle ges. Toda s soft a e s ste s are becoming increasingly integrated into the lives of their End Users and their ever-changing environments and needs. These demands lead to a growing complexity of systems. The development of adaptive systems is a promising way to manage this complexity. Adaptive systems are able to adapt their behavior at run time while considering the changing operational environment to maximize the satisfaction of End User needs.

It is difficult to compose dynamically performance based technical indicators at the different SOA layers to ensure information system sustainability. There is a lack of performance management in terms of its evolution for both quantitative and qualitative level indicators with time dimension along SOA layers. Along with that, there is no guidance for management of service or process reuse, handling changing or new business requirements and effective resource utilization. Moreover, estimation of the impact of new consumption of services and handling governance problems are still remained as challenges.

Research Problem

Provide efficient decision support for information system evolution in terms of service reuse with acceptable performance level while conforming to system governance rules. The main issue consists of how to manage dynamically performance, risk and maturity of SOA layers to ensure sustainability of information systems. The above-mentioned research problem leads to the following research questions to guarantee efficient performance based decision support for service reuse:

RQ1. Are technical indicators compliant with new quality standards?

RQ2. How to evaluate the impact of increased consumption of services on performance?

RQ3. How to incorporate changing or new End User requirements with the evolution of service life Cycle?

RQ4. How to handle resource demands of the system at different workloads?

RQ5. How to provide efficient performance-based decision support for service reuse?

Justification

As very little work has been done particularly for monitoring of performance of SOA layers with respect to the latest quality model, it is important to monitor and examine performance of SOA layers in terms of latest quality characteristics. Another important aspect is that existing works do not evaluate the impact of increased consumption on performance measurement over different time stamps. This leads to monitor and examine performance over different time stamps by adding or consuming more data.

There is very less concrete data on service reuse in current SOA engagements. Rather, a lot of recent writings have just pointed out the challenges in achieving service reuse.

Contributions

The main contribution of this research is to provide performance management, maturity evaluation, risk mitigation actions and reusability of services. Reuse of services in supporting new business processes, in addition to alignment of information technology with business functions, is a key motivation in using SOA for developing business solutions. Based on the current research challenges for service reuse, we highlight the contributions for the research gaps highlighted in part 1.5. The major contribution is to provide assessment and recommendations for service reuse during its evolution while preserving acceptable performance, maturity and risk levels. We present the list of contributions hereafter:

C1: Maximizing performance of SBSs by adding new quality characteristics with reference to latest quality standards.

• Performance Efficiency C8: Definition of a case study where performance-based decision support system is applied to validate and measure whether it can be reasonable for the suggesting service reuse.

Organization of Chapters

This thesis document consists of 5 chapters. After the introduction in Chapter

CHAPTER 2. Service Reuse and

Performance based Solutions

In this chapter, we present the works that are relevant to our research. We focus on four areas namely service-based reuse solutions, service performance, performance-based service structuring and performance-based service reasoning.

In the first area, we analyze various solutions that exist in the literature for service reuse. Service reuse is about reusing atomic services as a component of composite services. Composite services can in turn be reuse in larger service compositions. The management of service reuse can rely on technical indicators. SOA governance also intend to manage service reuse.

In the second area, we analyze performance-oriented solutions for SBS. Performance oriented solutions for SBS include qualitative and quantitative perspectives of performance monitoring.

Quantitative analysis deals with performance management while qualitative analysis is related to risk management and maturity models.

In the third area, we analyze literature related to performance service structuring in terms of both service domain and QoS. Services and QoS have mainly been structured under the form of ontologies.

Last area of research is related to service reasoning. Service reasoning helps to provide efficient decisions. For this purpose, we analyze existing decision support systems that help to provide effective decisions for SBS. While analyzing existing support systems, we also provide data mining algorithms that play an important role to provide efficient decisions.

The above-mentioned research areas triggered an important body of research. Consequently, we followed a thorough methodology to retrieve and analyze the related works. We hence start this chapter by the analytic methodology. We then present the state of the art related to various existing solutions for service reuse, performance-oriented solutions for SBS, service structuring, and finally service reasoning. We conclude the chapter by a discussion.

Analytic Methodology

The analytic methodology consists of two steps. The two steps are systematic analysis and research classification. In the systematic analysis step, we provide an analytic approach to retrieve papers systematically. The analytic approach that we follow is a systematic mapping study. In the research methodology step, we classify related work based on different areas of work retrieved from the systematic analysis step.

Systematic Analysis

Systematic mapping study is a method that has initially been used in classification of medicines.

Recently, it has also been applied in software engineering field. The systematic mapping study allows to show the frequency of publication, to determine the scope in the certain field, and to combine the results in answering the research questions. There are five steps in systematic mapping study including defining the research question, searching the relevant papers, filtering the papers based on the abstract, and mapping the data extraction. The review is carried out using Scopus, Web of Science and ISI Web of knowledge with different search criteria. Our first search criterion is service performance.

For that, we extracted 3103 research papers from year 2004 to 2018. We selected 2842 papers relevant to computer science domain in the second analysis. 994 papers related to SOA have been selected in the third analysis. The fourth analysis resulted in 486 papers based on Web services. The fifth analysis included 97 papers related to monitoring of Web services. We eliminated papers published before year 2010 which resulted in 28 papers in the final analysis. We categorized these papers based on performance management. The second search criterion is service reuse. For that, we extracted 711 research papers from year 1991 to 2018. Most of the papers under this category is not related to service-based systems but rather focus on computer networks or some other domains like water and energy consumption. Therefore, we selected papers that are relevant to service-based systems that results in 16 papers. The fourth search criterion is service performance-based decision support. For that, we extracted 103 research papers from year 2000 to 2018. We select 10 papers that are relevant to service-based reasoning.

Research Classification

The results of the systematic analysis provide a systematic structure allowing to build research

Service Reuse Solutions

The concept of reusability has been used along various axes. We focus here on reusability in software development life cycle (SDLC), Service life cycle and SOA governance.

perform evaluation based on the feedback of service consumers and provide an analysis report.

Doultsinoua et al. [START_REF] Doultsinou | Developing a Service Knowledge Reuse Framework for Engineering Design[END_REF] provide a procedure for selecting requirements and mapping with service reuse from existing repository of services for product-service systems. The authors describe the service issues and service knowledge that has an impact on product design. Lee et al [START_REF] Lee | Feature-oriented approach for developing reusable product line assets of service-based systems[END_REF] provide a featureoriented approach, to analyze and identify reusable services. Feature analysis and modeling are employed to identify and group units of features to provide services at the right level of granularity in a SBS. Ahmed-Kristensen and Vianello [START_REF] Ahmed-Kristensen | A model for reusing service knowledge based on an empirical case[END_REF] propose reuse service knowledge (RSK) model based upon the findings and the understanding from a general framework for developing a knowledge management strategy. The RSK model was developed based on a case study from a customized industry. The authors describe a case study from the oil industry investigating the transfer of knowledge within the service phase and also between the service and design phases. Allen et al. [START_REF] Allen | A user-centric approach to dynamic adaptation of reusable communication services[END_REF] provide a detailed description of the behavior of the network communication broker. The authors propose a method that incorporates smart reusable integration, automation and End User controllability. This work influences the convergence of services and providers to the End User the required services.

In order to provide effective decisions in the perspective of the lifecycle of service components, services and business processes, SOA governance plays an important role. In the next coming part 2.2.3, we analyze papers that focus on governance for service reuse.

SOA Governance

In order to promote service reuse and to create business agility, SOA governance mechanisms have been proposed. In this context, the Open Group [START_REF]SOA Governance Framework[END_REF] proposes a governance model. This model consists of two categories of processes that are governance processes and governed processes. The authors divide governed processes into four parts. These parts include the management of service portfolio, service lifecycle, solution portfolio and solution lifecycle. Niemann et al. [START_REF] Janiesch | Towards a service governance framework for the internet of services[END_REF] propose SOA governance model. This model is composed of five main building blocks. These building blocks are organizational governance entities, governance policies, best practices catalog, compliance observation and SOA maturity measurement. Filho and Azevedo [START_REF] Filho | CommonGOV: A consolidate approach for governance of service-oriented architecture[END_REF] extends Niemann s governance model and propose an approach named as a common governance (CommonGov) model for SOA.

CommonGov consists of four groups that are strategy, compliance, execution and support. The purpose of these groups is to ensure governance at their respective levels. highlight advantages and challenges of reuse of services. The purpose of this research is to apply different practices of SOA governance to address facets like terminology, service discovery, creation, and service entitlement. This paper discusses the importance and challenges of reuse in SOA. The authors define three key benefits of service reuse such as improving agility of solutions, reducing costs, and reducing risks. In this survey, they list the properties or fundamentals of governance used in the surveyed companies. Kim et al. [START_REF] Kim | A Decision Model for Optimizing the Service Portfolio in SOA Governance[END_REF] propose a decision model to evaluate the services based on prioritization mechanism. This approach identifies optimum service portfolio after making prioritization. The model considers prioritization of technical feasibility, business needs, development and maintenance cost. This model decides about the potentially realizable services based on the priority of each company.

Summary

Reuse has gained much attention and has been considered very important in the IT industry. Initially, reusing code and runtime components came into existence. As the IT industry evolves with new architectures and technologies, SOA emerged with the key benefit of runtime reuse. SOA promotes reuse of atomic services as composite services and reuse of composite services in composition of larger business processes. From the analysis of SOA governance approaches, we conclude that two areas are important to promote service reuse. These two areas are service compliance or policy and service performance measurement or monitoring. For this purpose, service portfolio can be enhanced. It is i po ta t to alig pe fo a e et i s ith usi ess goals su h as i ease i fle i ilit a d edu tio of business process costs. However, it is important to note that SOA governance varies according to the size and function of the organization. Existing metrics have not been pragmatically validated. It is required to suggest reuse of services that are efficient in terms of performance and are compliant with governance policies.

Service Performance

Web services can be monitored automatically or semi automatically at both atomic and composite level. They can also be monitored at any phase of service life cycle. Monitoring quality involves evaluating current performance based on some standards or expected level of performance. Service performance can be measured at both quantitative and qualitative levels. We explain the quantitative and qualitative service performance evaluation below.

Quantitative

As mentioned in the introduction chapter, ISO 25010 proposes quality characteristics. These quality characteristics are measured by quantitative indicators. In this thesis, we focus on performance

A. Performance Monitoring

Services are directly involved at the service, business process and integration layers of SOA, therefore performance can be monitored at these three layers. Performance of service can be analyzed based on quality characteristics such as performance efficiency and reliability. These invocations per second. In this paper, the dynamicity and real-time constraints of QoS is not analyzed.

Garcia Valls et al [START_REF] Garcia-Valls | iLAND: An Enhanced Middleware for Real-Time Reconfiguration of Service Oriented Distributed Real-Time Systems[END_REF] propose iLAND as a service-oriented approach for timely reconfiguration of realtime systems. Monitoring of time, network bandwidth and power consumption is performed in this paper. In this paper, the authors provide a virtualized infrastructure where service-based applications can execute. Asadollah and Thiam [START_REF] Asadollah | Web service Response Time Monitoring: Architecture and Vaidation[END_REF] propose monitoring of Web services. For this purpose, they propose a method to calculate the response time of Web services by using a proxy that is connected to the requested services. The authors have validated their approach by three tests for three different response time and the cost value. Moreover, ProAdapt is dynamic and automated. Fan [START_REF] Fan | A Decision-Making Method for Personalized Composite Service[END_REF] proposes an approach to measure computation cost and CPU time. The author uses particle swarm optimization algorithms for approximating execution plans of composite services. He performs experiments to monitor computation cost and CPU time on 30 tasks and 50 services. Sheng et al [START_REF] Sheng | Web services Composition: A Decades Overview[END_REF] provide a survey of Web service composition and Web service technologies. They evaluate service composition platforms on the basis of some parameters. These parameters include ease-of-use, simulation, adaptability, optimization, security, administration and monitoring. The authors found that many of the proposed automatic composition systems are unable to adapt to dynamic environments.

Integration layer mainly deals with the communication mechanisms. Messages are exchanged through SOAP, HTTP, TCP/IP protocols. Messaging through SOAP provides the ability to perform the necessary message transformation to connect the service requestor to the service provider and to publish and subscribe messages and events asynchronously. The following research for integration layer focuses only on response time, network load (bandwidth) and throughput. Tari et al. [START_REF] Tari | Benchmarking Soap Binding. On the Performance of Web services[END_REF] provide a benchmark of different SOAP bindings in wireless environments. The experimental results show that UDP binding has the lower overhead which results in a reduction in the response time and an increase in the total throughput. Then Tari et al. [START_REF] Tari | The Use of Similarity & Multicast Protocols to Improve performance[END_REF] propose a similarity-based SOAP multicast protocol (SMP) which reduces the network load by reducing the total generated traffic size. In the next paper, Tari et al. [START_REF] Tari | Network Traffic Optimization. On the Performance of Web services[END_REF] propose a tc-SMP technique as an extension of SMP providing the performance improvement of tc-SMP of about 30% higher network traffic reduction than SMP at a small expense of up to 10% rise in the response time. Yoon et al. [START_REF] Yoon | QoS Optimizer[END_REF] propose a mechanism to identify a suitable QoS combination for a specific system or a communication environment. However, it is difficult to find optimal QoS combination and their values for a certain system or service amongst many combinations.

B. Summary

We define parameters to perform a systematic analysis of the above-mentioned research papers. For each paper, we provide an overview of the content. We resume the approach taken by the authors and list the performance based technical indicators used in these papers. We mention if the approach is dynamic and using real time data or not. We also mention the number of services used while performing tests. We highlight the use of a decision support. For each paper, we make categorization as service, business process, integration and server level. Comparison of the existing papers based on these parameters is shown in Table 1 and Table 2. We observe that the existing approaches do not cover all the layers of SOA discussed in Chapter 1. Moreover, these approaches do not provide the decisional aspect for SBS in order to cover the service reuse capability, managing of resources and suggesting service compositions. Approaches are primarily static in nature, which makes them unsuitable for assuring runtime and emerging system qualities. Distribution of the quality models along the time dimension and the identification of their relationships are missing. There is a need to maximize performance by adding more performance based technical indicators for SOA layers. Existing approaches are not adaptable to new or changed business requirement. We will investigate the definition and structure of the performance based technical indicators of service-oriented architecture from latest release of ISO/IEC. We will develop and deploy services in WSO2 and oracle server to monitor the behavior of services with respect to selected performance based technical indicators.

Along with that we will create a performance profile of quantitative and qualitative technical indicators with time dimension along SOA layers. To make the whole process dynamic, we will use ontologies as a modelling paradigm and propose a decision support algorithm. We will recommend service reuse based on the performance evaluation of several Web services.

Qualitative

Performance of a service can also be analyzed based on qualitative characteristics. Qualitative characteristics proposed by ISO 25010 are explained in the introduction section. The following research focuses on reliability characteristics of ISO 25010. Reliability is measured based on maturity and risk management.

A. Maturity Models

A maturity model is a way to assess and improve business processes constantly. It describes the typical patterns in the evolutionary process of technology and business development of an enterprise [START_REF] Solli-Saether | The modeling process for stage models[END_REF]. It is used to rate the capabilities of maturity elements and to select the processes for improving their maturity [START_REF] Kohlegger | Results of a structured content analysis[END_REF]. Maturity models are widely applied in the field of information systems as a means of benchmarking and as an approach for continuous improvement [START_REF] Mettler | Towards a classification of maturity models in information systems[END_REF]. ISO/IEC 15504 [START_REF]Software Engineering-Process Assessment. Part 2: Performing an assessment[END_REF] uses (ISO/IEC 12207) [START_REF]Systems and Software Engineering -Software Life Cycle Processes[END_REF] to identify process capability for process improvement. It acts as a base in conducting an assessment for process definitions. ISO/IEC 15504 [START_REF]Information Technology -Process Assessment. Part 1: Concepts and vocabulary[END_REF] defi es p o ess assess e t as the s ste ati e aluatio of a o ga izatio s p o esses agai st a p o ess efe e e odel . 'ögli ge et al. [START_REF] Röglinger | Maturity models in business process management[END_REF] provide an analysis of a set of BPMMs. They provide an exhaustive analysis of ten BPMMs with respect to general design principles. These models adequately address the principles for a descriptive purpose of maturity model use. BPM-CF [START_REF] De-Bruin | An organizational approach to BPM: the experience of an Australian Transport Provider[END_REF] develops a holistic BPM maturity model. It facilitates the assessment of BPM proficiencies. It has five maturity stages. BPMM-OMG [START_REF]Object Management Group-OMG, Business Process Maturity Model (BPMM)[END_REF] and vPMM [START_REF] Lee | vPMM: A Value Based Process Maturity Model[END_REF] provide a maturity model and the assessment model. BPMM-OMG has five maturity levels and defines process areas at each level. This work refers to models that are publicly available. PMMA [START_REF] Rohloff | PMMA Process Management Maturity Assessment[END_REF] provides a holistic evaluation of all areas relevant to BPM based on a complete set of criteria. The authors provide a five steps model as an indicator for process maturity. This model corresponds to the implementation topics of the business process management. BPMM-OMG [START_REF] Krivograd | Development of an Intelligent Maturity Model-Tool for Business Process Management[END_REF] defines an intelligent maturity model tool. The Capability Maturity Model Integration (CMMI) models are the most well-known generic maturity models. The CMMI Product Suite has three different models. These models are CMMI-DEV, CMMI-SVC, and CMMI-ACQ for development, services, and acquisition, respectively [START_REF] Stall | Using CMMI-DEV and CMMI-SVC together where build stuff happens in CMMI-SVC[END_REF]. These models provide the essential elements that describe the characteristics of effective processes [START_REF]Cmmi for development, version 1[END_REF].

The CMMI-DEV model is used to assess and improve the software engineering processes of an enterprise that develop a product, whereas CMMI-SVC model is used to assess and improve the management of service delivery. CMMI models have two representations, staged and continuous.

SCAMPI [START_REF] Scampi Team | Standard CMMI Appraisal Method for Process Improvement (SCAMPI)[END_REF] is a standard CMMI appraisal method for process improvement. It is a process assessment method to identify maturity level of a software organization. It evaluates compliance with CMMI models. Hi s hhei s et al. [START_REF] Hirschheim | Service-oriented architecture: Myths, realities, and a maturity model[END_REF] publish a study report. The authors analyze SOA aspects from the perspectives of different stakeholders a d p opose Welke s "OAMM to oversee the enterprise SOA adoption. IBM provide Service Integration Maturity Model (SIMM) [START_REF] Arsanjani | The service integration maturity model: achieving flexibility in the transformation to SOA[END_REF]. SIMM focuses on the maturity of services and their integration. This model has a method dimension that discusses the maturity characteristics of service development methodologies at different levels. Later, it has been adopted by the Open Group [START_REF]OSIMM Version 2 Technical Standard[END_REF]. Hensle and Deb of Oracle Corporation [START_REF] Hensle | SOA maturity model-guiding and accelerating SOA success[END_REF] highlight SOAMM as a guide to accelerate the enterprise SOA adoption. This work describes a road map based on Oracle SOAMM. It does not provide any guidance on the methods being followed for service system engineering. Baghdadi [START_REF] Baghdadi | SOA maturity models: guidance to realize SOA[END_REF] proposes the SOA maturity framework to guide the SOA adoption process.

The author analyzes four SOAMMs, compare them with CMMI-SVC and proposes a maturity framework. This work is limited to the framework and can be further extended by providing methods for SOA adoption including models and tools. There are several SOAMM contributed by both academia and industry such as IBM SIMM/OSIMM, HP SOAMM [START_REF] Pugsley | Assessing your SOA program[END_REF], Oracle SOAMM, iSOAMM [START_REF] Rathfelder | iSOAMM: an independent SOA maturity model[END_REF], and Welke s In the following part, we explain research related to the mapping of CMMI process areas and SOAMM dimensions. For this purpose, Pulparambil et al [START_REF] Pulparambil | A comparison framework for SOA maturity models[END_REF] propose a set of overlapping categories between CMMI and SOAMM. Ho e e , the a e usi g a diffe e t ite io to defi e the atu it le el. Most of the SOAMMs adopted the same terminologies and levels of CMMI models. The authors highlight the commonalities between CMMI process areas and SOAMM dimensions as we can see in Figure 7. The assess e t a eas a e oadl lassified into five categories. In contrast to CMMI models, SOAMMs bring the architecture view and the business involvement under the scope of maturity assessment.

The service establishment and delivery, support, and work management are common to both the models. In addition to these common process areas/dimensions, there are some sets of dimensions that are unique to SOAMMs to focus on different aspects of enterprise SOA adoption. The authors define building blocks for the five levels of maturity. They are graphically represented in

B. Risk Management

Risk management plays an important role for addressing the issues of threats. There exist diverse lassifi atio s of these threats [START_REF]Nist special publication[END_REF][START_REF]IT-Grundschutz Manual[END_REF][START_REF]information technology -security techniques -management of information and communications technology security -part 1: Concepts and models for information and communications technology security management[END_REF] ranging from accidents to natural catastrophes and to deliberate acts. In the past years, risk management also highlights incident, disaster recovery and business continuity management [START_REF]British standard bs25999-1:2006: Business continuity management -part 1: Code of practice[END_REF][START_REF]British standard bs25999-2:2007: Business continuity management -part 2: Specification[END_REF][START_REF]2008 information technology -security techniques -guidelines for information and communications technology disaster recovery services[END_REF][START_REF]Business and it continuity overview and implementation principles[END_REF] along with threats. Over the last years, s ie tifi community increased its research efforts for highlighting the importance of business risks. In order to do so, several research papers as mentioned below highlights business process risk analysis, business process risk management and business process compliance risk.

The application of existing business process risk analysis techniques is an important area. However, the number of existing methods that endeavor to apply existing business process risk analysis techniques is low. CORAS [START_REF] Braber | Modelbased security analysis in seven steps-a guided tour to the coras method[END_REF] is a method for conducting security risk analysis. CORAS provides a customized language for threat and risk modeling. It provides guidelines to capture and model relevant information during the various stages of the security analysis. The CORAS approach includes seven steps that are introductory meeting, high-level analysis, approval, risk ide tifi atio , risk estimation, risk evaluation and risk treatment. Jallow et al. [START_REF] Jallow | Operational risk analysis in business processes[END_REF] propose a framework for risk analysis in business processes. The framework consists of the steps that model the activities of the business process as identify risk factors and probability of occurrence and effect. The authors provide a prototypical framework implementation by using Microsoft Excel. The framework consists of the following six steps such as model the activities, determine dimensions, identify risk factors, impact of risks, cal ulate ea h ide tified isk and calculate forecasts for each activity. There are several research results regarding the integration of risk aspects and security requirements into business process analyses.

Sackmann [START_REF] Sackmann | A reference model for process-oriented it risk management[END_REF] proposes a model as IT risk reference model for business process-oriented view. This model builds the bridge between the economic and more technical layers including vulnerabilities.

The author defines the relations between causes of IT risks and their effects on business processes or a co pa s etu s. Sackmann [START_REF] Sackmann | Selecting services in business process execution -a risk-based approach[END_REF] extends his work and expresses these relations in a matrix-based description. This model consists of four interconnected layers that are business process layer, IT applications or IT infrastructure layer, vulnerabilities layer and threats layer. Zur Muehlen and

Rosemann [START_REF] Muehlen | Integrating risks in business process models[END_REF] propose an approach to tackle the topic of risk management in the context of business process management. Additionally, they propose a taxonomy for business pro esses that i ludes fi e clusters such as goals, structure, information technology, data and organization. They propose two distinguished lifecycles such as build-time and run-time, and provide the lassifi atio of oth, e o s and risks.

Sadiq et al. [START_REF] Sadiq | Modelling control objectives for business process compliance[END_REF] propose a method for business process compliance. They highlight the dependency and interconnection between business and control objectives. They handle the modelling of control objectives along with their transmission onto business process models. Weber et al. [START_REF] Weber | Approximate compliance checking for annotated process models[END_REF] describe a method for validating whether the states reached by a process are compliant with a set of constraints.

This will check the compliance of a new or altered process against the constraints base, and the whole process repository against a changed constraints base. The authors formalize a knowledge base that consists of compliance rules and annotated process models respectively. Jakoubi et al. [START_REF] Jakoubi | Risk-aware business process management-establishing the link between business and security[END_REF] propose a method as risk-oriented process evaluation (ROPE). They represent risk elements by the help of graphical notations. The elements of risks include threats, resources, counter measures, and recovery actions for business process activity. Based on the ROPE methodology, Tjoa et al. [START_REF] Tjoa | A formal approach enabling risk-aware business process modeling and simulation[END_REF] and Suriadi et al. [START_REF] Suriadi | Current research in riskaware business process management -overview, comparison, and gap analysis[END_REF] propose a reference model for risk-aware evaluation. Milanovic et al.

[100] present a method for demonstrating availability related to services, underlying ICT infrastructure and human resources.

They use a fault model of two failure modes as temporal and value. The authors provide an analytical assessment method that follows seven steps such as defi e usi ess p o ess, refi e a ti ities, create an infrastructure graph, map services to infrastructure components, map business processes to atomic services, transform the Boolean expressions into reliability block diagrams or fault trees and calculate the availability of business process and services.

C. Summary

The existing literature based on maturity presents a conceptual framework of methodical building blocks at different levels of maturity. There is a lack of prescriptive properties as a guiding approach.

The existing models are generic maturity models for business processes with different viewpoints. It is required to construct methods based on the conceptual framework and provide prescriptive properties in order to guide the evolution from current maturity level i to next maturity level i+1 for "B" s. We aim to fill this gap by proposing methods to measure the level of maturity and we will provide a prescriptive guiding approach to evaluate the evolution from one maturity level to another.

The existing literature is based on risk analysis and risk-aware phases of process modelling. Types of risks with respect to SBS have not been mentioned in the above studied research papers. Along with that, impact of risk is also missing. There is also a lack of prescriptive properties in terms of mitigation actions for risks. Moreover, none of the above-mentioned app oa hes spe ifies d a i allo atio of resources with respect to risk. We can provide for example, in-depth consideration of service level management threats. There is a need of formalizing risk constructs in the form of semantics. We will identify types of risks related to SBS and formulate the impact of these types of risks on SBS. We will also propose mitigation actions for the identified risks and their impacts. As a result of these mitigation actions, we will recommend dynamic allocation of resources.

Performance based Service

Structuring

In order to structure the services and quality of services, ontologies have been widely used for the

Ontologies

As explained in the introduction, QoS is a non-functional property of a service. In this part, we provide the analysis of various QoS ontologies that exist in the literature. Giallonardo for new or changed End User requirements. Moreover, QoS ontologies do not evolve with time. Since several QoS information is stored in the above-mentioned literature, there is need of composite semantic ontology. This analysis will help to create a composite or complete QoS ontology.

Performance based Service

Reasoning

Performance based service reasoning can be performed by providing efficient decision support systems. A variety of decision support tools has emerged during the last decade to provide more systematic reasoning in different domains. With the passage of time, decision support systems are integrated with advanced concepts such as data mining.

Decision Support Systems

The Analytic Hierarchy Process (AHP) is a Multi Attribute Decision Making (MADM) method developed by Saaty [112] Data Envelopment Analysis (DEA) is a mathematical programming-based approach that is used to measure the relative efficiency of decision-making units which may have multiple inputs and outputs [119]. The main aim of DEA is to provide benchmarking guidelines for inefficient decision-making units.

For such inefficient decision-making units, DEA identifies efficiency units, namely the reference set.

The latter constitutes its benchmark, since it provides the necessary information on how much the unit needs to be enhanced to be considered efficient [120]. Ho et al. [121] review the literature of the multicriteria decision making approaches for supplier evaluation and selection. They analyze related articles appearing in international journals. This research provides evidence that the multi-criteria decision making approaches are better than the traditional cost-based approach.

Summary

There is no decision support for handling new End User requirements and reuse of services and processes. There is a lack of approach that provides decisions based on performance evaluations of one service instance as well as for the consumption of large number of services. Governance is also not used to make effective decision for service reuse.

Discussion

In this chapter, we analysed existing research works that are extracted from a systematic analysis.

Based on the systematic analysis of existing research, we classified the research areas. We discussed each area of research identified in research classification and analysed them. These areas of research are broadly categorized as performance-based service reuse solutions. First area of research is service reuse. We analysed different dimensions of service reuse such as software reuse, SOA governance and service reuse. Second area of research is service performance approaches at quantitative and qualitative level. Quantitative level is analysed by evaluating existing performance monitoring techniques while qualitative analysis includes the evaluation of maturity models and risk management.

We evaluated these approaches based on the performance based technical indicators. Third area of research is performance-based service structuring. This research area is important as service performance must be modelled to make efficient use of it. For this purpose, we analysed existing ontologies that are based on QoS or performance level technical indicators. Fourth area of research is performance-based service reasoning. In this area, we analysed existing decision support systems to provide efficient decisions in terms of services.

The mechanism for maximizing service reuse in the context of highly distributed SOA based applications with services developed by autonomous services providers is not fully understood at present. Reusability is regarded as a key concept in the existing work. However, the definition of formal technical indicator that can directly be used within typical SOA based modeling language is still missing.

The operation unit of traditional service composition is atomic service, and existing works seldom consider the reuse of service or process in any granularity.

From the above analysis, we propose following research directions.

o Reuse of services in terms of performance and are compliant with governance policies.

o Enhancing service portfolio in terms of performance monitoring and service policies.

o Distribution of the quality models along the time dimension.

o Maximizing performance by adding more technical indicators.

o Adaptation of new or changed business requirement.

o Evaluation of the service evolution from one maturity level to another.

o Formalization of risk constructs in the form of semantics.

o Creation of a composite and complete ontology that can evolve with time.

o Efficient decision support for the increased consumption.

CHAPTER 3. Performance Oriented Decision Support

From the state-of-the-art on performance-based service reuse solutions, we analyzed that currently complete performance based technical indicators definition that is compliant with latest international standards is still missing in service portfolio. Moreover, the perspective of new or changing business needs with time dimension is not addressed. In addition, no decision support has been provided for determining performance trends based on technical indicators with time dimension and increased consumption. Therefore, efficient decision support for reuse of atomic services or composite services in terms of performance and resource utilization remains a big challenge. This analysis highlighted the need of fully automatic performance-based methodology for service reuse in the dynamic SOA based organization, where efficient decisions are required to be made on-the-fly. Our goal is to ensure adaptability, reusability, evolvability, agility, dynamicity and sustainability of SOA based information system.

For this purpose, we propose PODSF. PODSF maximizes service portfolio in terms of performance profile and is compliant with latest quality standards. In addition, PODSF is aided with ontology structuring and reasoning to achieve the dynamic evolution of business needs while considering time dimension. Data mining algorithms of classification and machine learning have been effectively utilized to provide efficient decision support for performance-based service reuse.

Before explaining PODSF, we show its position in an SOA based organization in Figure 11. In this figure, we highlight the interaction of SBS actors and the flow of the information from one actor to another under the form of inputs and outputs. The actors are End User, ServiceRepository, ServiceOwner and IT Department. First of all, the End User will request to use a service. If the service is available in the ServiceRepository, then the service is provided to the End User along with SLA, otherwise IT Department will start the process of developing a new service. If the service has some performance degradations, then there is a need of performance evaluation. In this scenario, PODSF is required to provide performance assessment report and recommendations. PODSF can be seen from various entry points namely contextual, static and dynamic. Hence, we identify the elements of the environment that are required for the framework components. In addition, the framework process is detailed in terms of the interaction flow of different steps with the help of inputs and outputs. Finally, abstract execution of each component is illuminated by using an example.

PODSF Environment

PODS framework environment is composed of three parts. These parts are input, output and resources. The first part is the input in terms of End User requirement. The second part is the output in the form of recommendations. The third part is the resources that are used in PODSF.

A. Input

PODSF takes End User requirements as input. A sample of requirement is shown in Table 3. In this sample, we show one example of request for service and possible actions for this requirement. Possible actions include reuse existing service, create new service and check for other repositories. The End User sends a request to the IT department of a particular company for a service. If the service is performing well and if it is available, then IT Department will provide the service to the End User. If the service is not performing well, then IT Department needs performance evaluation from PODS framework.

B. Output

PODS framework provides a decision matrix of recommendations for service reuse or process reuse as output. A sample topology of recommendation is shown in Table 4. In this sample, we show different topology levels that we consider such as business, functional, applicative and technical. All of them have a particular aspect, measurement, type of answers and result. For instance, governance is related to the business aspect, call for blood is the functional aspect, while execution time is an applicative aspect. Technical aspects include availability, risk, maturity and time. The measurement mechanism for the governance of services at business level is the checking of policy compliance. At the functional level, we ask permission from the relevant organization to use the service. We measure the delay at applicative level. Measurements at technical level are in the form of assigning threshold levels. Type of answers are OK, MayBe and NO that are evaluated based on the actions such as compliant or not, available or not and others. Finally, one kind of recommendation is reuse existing service.

C. Resources

The main resources that we use in PODSF are the ISO 25010 quality model, repository of services, The above-mentioned elements of the environment plays an important role in order to execute the process flow of PODSF. Therefore, we propose steps to explain the overall process of PODSF in the below part.

PODSF Process

In this part, we explain the overall flow of the PODSF process as shown in Figure 13. PODSF process comprises of six major steps. The six steps of PODSF process are data management, traces management, ontology modelling, inference rules-based reasoning, analytical assessment and impact analysis. The output of the first five steps are the inputs of the following steps while the output of the last step is provided to the IT Admin who has requested for a service. The overall process of PODSF is illustrated below step by step. Moreover, it includes the creation of relationships between different concepts. The dynamic nature of ontology allows it to evolve with time and changing business needs. This step stores ontological concepts, relationships, object properties and data properties and delivers them as input to the next coming step.

Inference rules-based reasoning step develops inference rules based on the ontologies. The ontological concepts and relationships created at the former step, allows the reasoner to make efficient use of them. Hence, reasoning step creates a knowledge base of inference rules in order to perform efficient decision making. This step generates the knowledge base of rules and make available to the succeeding step of analytical assessment.

Analytical assessment follows two steps to evaluate the performance of atomic and composite services. The first step is to train the data set of knowledge base while the second step involves the assessment of this training data set with respect to service instances, services and composite services.

Analytical assessment applies classification algorithms of data mining. After applying all the classification algorithms, these step selects the most optimum result. This step generates its result in the form of a decision tree which contributes as input to the later step.

So far, the performance is evaluated for priority based technical indicators that yields to specific decisions. However, recommending a service that is efficient in terms of performance requires global evaluation of performance by increasing the consumption of services. This requires performing impact analysis. This step trails two steps. The first step involves the application of selected optimum classification algorithm to evaluate the performance of all service instances, while the second step includes the evaluation of performance for each service. This step also generates results based on the cost, confidence, support and accuracy. As a result, a report is generated and deliver to the IT Admin who has requested to provide performance assessment of service. The above enlightenment of PODSF process yields to implement the functionality of the proposed steps conceptually in the form of components. Consequently, we discuss the components of PODSF in the below part.

PODSF Components

PODSF is made of six major components. These components are data handler, traces handler, ontology builder, reasoner, process assessment analyser and impact analyser. The interactions between the components of the framework are shown in Figure 15. 5, along with their respective units and formula. Availability is a sub characteristics of reliability that may include other quality attributes to measure the degree to which the service is operational. The formula to calculate availability is shown below.

Availability = *

Throughput is a metric used to evaluate capacity sub characteristics of performance efficiency. It is calculated based on the number of active service, process and service instances in a particular time interval. The formula to calculate throughput is shown below.

Throughput = _ _ _

Delay is a metric used to evaluate time behavior. It is calculated on the basis of service, process or service instance deployed time and the time in which it is in use. The formula to calculate delay is shown below

Delay = -

Response Time is a metric used to evaluate time behavior. It is calculated on the basis of service, process and service instance ending and starting times. The formula to calculate response time shown below.

Response Time = -

Bandwidth is a metric used to evaluate capacity sub characteristics of performance efficiency. It is calculated based on service instance used in a particular time interval. The formula to calculate bandwidth is shown below.

Bandwidth =

Failure Rate is a metric used to evaluate capacity sub characteristic of performance efficiency. It is calculated based on the response and request counts. The formula to calculate failure rate is shown below.

Failure Rate = -

MTTR is defined as mean time to recover. It is a metric used to evaluate recoverability sub characteristics of reliability. It is calculated based on service, process and service instance down time in a particular time interval. The formula to calculate MTTR is shown below.

MTTR =

Service Time is a metric used to evaluate time behavior sub characteristics of performance efficiency.

It is calculated based on service, process and service instance start and end times. The formula to calculate service time is shown below.

Service Time = +

Total number of service instances is calculated by adding all number of instances. The formula to calculate the total number of instances is shown below.

= ∑ k =1
Now, we explain qualitative indicators that are available memory, risk and maturity. Available Memory is a metric used to evaluate resource utilization in terms of time behavior. It is calculated on the basis of used and available memory. The formula to calculate available memory is shown below.

Available Memory = _ -_

Risk is defined as the probability of occurrence of a threat at run time, that will have a negative impact on the system. Risk level is measured based on risk gravity. Formula to calculate risk gravity is shown below.

of a service and process with different time stamps. Traces are stored in the database during different time stamps. These data help the framework to analyze performance degradations at run time.

We study the medical domain where any hospital or medical organization wants to look-up an optimal solution via selecting several Web services from the Web service repository. Consider a small example of an urgent medical patient who arrived at a hospital. There are several precautionary and immediate service measures for the hospital management, such as call for blood, immediate doctor consultation, a a ge e t of e essa p odu ts a d e uip e t s, egiste i g patie t, providing him a room according to his/her severity and more. To manage all those aspects, we deploy services in WSO2 server to get the traces. Following is the detail of each of the Web services involved.

1. Call_for_Blood: This service gets the blood group of a patient, matches blood group in the repository of blood bank, and returns delivery date time of available bloods with their quantity.

2. Check_Doctor_Availability: This service gets patient complications and specialty of a doctor as an input, matches with the list of staff members of a hospital, and checks their available time slots.

Finally, it returns unique id of a doctor with its available timings.

3. GetSupplier: This service gets a list of products with their specification, checks the name of suppliers who can provide these products. Finally, it returns supplier id, delivery time and cost of each of products.

4. Find_Room_Availability: This service gets ward number and type of room as an input, matches the room requirements with the available rooms. Finally, it returns the room number as a response.

We have performed different tests and analyze performance of service, service operation and server. We perform a first test to evaluate the performance of one operation of GetSupplier service.

C. Ontology Builder

Ontology builder generates ontological structure in Protégè [123]. Protégè structure permits the addition of plug-ins to interact with other tools. Its graphical capabilities can draw concept trees and ontology flow diagrams that help in the visualization and generates OWL code automatically.

Ontologies provide a formal description of properties, concepts, and their relationships in a coherent way. Another important step is the creation of parent child classes. Ontology has two views. The first view is the static view of domain knowledge. It is usually represented or created in the form of classes.

This view is commonly referred as Tbox. The second view is the dynamic view of ontology instantiation.

This view is commonly referred as Abox. This is usually represented by assertion knowledge.

Ontologies are able to evolve with different time stamps. Knowledge base containing ontology concepts and instances can evolve with different time stamp as well. Therefore, it is possible to define or cumulate new concepts. However, it is important to verify that the ontology classes, concepts, relationships and properties are correctly defined and are consistent with the basic rules of ontology creation. For this purpose, ontology reasoner is built in Protégè to check the consistency of ontologies.

Reasoner inspects consistency by class checking, verifying relationships and eliminating conflicting definitions. Ontology builder uses reasoner of Protégè to verify its consistency to avoid all types of ontological error.

Ontology builder generates an ontology for service domain and ontologies of performance at SOA layers. Methodology to create performance profie from n ontologies is shown in Figure 21.

Performance based ontologies are developed at process defined as composite service, services, integration and governance layers of SOA. These ontologies stores the concepts, properties and relationships related to the technical indicators of the corresponding layers. Ontology builder generates a performance profile of these ontological concepts, properties and relationships. They can also evolve with time frequency. Up_Time is the time period the service is available since its deployment. Down_Time is the time period of un-availability of a service since its deployment. Delay is the average response time of a service. Loss express the unavailability of the service so that it cannot be invoked.

training set. A sample of training set created by data discovery step is shown in Table 9. This table presents for two quality characteristics, the sub characteristics, the type of technical indicators, either quantitative or qualitative, and the corresponding measurement formulas. Let s o e a k to the hospital e a ple. To be able to manage the patient, the hospital management service has some requirements for each one of the implied Web services. Those requirements are expressed under the form of inputs and outputs. Table 10 shows the se i es p ofile of the hospital management. This figure illustrates inputs and outputs of the corresponding Web service. After evaluating results for services, we estimate the cost, predictive confidence and accuracy of the performance evaluations. Finally, recommendations have been made in terms of reuse atomic service, composite service and resource allocation. We do not provide any new mechanisms for governance policy creation nor define any new policies. However, the proposed approach takes into account existing governance policies while using services. It also elaborates enforcement strategies that PODSF will follow for the performance evaluations in terms of resource utilization. We will explain the details in the next coming chapters dedicated to implementation and evaluation.

Discussion

In this chapter, we discussed the proposed framework, PODSF, dedicated for effective decision support in terms of performance-based service reuse. PODS framework exploits ISO 25010 performance-based characteristics at SOA layers. The different components of PODS framework are presented in this chapter. We have explained PODS framework with the help of an example related to hospital management domain. We have provided mechanisms to evaluate performance, risk and maturity. We have proposed performance-based ontologies for SOA layers and developed inference rules from these ontologies. We have analyzed the traces of performance based technical indicators on services deployed in WSO2 sever. As a result, performance profile is provided as input to the analytical assessment component. Analytical assessment component has deployed services, executed performance profile, analyzed decisions by using classification algorithms and selected optimum decision. This component provides decision chart as output which becomes the input of impact analysis component. Impact analysis component has analyzed the overall performance by increasing services load to evaluate a global decision for service reuse. This component provides decision in the form of recommendation. In the next chapter, we will discuss the implementation of PODS framework.

With the help of PODSF, we perform monitoring of service, process and integration layers.

the automation process. PODS system classes discuss the implementation of all the classes to build the system.

We hence start this chapter by the PODS research design phase. We then present the PODS research prototype. We explain the PODS system in the last part. We conclude the chapter by a discussion.

PODS Research Design

Research design traces the complete methodology that is used to integrate the different components of the framework in a rational and coherent way. In this way, the research problem is effectively addressed. The most important criterion is that the research design must be appropriate for testing the particular hypothesis of the study. This research study uses quantitative approach. A quantitative approach develops the knowledge and inquires the strategies on the basis of experiments or tests.

In this part, we explain the research design of the PODS by highlighting the interaction of internal and external actors. PODS research design is composed of two parts. These two parts are PODS ontology structuring and PODS reasoning. PODS ontology structuring is supported by different ontologies implemented at the domain level as well as for SOA layers performance. PODS reasoning is aided with the implementation of semantic inference rules. We show and explain the implementation of these two parts below.

PODS Ontology Structuring

Ontology builder generates ontologies based on a set of basic concepts containing several instances.

This promotes the reuse of ontology knowledge in many use cases. We have developed ontologies in Protégè and used DL Reasoner to verify their consistency. The verification avoids all types of ontological error. Protégè supports the definition of classes, sub-classes, the relationships between them, their individual properties and instantiation. SOA has nine layers that have already been defined in the introduction chapter. SOA layers ontological concepts are shown in Figure 24. This ontology defines concepts for consumer, component, service, process, QoS, operation, integration, governance, information architecture layers. In order to maximize service reuse along service lifecycle, we develop performance and decision-based ontologies. For this purpose, we target layers that are related to performance and service reuse concepts for decision support. These layers are service, process, integration and governance layer.

A. Performance Ontologies for SOA layers

We now explain the ontological concepts of the performance at process layer, integration layer governance layer and service layer. Ontologies for all these layers are shown below step by step. We start with ontology of performance at process layer. Note that process is a combination of two or more atomic services as a composite service to complete the desired functionality requested by the consumer. Therefore, the performance of process relies on the underlying services that are composed to have a process. So, the value for the technical indicator at process level is calculated based on all the atomic services that are involved in the process. The work on ontology of performance at process layer has already been published [127]. o Process-Loss: specifies that the composite service is un-available (i.e., it cannot be invoked). If any of the atomic service of the process is not available, then it means that whole process cannot function properly without alternate service allocation.

o Process-Duration: expresses the time duration of a composite service since it is deployed, executed and remained in process. We evaluate composite service duration by calculating the average duration of all underlying atomic services. It has three sub concepts to record Maximum, Minimum and Average duration.

After the process layer, we now focus on the ontology at integration layer. Integration layer means communication at the messaging level. This ontology is represented in Figure 26. Technical indicators concepts at integration layer are hasThroughput, hasReliableMessaging, hasBandwidth and hasResponseTime. We have already published this ontology of performance at integration layer in a book chapter [128]. These technical indicators are explained below. The ontology of governance layer is shown in Figure 27. Governance ontology defines concepts as hasPolicy, hasSLA and hasServicePortfolio. o Service Portfolio: is described by service design package. It has three elements that are service pipeline, service catalogue and retired services. Service pipeline contains references to services that are under development. Service Catalogue holds links to active services. Retired Services are services that are considered as obsolete.

B. Performance Oriented Decision Support Ontology PODSOnt

Now, we propose an ontology that integrates all performance ontologies at SOA layers of part B and extends ontologies at SOA layers and extends service layers in terms of performance and decision QoS.

As a result, a composite and coherent global ontology in terms of performance and decision support for SBS is produced. This ontology is named as performance-oriented decision support ontology (PODSOnt) and is developed to maximize the service reuse capabilities. Figure 28 A composite hierarchy of performance profile is shown in Figure 29. Performance profile is generated from the ontological concepts of PODSOnt.

PODS Reasoning

In order to solve problems and advise the End User in decision-making, the decision support system need to access a domain knowledge base. Therefore, the effectiveness of the system relies heavily on the way the knowledge is represented. Hence, the knowledge base needs to be implemented so that the knowledge becomes explicit and readable by a machine. This set of classes, relationships, instances and inference rules allows decision model to compose the domain knowledge base. We compose semantic inference rules to evaluate performance management. Some of these rules are already published in a conference [127] and described in section 3.3. Inference rules that compose the knowledge organization from the relationships between PODSOnt concepts are shown in Table 14 and Table 15. The right column contains the rules corresponding to the technical indicators listed in the left one. We define the rules using SWRL Protégé. The implementation of inference rules using ontological concepts, properties and relationships provides a knowledge base. Since inference rules can evolve with time, they can help in providing enhanced analytics and manipulations in order to help decision makers to take right accurate on the fly. We explain the Implementation of PODS research prototype phase in the below part. order to facilitate the calculation of service or process maturity. The CMMI is a basic foundational building block for achieving service or process improvement and ensuring the service or business process optimization. The service is considered disciplined when its functional specifications are identified. The business process is considered as managed when its business specifications are identified. Once the functional and business specifications are defined, the service or process is able to be executable and used. The knowledge of service or process performance tends to be more qualitative rather than quantitative up to Matu it Le el 3 defi ed . I the third level of defi ed , we can obtain measures that provide information about the availability of service or process. In this level, where the service or process is deployed and used, several means have been set up in order to supervise the evolution of their maturity over the time. When the service or process runs, we are able to assess its performance in the fourth level named as quantitatively managed . The real use of the service or process by its end End Users corresponds to the Maturity Level 4. It insists on managing service or process performance and addressing the main causes and sources of variation. These causes of variation can indicate a problem in service or process performance and may require correction and solution to maintain service or process performance during its utilization. At Maturity Level 5, organization emphasizes on reducing the common cause of variation and it improves the overall performance level. The service or process is considered optimized if the service or process is stable for a long time. There is no evolution of the means of control and performance. On the basis of the service or process history during a certain period, a deviation is detected. If the service or process is not able to answer, it should be return to the second or the third level of maturity to redefine the specifications or it has to finish.

PODS Research Prototype

Line 9 and 10 estimates and stores service-instance-start-time and availability along with values. Line 11 explains the third for loop to calculate maturity-level of services in Line 12. Line 13 writes maturity profile with values for all service instances in the Maturity-profile.txt text file and the algorithm ends.

C. Risk Management Algorithm

Risk management is also performed based on the End User requirement and priority. We show risk types, corresponding assessment and mitigation action in Table 17. Risk types are loss of service, specification changes and unexpected behavior. We define an assessment for each risk type. The loss of a service is imputed to network problems, specification changes is resulted due to format change or loss of service and finally, an unexpected service behavior is caused due to particular service specification change. Specific mitigation actions are proposed for each type of risk. One of the way to mitigate the loss of a service is to suggest alternative services. If the specification of a service changes, the only way to solve this problem is to provide a new service. In order to identify the cause of unexpected service behaviour, we need to perform testing of services. In this way, this problem can be mitigated. The Risk Management algorithm is shown in Figure 32. The algorithm begins with inputs and outputs. In the Risk Management algorithm, risk is evaluated based on the inference rule presented previously in Table 14 and Table 15, Section 4.1.2. Risk level is computed based on risk gravity. Risk gravity is measured by risk probability and risk severity. The steps for risk management process are identify risk, measure the level of risk, calculate the probability percentage, make assessment and mitigate action.

The algorithm returns the risk text file for risk profile. Risk management provided the implementation for the identification of risk level. This data management part shaped and managed data by computational analysis. Hence, data are now tuned in order to apply decision-oriented algorithms. We explain the implementation of the decision support system in the following part.

Decision Support

A decision support is a manner of scrutinizing business data and delivers it to the End User so that they can take business decisions more easily, efficiently and dynamically. A system that accumulates, categorizes and investigates business data to enable quality decision-making for management, operations and planning is categorized as decision support. A well-designed DSS supports decision makers in assembling data and forecasting based on manipulations of data.

The decision support is divided into three parts. The first part shows and describes performance evaluation for a specific decision. The second part displays and explains the algorithm for impact analysis of a new consumption. The third part illustrates and explicates decision evaluation.

Classes of PODSS

The For each class, we present its general features followed by its signature and its functions.

Data Handler

This class gets the traces of technical indicators from the database. This class contains two functions.

Signature: public void DataHandler ()

Signature of Functions:

public void GetData () public void SetData ()

WebServiceSelector

This class selects the existing services from the repository of services. It implements existing Web service selection algorithm.

Signature : public void SelectWebService ()

SemanticXMLGenerator

This class generates semantic XML from the RDF concepts. This class has one function.

Signature: public class SemanticXML.

RdfToXML:

This function generates XML syntax from RDF. RDF is a collection of ontological concepts, classes, objects and relationships between them. As a result, a SemanticXML file has been generated.

Signature: public void RdfToSemanticXML ()

SemanticXMLReader

This class reads XML specification and it has one function named as ReadSemanticXML.

Signature: public class SemanticXMLReader.

ReadSemanticXML:

This function reads the SemanticXML specification and stores it in a reader object. It takes the SemanticXML file as input and output is the object.

Signature: public void ReadSemanticXML (String file) throws FileNotFoundException

InputHandler

This class handles all the inputs that the system used and it has fourteen functions.

Signature

Classifier

This class applies classification algorithms on the data. This class Classifier class includes four main functions.

Signature: public class Classifier

ApplyLogisticRegression

The ApplyLogisticRegression function reads technical indicators information of the SemanticWSDL objects from the SemanticWSDLParser class. This function applies logistic regression classification algorithm.

Signature: public void ApplyLogisticRegression ()

ApplyNaïveBayes

The ApplyNaïveBayes function reads technical indicators information of the SemanticWSDL objects from the SemanticWSDLParser class. This function applies naïve Bayes classification algorithm.

Signature: public void ApplyNaïveBayes ()

ApplySupportVectorMachine

The ApplySupportVectorMachine function reads technical indicators information of the SemanticWSDL objects from the SemanticWSDLParser class. This function applies support vector machine classification algorithm.

Signature: public void ApplySupportVectorMachine ()

ApplyDecisionTrees

proposed algorithms and inference rules. As a result, we obtain a dynamic efficient decision support system based on performance.

In the next chapter, we will evaluate our performance-oriented decision support system on an industrial case study and discuss some analytical results.

CHAPTER 5. Evaluation of PODSS

The PODS implementation is explained in detail with the help of its three phases of research design, research prototype and system. However, every system must need to be validated and evaluated. This chapter is dedicated to providing the evaluation of PODSS. PODSS is evaluated by fetching services from a public repository of shared services and usage scenarios.

Before explaining the different phases of this chapter, we first explain the high-level schema of the PODSS evaluation. High level schema of PODSS evaluation is shown in Figure 37.

Service Reuse Use Case

The purpose of a use case diagram in UML is to demonstrate the different ways that a user might interact with a system. It helps to evaluate the system. We explain the use case by describing the notion of three different strategy levels defined for the business function of a company. These three levels are business level, functional level and applicative level. At the business level, a business process is defined based on the requirements of End User. At the functional level, processes are defined to provide the desired functionality of business process. Finally, at the applicative level, functionality of each service task is defined for every process. Service tasks are demarcated by defining service methods, inputs and outputs. The output of each service task is the input of the following service task.

We need to develop a business process in order to analyze collaboration of two business partners that are partner one and partner two. For this purpose, we explain a use case of the business process and the underlying services that we need to develop. This use case is used to evaluate the capacity of these two partners to industrialize products from common customer projects. The aim is to identify business opportunity and the objectives are to reduce project quotation costs, optimize the delay of customer quote treatment and reduce the delay of project acceptance without disturbing the process quality.

We classify business opportunity in the form of Mandatory, High ROI, nice to have or not relevant.

Customer project details and the data of two industrial partners are the expected results of this analysis or evaluation. The input is the project submitted by a customer for the evaluation. We name this business process as CollaborationAnalyzer. CollaborationAnalyzer schema is shown in Figure 38.

This figure illustrates all the service tasks required to complete this business process. First row of the figure shows a user task in which a customer submits its project to inspect business opportunity. In the first step, we show the application and the services that we need to develop. First service is ep ese ted as De o posep oje t a d defi ed as se i e task to de o pose the p oje t i featu es based on CAD file form. Feature analytic service will provide project classification and ranking based on existing BigData infrastructure under development by the partner 1 and partner 2. For this purpose, we define a second service task named as RankProject. Third service generates an internal ranking report and is defined as GenerateRankingReport service task. A notification is sent to the two partners to let them know that the ranking report is available. Partners receive the notification and they will accept or reject the quotation. The decisions from both partners is consolidated. If the project is accepted by both partners, then the project is sent to the quotation process and they update their respective QuotationProcess for this consolidated decision. In this iteration, analytics are generated by applying three classification algorithms that are decision tree, naïve bayes and support vector machine. We designate 50 percent of data coming from the repository for this iteration. We classify this data by applying classification algorithms and get analytical results. We begin this iteration by illustration performance criteria in For this purpose, we define rules to evaluate the recommendation weights such as OK, NO and MayBe.

Basic rules to generate recommendations weight are shown in Figure 42. We follow the pattern of SLA to define these rules. It starts by defining the recommendation NO. After the assignment of all weights, the remaining monitoring data is updated to the recommendation weight NO. The other recommendation weights are OK and MayBe. Recommendation weight is assigned to OK if the maturity is greater then and equal to 3 OR maturity is greater then and equal to 2 AND risk is less than or equal to 0.0001 AND available memory is greater then and equal to 0.8 AND failure rate is less then and equal to 0.03. Another predicate is used to assign the recommendation weight as OK that is if maturity is greater then and equal to 2 AND risk is less then and equal to 0.001 AND available memory is greater then and equal to 0.5 AND failure rate is less then and equal to 0.05. Recommendation weight is assigned as MayBe, if maturity is greater then and equal to 2 AND service time is less then and equal to 0.5 AND failure rate is less then and equal to 0.05. Since it is proved from the results that decision tree is the most optimum therefore we select decision tree model to be applied in the next iteration. We now explain the working of next iteration two.

Iteration 2:

Iteration 2 involves the deployment of existing 3DScan application in performance monitoring server and gathered traces from it. After this, selected optimum decision tree algorithm is applied on the traces gathered from the server. Finally, it consolidates the both results generated from the model application on traces of server as well as the results generated in iteration 1. Traces management is already explained in chapter 3. We now explain the application of decision tree model on deployed 3DScan application traces.

After applying deploying 3DScan application, we first evaluate results based on technical indicators. The next part uncovers different decision scenarios developed for the capitalization of service reuse based on the above performance-oriented data mining analytics.

Decision scenarios for Service Reuse

Decision scenarios on service reuse are displayed through an interface manipulated by an IT manager who is interested to get performance analysis as well as recommendation report. The decision part allows the End User to accompany the evolution of the trajectory of the performance (performance efficiency, availability, maturity and risk) with time. First level decision interface displays information describing the specific decision based on priority of End User. Second level decision interface displays information describing the decision for the recommendation based on instances. Final level decision interface shows the global decision for each service.

In order to describe the application of classification algorithms, we develop scenarios. A scenario designates a goal for which an End User might use a software and all the features of the software that they would require in order to achieve the desired goal. We will provide in detail the unfolding of PODSS scenarios. We will also present the ability of the system to make a fast and reliable decision. As a result of this, results are generated for each service. We now present the generated decision result in Table 18 for the 3DScan services. It also illustrates the total number of cases. e ui e e ts. "i e, pe fo a e of se i es ha ges ith ti e, the e a e flu tuatio s i esou e availability and priority of resource requirements. This involves reallocation of resources based on the estimated results. Note that, our goal is to provide recommendations to the IT Admin. However, this approach will not provide any mechanism to allocate resources. It only provides suggestions based on the estimated results. As a result of this provisioning approach, following actions are suggested to be handled dynamically.

1. Actions to take when performance fluctuates with increased number of consumption of data.

2. Provisioning mechanisms in the infrastructure that need to be measured and controlled dynamically for the triggered event of resource allocation.

Provisioned resources restoration

Upgradation or migration

The results obtained from our performance system are encouraging and significant. Having interesting solutions shows, that this work has helped a lot in the convergence of performance.

Certainly, the interpretation of the information brought back to the End User interface (performance profile-based service portfolio, assessment report, decision matrix and recommendation of the solution) represents an interesting contribution for the company. An important aspect of our approach is therefore to put in place PODSS to provide an End User with useful information when he or she needs it, as quickly as possible, and in a usable way. However, the major advantage of the proposed system is its ability to quickly and dynamically display the information to the End User.

Discussion

Current approaches for performance evaluation rely primarily on workflow systems to ensure either monitoring or process monitoring or decision support based on execution traces and are not compliant with latest quality standards. Indeed, these traditional methods are based on the supervision and the monitoring of the behavior of the process, but do not integrate reasoning based on a semantic richness coming from an ontological model.

With the dynamic nature of services, SOA based companies also seeks a dynamic analytical decision support system based on the assessment resulting from performance evaluation to better meet its commitments. Accelerating decision-making is considered today as a strategic resource that can provide a decisive competitive advantage for the company. To do this, our proposal makes it possible to create a learning process from the statistical analysis of technical indicators and from the execution traces. This makes it possible to react fairly quickly to make decisions in a dynamic environment.

Usually, when the End User is involved in a decision support system, he is often confronted with a lot of information, which he has to analyze, synthesize and exploit. It is then necessary to automate certain tasks with high added value to optimize this decision support system. The PODSS is a dynamic system that analyzes the data and displays it to the End User.

CHAPTER 6. Conclusion and

Future Works

Conclusion

Reuse of services in a SOA environment provides many benefits including improving agility of solutions and reduction of cost. Agility is guaranteed by quickly assembling new business processes from existing services to meet changing marketplace needs. Cost is reduced by not just avoiding duplication of code for enabling similar business functions, but also throughout the SOA life-cycle spanning of service deployment and management.

This research work provides a decision support system called PODSS for accelerating performance of SBS by recommending reuse of services to ensure sustainability. The proposed research work accelerates the analysis of existing service networks to validate service reuse capabilities. PODSS is supported by five models.

Performance based technical model

In this model, we exploit ISO/IEC 25010 quality characteristics and their sub characteristics that are relevant to ensure the performance of SBS. Sub characteristics that we exploit are time behavior, resource utilization, capacity, maturity, availability, fault tolerance, recoverability and reusability. We measure these sub characteristics based on qualitative and quantitative technical indicators.

Performance based ontological model

This model is composed of two blocks. First block is the creation of structure and the second block is the creation of reasoning. In the first block, first of all we create service domain ontology. We create all the classes, instances, attributes and their relationship in this ontology. In the second step, we create the ontologies of qualitative and quantitative technical indicators for service, process, integration and governance layers of SOA. Finally, we aggregate all proposed ontologies to create a composite performance-oriented decision support ontology that mainly highlights concepts of performance and decision. In the second block, we develop reasoning rules for the evaluation of performance, maturity, risk and recommendation results.

Performance based machine learning model

In this model, we apply machine learning models to evaluate knowledge base of performance. We create a training data set to generate recommendation rules in this model. We apply classification algorithms on the training data of services and technical indicators. Classification algorithms are logistic regression, naïve Bayes, support vector machine and decision Trees. After the generation of model, we get the algorithm that provides optimum results which is in our case is decision tree classification algorithm. Therefore, we apply decision tree algorithm on the data generated from the traces of application server. Finally, the results for service instances are aggregated and passed to the ontologies and inference rules to generate results for each service.

Performance based decision model

This model is composed of three parts. Three parts are performance management, maturity evaluation and risk management. We propose decision support algorithm for all of these parts. Decision model will generate recommendations as reuse service or process if it is best in terms of performance, maturity and risk. This decision model provides three kinds of decisions. First decision is based on the End User choice. End User give priority to each of these measures and decision model recommend service accordingly. This type of decision is called specific decision. Second decision is based on the performance evaluation of all service instances. Third decision is the accumulative decision based on the performance of service instances for each service. Final decision is called global decision that is based on cost, confidence and precision. Decision model recommend service based on accumulative decision.

Performance based validation model

Validation model uses QoS web services inputs from two public repositories. We discuss a business process use case for atomic and composite services recommendation. In this model, we perform several tests by increasing the number of services and instances. We deploy 1000 services and each service is invoked 100 times. We apply classification algorithms on the data in two iterations. In the first iteration, we apply classification algorithms and selected the algorithm that has most optimum result. In the second iteration, we apply the selected decision tree classification algorithm on the data of traces gathered from application server and generates results for service instances. Finally, these results are aggregated and processed in the ontologies and inference rules that generates results for each service. We provide recommendations such as reuse existing service, suggesting composite service and resource allocation.

Our approach may not perfectly represent reality. It would be wise to consider possible discrepancies when considering a point of analysis. It is possible to integrate other quality characteristics like security and maintainability. PODSS can also be tested in some real time environments. It is also possible to expand PODSS by implementing new services with new SLA and new business process. These limitations will obviously be taken into consideration in future works.

Future Works

Due to time constraints, this research work still has some works to improve for further research.

Inclusion of performance-based Quality Characteristics

There are several quality sub characteristics proposed by ISO/IEC 25010 series as mentioned in the introduction section, we have only included that are important to evaluate performance. However, there remains some quality characteristics that can also be considered in terms of following perspectives:

a. Security Information systems that demands high performance also requires complicated network and computer infrastructure to support distributed collaboration that should be provisioned on-demand. Dynamic performance-based service recommendation also requires consistent security target such security issues.

b. Portability

Portability is the usability of the same system in different environments. It is the ability of the system to be transportable to any device or hardware. Portability is the key quality attribute for cost reduction.

c. Usability

Proposed system is implemented for End User who is IT Admin. This system does not provide any mechanism to interact with the user who has requested for the service. It would be interesting to provide a mechanism of interaction between the system and the user who intend to use the service.

d. Compatibility

Compatibility is the ability of the system to be able to work in any environment regardless of the platform and other dependencies. There are different kind of compatibility tests that can be performed.

2. For the moment, we are recommending reusing existing service and process.

a. However, there can be a scenario in which it is necessary to implement new service with new SLA.

CHAPTER 1 .

 1 INTRODUCTION .................................................................................................................

FIGURE 1 :

 1 FIGURE 1: SOA REFERENCE ARCHITECTURE [4] .............................................................................................................. FIGURE 2: ISO/IEC 25010 QUALITY MODEL FOR SOFTWARE PRODUCTS [8] ......................................................................... FIGURE 3: EXTENDED SOA FUNCTIONALITY WITH ORACLE FUSION MIDDLEWARE [17] ........................................................... FIGURE 4: TOGAF [22] .............................................................................................................................................. FIGURE 5: RESEARCH CLASSIFICATION ............................................................................................................................ FIGURE 6: DIMENSIONS OF WELKE S SOAMM [80] ........................................................................................................ FIGURE 7: MAPPING OF CMMI MODELS AND SOAMMS [81] .......................................................................................... FIGURE 8: SERVICE LIFECYCLE [82] ................................................................................................................................ FIGURE 9: METHODICAL BUILDING BLOCKS [82] .............................................................................................................. FIGURE 10: WEB SERVICE ONTOLOGY [111] ................................................................................................................... FIGURE 11: POSITION OF PODSF IN SOA BASED ORGANIZATION ........................................................................................FIGURE 12: PODSF ................................................................................................................................................... FIGURE 13: PODSF PROCESS ...................................................................................................................................... FIGURE 14: DATA FLOW OF PODSF ............................................................................................................................. FIGURE 15: PODSF COMPONENTS AND THEIR INTERACTION ............................................................................................. FIGURE 16: DATA MANAGEMENT IN PODSF .................................................................................................................. FIGURE 17: GETSUPPLIER SERVICE INFORMATION IN WSO2 SERVER ................................................................................... FIGURE 18: GETSUPPLIER SERVICE OPERATION IN WSO2 SERVER ....................................................................................... FIGURE 19: SERVER INFORMATION IN WSO2 SERVER ...................................................................................................... FIGURE 20: GETSUPPLIER SERVICE SUMMARY USING WSO2 SERVER ................................................................................... FIGURE 21: METHODOLOGY TO CREATE PERFORMANCE PROFILE ........................................................................................ FIGURE 22: SONT ONTOLOGY BASED ON TECHNICAL INDICATORS OF WSO2 SERVER ............................................................. FIGURE 23: INFERENCE RULES USING SWRL IN PROTÉGÉ .................................................................................................. FIGURE 24: SOA LAYERS ONTOLOGICAL CONCEPTS .......................................................................................................... FIGURE 25: ONTOLOGY OF PERFORMANCE AT PROCESS LAYER ........................................................................................... FIGURE 26: ONTOLOGY OF PERFORMANCE AT INTEGRATION LAYER. .................................................................................... FIGURE 27: ONTOLOGY OF GOVERNANCE LAYER. ............................................................................................................. FIGURE 28: PERFORMANCE ORIENTED DECISION SUPPORT ONTOLOGY (PODSONT) .............................................................. FIGURE 29: PERFORMANCE PROFILE .............................................................................................................................. FIGURE 30: PERFORMANCE MANAGEMENT ALGORITHM ................................................................................................... FIGURE 31: MATURITY EVALUATION ALGORITHM ............................................................................................................ FIGURE 32: RISK MANAGEMENT ALGORITHM ................................................................................................................. FIGURE 33: PERFORMANCE EVALUATION FOR SPECIFIC DECISION BASED ALGORITHM ............................................................. FIGURE 34: IMPACT ANALYSIS ALGORITHM ..................................................................................................................... FIGURE 35: DECISION EVALUATION ALGORITHM .............................................................................................................. FIGURE 36: PACKAGE DIAGRAM OF PODSS ................................................................................................................... FIGURE 37: HIGH LEVEL SCHEMA OF PODSS EVALUATION .............................................................................................. FIGURE 38: COLLABORATIONANALYZER SCHEMA ........................................................................................................... FIGURE 39: SDSCAN APPLICATION .............................................................................................................................. FIGURE 40: USE CASE IMPLEMENTATION...................................................................................................................... FIGURE 41: PERFORMANCE CRITERIA ........................................................................................................................... FIGURE 42: BASIC RULES FOR THE ASSIGNMENT OF RECOMMENDATION WEIGHTS ............................................................... FIGURE 43: ANALYTICS OF CLASSIFICATION ALGORITHMS ................................................................................................ FIGURE 44: PARAMETRIC RESULT OF CLASSIFICATION ALGORITHMS ................................................................................... FIGURE 45: RESULTS FROM 3DSCAN APPLICATION ......................................................................................................... FIGURE 46: DECISION TREE MODEL.............................................................................................................................

FIGURE 47 :

 47 FIGURE 47: RESULTS FROM DECISION TREE MODEL........................................................................................................ FIGURE 48: COST MATRIX FOR DECISION TREE MODEL ................................................................................................... FIGURE 49: RECOMMENDATION OF SERVICE BASED ON RESPONSE_TIME ........................................................................... FIGURE 50: RECOMMENDATION OF SERVICE BASED ON SERVICE_INSTANCE_TIME ............................................................... FIGURE 51: RECOMMENDATION OF SERVICE BASED ON THROUGHPUT ............................................................................... FIGURE 52: DECISION RESULTS BASED ON SERVICE INSTANCES .......................................................................................... FIGURE 53: MATURITY EVALUATION BASED ON INSTANCEID ............................................................................................ FIGURE 54: RISK EVALUATION BASED ON INSTANCEID ..................................................................................................... FIGURE 55: SERVICE TIME EVALUATION BASED ON INSTANCEID ........................................................................................ FIGURE 56: RECOMMENDATION PREDICTION AND COST ANALYSIS MATRIX ........................................................................ FIGURE 57: PARAMETRIC ANALYSIS MATRIX .................................................................................................................. FIGURE 58: PREDICTIVE CONFIDENCE ..........................................................................................................................

  FROM AN END USER ................................................................................................... TABLE 4: A SAMPLE TOPOLOGY OF RECOMMENDATION: THE CALL FOR BLOOD EXAMPLE .........................................................TABLE 5: QUANTITATIVE TECHNICAL INDICATORS ............................................................................................................. TABLE 6: OBJECT PROPERTIES OF SONT ......................................................................................................................... TABLE 7: DESCRIPTION OF OBJECT PROPERTIES OF SONT ................................................................................................... TABLE 8: DESCRIPTION OF DATATYPE PROPERTIES OF SONT ............................................................................................... TABLE 9: PERFORMANCE MEASUREMENT ....................................................................................................................... TABLE 10: SERVICES PROFILE FOR HOSPITAL MANAGEMENT .............................................................................................. TABLE 11: A SAMPLE OF SPECIFIC DECISION ................................................................................................................... TABLE 12: FIRST LEVEL RESULTS FOR SERVICE INSTANCES .................................................................................................. TABLE 13: SECOND LEVEL RESULTS FOR SERVICE RECOMMENDATION .................................................................................. TABLE 14: INFERENCE RULES (IR) (1/2) ......................................................................................................................... TABLE 15: INFERENCE RULES (IR) (2/2) ......................................................................................................................... TABLE 16: MATURITY EVALUATION BASED ON CMMI LEVELS ............................................................................................ TABLE 17: RISK ASSESSMENT AND MITIGATION ............................................................................................................... TABLE 18: DECISION RESULTFOR EACH SERVICE .............................................................................................................

Figure A. 1 :

 1 Figure A.1: Structure of Thesis

Figure 1 :

 1 Figure 1: SOA Reference Architecture [4]

Figure 2 :

 2 Figure 2: ISO/IEC 25010 quality model for software products [8] ISO/IEC 25010 quality characteristics that play very important role for achieving performance of SBS are performance efficiency, reliability and maintainability. Under these quality characteristics, the important quality sub characteristics are time behavior, resource utilization, capacity, availability, fault tolerance, recoverability, maturity and reusability. Time behavior is further analyzed based on

Figure 3 :

 3 Figure 3: Extended SOA Functionality with Oracle Fusion Middleware [17]

Figure 4 .

 4 Figure 4. TOGAF is a framework that provides a detailed method and a set of supporting tools for developing enterprise architecture within an organization. It helps to utilize resources more efficiently, effectively, to realize a greater return on investment. One of the most important phase of TOGAF is Information Systems Architectures. This architecture describes the development of Information Systems Architectures containing the development of Data and Application Architectures.

Figure 4 :

 4 Figure 4: TOGAF [22]

  classification. We build a research classification based on the systematic analysis of relevant research areas as shown in Figure5. This classification is based on service reuse and performance-based solutions. There are four main classifications for this research area. The first classification consists of research works that proposes architectures or systems for service reuse. These works highlight some important concepts related to quality evaluation and quality engineering. Quality is evaluated on the basis of time, cost, performance, resource, capacity and efficiency. Quality is structured on the basis of ontologies and managed through frameworks and knowledge representations. The second classification consists of research works that focus on service performance. Performance of service is measured or analyzed at both quantitative and qualitative levels. Quantitative level provides quantitative technical indicators for performance management while qualitative level analyzes maturity and risk. The above mentioned two classification approaches yield to two other major classification defined as performance-based structuring and performance-based reasoning for services. Structuring is performed by using ontologies while reasoning has been made by decision support systems followed by some data mining algorithms for efficient decision support.

Figure 5 :

 5 Figure 5: Research Classification

  efficiency and reliability characteristics of ISO 25010. Reliability is measured based on availability subcharacteristic and performance efficiency is measured based on time behavior and capacity subcharacteristics. Quantitative technical indicators related to time behavior and capacity are response time, service start, end times, throughput, transporting time (up time), CPU time and bandwidth. Quantitative technical indicators related to availability are request count, response count, up time, execution or processing time and down time. The performance of a service can be analyzed based on these quantitative technical indicators.

  quality characteristics are measured by different technical indicators like response time, throughput, availability, execution time, network bandwidth, CPU time, server CPU, task CPU, server memory utilization and task memory utilization. Oriol et al [42] propose a framework named as SALMon. It is supported by two services: the monitor service and the analyzer service. The monitor service measures the values of response time, throughput and availability. The analyzer service detects whether SLA is being or going to be violated. SALMon supports passive monitoring and testing. It supports any type of service technology. This framework ensures quality guarantees in SLA. The authors perform tests on 11 services with 30

  Web service invocations. The first test is used to measure the processing time. The second test measures the processing time and transporting time. The third test measures queuing time for Web services, where two End Users may invoke a Web service at the same time. The proposed monitoring method has not been implemented. Avila et al[START_REF] Avila | Fuzzy Logic Based QoS Optimization Mechanism for Service Composition[END_REF] propose an optimization model that performs service selection based on historical QoS data. Historical QoS data includes execution time traces. The authors use fuzzy logic to dynamically define the level of QoS that can be delivered. Garcia Valls et al[START_REF] Garcia-Valls | A Real-Time Perspective of Service Composition: Key Concepts and Some Contributions[END_REF] propose reconfiguration of service compositions for distributed real-time systems. Monitoring of execution time is performed in this paper. They present an algorithm that target embedded real-time systems. Zheng et al[START_REF] Zheng | Investigating QoS of Real-World Web services[END_REF] investigate quality of service based on real world Web services. They conduct three large-scale distributed evaluations on real world Web services and collect comprehensive Web service QoS data sets. First, 21,358 Web service addresses are obtained by crawling Web service information from the Internet. Then, three Web service evaluations are conducted. In the first evaluation, failure probability of 100 Web services is assessed by 150 distributed service End User. In the second evaluation, response time and throughput of 5,825 Web services are evaluated by 339 distributed service End User. And in the third evaluation, response time of 4,532 Web services is evaluated by conducting 30,287,611 invocations. The authors have used PlanetLab global research network for monitoring of QoS. Kahlon et al [48] conduct a survey of existing research papers based on the activities of Web service life cycle. They highlight different activities involved in the service life cycle as specification, requirement, analysis, deployment, execution, monitoring, recovery and testing.McKee et al[START_REF] Mckee | Enabling Decision Support for the Delivery of Real-Time Services[END_REF] monitoring current system state within a workflow execution. In this work, system performance is monitored by server CPU, task CPU, server memory utilization and task memory utilization. Experimental validation is performed on real server utilization data from Google Cloud and their own local server cluster. The authors apply their probabilistic model to a single service in the workflow. Boumahdi et al[START_REF] Boumahdi | SOA+D: A New Way to Design the Decision in SOA -Based On the New Standard Decision Model and Notation (DMN)[END_REF] propose model named as SOA+d. They integrate elements into two dimensions such as conceptual and methodological. They model decision, intelligence, design and the choice activities.Performance of business process can also be analyzed based on quality characteristics such as performance efficiency and reliability. These quality characteristics are measured by different technical indicators like response time, and CPU time. Aschoff and Zisman[START_REF] Aschoff | QoS-driven Proactive Adaptation of Service Composition[END_REF] monitor the response times of services. They propose proactive adaptation of service composition (ProAdapt) based on the exponentially weighted moving average (EWMA). Decision has been made by considering both

model [ 80 ]

 80 . Welke s odel focuses on the maturity of enterprise architecture. There are two facets for this model that are SOA attributes and SOA motivations. The SOA motivations are infrastructure effi ie , euse, appli atio a d data o positio , usi ess a al ti s a d p o esses, fle i ilit a d agility, and enterprise transformation. Each of these motivations is associated with a maturity level. Infrastructure effi ie a d euse a e at the otto le el, o positio a d usi ess p o ess a age e t a e at the iddle le el, a d fle i ilit a d e te p ise t a sfo atio a e at the highest level of maturity. Figure 6 depicts the six "OA att i utes of Welke s odel.

Figure 6 :

 6 Figure 6: Di e sio s of Welke's SOAMM [80]

Figure 7 :

 7 Figure 7: Mapping of CMMI Models and SOAMMs [81]After mapping CMMI process areas and SOAMM dimensions, Pulparambil et al[START_REF] Pulparambil | Exploring the main building blocks of SOA method: SOA maturity model perspective[END_REF] propose an approach based on SOA adoption initiative for maturity levels. The authors model the service lifecycle activities as shown in Figure8. Service lifecycle activities i lude se i e ide tifi atio , se i e contract design, and the service discovery phases. The governance of se i e defi es a set of p o esses to manage the activities of service lifecycle. This includes design-time rules and enforcement for service creation and run-time governance policies for service usage and operation policies.

Figure 8 :

 8 Figure 8: Service Lifecycle [82]

Figure 9 .

 9 Figure 9. The bottom layer represents the entire corporate IT. The Initial level uses existing software development methods such as object-oriented or component-based. The Managed level uses serviceoriented software engineering methods, enhances the method and practices to address the creation, implementation, and deployment of services, and adopt SOA project methodology. The Defi ed le el

Figure 9 :

 9 Figure 9: Methodical Building Blocks [82]

  creation and elicitation of domain knowledge[101]. Ontologies represent formal specifications about the component of the systems and their relationships in a machine understandable and processable manner[102]. They have played an important role in both semantic web applications and knowledge engineering systems[103]. Several tasks such as information storage, processing, retrieval, decision making are done on the basis of ontologies. In this section, we provide analysis of existing ontologybased research that focuses on QoS. Ontologies archive current or historical decision-making processes and their outputs, outline decision-making rules, provide semantic representation and a tree structure that provide better searching time. Ontologies explicitly represent the data along with their semantics to facilitate the transfer of information. They are used to describe semantic representation of Web services such as domain concepts and terminologies of QoS properties.

  and Zimeo [104] propose the onQoS ontology defined with OWL language. It is composed of three extensible complementary layers: upper, middle and lower ontology. The upper ontology introduces the QoS ontological language that p o ides the o ds to des i e a d fo ulate the i fo atio of Qo". The iddle o tolog describes the standard vocabulary of ontology such as QoS parameters, QoS based technical indicators and QoS scales. The lower ontology describes the concepts, the properties and the constraints of a specific domain. Lin et al. [105] proposed an ontology based QoS-Aware support for semantic Web services. They have composed their ontology into upper and lower level property. Tran et al. [106] propose QoS ontology to store the information and constraints of QoS properties at different quality levels and fine-grained service level. This QoS ontology allows storing QoS values from End User and system brokers. The QoS based technical indicators for this ontology are throughput, latency, response time, MTTR, uptime, failure, authentication, failover, disaster and cost. The QoS properties of the attributes are divided into two groups: required and optional. Each group can contain many sub level properties that can have different data type values such as single value types (string, boolean, enumeration and numeric), boolean and string-based type (for non-measurable QoS properties), numeric based type (for both measurable and non-measurable QoS properties) and multiple value types (range, set, list, vector). D Mello a d A a tha a a a a [107] propose an extension to the OWL-S to support the storing of QoS and business offering. The authors create functionality ontology to store all functional concepts. The authors proposed a service selection algorithm that performs the functional matching by comparing the functional concept provided by End User with the concepts of Web services based on the functionality ontology, and a matching degree is determined. Benaboud et al. [108] propose a semantic Web service discovery approach based on agents and ontologies. The framework is modelled by adding semantics of QoS attributes with Web service profiles. It describes the design and implementation of a Web service matchmaking agent. Agent uses an OWL-S based ontology and an OWL reasoner to compare ontology-based service descriptions. Moraes et al. [109] propose an ontology named as MonONTO. They have considered network performance technical indicators such as response time, availability and throughput. Their system monitors the performance of advanced internet applications. This ontology serves as a support to a decision recommendation system by providing high-level information to the End User about the compliance of the network facing the service level demands. This process is primarily accomplished through the match making of Network Characteristics against Service Characteristics individuals. These individuals are essentially concepts of QoS technical indicators. Pakari et al. [110] propose a hybrid semantic matching approach for service discovery from OWL-S ontology. The authors have enhanced OWL-S ontology by creating concepts to store End User requirements for services. They have calculated global matching score from the sum of multiplication between weights with the scores obtained from three different comparisons. These comparisons are syntactic similarity, structural similarity and semantic similarity. Chhun et al. [111] propose Web service ontology (WSOnto) as shown in Figure 10. WSOnto is composed of two parts. The first part presents services categories and the se o d pa t p ese ts se i e i fo atio . The se i e s atego efe s to the value of tModel in the UDDI registry. Service information part is composed of functional and non-functional properties. Functional properties are related to the input, output of service and service operations, while nonfunctional properties are related to QoS. QoS is further composed of performance and security. Performance based technical indicators includes availability, execution time and totalCalled, while indicators related to security are encryption, authentication and authorization.

Figure 10 : 2 . 4 . 2 Summary

 10242 Figure 10: Web service Ontology [111]

  Matrix algebra is then used to sort out variables to arrive at the best choice[115].Wua et al. [116] propose Fuzzy AHP (FAHP) and adopt the three MCDM analytical tools of SAW, TOPSIS, and VIKOR to rank the banking performance and improve the gaps with three banks. First, the authors estimate the relative importance of the chosen balanced score card indices by fuzzy AHP and then they adopt MCDM tools.Büyüközkan et al. [117] propose service quality framework. They examine the concept and factors of service quality. The authors use fuzzy AHP) for structuring to evaluate the proposed service quality framework. They present a case study in healthcare sector in Turkey to clarify the methodology.Büyüközkan et al. [118] examine the electronic service quality concept and determine the key components of electronic service quality. The authors propose electronic service quality framework by using service quality (SERVQUAL) methodology as the theoretical instrument.They provide a Web service performance example of healthcare sector in Turkey by using a combined multiple criteria decision making (MCDM) methodology containing FAHP. The work presented in this paper shows the applicability of the electronic service quality framework in explaining the complexity of aspects observed in the implementation of healthcare services via Internet.

o

  WSO2 server[122] and database of traces. ISO 25010 quality model provides both qualitative and quantitative characteristics to evaluate the performance of services. We select a list of services from the existing repository and deploy them in WSO2 server to get the traces of technical indicators. With the help of traces, the status of a service or a process can be quickly known. WSO2 server expands SBS development efforts by integrating data stores, creating composite data views, and hosting data services. With the help of this, we can easily deploy services and analyse them by integrating technical indicators. To make efficient use of WSO2 server capabilities and to exploit quality characteristics, we trail following steps. Deployment of services and processes in WSO2 server o Collection of the traces at run time o Storage of traces in the database o Evolution of traces with timestamp o Dynamic evolution of traces by ontology creation and semantic rules.

Figure 13 :

 13 Figure 13: PODSF Process

  Now, we explain the data flow of PODSF as shown in Figure14. The upper most row of the figure shows the flow of data that begins with the event of risk. Risk analysis generates risk chart and stores in the form of ontology structures. Ontology structure stores the concepts related to risk such as risk type and mitigation action. This mitigation action is inferenced in the form of semantic rules, and specific decision for risk is evaluated by performing data analytics. The middle row of the figure starts with the event of maturity. Maturity analysis formulates maturity level chart and store this information as ontological concepts in respective ontology. Mitigation action concept is advanced by the inference engine to generate semantic rules. These semantic rules are analyzed to create specific decision for maturity. The lowest row of the figure demonstrates the event of performance monitoring. Metrics are stored in the repository and extracted by respective ontologies. Ontologies are used to generate concepts and are stored in performance measurement repository. Based on these concepts semantic rules are generated by inference engine. Specific decisions for performance are made by tuning these data. All the specific decisions are formalized by running classification algorithms. Because of these specific decisions, a knowledge base is created to further tune it for generating global decisions. For this purpose, machine learning model is used.

Figure 14 :

 14 Figure 14: Data flow of PODSF

Figure 15 :

 15 Figure 15: PODSF Components and their interaction

Figure 17 illustrates

 17 Figure 17 illustrates GetSupplier service information in WSO2 server. The upper part of the figure shows the statistics of the service while the lower part displays configuration for QoS. Statistics of services represent different attributes of this service, such as name, description, service group name, deployment scope, service type, service deployed time and service up time. Configuration of QoS demonstrates the status of the service, security, reliable messaging, response caching, policies, transports, modules, operations and configuration parameters.

Figure 17 :

 17 Figure 17: GetSupplier Service Information in WSO2 server (Upper part: Service Statistics. Lower part: QoS Configuration)

Figure 18 shows

 18 information about GetSupplier service operation in WSO2 server. The upper part of the figure provides the information and statistics of the operation while the lower part displays KPI analysis graph. Information of the operation includes WSDL file versions and the endpoints used to perform this test. Statistics of operation represent different KPI analyzed in this test and their values. This test is performed to evaluate the performance efficiency in terms of time frequency and faults. For this pu pose, th ee KPI s a d th ee et i s a e a al zed. The th ee KPI s a e request count, response time, and fault count while three metrics are maximum response time, minimum response time and average response time. KPI analysis graph shows the average response time of the service in different time intervals. The values of average response time and time instance correspond to the unit of milliseconds. The analysis shows that no fault is encountered during this test. originated from the tests in the database to make it available for the next component of ontology builder.

Figure 21 :

 21 Figure 21: Methodology to Create Performance Profile As an example, we explain the structure of the service ontology (SOnt), and we show how it stores the traces of events gathered from the execution of services in WSO2 server. The domain owl classes of proposed SOnt are represented in Figure 22. This ontology has already been published [124]. SOnt facts base comprises instances of some SOnt classes and values from statistics of WSO2 application server. However, performance-based ontologies at relevant SOA layers and a composite ontology for performance-oriented decision support, will be implemented in implementation chapter. Service provider, service consumer and service host are the concepts that have already been used in the literature. Technical indicators like response time and delay are also used [125]. Further, we classify different performance levels. Each of the service and its operations are monitored. Performance level is a level at which a service network can be monitored. Performance level has various sub concepts to monitor the performance. These sub concepts are binding Level, service level, business process level and server level. Technical Indicators concept records the value and description of each of the performance based technical indicators. Each of the service and its operations are monitored. Therefore, performance indicators are recorded for both service as a whole and its operations. The various performance based technical indicators that we use are described hereafter. Response_Time is the response time of a service or operation. It has three sub concepts to record, Maximum, Minimum and Average. Request_Count shows the number of invocations of a service. Response_Count is the number of replies for an invocation of a service. Fault_Count is the number of invocations the service has not replied to. Deploy_Time is the time at which the service has been deployed on the server.

Figure 24 :

 24 Figure 24: SOA Layers Ontological Concepts

Figure 25

 25 shows ontology of performance at process layer. The six technical indicators at process layer are explained below. o Process-Response-Time: captures the response time of a composite service. It evaluates response time of atomic service that forms the composite service and measure the response time as a whole. We evaluate composite service response time by calculating the average response time of all underlying atomic services. It has three sub concepts to record Maximum, Minimum and Average response time.

Figure 25 :

 25 Figure 25: Ontology of Performance at Process Layer o Process-Up-Time: illustrates the time period the composite service is available since its deployment. We evaluate composite service up time by calculating the average up time of all underlying atomic services. It has three sub concepts to record Maximum, Minimum and Average Up time.

o

  Throughput: shows the throughput handled by protocol. It is calculated by the average response time of the protocol by number of requests. o Protocol-Response-Time: captures the response time of the underlying protocol used for the transfer of messages. It has three sub concepts to record Maximum, Minimum and Average response time. o Bandwidth: represents the bandwidth handled by protocol. It is measured by calculating the number of instances handled by protocol in time unit. o Binding-Reliable-Messaging: Messaging through protocol is measured by necessary message transformation to connect the service requestor to the service provider.

Figure 26 :

 26 Figure 26: Ontology of Performance at Integration Layer.

Figure 27 :

 27 Figure 27: Ontology of Governance Layer.o Policy: contains two types of policies that are global policy and specific service policy. Global policy is applied to all interfaces while specific service policy is for each service. Policy has elements such as service policy map and rules. Policy map contains ordered set of rules while rules are associated with class command.

Figure 28 :

 28 Figure 28: Performance Oriented Decision Support Ontology (PODSOnt)

A

  research prototype is used to build a solution, release or model in order to test a process. It is also considered as the step between the formalization and the evaluation of an idea or a solution. PODS research prototype discusses the most important algorithms of PODS and explains their workings. It introduces our research prototype implementation and discusses various features and methods. PODS research prototype is composed of two phases. These two phases are data management and decision support. Data management phase discusses the most important algorithms used to generate data related to the performance, risk and maturity of SBS. Decision support phase use these data to create training set and evaluate decisions by the help of algorithms. service. Line 26 assess the availability of compose services and return the composite service if it is available in Line 27. Line 28, 29, 30 and 31 evaluate throughput, bandwidth, failure Rate and MTTR. All performance variables, values of service instance are reported in the Performance-profile.txt text file in Line 32. Finally, the algorithm ends by returning performance profile. By the help of this profile, we can evaluate atomic or composite service that is best in terms of performance based on the preferred choice of the End User. Moreover, global performance efficiency and reliability of services can also be assessed with the help of this algorithm.

Figure 30 :

 30 Figure 30: Performance Management Algorithm

Line 1 ,

 1 2 and 3 take inference rules IR and ontological concepts of PODSOnt as inputs, in the form of sets. Line 4 indicates the output of the algorithm, which is the Risk-profile.txt text file. The Risk-Evaluation function is initiated at Line 5. Line 6 starts with a for loop to evaluate each service while Line 7 instantiates the second for loop for each invocation of service. At Line 8 the Check-Risk-level function begins. This function evaluates the risk level of services based on the threshold values. At Line 9, a third for loop calculates risk-level of services based on the inference rules IR and store this value at line 10. Risk profile with values for all service instances are reported in the Risk-profile.txt text file at Line 11, and the algorithm ends.

Figure 32 :

 32 Figure 32: Risk Management Algorithm

  major classes implemented in PODSS are shown in the package diagram in Figure 36. .lang. Gui package includes the MainFrame which is the entry point for PODSS. This class is responsible for generating the GUI of the system, and this is the main controller class that calls other classes. Second package is PerformanceOrientedDecisionSupport that includes all functional classes. The remaining classes of third package named as java.io are helper classes for different functionalities in PODSS. Fourth package is java.util that uses vectors. The advantage of vectors in Java as compared to arrays, lies in the fact that vectors expand automatically when new data are added to them. Finally, fifth package of java.lang describes the data types used as integer and string. These classes are presented and explained below.

Figure 36 :

 36 Figure 36: Package Diagram of PODSS

  Public void setServiceName (String Name) Signature: Public void public String getSLAName () Signature: Public void getSLAName (String Name) Signature: Public void public String getServiceProviderName () Signature: Public void setServiceProviderName (String Name) Signature: Public void public String getServiceConsumerName () Signature: Public void setServiceConsumerName (String Name) Signature: Public void public String getServiceHostName () Signature: Public void setServiceHostName (String Name) Signature: Public void public String getTechnicalIndicatorName () Signature: Public void setTechnicalIndicatorName (String Name) Signature: Public String getValue () Signature: Public void setValue (Double Name)

Figure 37 :

 37 Figure 37: High level Schema of PODSS Evaluation This chapter is composed of three phases. The three phases are PODSS data set, PODSS structure and PODSS evaluation. PODSS data set is supported with the analysis of public repository of shared services. PODSS structure is demonstrated with the help of use case. PODSS evaluation is carried out by formulating different scenarios or cases.

Figure 38 :

 38 Figure 38: CollaborationAnalyzer SchemaSince the application is supported by different service tasks, it is very time consuming to follow the traditional process of development. It incurs cost, time, resources and trust problems. Therefore, in the perspective of maximizing service reuse, we identify in the FIWARE for Industry portal (http://www.fiware4industry.com/) some interesting APIs to be reused. For example, 3DScan offers comprehensive modules for 3D visualization of high density or high-resolution files consisting of millions of points in the format of point clouds (.txt) and mesh (.stl). Additionally, it provides the management interface for 3D file storage with relational database. There are two open source components provided by the specific enabler that are storage and visualization. The specific enabler aims at offering assistance for performing quality controls and an intuitive visualization decision support system to determine if the analyzed manufactured part must be accepted or rejected. This service is supported by 6 API that are developed in Java. SDScan application is shown in Figure39. This figure demonstrates six services of 3DScan application. These services are get name of stored object , get source code of file , upload file delete file and update file . Get name of stored object gets the file path of the stored object. Get source code of file gets the Java script of the file. Upload file service creates new file. Delete file service deletes existing file. Finally update file service writes to the file.

Figure 41 .

 41 figure demonstrates list of all the technical indicators while second column shows data type of the corresponding technical indicator. Other columns represent average, minimum, maximum and median value for each technical indicator.

Figure 41 :

 41 Figure 41: Performance Criteria After the formulation of performance criteria, we construct a model based on classification algorithms.

Figure 42 :

 42 Figure 42: Basic Rules for the Assignment of Recommendation Weights After applying these rules for all algorithms, we get the analytics as shown in Figure 43. This analytical result shows service ID, service instance ID, values of technical indicators and recommendation based. Technical indicators values are generated based on the semantic rules defined in section 4 while recommendations are generated based on the rules displayed above in Figure 42.

Figure 43 :

 43 Figure 43: Analytics of Classification AlgorithmsAfter the construction of analytical results from all models, we evaluate them based on some parameters. The parameters that we chose to evaluate classification algorithms are predictive confidence and precision. Parametric result of classification algorithm is shown in Figure44. This result shows that decision tree algorithm is the most optimum with precision percentage of 99,8787 and predictive confidence of 99,7247.

Figure 44 :

 44 Figure 44: Parametric Result of Classification Algorithms

  For instance, we show 3DScan results based on risk level in Figure 45. This analytical result shows service ID, service instance ID, values of technical indicators and recommendation based on rules. Technical indicators values are produced based on the combined results of traces gathered from server as well as results generated in iteration 1 while recommendations are generated based on the rules displayed above in Figure 42.

Figure 45 :

 45 Figure 45: Results from 3DScan Application

Figure 47 :

 47 Figure 47: Results from Decision Tree Model Cost matrix for decision tree model is shown in Figure 48. First column of the figure shows the target weights. These target weights are MAYBE, NO and OK. The second column presents the MAYBE value for each target weight while third column shows NO value for each target weight. Finally, last column displays OK value for each target weight. From this result, we can see that there are 0 instances for the class of MayBe with MayBe. 2.6465 instances are resulted for the class of MayBe with NO and same number of instances justified the class of MayBe with OK. 1.6251 instances are resulted for the class of NO with MayBe and NO with OK while 0 instance justified for NO with NO class. Class OK with MayBe and class OK with NO justified 147.2743 instances while 0 instance fulfilled the class of OK with OK. From these results, we can see that 0 cost is benefited in case of the class MayBe with MayBe, OK with OK and NO with NO.

Figure 48 :

 48 Figure 48: Cost Matrix for Decision Tree Model

Scenario 1 :

 1 Decision Results based on priority of End User Specific decisions are made based on the priority of technical indicators specified by End User. These decision results can be provided in both graph and tabular form as desired by End User. We show a graph-based representation for the recommendation of service based on the priority of response_time as shown in Figure 49. This figure shows the response time fluctuations of service instances in different time intervals. From this graph, we recommend service who has less percentage recommendation of NO with minimum response time. Horizontal axis shows the response time values that starts with <0.0001 and ends at >=0.0009. Vertical axis shows the percentage of recommendation class NO that starts with 0 and goes until 14.

Figure 49 :

 49 Figure 49: Recommendation of Service Based on Response_Time A graph-based representation for the recommendation of service based on the priority of Service_instance is shown in Figure 50. This figure shows the service instance time deviations in

Figure 50 :

 50 Figure 50: Recommendation of Service Based on Service_Instance_Time A graph-based representation for the recommendation of service based on the priority of Throughput is shown in Figure 51. This figure shows the throughput variations in different time intervals. From this graph, we recommend service who has less percentage recommendation of class NO with less throughput percentage. Horizontal axis shows the values of throughput that starts with <1.05216 and ends with NULL. Vertical axis shows the percentage of recommendation class NO that starts with 0 and ends with 14.

Figure 51 :

 51 Figure 51: Recommendation of Service Based on Throughput Scenario 2: Decision Results based on Service Instances Second level decision interface provide a performance matrix based on the recommendation weights for all instances. A sample of decision results based on service instances is shown in Figure 52. For instance, we only show the results of six services separated by blue lines. First service involves four instances while second service involves thirteen instances. Third service is instantiated twelve times

Figure 52 :

 52 Figure 52: Decision Results based on Service Instances First level evaluation is made based on the maturity for all instances. We display a graph based representation for the maturity evaluation based on instanceID as shown in Figure 53. Horizontal axis of this graph shows the maturity levels that starts from 0 and goes until 3. Left vertical axis of this graph represents percentage of service ID that starts with 0 and goes until 120. Right vertical axis of the graph shows different service ID with instance ID in different colours. The light green colour service which is named as API157 has 100 percent instances that satisfies maturity level 2 while 1 percent instances of the same service lies at maturity level 3.

Figure 53 :

 53 Figure 53: Maturity Evaluation based on instanceID Second level evaluation is made based on the risk for all instances. We display a graph-based representation for the risk evaluation based on instanceID as shown in Figure 54. Horizontal axis of this graph shows the risk level that starts from <0.00999 and goes until NULL. Left vertical axis of this graph represents percentage of service ID that starts with 0 and goes until 70. Right vertical axis of the graph shows different service ID with instance ID in different colours. The light green colour service which is named as API157 has 60 % instances that resulted with <0.0099 risk level, 25 % instances that resulted with <0.01998 risk level, 7 % instances that resulted with <0.02996 risk level, 5 % instances that resulted with <0.03995 risk level.

Figure 54 :

 54 Figure 54: Risk Evaluation based on instanceID Third level evaluation is made based on the risk for all instances. We display a graph based representation for the risk evaluation based on instanceID as shown in Figure 55. Horizontal axis of this graph shows recommendation classes that are NO, MayBe and OK. Left vertical axis of this graph represents percentage of service ID that starts with 0 and goes until 70. Right vertical axis of the graph shows different service ID with instance ID in different colours. The light green colour service which is named as API157 has 60 % instances that resulted with NO recommendation, 39% instances that resulted with MayBe recommendation while 3% instances resulted with OK recommendation.

Figure 55 :

 55 Figure 55: Service Time Evaluation based on instanceID Scenario 3: Decision Results for each service Decision results for each service are made based on the generated results for all instances. For this purpose, we instantiate these results in ontology and semantic rules already implemented in chapter 4. As a result of this, results are generated for each service. We now present the generated decision

Scenario 4 :

 4 Global Decision based on the overall PerformanceGlobal decision based on the overall performance has also been evaluated. The parameters that we consider for global evaluation are cost, accuracy, precision and confidence. Recommendation prediction and cost analysis matrix for all instances is shown in Figure56. This matrix displays results in the form of recommendations to reuse service based on the instances. These recommendation results are based on the prediction cases of MAYBE, NO and OK. Other parameters that are illustrated in this figure are based on total instances, percentage of correct instances and cost of each prediction case. From this result, we can see that 18557 instances satisfied the case of MayBe with MayBe while 334 instances fulfilled the case of OK with OK. However, 30523 instances resulted for the case of NO with NO.

Figure 56 :

 56 Figure 56: Recommendation Prediction and Cost Analysis Matrix Parametric analysis matrix is shown in Figure 57. Parameters are statistics of average precision, global accuracy and cost for the target values of recommendation weights as well as in total for all instances.

Figure 57 :

 57 Figure 57: Parametric analysis matrix A graph-based analysis of predictive confidence is shown in Figure 58. Horizontal axis of the graph shows the decision tree classification model while vertical axis of the graph represents percentage values of confidence predictive class. This graph shows that decision tree class resulted with 100 percent confidence with increased number of services and instances.

Figure 58 : Predictive Confidence 5 . 2 . 3 Recommendations 1 . 1 .

 5852311 Figure 58: Predictive Confidence

TABLE 1 :

 1 COMPARISON OF THE EXISTING PERFORMANCE MANAGEMENT TECHNIQUES (1/2) ...................................................

TABLE 2 :

 2 COMPARISON OF THE EXISTING PERFORMANCE MANAGEMENT TECHNIQUES (2/2) ...................................................

TABLE 3 :

 3 A SAMPLE REQUIREMENT

  [8]. This model includes a concrete quality model that classifies software quality into a structured set of high-level characteristics and sub characteristics. The major characteristics of this model are functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability and portability. Among these quality characteristics, performance efficiency, reliability and maintainability related to reusability play an important role to ensure performance of service life cycle. ISO/IEC 25010 might not accommodate entirely into the Web service domain. The high-level quality characteristics of ISO/IEC do not provide

quantitative or qualitative measurements. Therefore, it is important to divide them into concepts such as response time, latency or execution time. When these concepts are clearly defined in measurable terms, they are usually known as quality metrics. As defined by Bu stei , a ualit et i is a

  Availability is measured by checking that a service or system is operational and available when needed. This can be analyzed based on quality technical indicators like service up time, service down time, request count and response count. Fault Tolerance is analyzed by checking that a service or a system operates as planned despite the incidence of faults.

Time behavior is further analyzed based on technical indicators such as response time, service or process start and end times. Resource utilization is based on CPU frequency, RAM size, storage device and maximum CPU load. Capacity is measured by throughput and bandwidth of service instances.

  This work addresses and defines processes of governance model. Joachim et al[START_REF] Joachim | The influence of SOA governance mechanisms on IT flexibility and service reuse[END_REF] classify governance into three broad categories. They identify corresponding existing governance mechanism for each category. The authors have made this classification based on a survey of 81 SOA based companies in Germany. They highlight the different kinds of governance policies used in these companies at various departments. The three categories are structure, processes and employees or relations. Governance mechanism for the category of structure includes decision making bodies, standards and roles or responsibilities. Governance mechanism for the category of process includes service management, service development and performance measurement. Governance mechanism for the category of employees or relations includes qualifications, IT or business communications, collaboration and incentives. Dan et al.[START_REF] Dan | SOA Service Reuse by Design[END_REF]

Strategy group focuses on achieving governance at strategic level. Compliance group ensures policies. Execution group handles service portfolio, service life cycle, solution composition cycle and solution portfolio. Support group handles versioning, monitoring and problem management.

Table 1 : Comparison of the Existing Performance Management Techniques (1/2)

 1

  in 1980. The method has broad applications widely used in different fields including engineering, business management, government, education, telecommunication, construction, health, and others. The method focuses on prioritizing selection criteria and distinguishing the more important criteria from the less important ones. AHP is made up of suitable techniques for prioritizing critical management problems[113]. The steps of calculation that are considered in AHP include Hierarchy Construction, Comparative Judgment Matrices; Normalization Procedure; and Weight Synthesis and Consistency Test[114]. It utilizes the judgments of decision makers to structure decision problems into hierarchies. That is, AHP constructs ranking of decision items utilizing comparisons or correlations between every pair of items constituted as a matrix. The matched comparisons generate weighting scores that measure the amount of significance items and criteria have with one another.

  If the ServiceOwner allows to use existing services, the services will be provided to the End User, otherwise, it is required to request IT Department to create a new version of the same service and SLA. Hence, a new version of the existing service will be provided to the End User. step 3. The third step is model application. In this step, existing services are monitored in the application server and they generate traces. The selected classification model is applied on these traces and generates results for service instances. The results from both steps are aggregated and transferred to step 4. Step 4 is defined as results generation. In this step, results are instantiated in the ontologies, and the reasoner generates results for each service based on semantic rules. Finally, decisions are generated in the form of recommendations to reuse existing service, create new service, check other repositories and check for resources.

Table 3 : A Sample Requirement from an End User

 3

	Requirement	Actions
	Requests for a service	Reuse existing, check number	Create new	Check resources
		of requests	service

Table 4 : A Sample Topology of Recommendation: the Call for Blood example

 4

	Topology	Aspect	Measurement	Type of Answers	Recommendation
	Business	Governance	Check Policy compliance	Compliant or not	Reuse existing service
	Functional	Call for blood	Allowed to use	Available
	Applicative	Execution time	Not delayed	OK
	Technical	Availability	Threshold values	OK
		Time		MayBe
		Risk
		Maturity

Table 5 : Quantitative Technical Indicators

 5

	Technical Indicator	Unit	Formula
	Response Time	Ms	Service End Time-Service Start Time
	Throughput	Sec	Number of active requests processed per unit time
	Bandwidth	Int per sec	Service_Instance per time unit
	Availability	%	(Response_count/ (total * 100))
	Delay	%	Service Deployed Time-Service Up Time
	service_up_time	%	(100 -service_down_time)
	Failure rate	%	Response_count-Request_count
	MTTR	Seconds	service_down_time/ no_intervals
	Service instance start time	minutes	service_deploy_time in minutes
	Service instance end time	Seconds	Stop time in seconds

Table 9 : Performance Measurement

 9

	ISO/IEC Quality	ISO/IEC sub-Quality	Type of Technical Indicators	Measurement Formula
	Characteristics	Characteristics
			Quantitative	Qualitative
	Performance	Time behavior	Response time		(Average_response_time=
	Efficiency				(service_instance_end_time) -
					(service_instance_start_time))
					Service_deploy_time in minutes
					Stop time in seconds
		Resource utilization		RAM Size/Type,
				CPU
		Capacity	Throughput		Number of active requests processed
					per unit time
			Bandwidth		Service_Instance per time unit
				Max CPU load
				Storage device
	Reliability	Availability			(Response_count/ (request_count *
					100))
			Requests count		Number of requested
			Response count		Number of answered
			Failure rate		Response_count-Request_count
			MTTR		service_down_time/ no_intervals
		Risk		Risk level	Risk Chart
		Maturity		Maturity level	Maturity Level Chart

Table 13 : Second Level Results for Service Recommendation

 13

	Technical Indicators	Level two Result	Threshold Value
	Risk_level_Service	Good	Choose the most repeated result among all instances
	Maturity_level _Service	Very Good	Choose the most repeated result among all instances

  provides the structure of PODSOnt. PODSOnt begins with service domain concept. Service domain has performance layers. Layers are highlighted by pink colour. We have already explained the concepts of performance at different layers. Now, we highlight performance and decision concepts in this ontology. Service layer has service 1 which has QoS concepts. QoS is defined by performance efficiency, maturity, risk and recoverability concepts. Performance efficiency is measured by time behaviour, resource utilization and capacity. Maturity is measured at five levels. Level 0 and level 1 are measured by service instance time while the other levels are measured by availability. Risk is measured by risk gravity, and risk gravity is measured by risk probability and severity. Recoverability has failure rate and MTTR. MTTR is measured by service down time and time intervals. Failure rate is measured by service instance response count and total service instance response count. Service has decision concept. Decision is measured by service instance ID and total service instance ID. Decision has result and result is defined by class OK, class MayBe, and class NO. If the result is OK then it means that service is recommended for reuse else if result is MayBe, service maybe recommended and finally, if result is NO then service is not recommended.

Table 14 : Inference Rules (IR) (1/2) Technical indicators SWRL Rules Availability

 14

	Available_Memory	swrl:difference(Memory_Allocated,Memory_Usage,?x)
		->Available_Memory(?x)
	Risk_Gravity	swrl:multiply(Probability,Severity,?x)->Risk_Gravity(?x)
	Maturity_level_0	swrl:equal(Service_Instance_Time,0,?x)->Maturity_Level0(?x)
	Maturity_level_1	swrl:greater(Service_Instance_Time,0.00000001,?x)-> Maturity_Level1(?x)
	Maturity_level_2	swrl:greater(Availability, 98.999,?x)->Maturity_Level2(?x)
	Maturity_level_3	swrl:greater(Availability, 99.99,?x)->Maturity_Level3(?x)
	Maturity_level_4	swrl:equal(Availability, 100,?x)->Maturity_Level4(?x)

swrl:divide(Total_Response_Count,Total_Request_Count*100),?x) -> Availability(?x) Throughput swrl:divide(no_of_active_request,Average_Response_Time,?x)-> Throughput(?x) Delay swrl:difference(Service_Deployed_Time,Service_Up_Time,?x)->Delay(?x) Response_Time swrl:difference(Service_End_Time,Service_Start_Time,?x)-> Response_Time(?x) Bandwidth swrl:divide(service_instance,Time,?x)->Bandwidth(?x) Failure_Rate swrl:difference(Request_Count,Response_Count,?x)->Failure_Rate(?x) MTTR swrl:divide(Service_Down_Time,No_Intervals,?x)->MTTR(?x) Service_Time swrl:sum(Service_Start_Time,Service_End_Time,?x)->Service_Time (?x) Total_No_of_Service_Instances swrl:sum(Service_Instance_ID,?x)->Total_Service_Instances (?x)

Table 15 : Inference Rules (IR) (2/2) Decision Variables SWRL

 15

	Count_Service_Instance_ID	Service_Instance_ID (? p) ^ hasResult(?p, ?OK) -> swrl:count(?OK)
	_Recommendation_OK
	Count_Service_Instance_ID	Service_Instance_ID(?p)^hasResult(?p,?MayBe)-> swrl:count(?MayBe)
	_Recommendation_MayBe
	Count_Service_Instance_ID	Service_Instance_ID (?p) ^ hasResult(?p,? NO) -> swrl:count(?NO)
	_Recommendation_NO
	Set_ Service_Recommendation	swrl:greater(Count_Service_Recommendation_NO,
		(Count_Service_Recommendation_OK^
		Count_Service_Recommendation_MayBe),?x)-> Set_Recommendation (?NO)
	Set_ Service_Recommendation	swrl:greater(Count_Service_Recommendation_OK,
		(Count_Service_Recommendation_NO^
		Count_Service_Recommendation_MayBe),?x)-> Set_Recommendation (?OK)
	Set_ Service_Recommendation	swrl:greater(Count_Service_Recommendation_MayBe,
		(Count_Service_Recommendation_OK^ Count_Service_Recommendation_NO),?x)->
		Set_Recommendation (?MayBe)

Table 16 : Maturity Evaluation based on CMMI Levels

 16 Maturity evaluation part explained the implementation of maturity estimation at the five stages of CMMI. Now, we describe the implementation of risk management and computation of risk mitigation actions.

	CMMI Level	Course of Action	Percentage Threshold
	Initial	No control, no reliable service or process	15 %
	Managed	Modelled	30 %
	Defined	Tasks and roles are defined	55 %
	Quantitatively Managed	Systematic measurement	75 %
	Optimizing	Repetitive improvement	100 %

Table 17 : Risk Assessment and Mitigation

 17

	RISK		Assessment	Mitigation Action
	Loss of service		Network problems	Use of alternative service
	Specification changes		Format change or loss of service	Discovery of new service
	Unexpected	service	Analysis of published service specifications Service testing
	behavior

Table 18 : Decision Result for each service Attributes Recommendation Service 1 NO

 18

	Service 2	NO
	Service 3	May Be

Table 2: Comparison of the Existing Performance Management Techniques (2/2)

We explain the methodology of PODSF components and conceptual implementation of each component step by step in forth coming parts A, B, C, D, E and F. In addition, we explain the input, output, technology, models and algorithms that are used by each component.

Reusability in SDLC

The first dimension in which reusability plays a vital role is SDLC. Software reuse has been used in the context of object-oriented programming and component-based development. The primary mechanism for achieving reuse in object-oriented programming is inheritance. Inheritance creates strong dependencies such as coupling among application objects. A variety of approaches have emerged to guarantee reusability for SDLC phases. Aversano et al [START_REF] Aversano | Business Process Aware Identification of Reusable Software Components[END_REF] propose an approach to identify reusable components in software systems by analyzing the business processes that use them. The authors intend to obtain services from existing pieces of code. They extract o po e t s code from the existing software systems by identifying those ones that support the business process and candidate them for implementing a service. For this reason, they exploit the recovery of the links existing between the business process model and the supporting software systems.

Reusability in Service Life Cycle

The second dimension is to guarantee atomic services reuse and composite services. Feuerlicht and Lozina [START_REF] Feuerlicht | Understanding Service Reusability[END_REF] list three principles for service reuse: service coupling, service cohesion and service granularity. They define service reuse as the ability of a service to participate in multiple service compositions. They closely relate service reuse to service composability. Perepletchikov et al. [START_REF] Perepletchikov | Cohesion Metrics for Predicting Maintainability of Service-Oriented Software[END_REF] propose an approach that measures cohesion of service. This approach is applied at design time for service interface. They highlight cohesion in the context of service interface data, usage, implementation and sequential. This approach does not consider XML-based service description language and business process definition languages. This approach mainly concerns service consumer for the utilization of the service. BPEL process reuse is also promoted in organizations and SOA solutions with the aim of reducing effort and change. Xue et al [START_REF] Xue | A Graph Based Technique of Process Partitioning[END_REF] propose a technique of process partitioning. The authors construct decentralized service compositions from the code and provide a graph transformation-based approach. They also discuss some issues about decentralized service compositions and performance tests of service compositions. From the experimental results, the authors show that this technique have lower average response time and higher throughput in runtime environment as compared to centralized composition approaches. Khoshkbarforoushha et al. [START_REF] Khoshkbarforoushha | A metric for composite service reusability analysis[END_REF] propose an approach for evaluating reuse of a composite service. This approach provides analysis based on logic and description mismatch. They propose a metric formula to decide the probability of a service to be reused. The authors applied this metric on a BPEL process. Choi et al. [START_REF] Choi | A quality model for evaluating reusability of services in SOA[END_REF] present a model for reuse of atomic services in SOA. This model is based on the metrics of business commonality, modularity, adaptability, standard conformance, and discoverability of services in SOA. The authors The above discussion yields to integrate all proposed solutions together in the form of framework called PODSF. We discuss PODSF below in detail, including its technical environment, components interactions in the form of input, and output and description of components in the form of conceptual implementation.

PODSF

We propose PODSF to provide efficient decision support based on performance as shown in Figure 12.

This figure is separated into two parts. The upper part of the figure shows conceptual implementation of the components while the lower part presents the s technical environment of PODSF. attributes to measure the degree to which the service is operational. Maturity is evaluated through the CMMI method which defines the level of service or process control at a particular instance. We consider that a mature process is generally one that moves from an unstable state to a stable state. A higher level of maturity in the service or process will result in better control of results, improved goal prediction, and greater effectiveness in achieving goals. We evaluate maturity based on the availability of a service or a process using CMMI levels. We choose the CMMI levels because of the efficient method for assessment and evaluation of the service or process. The formula to calculate maturity at each level is shown below.

B. Traces Handler

Traces handler provides status report of services and processes at run time.

Consumed_By

Captures the relationship of each service consumed by its consumers.

Has_Attributes

Each service has some attributes (Estimated_Attributes). It is linked to the attributes by this property.

Has_Indicators

The performance of each service is monitored via various KPI, and this property links service with KPI concept.

Has_Performance_Level

Makes the relation between service concept and the performance level.

Hosted_By

It captures the relation between each service and its host.

Measured_At

Each service is monitored and performance is measured at the performance level (Performance_Level).

Measured_By

Each service QoS is measured by the QoS metrics (QoS_Metrics) via this property.

Provided_By

Captures the relation of each service provided by its provider.

A service concept has some datatype properties to capture different attributes in the SOnt as shown in Table 8.

Description

Captures the description about the service.

Group_name

Records the Name of the group to which the service belongs.

Deployment_Scope

Captures the deployment scope of the service.

By the help of these concepts and relationships, reasoner component will generate semantic rules to infer new knowledge. These rules are identified in relative to the diverse usage scenarios. Dynamic nature of ontology allows to integrate or aggregate new concepts and can evolve with time. As a result, semantic rules can also evolve.

D. Reasoner

Reasoner component generates and publishes inference rules in SWRL. It uses SPARQL queries to support the decision making. Ontologies support the decision through interaction via queries. This component uses ontological concepts values and generate inference rules. It customs aggregated QoS functions like divide and difference, that can be easily defined and managed. These rules help to detect performance degradations. Since we create inference rules by using ontological concepts, therefore inference rules can also evolve with different time stamps and with the new requirements. We create a knowledge base of inference rules. For instance, we present inference rules based on the ontological concepts defined for technical indicators at WSO2 server in. Figure 23. Note that these inference rules have already been published [126]. We will expand this knowledge base in the implementation section. We show the inference rules that use the concepts of SOnt ontology, and that are mainly based on WSO2 server metrics. Those SOnt concepts are total response count, total request count, service deployed time, service up time, memory allocated, memory usage, no of successful invocations, total no of invocations, total response count and average response time. Inference rules are generated for the computing of availability, delay, memory available, reliability and throughput. Following is the description of these rules. Availability is calculated as the total response count of a service or process divided by total request count of a service or process. If the requested service is available, then we can suggest reusing this service. Delay is measured as the difference of service_deployed_time and service_up_time. Memory available is measured as the difference of memory usage and memory allocated. Reliability is calculated as no_of_successful_invocations divided by total_no_of_invocations.

Throughput is calculated as the total_response_count divided by average_response_time.

Reasoner component provided the knowledge base of semantic inference rules. This knowledge base is useful to evaluate performance of services and helps to provide decision support in dynamic environments. Furthermore, this component stored this knowledge base so that the next component of process assessment analyzer can retrieve it for data discovery and data analysis.

E.

Assessment Analyzer

Assessment analyzer component encompasses two steps. The two steps are data discovery and data analysis. Data discovery step involves the discovery of inference rules from database and the training of these data. Data analysis step evaluates the deployed services and processes on the basis of this

Maturity_level _service_ instance_3

Very Good 4

Maturity_level _service_ instance_3

Very Good 4

Maturity_level _service_ instance_3

Bad 1

First level results for service instances provide results based on all instances for all technical indicators.

We show a sample result for risk level and maturity level evaluation for service instance 1, 2 and 3. We remark that two results are marked as Good while one is marked as Bad, based on the threshold value defined for risk. Similarly, maturity level is evaluated as Very Good for two instances while it is marked as Bad for one instance. These results vary according to the threshold values defined for each technical indicator.

After generation of results for all the instances of the services, results are calculated for each service.

A sample of second level results for service recommendation is shown in Table 13. In this table, we calculate the most repeated result among all instances. Based on the illustration of Table 12, risk level for service is recommended as Good as it is repeated two times. We observe the same configuration for maturity level which is recommended as Very Good based on its repetition of two times. We complete this evaluation for all technical indicators and generate a global performance decision.

CHAPTER 4. Implementation of PODSF

This chapter is dedicated to the implementation of PODSF. It brings together the integration of all the components of the framework to build a performance-oriented decision support system. The main functionality is to implement DS Framework automatically to provide efficient decision support to recommend the most optimum service in terms of performance and compliance to its governance policy.

The PODSF implementation is discussed in detail by including its three phases. The three phases are PODS research design, PODS research prototype and PODS system. PODS research design phase is aided with the implementation of PODS ontology structuring and PODS reasoning. PODS research prototype phase is dedicated to the implementation of the algorithms of the system. PODS system phase is committed to the automation of PODS research prototype.

PODS research design phase is composed of two parts. These two parts are PODS ontology structuring and PODS reasoning. PODS ontology structuring discusses the implementation of service domain ontology and performance-based ontologies. Performance based ontologies are implemented for process, integration and governance layers of SOA. Finally, a composite performance-oriented decision support ontology is implemented to generate a performance profile and to provide decision support.

This ontology aggregates proposed ontologies and extends the performance and decision support concepts at service layer. PODS reasoning generates a knowledge base of semantic inference rules by using the ontological concepts mentioned in PODS ontology structuring phase. This knowledge base is used to generate decisions in different iterations.

PODS research porotype phase is composed of two parts. These two parts are data management and decision support. Data management part is supported by the implementation of three algorithms.

These three algorithms are performance management algorithm, maturity evaluation algorithm and risk management algorithm. Decision support part is aided by the implementation of three algorithms.

These three algorithms are performance evaluation for specific decision algorithm, impact analysis of new consumption algorithm and decision evaluation algorithm.

PODS system phase is organized into two parts. These two parts are high level architecture of PODS system and PODS system classes. High level architecture of PODS provides the architecture detail of

Data Management

Data management is the preparation of shaping and sustaining data progressions to meet ongoing information lifecycle prerequisites. In order to provide better analytics and flexibility in the data manipulation, the data must be measured and managed statistically. By correctly managing and preparing the data for analytics, decision can be made efficiently. Therefore, the efficacy of decision support system relies heavily on the way the data is managed.

Data management is divided into three parts based on its implementation. The first part shows and describes the implementation of performance management. The second part displays and explains the implementation of maturity evaluation. The third part illustrates and explicates the implementation of risk management.

A. Performance Management

Performance management is performed based on the End User requirement and priority. The implementation of performance management is shown in Figure 30

B. Maturity Evaluation

Maturity evaluation is also performed based on the End User requirement and priority. Maturity 14 and Table 15, Section 4.1.2. The evolution of maturity along the five levels of CMMI is taken into account in these inference rules. They are represented by the five rules in Table 14. Maturity of the service or process is computed by providing a threshold percentage value as shown in Table 16. For each level, the appropriate ponderation is associated in

A. Performance Evaluation for Specific Decision

Performance evaluation for specific decision provides decision based on performance, risk and maturity. The performance evaluation for specific decision algorithm is shown in Figure 33 In this part, we explained the implementation of performance evaluation for specific decision.

Decisions evaluation is performed based on the priority of End User. This kind of decision is called specific decision. Specific Decision is computed based on classification algorithms. Result of the most optimum algorithm has been taken into consideration. Hence, decision is now tuned based on the priority of End User. After performance evaluation, we explain the implementation of impact analysis in the following part to evaluate a global decision.

B. Impact Analysis

Impact analysis evaluates global decision based on performance, risk and maturity by increasing the consumption of services. The impact analysis algorithm is shown in Figure 34. The algorithm begins with inputs and outputs. Line 1 and 2 take inputs as PODSOnt ontology and impact analysis text file. In this part, we analyze decision evaluation based on all service instances. Now, we explain the evaluation of decision based on each service.

C. Decision Evaluation

The decision evaluation part creates a decision matrix based on both specific and global decisions. The decision evaluation algorithm is shown in Figure 35. This algorithm begins with inputs and outputs. In this part, we have explained PODS research prototype that provided the algorithms of data management and decision support. In the next part, we will explain the automation of this prototype.

PODS System

PODS system (PODSS) is the implementation of PODS research design and PODS research prototype.

In this part, we discuss the implementation of all the major classes. PODSS is aided with the data management and decision support algorithms discussed above in section 4.2 for the generation of specific and global decisions.

PODSS High Level Architecture

PODSS takes rdf file as input. This rdf file contains the ontological concepts and inference rules. An XML specification has been generated from this rdf and stores in the object. After this, classification has been applied to generate specific decisions. Finally, generic decisions have been made for each service. The six components of the architecture are presented below.

SemanticXMLGenerator

PODSS creates semantic XML specification from the ontological concepts and inference rules presented in section 4.1. This generator generates XML from RDFconcepts, classes and properties of ontologies.

SemanticXML Reader:

The reader reads the SemanticXML specification and stores it in an object. The reader object stores the XML information from the SemanticXML specification in the form of vectors. The advantage of vectors in Java compared to arrays, lies in the fact that vectors expand automatically when new data are added to them.

Classifier:

The classifier takes SemanticXML object from the SemanticXML reader as input. It applies classification algorithms on the data gathered from SemanticXML object and evaluate performance for services instances and generates specific decisions. Specific decisions are also generated based on the priority of technical indicator specified by the End User.

Impact Analyzer:

The impact analyzer takes specific decisions from the classifier as input. It uses the impact analysis algorithm and generates global decisions. Global decisions are based on the overall evaluation of the performance with the increased consumption of services.

Decision Generator:

The decision generator takes the results of classifier as input and generates results for each service.

Decisions are stored in the form of identitity matrix to recommend the most optimum service in terms of performance. It uses the decision evaluation algorithm and generates recommendations.

The ApplyDecisionTrees function reads technical indicators information of the SemanticWSDL objects from the SemanticWSDLParser class. This function applies decision Trees classification algorithm.

Signature: public void ApplyDecisionTrees ()

ImpactAnalyzer

The ImpactAnalyzer class applies proposed impact analysis algorithm and generates global decision.

Signature: public class ImpactAnalyzer

DecisionGenerator

The DecisionGenerator class applies proposed decision evaluation algorithm and generates decision matrix. It has one main function.

Signature: public class DecisionGenerator

CreateMatrix

The CreateMatrix function generates the matrix which shows recommendations for most optimum service in terms of performance.

Signature: public void CreateMatrix ()

Discussion

In this chapter, we have presented the implementation and important algorithms of PODS.

Implementation of PODS has been made on the basis ontologies, reasoning rules and PODS algorithms.

We provide algorithms for performance, risk, maturity, analytical assessment, impact analysis and decision support. Performance based ontological graphs provide fast retrieval and exploitation.

Inference rules are provided by using ontological concepts to generate knowledge base of performance profile and decision. This knowledge base is used to perform data discovery and analytical assessment by using classification algorithms to provide aggregation rules. We compare the result and select the optimum classification algorithms result which is decision tree in this case. From this analytical assessment, we get the trends of performance based technical indicators as a result. We analyze the performance of services with different time stamps and provide a decision chart. We also analyze the impact of consuming more services and a trend of overall performance under different consumption loads to make a generic decision for service reuse. We automate the whole process of performance oriented decision support in java language and developed a system that has used The above defined use case of business process can reuse services of this 3DScan application based on the performance evaluation of services. We now explain the use case implementation for performance evaluation.

Use Case Implementation

Use case implementation includes the evaluation of the whole proposed approach. To validate the proposed concepts and implementation details described in the previous sections, we gather QoS web services inputs from two public repositories (https://github.com/wsdream/wsdream-dataset). Use case implementation is shown in Figure 40. This figure shows the overall evaluation process. The proposed validation was conducted in an agile and incremental approach. On the one hand, the ontological models are instantiated for the raw data as well as for the traces results. On the other hand, data mining techniques have been applied to generate first level results. Final results involve the evolution of ontologies and semantic rules for service reuse. First, raw data of service instances from the existing repository of shared services is instantiated in the proposed ontologies and semantic rules. After this, three classification models have been applied.

From these results, we chose the model that generates the most optimum results. Secondly, we deploy application in the performance monitoring server, generates traces and applies the selected model.

We consolidate the both results generated from the selected model in the first level as well in the second level. Final consolidated results are based on service instances are instantiated in the ontology in order to generate aggregation rules for each service. Finally, we get the results for each service based on which we provide decisions to the End User in terms of atomic or composite service reuse recommendation. We now explain the data analytics generated at each level of use case implementation.

Data Mining Analytics

Data mining analytics step involves the application of machine learning approach. We chose classification algorithms of machine learning approach in order to analyze the generated semantic rules and traces to get the performance evaluation results for services. Tests are performed in two iterations.

Iteration 1:

After getting results for each technical indicator, the resulted decision tree model is shown in Figure 46. Links between all nodes are generated based on implemented predicates. Node 0 is linked to node For the validation of this research work, a case of application in the SOA industry has been treated in this chapter with a network of partners. On the other hand, the case study described, although simplified, allowed us to illustrate the use of the PODSS and the real interest of such a tool in the complement of the analysis of the SBS over time. We have seen examples of scenarios leading to problems and the contribution of our proposal in the responsiveness of the decision making in terms of the evolution of performance efficiency, availability, maturity and risk for service reuse.