Tehreem Masood

Chantal Bonner Cherifi

Néjib Moalla

Muhammad Fahad

Performance Oriented Decision Making to Guide Web Service Lifecycle

Keywords: Service Network Monitoring, Decision Support, Ontology, Performance, Technical Indicators

Service composition networks are becoming increasingly important and more critical for the enterprise collaborations. The sustainability of service based systems is driven with the support of performance metrics analysis for decision making. Some of the existing works only focused performance at messaging level. Ontology based performance monitoring techniques did not provide the recommendation model for better quality of service. In this paper we propose a semantic service recommendation framework (SSRF) based on Service Networks Monitoring (SNM) concepts. This framework includes creation of Service Network Monitoring Ontology (SNMOnt), extracting traces of technical indicators for services and storing decision data in the existing database. The decision support covers the unavailability of service and recommendation of services based on technical indicators. Our framework is meant to support the creation of shared domain knowledge ensuring an optimal decision making system for web service lifecycle.

Introduction

Service-Oriented Architecture (SOA) is an emerging cross-disciplinary paradigm for the distributed and service oriented computing [START_REF] Gottschalk | Introduction to web services architecture[END_REF]. One of the challenges in SOA is to provide an efficient way to discover compatible Web services and compose them into business process. It is important to create dynamically scalable business processes and guarantee their performance, availability, reliability and throughput to be used by internal and external partners. Selecting the most significant web service according to a consumer requirement is a challenging task. Technical indicators needs to be considered when there are several functionally similar web services. Semantic web uses the notion of ontology's for the creation and elicitation of domain knowledge [START_REF] Antoniou | A Semantic Web Primer[END_REF]. Ontology's represent formal specifications about the component of systems and their relationships in a machine understandable and processable manner [START_REF] Fahad | A Framework for Ontology Evaluation[END_REF]. They have played an important role in both semantic web applications and knowledge engineering systems [START_REF] Gomez-Perez | Ontological Engineering: With Examples from the Areas of Knowledge Management, E-Commerce and the Semantic Web[END_REF]. Several tasks such as information storage, processing, retrieval, decision making etc. are done on the basis of ontologies by such systems. The problem of providing seamless decision making capabilities based on the new project requirements of users is very important. There are different levels of performance in the service network monitoring like binding level, service level, server level and business process level. Business process level is used for the performance analysis at the composition of service [START_REF]Documents Associated with Business Process Model and Notation (BPMN) Version 2.0[END_REF]. Binding level covers the performance at the protocols level [START_REF]Simple Object Access Protocol (SOAP) 1.2, Part 0, Primer[END_REF]. Service is composed of different operations. Performance can be monitored at both the service and different operations level. Server level covers the performance of resources available. Current research support specific activities, but do not fulfil the requirements of all the activities in the Service-based System's lifecycle. Different technologies are available that can be effectively utilized for better performance of services. Now-a-days, WSO2 application server is widely being used for the deployment of web services. It has sophisticated infrastructure to capture statistics at operation, service and server level [7]. Our objective in this research is to provide decision support combining service/process technical indicators in order to generate validation arguments for the expansion of the service environment. Therefore in this paper, we propose SSRF based on the SNM. We provide decision support that covers the unavailability of services and recommendation of services based on technical indicators. The proposed model integrates the following building blocks. The first block is the identification and classification of performance metrics from Information Technology Infrastructure Library (ITIL) [START_REF] Donna | A Guide to Service Desk Concepts: Service Desk and the IT Infrastructure Library[END_REF]. Second block is to structure the performance based technical indicators for atomic service, business process, server and binding. For this purpose we design a sophisticated SNMOnt as a base infrastructure. It aggregates the main concepts and relationships between them. QoS requirements, service domain concepts, technical indicators and performance levels are the major concepts. Third block is the decision support based on some inference rules like availability, reliability, throughput, memory available and delay. The remaining of the paper is organized as follows: Section 2 includes related work of different frameworks. Section 3 discusses our proposed approach. We conclude the paper in the last section.

Related works

There are different categories of techniques available that can be effectively utilized in order to provide better performance of service-oriented networks. Therefore related work section has two dimensions. First, we study techniques related to the performance issues of web services. Second, we include ontology based QoS monitoring techniques. Third, we provide analysis of techniques of both sections.

Performance based Web services Techniques

In this category we will discuss some techniques that have been proposed to ensure performance. While analyzing these techniques, it has been observed that all these techniques only focused the binding level performance. Tari et al. proposed a benchmark of different SOAP bindings in wireless environments. Three sets of experiments were carried out: loopback mode, wireless network mode and mobile device mode. The experimental results show that HTTP binding inherits very high protocol overhead (30%-50% higher than UDP binding) from TCP due to the slow connection establishments and tear-down processes and the packet acknowledgement mechanism. UDP binding has the lower overhead because it does not require establishing connections before transmitting datagram's and does not address reliability. This results in a reduction in the response time and an increase in the total throughput. Its configuration and results can serve as a standard benchmark for other researchers who are also interested in the performance of SOAP bindings in wireless networks [START_REF] Phan | Benchmarking Soap Binding. On the Performance of Web Services[END_REF]. Tari et al. proposed a similarity-based SOAP multicast protocol (SMP) which reduces the network load by reducing the total generated traffic size. It is based on the syntactic similarity of SOAP messages. In particular, the SMP reuses common templates and payload values among the SOAP messages and only sends one copy of the common part to multiple clients. SMP makes use of the commonly available WSDL description of a SOAP Web service when determining the similarity of response messages. For messages that are highly similar, instead of generating messages with duplicated similar parts for different clients, the duplicated parts are reused for multiple clients and are sent only once from the source [START_REF] Phan | The Use of Similarity & Multicast Protocols to Improve performance[END_REF]. Tekli et al. conducted an extensive review of XML processing in the context of SOAP-based web services. The review analysed different techniques to improve performance in XML serialization, parsing and deserialization. Delay distributions model the distribution of waiting times that represent the time needed to complete a given task, such as, the time necessary to execute an operation, to parse an XML input message, or to build a SOAP output message. Distributions of waiting times are specified using the results of the service testing on the total operation execution time [START_REF] Tekli | SOAP processing performance and enhancement[END_REF].

Ontology based QoS Monitoring Techniques

We have narrow down our related work with respect to ontology because of its various advantages. Several tasks such as information storage, processing, retrieval, decision making etc. are done on the basis of ontologies by such systems. In this section we list ontology based research that focuses on quality of services. Lin et al. proposed an ontology based QoS-Aware support for semantic web services. They have used ontology to describe Quality of service metrics. They have composed their ontology into upper and lower level property. They have not considered the input/output operations. They have not included real time values for the performance analysis to reach towards optimal web service [START_REF] Lin | Ontology-based QoS-aware support for semantic web services[END_REF]. Moraes et al. designed an ontology named MonONTO for proposing recommendation for the advanced internet applications users. They have considered information concerning the application type, traffic generated and user profile along with network performance metrics. Their expert system monitors the performance of advanced internet applications. Their ontology serves as a support to a decision reference tool by providing high-level information to the user about the agreement of the network facing the service level demands. They have used a fixed list of network parameters. Therefore, it does not deal with the heterogeneity and extensibility issues. Implementations of web services have not been done by them. Additionally, it does not deal with quality of service mapping [START_REF] Moraes | Mononto: A domain ontology for network monitoring and recommendation for advanced internet applications users[END_REF]. Benaboud et al. proposed Semantic Web Service Discovery Based on Agents and Ontologies considering the fuzzy constraints. Their framework is modeled 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. They have used fuzzy constraints increases the efficiency of the web service discovery approach by providing the customers the web services which are not actually satisfying the input QoS constraints, but are close to the QoS constraints specification [START_REF] Benaboud | Semantic Web Service Discovery Based on Agents and Ontologies[END_REF].

Analysis

The experimental results of the first technique of section 2.1 shows that HTTP binding acquires very high protocol overhead in terms of response time from TCP due to the slow connection establishments. UDP binding has the lower overhead in terms of response time because it does not require establishing connections before transmitting datagram's. Results for the second technique of section 2.1 shows that SMP has medium response time, throughput and network traffic. The third technique of section 2.1 is a survey of XML processing in the context of SOAPbased web services. All these techniques are related to the performance of web service at binding level which we can utilize in proposed framework. The focus of our research work is at the infrastructure level covering service, server, binding and business process level. Section 2.2 covers the techniques that are related to ontology based QoS monitoring. First technique of this section has not considered the input/output operations. Second technique of this section is related to the ontology of performance at the network traffic level. The third ontology based technique is specific to the monitoring of agent based systems. To be effective, QoS evaluation approaches should rely on models representing the systems in an accurate/realistic way, and whose parameters can be adjusted at runtime according to measured data. Therefore we propose a semantic service recommendation framework that infers decision support at the infrastructure level. Infrastructure level covers the service, server, binding and business process level.

Proposed Approach

This section presents SSRF to recommend the services based on technical indicators requested by the consumer. Figure 1.1 illustrates SSRF. First of all, user send request to consume existing service. Second step has two parts. First part is to get traces or events from application server. First we deploy services and BPEL in the WSO2 server. Server stores values of technical indicators in some database. Second part includes the design and instantiation of SNMOnt by storing the values of technical indicators. It aggregates the main concepts and relationships between them. Third step is the decision support. Decision support constitutes some inference rules. Inference rules includes availability, reliability, throughput, memory available and delay. Based on these rules, proposed SSRF generates some recommendations like reuse existing service, service is not available and physical resource is not available.

Service Network Monitoring Ontology (SNMOnt)

We define an ontology named as SNMOnt in order to store the traces of events gathered from the execution of service/business process in WSO2 server. We use some concepts from the literature as well as define some new concepts. 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 [START_REF] Chhun | A multi-criteria service selection algorithm for business process requirements[END_REF]. But the technical indicators that we show in our ontology are specific to WSO2 server. Further we classify different performance levels. Performance Level concept uses the level where service network can be monitored. It has various sub concepts such as binding level, service level, business process level, and server level. Each of the service and its operations are monitored. Response Time captures the response time of a service/process. It has three sub concepts to record Maximum, Minimum and Average response time. Request Count shows the number of invocation of a service. Response Count shows the number of replies for an invocation of a service. Fault Count shows the number of invocations the service has not replied. Deploy Time shows when the service is deployed at the server. Up Time shows the time period the service is available since its deployment. Down Time shows the time period of un-availability of a service since its deployment. Delay shows the average response time of a service. Loss shows that the service is un-available. Data properties that are used to link concepts are shown in Fig 1 .3. Consumed_By relationship captures the relationship of each service consumed by its consumers. Has_Indicators relationship describes that performance of each service is monitored via various technical indicators. Hosted_By relationship captures the relation of each service hosted by its Host. Measured_At relationship describes that each service is monitored and performance is measured at the Performance_Level. Provided_By captures the relation of each service provided by its provider. We design our SNMOnt in Protégé 5 and uses jess reasoner to verify its consistency to avoid all types of ontological error [16]. 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 visualization and generates OWL code automatically.

Concepts

Decision Support

We use SNMOnt concepts values and generate inference rules. SNMOnt 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 for the 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/business process divided by total request count of a service/business process. If the requested service is available then we can reuse 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 number of successful service operation invocation divided by total number of service operation invocations. Throughput is calculated as the total response count divided by average response time. Figure 1.4 shows these inference rules that compose the knowledge organization originated from the relationships between SNMOnt concepts. We use aggregate QoS functions (like divide, difference) that can be easily defined and managed. Based on these rules we recommend that "the selected service or business process is available or not", "reuse existing service","delay of a deployed service or business process", "memory is available or not to support the new deployment", "reliability of a service or business process in terms of service operation invocations" and "throughput of a service or business process". We store decision data in existing database to deploy decision. We define these rules using SWRL (Semantic Web Rule Language) [START_REF] W3c | Semantic Web Rules Language[END_REF] in Protégé. Future recommendations will include "service composition is not possible" and "security compliance problem in the deployment".

Technical Indicators SWRL Rules

CONCLUSION

In this paper, we focus on how to accomplish and improve enterprise business and IT together. We propose a framework named as SSRF based on the SNM. This framework includes the extraction of traces of technical indicators for services or business process, design of ontology named as SNMOnt, instantiating ontology by values of technical indicators, providing decision support based on inference rules and storing decision data in the existing database. Proposed framework generates recommendations like service availability, reuse existing service, delay of a deployed service, memory is available or not to support the new deployment and reliability in terms of service operation. The use of the framework aims at increasing particularly the alignment of the requirements and of the objectives of the enterprise business and IT in decision making. We will enhance our work to cover the recommendation of service composition and security compliance problem. We will implement our work by using real time case study.

Fig. 1 . 1 .

 11 Fig.1.1. Semantic Service Recommendation Framework (SSRF)

Fig

Fig. 1 . 2 .

 12 Fig.1.2. Service Network Monitoring Ontology (SNMOnt)

Fig. 1 . 4

 14 Fig.1.4 Inference Rules using SWRL


Tehreem Masood
email: tehreem.masood@univ-lyon2.fr

Chantal Cherifi
email: chantal.bonnercherifi@univ-lyon2.fr

Néjib Moalla
email: nejib.moalla@univ-lyon2.fr

Performance Monitoring Framework for Service Oriented System Lifecycle

Keywords: Web Services, Service Oriented System, Quality of Service, Ontology, Technical Indicators and Performance

Service oriented systems are highly dynamic systems composed of several web services. One of the most important challenges in service oriented systems is to deliver acceptable quality of service. For this purpose, it is required to monitor quality of service along different activities of service oriented system. Existing research focuses on specific activities but do not take into account all the activities of service oriented system together at the infrastructure level. In this paper, we present performance monitoring framework to provide support for the whole service oriented system lifecycle. Our framework integrates several ontologies to monitor the performance of service oriented systems in order to ensure their sustainability. We design a base Service Monitoring Ontology that captures all the information about the service domain.

Along with that we design ontologies for technical indicators at service level, binding level, composition level and server level. We conduct a performance evaluation over real web services using suitable estimators for response time, delay, loss and more.

INTRODUCTION

For many companies using big data path, collecting data has been a costly exercise with varying degrees of risk factors. Using big data is time consuming and hence lacks reactiveness which is not acceptable in real time decision making [START_REF] Agrawal | Challenges and Opportunities with[END_REF]. These days understanding how real-time external data sources benefit an organization is vital. Service oriented systems are highly dynamic systems composed of various web services providing by different service providers [START_REF] Andrikopoulos | State. of the art report on software engineering design knowledge and survey of HCI and contextual knowledge[END_REF]. These systems are based on service oriented architecture (SOA) which provides interoperability, reusability, composition of web services and loose coupling [START_REF] Erl | Soa: Principles of service design[END_REF]. SOA allows realizing business processes by recursively combining services into orchestrations [START_REF] Weerawarana | Web Services Platform Architecture[END_REF]. The business process is then itself exposed as a service to consumers. The standard language for service orchestration based on Web services is BPEL (BPEL 2.0 2007). Service oriented architecture is used as a means to develop adaptive distributed software applications in a reactive manner. We can now develop techniques which take into account key data points to arrive at a more accurate real time predictions. An important aspect in the service oriented system lifecycle is management of the performance along its lifecycle. Performance requirements on service or business processes are specified as technical indicators with target values which are to be achieved in a certain analysis period. Typical technical indicators are service duration, process duration, service response time, process response time and more. Due to the dynamic nature of service oriented systems, it is required to monitor Quality of Service (QoS) along various stages of its lifecycle. Technical indicators can be monitored at service or process execution time using WSO2, Oracle or Business Activity Monitoring technology. Semantic web uses the notion of ontologies for the creation and elicitation of domain knowledge [START_REF] Gomez-Perez | Ontological Engineering: With Examples from the Areas of Knowledge Management, E-Commerce and the Semantic Web[END_REF]. Ontologies represent formal specifications about the components of systems and their relationships in a machine understandable and processable manner [START_REF] Antoniou | A Semantic Web Primer[END_REF]. They play an important role in both semantic web applications and knowledge engineering systems [START_REF] Fahad | A Framework for Ontology Evaluation[END_REF]. Several tasks such as information storage, processing, retrieval, decision making etc. are done on the basis of ontologies by such systems. In this paper, we introduce a framework towards performance monitoring of service oriented system based on technical indicators. The framework consists of four major steps (i) Monitoring of performance to ensure its sustainability, (ii) Service monitoring ontology (iii) Ontologies for performance measurement of service oriented activities and (iv) Merging ontologies. The remaining of the paper is organized as follows: Section 2 includes related work. Section 3 discusses performance measurement of service oriented activities. Section 4 discusses our proposed performance monitoring framework. We conclude the research in the last section.

RELATED WORK

In this section we discuss some techniques that have been proposed to ensure performance of web services.

Performance Analysis of SOA Techniques

In this section we analyze research that focuses on QoS. [START_REF] Tari | Benchmarking Soap Binding. On the Performance of Web Services[END_REF] proposed a benchmark of different SOAP bindings in wireless environments. Three sets of experiments were carried out: loopback mode, wireless network mode and mobile device mode. The experimental results show that HTTP binding inherits very high protocol overhead (30%-50% higher than UDP binding) from TCP due to the slow connection establishments and tear-down processes and the packet acknowledgement mechanism. UDP binding has the lower overhead because it does not require establishing connections before transmitting datagram's and does not address reliability. This results in a reduction in the response time and an increase in the total throughput. Its configuration and results can serve as a standard benchmark for other researchers who are also interested in the performance of SOAP bindings in wireless networks. [START_REF] Lin | Ontology-based QoSaware support for semantic web services[END_REF] proposed an ontology based QoS-Aware support for semantic web services. They have used ontology to describe Quality of service metrics. They have composed their ontology into upper and lower level property. They have not considered the input/output operations. They have not included real time values for the performance analysis to reach towards optimal web service.

Ontology based QoS Analysis

Techniques [START_REF] Moraes | Mononto: A domain ontology for network monitoring and recommendation for advanced internet applications users[END_REF] designed an ontology named MonONTO for proposing recommendation for the advanced internet applications users. They have considered information concerning the application type, traffic generated and user profile along with network performance metrics. Their expert system monitors the performance of advanced internet applications. Their ontology serves as a support to a decision reference tool by providing high-level information to the user about the agreement of the network facing the service level demands. They have used a fixed list of network parameters. Therefore, it does not deal with the heterogeneity and extensibility issues. Implementations of web services have not been done by them. Additionally, it does not deal with QoS mapping. [START_REF] Benaboud | Semantic Web Service Discovery Basedon Agents and Ontologies[END_REF] proposed Semantic Web Service Discovery Based on Agents and Ontologies considering the fuzzy constraints. Their 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. They have used fuzzy constraints increases the efficiency of the web service discovery approach by providing the customers the web services which are not actually satisfying the input QoS constraints, but are close to the QoS constraints specification.

QoS Aggregation and Performance Prediction Techniques

QoS-based service selection has been done [START_REF] Jaeger | QoS-Aware Composition of Web Services: An Evaluation of Selection Algorithms[END_REF] to describe how to find an optimal selection of functionally equivalent services based on their QoS properties. QoS aggregation as part of QoS-based service selection mostly addresses only QoS properties when interacting with other services [START_REF] Unger | Aggregation on QoS und SLAs in BPEL Geschaeftsprozessen Diplomarbeit[END_REF]). It also neglects the time which is taken by the BPEL engine software to navigate through the process model [START_REF] Rud | Performance Analysis in WS-BPEL-Based Infrastructures[END_REF]. The IT infrastructure consisting of hardware and software effects response time, throughput and availability of the service oriented system lifecycle. If the IT infrastructure is predefined, the goal is to estimate performance of service oriented system lifecycle (performance prediction) [START_REF] Marzolla | Performance Prediction of Web Service Workflows[END_REF], for example, by using benchmarking techniques.

SERVICE ORIENTED ACTIVITIES FOR PERFORMANCE ANALYSIS

An important aspect in the service oriented system (SOS) is management of the performance of different activities. There are different activities in service based systems to analyze performance like messaging, service, binding, business process and server. Service based activities for performance analysis are shown in Figure 1. Service is composed of different operations. Performance can be monitored at both the service and different operations level. Business process level is used for the performance analysis at the composition of service. Binding level covers the performance at the protocols level. Server level covers the performance of resources available. There are different types of technologies available which we can effectively utilize to guarantee better performance. Data abstraction layer is used to query data from the database and the historical information about the data and components which is available in the legacy. The component services access the Data abstraction layer to fetch and retrieve data.

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 [START_REF] Tari | Benchmarking Soap Binding. On the Performance of Web Services[END_REF]. In this way services are published in the service layer. Service oriented architecture is in process at the process orchestration layer. All this information is stored in the UDDI [START_REF] Zhou | QoS-Aware Web Services Discovery with Federated Support for UDDI[END_REF]. On the top level layer, BP applications provide process orchestration mechanism to execute enterprise business processes. BP application use Business Process Modeling Notation (BPMN) to design their business processes. Governance rules are the set of policies like service will be available for one year etc. Security is used to provide some integrity to the system like authentication with the help of user name and password. Service metrics are the parameters in order to guarantee the performance of web services.

For example in the ITIL [START_REF] Donna | A Guide to Service Desk Concepts: Service Desk and the IT Infrastructure Library[END_REF], there are 5 sub-categories and more than 100 metrics available for service support process and 5 sub-categories and more than 50 metrics available for service delivery processes. BP state intelligence is used to provide some intelligence or flags to measure the performance of BPEL.

PERFORMANCE MONITORING FRAMEWORK

This section presents our Performance Monitoring Framework. The first step of our approach is the specification of service or business process performance requirements. This specification is typically performed on user requirement or business goals in a certain time period. We divide our proposed performance monitoring framework into different steps as shown in Figure 2. We design performance based ontologies for all the activities of SOS. After the creation of these ontologies, we identify the common concept by merging these ontologies which results in performance profile.

Performance requirements of SOS are monitored in terms of technical indicators. These technical indicators have target values that are required to achieve in a certain time period. For this purpose we perform performance analysis for SOS activities already explained in Section 3. We identify technical indicators at the service level, business process level, server level and binding level. We create ontologies for all these levels and merge these ontologies to create performance profile at the infrastructure level.

Major steps for the creation of performance profile are:

• Specifying ontological concepts • Management of common concepts • Quality assurance on the performance profile

In the following sub sections we explain service monitoring ontology and ontologies at service level, server level, business process level and binding level.

Service Monitoring Ontology (SMOnt)

In this step we design a sophisticated Service Monitoring ontology (SMOnt) as a base infrastructure. It aggregates the main concepts and relationships between them. QoS requirements, service domain concepts, key performance indicators and performance levels are the major domains. SMOnt is shown in Figure 3.

Combined

Combined based classification includes all those indicators that can be measured by both time and size units like bandwidth and throughput. Bandwidth is defined as the tasks per time unit and average data blocks per time unit. Throughput is defined as the number of operations per second.

Performance Ontologies

In this step, we explain the ontological concepts of technical indicators at service level, business process level, binding level and server level. Ontologies for all these activities are shown below step by step.

Figure 4 shows the ontology of technical indicators at service level.

Technical indicators at service level are explained below. Loss: shows that the service is un-available (i.e., it cannot be invoked). Process-Loss: shows that the business process is unavailable (i.e., it cannot be invoked).

Process-Duration: shows the time duration of business process since it is deployed, executed and remained in process. Some other technical indicators of service level are also used in order to estimate their value at composition level like availability and service response time.

Figure 6 shows the ontology of technical indicators at server level. Technical indicators for the server level are free disk space, CPU Load, free RAM, throughput, bandwidth and reliability. We estimate available memory to support the new deployment by analyzing free disk space, CPU load and free RAM. Bandwidth is defined as the tasks per time unit and average data blocks per time unit. Throughput is defined as the number of operations per second.

Merging Ontologies

After designing ontologies for technical indicators of SOS activities, we merge them to create performance profile at the infrastructure level. There are three levels of analysis required for performance monitoring of SOS lifecycle.

Level 1:

In level 1, we try to increase the coverage of monitoring performance model. Also identification of sources of performance loss. We conduct a performance evaluation over real web services using suitable estimators for all the technical indicators at service level, business process level, server level and binding level. We perform this performance evaluation using WSO2 server and Oracle® Content Services Administrator.

CONCLUSIONS

In this paper we propose a performance monitoring framework to ensure sustainability of SOS at the infrastructure level. The framework consists of monitoring of performance, Service monitoring ontology, ontologies for performance measurement of service oriented activities and merging of ontologies. Extensive analysis of technical indicators with timing constraint to create performance profile is in process. We will implement our work by using real time case study.

Figure 1 :

 1 Figure 1: Service based Activities for Performance Analysis.

Figure 3 :

 3 Figure 3: Service Monitoring Ontology (SMOnt). Service: This concept has various data type properties to capture different attributes in SMOnt. It also has various object properties that links Service concept to other concepts. The details are as follows: Data type properties Name: records the name of the service. Description: captures the description about the service. Group_name: records name of the group to which the service belongs.

Figure 2 :

 2 Figure 2: Creation of Performance Profile.

Figure 4 :

 4 Figure 4: Ontology of Technical Indicators at Service Level. Response Time: captures the response time of a service/operation. It has three sub concepts to record Maximum, Minimum and Average response time. Request Count: shows the number of invocation of a service. Response Count: shows the number of replies for an invocation of a service. Fault Count: shows the number of invocations the service has not replied. Deploy Time: shows when the service is deployed at the server Up Time: shows the time period the service is available since its deployment

Figure 5

 5 Figure 5 shows the ontology of technical indicators at business process level. Technical indicators at business process level are explained below. Process-Response-Time: captures the response time of a business process. It has three sub concepts to record Maximum, Minimum and Average response time.Process-Up-Time: shows the time period the business process is available since its deployment Process-Down-Time: shows the time period of unavailability of a business process. Process-Delay: shows the average response time of a process. Process-Loss: shows that the business process is unavailable (i.e., it cannot be invoked). Process-Duration: shows the time duration of business process since it is deployed, executed and remained in process. Some other technical indicators of service level are also used in order to estimate their value at composition level like availability and service response time. Figure6shows the ontology of technical indicators at server level. Technical indicators for the server level are free disk space, CPU Load, free RAM, throughput, bandwidth and reliability. We estimate available memory to

Figure 7

 7 Figure 7 shows the ontology of technical indicators at binding level. Binding level means at the messaging level. Technical indicators at transport messaging level are binding-throughput, bindingreliable-messaging, binding-security (authentication, authorization, and encryption), binding-bandwidth.

Figure 5 :

 5 Figure 5: Ontology of Technical Indicators at Business Process Level.

Figure 6 :

 6 Figure 6: Ontology of Technical Indicators at Server Level.

Figure 7 :

 7 Figure 7: Ontology of Technical Indicators at Binding Level.


O Senhadji

El Rhazi

Multi-Task Optimisation Queuing theory and efficient simulation Queuing Theory Multi-Tasking

Table of Contents

Introduction

In many life situations, there exist queues with different behaviours. The purpose of this paper is to model those queues. These queues are prevalent in several areas. Not only, in the daily life in the administrative branches, or in the banks, but also in computer science and in telephone networks. The sharing of resources via a server, and the stream of commands to the level of the microprocessor or the management of telephone calls are all models for the queue. The present paper is divided into three parts: a basic theory part, an implementation part and a development of the code which will enable us to get some results.

The simulation are based on the following model:

• The durations between two successive arrivals are independent random variables of the same law: exponential of parameter λ(ε) that will be designated by M (for Markov). • The time of service at the counters are independent variables and of same law: This law is taken exponential in the first place and bimodal in second place noted G. The bimodal case allows to model the possibility of lengthy queries and short ones. • A single server will be taken.

• Different strategies of service of customers in the queue will be addressed:

First in first out (FIFO) the more natural one! LIFO (last in, first out). SIRO (service in random order) or the next customer is taken randomly in the queue, PS (Processor sharing) LIFOpreemp (LIFO pre-emptive strike) or the current service is interrupted to immediately take in the new customer arrived.

Simulation Model

To simulate the chains M/M/1 and M/G/1, or the two notation that have been explained previously, we must simulate two laws:

The exponential law ε(λ)

The exponential law of a parameter λ is simulated by the dual function va1 (double l). We used to this end the result of probability. U being a random variable of uniform law on [0, 1]

The bimodal law

A random variable following this law takes two kinds of values, to simulate periods of short and long past over the counter according to the client's request. The density of this law has been taken equal to:

Where α is a normalization constant, λ is the parameter of the exponential and s represents an order of magnitude of the lengthy queries (requete_longue).

The function that simulates this law is double va2 (double l). To simulate this law, the following theoretical result was used:

• X random variable density equal to p • U random variable of uniform law on [0,1] The following figures represented the histograms generated by these two functions va1 and va2. Note the conformity of the histogram with the exponential laws of va1 and bimodal of va2.

O. Senhadji El Rhazi

Coding Approach

We recall that the strategies involved to designate what client serve -and when (LIFO Preemp)among the crowd of customers in the queue.

FIFO (First In First Out)

To implement the FIFO strategy a stack INTVECTOR st is taken into account. This stack contains (at each moment) all clients who are in the queue except the one who is at the counter. The number j is designated by the variable ds_guichet.

Each time a new client n arrives in the queue, its number -his rank in the queue, the customers being stowed in an ascending order of their time of arrival-is added to the end of the queue by the instruction st.push_back(n). The empty variable is then set to 0 empty = 0 to indicate that the stack is not empty. Each time a client leaves the queue, the top customer in the queue can then be directed into the counter-strategy FIFO which expressed by the following statement:

• j=st.front() ; the highest element in the stack • st.erase(begin()) ; the client leaves the stack • ds_guichet=j ; the variable ds_guichet is redefined

LIFO (Last In, First Out)

The same variables that previously were taken with the same definitions are also used here. Each time a new client n arrives in the queue, its number is added to the end of the queue by the instruction st.push_back(n). The empty variable is then set to 0 empty = 0 to indicate that the stack is not empty. Each time a client leaves the queue, the last customer in the queue can then be directed into the counter-strategy LIFO which expressed by the following statement:

• j=st.back( ); the lowest element in the stack • st.erase(st.end( ))-1 ; the client leaves the stack, the last element is deleted • ds_guichet=j ; the variable ds_guichet is redefined

SIRO (Service In Random Order)

The same variables that previously are taken with the same definitions are also used here. This strategy involves a new function void shaker (INTVECTOR &s) whose role is to randomly swap the elements of the queue. The top item in the stack will be random. In each new arrival, the newcomer is added at the end of the queue by the instruction st.push_back(n). Similarly, as previously, the empty variable is set to 0. In each departure of a customer, when his treatment is completed, a new customer will then randomly taken -strategy SIROin the queue to go to the ticket counter. This is expressed by these commands:

• shaker(st) ; random permutation of the elements of the stack • j=st.front() ; the highest element of the stack is taken • st.erase(st.begin()) ; this element is removed from the stack • ds_guichet=j ; the variable ds_guichet is redefined

Ps (Processor Sharing) O. Senhadji El Rhazi

This strategy is a bit unusual in the sense that all requests are processed at the same time. The explanation of this strategy encroaches on the algorithmic part of the next part which will therefore be more concise.

The variables used are:

LIFOpremp (LIFO pre-emptive strike)

The principle of strategy is to serve immediately the newcomer by interrupting the processing of the current request.

The variables used are:

• INTVECTOR st (the same defined previously for FIFO)

• A table RESTE_A_TRAITER • A varibale ds_guichet (the same defined previously)

In each arrival of a new client, the one at the ticket counter is sent to the queue st.push_back(ds_guichet). The remaining time to satisfy his request is logged RESTE_A_TRAITER[ds_guichet]. The variable ds_guichet is initialized to n the number of the last client arrival. Finally empty = 0 to indicate that the stack is not empty.

In each departure of a customer, the last client returned sees the treatment of its query resume which expressed by:

• j=st.back( ); the lowest element in the stack, the last returned • st.erase(st.end( )-1); the client leaves the stack • ds_guichet=j ; the variable ds_guichet is redefined

The Algorithm

The purpose of this algorithm is to return a history of events which take place between the moment 0 of departure and a time T corresponding to the passage of N client by the service. The events are, the arrivals and departures of the customers. The history must include the O. Senhadji El Rhazi moment of arrival, departure, the waiting time in the queue before the beginning of the processing of the request and the duration of treatment for each client. These data will allow then to calculate averages and make comments on each type of queue characterized by its strategy and its laws.

In practice, the historical data are taken after a moment corresponding to the passage of 1000 clients since the initial moment and before the moment after which will 100 in the queue. This is to help to stabilize the system in a stationary speed. These two moments are expressed respectively by the variables heats and cools. The historical data are then stored in a file res.txt. The history is defined by four tables:

• Arrival to store the moment of arrival of each client.

• DUREE_TRAITEMENT to store the duration of the processing of the query.

• OUTPUT to store the time of output of the customers at the counter.

• TREATMENT to store the moment of the beginning of treatment, this variable is unused for the queues PS and LIFOpreemp.

The flow time is simulated by three variables:

• time the current time since the first arrival of a customer.

• t the time between the moment current (time) of the arrival of the next customer.

• u the time between the moment the current departure next to a client.

The variable t follows, throughout the algorithm, an exponential law. On the other hand u follows, in the first case, an exponential law and, in the second case, a bimodal law. These two variables therefore indicate the closest event. In effect t ≤ u designates an arrival then that t ≥ u designates a departure. The time variable time is accordingly corrected for each event, it is in other words to a sum of several t and u scenarios.

If the nearest event is an arrival of a customer n then:

• The time variable is corrected: time = time t ;.

• By definition of u and t: u = u -t ;. t= va1 (λ);.

• The moment of arrival is recorded in the table ARRIVAL: ARRIVAL[n] =time ;.

If the event the nearest is an output from a client n then:

• The time variable is corrected: time = time u ;.

• By definition of t: t = t -u ;.

• The moment of departure is in the table OUTPUT: OUTPUT[ds_guichet] =time ;

The next customer j -if the queue is not empty-is taken according to the logic and the algorithm explained in the previous section:

• By definition of u: u= va2 (mu).

• DUREE_TRAITEMENT[j]= u ;.

• If the queue is empty empty = 1 ;.

If the queue is empty the choice step (previous section) is skipped. It goes directly to the next arrival and the customer is directly supported.

  Introduction ............................................................................................................................................ Simulation Model .................................................................................................................................... 1.1 The exponential law ε(λ) ............................................................................................................... 1.2 The bimodal law ............................................................................................................................ Coding Approach ..................................................................................................................................... 2.1 FIFO (First In First Out) .................................................................................................................. 2.2 LIFO (Last In, First Out) .................................................................................................................. 2.3 SIRO (Service In Random Order) ................................................................................................... 2.4 Ps (Processor Sharing) ................................................................................................................... 2.5 LIFOpremp (LIFO pre-emptive strike) ........................................................................................... The Algorithm ......................................................................................................................................... C/C++ Source Code ................................................................................................................................. O. Senhadji El Rhazi

  Size variable to measure the number of customers in the queue • A table RESTE_A_TRAITER containing the wait times • Remaining for each clients; the queries being processed at the same time.• Next to designate what client exit the queue.In each arrival of a new client, its number is stored in st st[size] =n, the size of the queue increases, size=size 1, the time remaining to him is given by RESTE_A_TRAITER[n] =Va2 (mu). The empty variable is, as previously, upgrade to 0 empty = 0. The next customer who will leave the queue is the one whose box RESTE_A_TRAITER[n] is minimal. Moreover, the variable next is such that RESTE_A_TRAITER[next] is minimum. In each departure of and the variable size is decremented size= size -1 ;. the variable next is then recalculated according to the same principle.

	a	customer,	the	element	RESTE_A_TRAITER[next]	is	crushed	by
	RESTE_A_TRAITER[size]

• A table int st[N] containing customers •