Index of /rozprawy2/10249

Pełen tekst

(1)AGH UNIVERSITY OF SCIENCE AND TECHNOLOGY. Faculty of Electrical Engineering, Automatics, Computer Science and Electronics. QoS driven Semantics Based SOA Applications Composition and Execution. Ph.D. Dissertation. Author: mgr in˙z. Tomasz Szydło. Supervisor: prof. dr hab. in˙z. Krzysztof Zieli´ nski. Krak´ ow, June 16, 2010.

(2) ´ AKADEMIA GORNICZO-HUTNICZA. Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki. Zarza ¸dzanie jako´scia ¸ kompozycji i wykonania w oparciu o informacje semantyczne aplikacji zorientowanych na usługi. Rozprawa doktorska. Autor: mgr in˙z. Tomasz Szydło. Promotor: prof. dr hab. in˙z. Krzysztof Zieli´ nski. Krak´ ow, June 16, 2010.

(3) A CKNOWLEDGMENTS Author would like to express his gratitude to Professor Krzysztof Zieli´ nski for his helpful remarks and assistance with the research described in this thesis. Author thanks all members of the Distributed Systems Research Group at the Computer Science Department of AGH University of Science and Technology for their support. Finally, author would like to thank his wife Katarzyna and family for their understanding and endless patience as without their support, this dissertation would have never been finished. The research was partially supported by the European Union in the scope of the European Regional Development Fund program no. POIG.01.03.01-00-008/08.. i.

(4) C ONTENTS List of Tables. v. List of Figures. vii. 1 Introduction 1.1 SOA application composition and execution 1.2 Semantic service description . . . . . . . . . 1.3 SOA adaptability . . . . . . . . . . . . . . . 1.4 Thesis statement . . . . . . . . . . . . . . . 1.5 Research contribution . . . . . . . . . . . . 1.6 Dissertation Organization . . . . . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 2 Background and Related Work 2.1 Service Oriented Architecture . . . . . . . . . . . . . 2.1.1 Service-Oriented Solution Stack . . . . . . . . 2.1.2 State management . . . . . . . . . . . . . . . 2.1.3 SOA Integration . . . . . . . . . . . . . . . . 2.1.4 Enterprise Service Bus . . . . . . . . . . . . . 2.2 Quality Management . . . . . . . . . . . . . . . . . . 2.2.1 Metrics importance for SOA . . . . . . . . . . 2.2.2 Metrics Taxonomy for SOA . . . . . . . . . . 2.3 Autonomic Computing . . . . . . . . . . . . . . . . . 2.3.1 Self Management . . . . . . . . . . . . . . . . 2.3.2 Autonomic Computing maturity levels . . . . 2.3.3 Autonomic Element . . . . . . . . . . . . . . 2.3.4 Policies for Autonomic Computing . . . . . . 2.4 Adaptability . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Static versus Dynamic Service Composition . 2.4.2 Behavioural versus architectural adaptability 2.5 Composition and Execution Frameworks . . . . . . . 2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . .. ii. . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . .. 1 1 3 3 4 5 5. . . . . . . . . . . . . . . . . . .. 6 6 9 11 12 13 17 18 19 20 21 22 22 23 25 25 26 27 30.

(5) CONTENTS. iii. 3 Concept of SOA Application Composition and Execution 3.1 Composite Service Model . . . . . . . . . . . . . . . . 3.2 Model of composite service execution . . . . . . . . . . 3.3 Service similarity . . . . . . . . . . . . . . . . . . . . . 3.4 Adaptation process . . . . . . . . . . . . . . . . . . . . 3.4.1 Static adaptation . . . . . . . . . . . . . . . . . 3.4.2 Dynamic adaptation . . . . . . . . . . . . . . . 3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 32 32 35 37 37 38 39 40. 4 Concept of Adaptive VESB Execution Framework 4.1 Adaptability Mechanisms . . . . . . . . . . . . . . . 4.2 A transformation . . . . . . . . . . . . . . . . . . . 4.2.1 Interceptor Design Pattern . . . . . . . . . . 4.2.2 Sensors . . . . . . . . . . . . . . . . . . . . 4.2.3 Effectors . . . . . . . . . . . . . . . . . . . . 4.3 V transformation . . . . . . . . . . . . . . . . . . . 4.4 Layered architecture of Adaptive VESB framework 4.4.1 Instrumentation layer . . . . . . . . . . . . 4.4.2 Monitoring layer . . . . . . . . . . . . . . . 4.4.3 Management layer . . . . . . . . . . . . . . 4.4.4 Exposition layer . . . . . . . . . . . . . . . 4.4.5 Policy Engine layer . . . . . . . . . . . . . . 4.5 Model Analyser System . . . . . . . . . . . . . . . . 4.5.1 Service Matchmaker . . . . . . . . . . . . . 4.5.2 Metrics engine . . . . . . . . . . . . . . . . 4.5.3 Model Projection Generator . . . . . . . . . 4.6 Summary . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. 41 41 43 44 45 46 49 50 52 52 53 53 53 54 55 56 56 57. 5 Implementation Details 5.1 Overview of Existing SOA Integration Platforms 5.1.1 Comparison of selected systems . . . . . 5.2 Enterprise Service Bus extensions . . . . . . . . 5.2.1 Interceptors . . . . . . . . . . . . . . . . 5.2.2 Routing Table effector . . . . . . . . . . 5.2.3 Monitoring Agent . . . . . . . . . . . . . 5.2.4 Service Lister . . . . . . . . . . . . . . . 5.2.5 Management Agent . . . . . . . . . . . . 5.3 Exposition Layer Components . . . . . . . . . . 5.3.1 Facts Engine . . . . . . . . . . . . . . . . 5.3.2 Policy Engine . . . . . . . . . . . . . . . 5.4 Model Analyser System . . . . . . . . . . . . . . 5.4.1 MatchMaker . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. 58 58 60 61 61 64 65 65 65 65 67 68 70 70. . . . . . . . . . . . . .. . . . . . . . . . . . . ..

(6) CONTENTS. 5.4.2 Model Projection Generator 5.4.3 MapGraphReduce algorithm 5.4.4 Metrics Engine . . . . . . . 5.5 VESB Studio . . . . . . . . . . . . . 5.6 Summary . . . . . . . . . . . . . .. iv. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 71 72 74 77 80. 6 System Evaluation 6.1 Experiment 1 - Adaptive service acquisition . . . . . . . . . 6.1.1 Unmodified scenario . . . . . . . . . . . . . . . . . . 6.1.2 Scenario with adaptation policy . . . . . . . . . . . . 6.1.3 Scenario with fair adaptation strategy . . . . . . . . 6.1.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Experiment 2 - Delivering Complex Services . . . . . . . . . 6.2.1 Analysis of the model of composite service execution 6.2.2 Execution Time disturbance . . . . . . . . . . . . . . 6.2.3 Maintenance cost minimalization . . . . . . . . . . . 6.2.4 Variable QoS . . . . . . . . . . . . . . . . . . . . . . 6.2.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. 81 . 81 . 83 . 83 . 86 . 86 . 88 . 89 . 91 . 96 . 98 . 102 . 102. 7 Conclusions 103 7.1 Thesis verification and Confirmation . . . . . . . . . . . . . . . . . . . . 103 7.2 Novel concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 7.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Abbreviations. 106. References. 108.

(7) L IST. OF. TABLES. 4.1 NMR Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 VESB message handling rules . . . . . . . . . . . . . . . . . . . . . . . .. 48 50. 5.1 Comparison of selected systems . . . . . . . . . . . . . . . . . . . . . . . 5.2 Instrumentation layer components . . . . . . . . . . . . . . . . . . . . . 5.3 Exposition layer components . . . . . . . . . . . . . . . . . . . . . . . .. 61 62 66. 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9. Testbed software configuration . . . . . . . . . . . . . . . . . . Simple adaptation policy . . . . . . . . . . . . . . . . . . . . . . Routing rules for fair adaptation strategy . . . . . . . . . . . . . Service instances similarity . . . . . . . . . . . . . . . . . . . . Complex adaptation policy . . . . . . . . . . . . . . . . . . . . . Services deployed in the ESB for complex service scenario . . . Policy rule that selects cheapest solution from the solution space Service instances that constitute composite services . . . . . . . Fitness factors of composite services for variable QoS test case .. v. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . 82 . 84 . 86 . 92 . 94 . 96 . 96 . 99 . 100.

(8) L IST 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11. OF. F IGURES. Before and after SOA (SUN Microsystems) . . . S3 Model . . . . . . . . . . . . . . . . . . . . . Enterprise Integration Patterns . . . . . . . . . JBI architecture . . . . . . . . . . . . . . . . . . WSDL Component Model Schematic (JSR 208) Different ways of perceiving quality . . . . . . . Metrics taxonomy for SOA . . . . . . . . . . . . Metrics for simple and composite services . . . Evolution of autonomic systems . . . . . . . . . Structure of an autonomic element. . . . . . . . Goal driven adaptable SOA . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. 9 10 14 15 16 18 19 20 22 23 28. Model driven adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . Projection of an abstract composite service onto a composite service . . . Adaptation process of composite service . . . . . . . . . . . . . . . . . . Exemplary model of composite service execution . . . . . . . . . . . . . Parallel service invocation: a) synchronized activation; b) fastest predecessor activation; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Solution space for dynamic binding . . . . . . . . . . . . . . . . . . . . .. 33 34 35 36. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13. 42 43 44 45 46 47 49 51 52 53 53 54 57. 3.1 3.2 3.3 3.4 3.5. Integration layer extension with adaptability mechanisms . . . . . . . . ESB Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interceptor Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . Chain of interceptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service selection with semantic information . . . . . . . . . . . . . . . . Abstraction level of message flow . . . . . . . . . . . . . . . . . . . . . . VESB concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layered architecture of Adaptive VESB . . . . . . . . . . . . . . . . . . . Adaptive ESB internal architecture . . . . . . . . . . . . . . . . . . . . . Monitoring layer diagram . . . . . . . . . . . . . . . . . . . . . . . . . . Sequence of processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture of Model Analyser System . . . . . . . . . . . . . . . . . . . Reducing solution space by recursive model of composite service execution. vi. 37 39.

(9) LIST OF FIGURES. vii. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13. Enterprise Service Bus extensions . . . . . . . . . . . . . . . . . . . . . . Interceptor interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTT for InOnly messages . . . . . . . . . . . . . . . . . . . . . . . . . . . Flowchart representing decision process performed by FE . . . . . . . . . Service Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Model synchronization a)model of complex service execution; b)EAI model; Execution of function M AP (v, IN T ER) . . . . . . . . . . . . . . . . . . Execution of function GRAP H REDU CE(v, IN T ER) . . . . . . . . . Interfaces for edge and node metrics . . . . . . . . . . . . . . . . . . . . Basic class of graph metric . . . . . . . . . . . . . . . . . . . . . . . . . . Instrumentation layer management . . . . . . . . . . . . . . . . . . . . . Model of Complex Service editor . . . . . . . . . . . . . . . . . . . . . . Management of adaptation policies . . . . . . . . . . . . . . . . . . . . .. 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12. Message flow of the case study . . . . . . . . . . . . . . . . . . . . . . . 82 Test case a)logical architecture b)physical architecture . . . . . . . . . . 82 Original test case scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Test case scenario with adaptation policy . . . . . . . . . . . . . . . . . . 85 Test case scenario with multiple service instances . . . . . . . . . . . . . 87 EAI model of Complex Service . . . . . . . . . . . . . . . . . . . . . . . . 88 Complex Abstract Composite Service . . . . . . . . . . . . . . . . . . . . 89 Number of visitors per hour . . . . . . . . . . . . . . . . . . . . . . . . . 90 Probabilities on model edges . . . . . . . . . . . . . . . . . . . . . . . . 90 Probabilities on model edges . . . . . . . . . . . . . . . . . . . . . . . . 91 Test case scenario with marked time of disturbance . . . . . . . . . . . . 92 Projection of the model of composite service execution onto composite services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Policy scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Test case scenario with applied adaptation policy . . . . . . . . . . . . . 95 Test case scenario with applied adaptation policy and cost constraints . . 97 Execution cost comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Number of visitors per hour . . . . . . . . . . . . . . . . . . . . . . . . . 98 Evaluated metrics weights . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Test case scenario with variable QoS . . . . . . . . . . . . . . . . . . . . 101. 6.13 6.14 6.15 6.16 6.17 6.18 6.19. 61 63 63 67 70 71 73 73 74 75 78 79 79.

(10) C HAPTER 1. I NTRODUCTION This chapter briefly introduces the basic terms and concepts of SOA applications composition and execution. The chapter also presents the goals and main assumptions of the thesis. Software systems are becoming larger and far more complex than ever. At the same time they must provide assured quality and performance whereas time to market is shortened significantly. Analysing many projects from 2003 to 2006, IBM research has found that most of them express the same architectural template - basis functionalities of these projects are reusable components that might be shared between projects. Service-Oriented Architecture (SOA) enables the development of applications that are built by combining loosely coupled and interoperable services. In SOA, centre of gravity is moved from development to integration phase. Modern software systems are often designed in the way that can safely adapt to changes in the execution environment. Adaptation process is expected to be performed with little or no human intervention. As computing systems are becoming larger and more complex, adaptation task becomes challenging because of arising complexity of developed software.. 1.1. SOA application composition and execution. Nowadays most of the available software is composed of various modules and services provided by several providers. The process of service composition and execution consists of a workflow creation that realizes the functionality of a new service, followed by its deployment and execution on a runtime infrastructure. Service Oriented Architecture is widely-accepted architecture for integration of software components. Application in SOA is composed from a set of services that are connected together in the integration platform. Such an application is described as an abstract composition and then executed in the execution container that is responsible for mapping between abstract services to concrete service instances during service execution. Mapping process can be performed by a user or planner before execution or can be performed during 1.

(11) CHAPTER 1. INTRODUCTION. 2. a runtime. Mapping process should take into account delivered QoS. This class of a software is particularly suitable for adaptability extensions to be applied because service instances could be replaced during execution. A number of approaches have been proposed in the literature for Web Service Composition and Execution (WSCE)[104][27][20]. Nevertheless, majority of the works propose solutions where system gets as an input task request and on that basis generates an abstract composition, which is then grounded and finally executed. This assumes a task request is precisely defined and generates executable composition in the way that programmer exactly wants. In a real world applications, this is hardly possible as there is a large number of technological details that have to be specified and programmer has to deal with. It includes error handling, communication protocol transformation and technical aspects related to integration of systems between providers. This thesis introduces a new concept of an adaptive at runtime SOA applications composition and execution. Programmers will be allowed to design and implement the application, and then adaptation policy will be applied in order to extend the application of adaptability mechanisms. Adaptability in runtime requires detailed information of how system behaves and how some services may influence another ones. Solutions presented in the literature include this information in a generated abstract composition which may be then used for adaptation purposes. The concept presented by author assumes that an application is not aware of applied adaptation policies, and it is not modified. Instead of that, model of complex service execution should be provided and then used for adaptation purposes. Such a model represents the knowledge of how the complex system behaves, and is updated in a runtime. Models not only filter too detailed information but also add model specific data such as non-functional metrics or semantic information of user experience[17]. Despite the fact that application is not generated from high-level description, provided model may be used to modify composition of the application in order to achieve high level goals. This modification addresses service selection, binding protocol and interaction policy choices. Adaptability process mainly concerns integration mechanisms that are introduced in the execution layer. Currently, Enterprise Service Bus (ESB) has been found as a promising approach for developing SOA software and is adopted by large and well-known companies. The ESB is an integration technology that allows architects to compose applications with services using various communications protocols. The large interest in ESB moves this discussion to the execution environment and the technology. Additionally, concept of Virtual ESB is introduced as an extension that provides mechanism for provisioning many separated logical ESBs sharing a single ESB container and improving scalability and manageability..

(12) CHAPTER 1. INTRODUCTION. 1.2. 3. Semantic service description. Today’s services are designed primarily for human interpretation and use. They are described syntactically and rely on human understanding of the semantic elements. Services described ontologically can enable additional interoperability on top of syntactical interoperability achieved by standards such as WS-* or Corba-IDL. Semantic descriptions through ontologies enable possibility for automated discovery, selection and invocation of services. Ontology is a formal representation of a set of concepts within a domain and the relationships between these concepts. Since the 1990s, a number of research efforts have explored how the idea of ontologies could be made useful on the World Wide Web. The Web Ontology Language (OWL)(formely DAML+OIL) is a family of knowledge representation languages for authoring ontologies, and is endorsed by the World Wide Web Consortium. This family of languages have three different levels of expressiveness: OWL Lite, OWL DL and OWL Full. OWL DL and OWL Lite semantics are based on Description Logic[11] which is used for formal reasoning on the concepts of an application domain. OWL Full is less restrictive than previous ones and is hardly possible to find the software that fully supports it. OWL-S[19] is an ontology, within the OWL-based framework of the Semantic Web, for describing Semantic Web Services. OWL-S is motivated by the need to provide three essential types of knowledge about a service. It gives an answer to questions what does the service provide for prospective clients, how is it used and how does one interact with the service. It enables users and software agents to automatically discover, invoke, compose, and monitor web resources offering services, under specified constraints. There are other languages and ontologies for describing semantic services, but OWL-S is the most promising ones. Although there are several frameworks for automatic service selection, composition and execution with usage of semantic service description, it is unlikely to find one that can mange problems appeared during software integration. Author proposes the framework for service composition and execution where application is designed by a programmer and then executed and adapted during a runtime with usage of semantic service description. Proposed framework leverages the aspect of semantic service discovery in adaptability process.. 1.3. SOA adaptability. Complexity of computing systems goes beyond human capability. Widely available platforms and tools have extended the size and complexity of software and systems that architects are able to design. Growth of systems is not only in the complexity, but also in the number of devices connected together. As systems become more interconnected and combine number of technologies, complexity is a problem even for the most skilled IT professionals. The promising approach to deal with such problems is an idea of Au-.

(13) CHAPTER 1. INTRODUCTION. 4. tonomic Computing[64]. System analyses composite service deployed in the execution environment and adapts to the changes in the execution environment, which may result in deviation of Quality of Service (QoS) and Quality of Experience (QoE). Concept of adaptability presented in this thesis is based on observation that changing instance of a particular service, which is a part of a whole system, may influence overall QoS. Service instances might be used interchangeably only when they provide the same functionality. Services are enhanced with formal semantic description and consist of service description in terms of functional aspects. One of the important tasks related to semantic services is a discovery problem. This involves finding suitable services from the repository that match the query requirements[65]. Process of adaptation can be seen as a process of continuous composition. Services instances are replaced by its semantic description and composed using different instances, but with the same functionality. Service instances differ in non-functional aspects, thus switching between them may influence overall quality of provided composite service.. 1.4. Thesis statement. This dissertation puts forward the thesis that it is possible to build a system that will add adaptability mechanisms to SOA execution environment. Proposed adaptability extensions should be transparent for the application and should have elements of autonomy. Transparent adaptability for the application means that an application is not aware of it’s modifications and adaptations in order to achieve high level goals. Given the described considerations, the thesis of this dissertation is: Service Oriented Architecture could be extended by mechanisms that enable adaptability of applications to the changes in the execution environment in accordance to an adaptation policy and semantic service description. The dissertation presents the mentioned mechanism as well as its prototype implementation. The thesis introduces an original concept of adaptability, which exploits model of composite service execution as well as adaptation policies. Understanding of the policies varies between researchers and applications, but in this work, term policy is used to represent a set of considerations to guide decisions. Semantic service description is used to compare services and finds alternatives. Due to the usage of semantics, this process can be performed automatically during a runtime. The proposed mechanism is platform independent and can be used in a general problem of building adaptive software systems for SOA. Author particularly focuses on the ESB as an execution environment..

(14) CHAPTER 1. INTRODUCTION. 1.5. 5. Research contribution. The main contributions of this dissertation are as follows: • introduction of a model of complex service execution that is an abstract representation of complex service and contains statistical information about system behaviour from historical invocations; • formulation of a concept of SOA composition and execution utilizing adaptability mechanisms - application can be designed and implemented without adaptability aspects, but instead of that introduced model of complex service execution is provided and then used for adaptation purposes; adaptation is guided by a policy that is applied and modifies execution environment; • proposition of mechanisms that extend SOA integration layer of adaptability mechanisms and architectural decision block that guides actions in light of a given conditions; • concept of Adaptive VESB execution framework based on the proposed concept of SOA execution and composition; two transformations are defined constituting a presented architecture; A transformation enables adaptability aspects to ESB; V transformation adds Virtual ESB concept to Enterprise Service Bus; • proof of concept by an implementation of Adaptive VESB execution framework; popular and commonly used integration platform for SOA has been used as a foundation for proposed framework; • Adaptive VESB execution framework evaluation as a result of test cases that demonstrate system behaviour guided by complex adaptation policies.. 1.6. Dissertation Organization. The thesis is organized as follows: Chapter 2 is a survey of existing technologies and concepts related to building adaptive SOA applications including autonomic computing and policy-driven management systems. The concept of model-driven adaptability is introduced in Chapter 3. Chapter 4 presents patterns enabling ESB adaptability as well as layered architecture of Adaptive VESB framework. The prototype implementation of the framework is described in Chapter 5. Chapter 6 includes system evaluation and verification of thesis results. Chapter 7 concludes the results and summarizes the dissertation..

(15) C HAPTER 2. B ACKGROUND. AND. R ELATED W ORK. The chapter introduces and discusses main problems and challenges of composition and execution of adaptive software. The main goal of this chapter is to perform a survey of topics related to the presented research. The survey starts with description of Service Oriented Architecture. Subsequently, author presents an idea of Autonomic Computing as a system, which can manage itself given high-level goal. Then, Quality Management in SOA applications is presented as a crucial element, which enables a possibility to verify whether system meets the requirements in respect to selected measures. Adaptation of such systems requires definition of different types of service compositions and discussion which are more appropriate for runtime adaptation. Execution environments for SOA are presented and compared. Finally, the last part of the chapter describes projects related to the research presented in this dissertation.. 2.1. Service Oriented Architecture. In 1972 Dennis Ritchie at Bell Telephone Laboratories developed a general purpose programming language C for the use with the Unix operating system[60]. Main design objectives were to design an imperative language that provides low-level access to memory and to encourage machine-independent programming. It was the successor of previously used languages such as PDP-7, B, Fortran and others. At that time, communication protocol model between computers focused on the network layer and client-server model of constructing distributed software. The idea behind this model is to group cooperating programs into groups called servers that offer services to the group called clients. Client sends a request message to the server asking for some service and server after performing its task returns the results to the client. Despite the fact that client-server model assures convenient method for distributed system structuralization, it suffers from basic paradigm around which all communication is built. The procedures send and receive that are used in that model are related mostly for I/O programming[103]. It was not a good idea to make base paradigm for 6.

(16) CHAPTER 2. BACKGROUND AND RELATED WORK. 7. distributed computing on this solution. Programmers had to use sockets and had to write an entire protocol stack themselves. Birrel and Nelson[16] proposed the idea of Remote Procedure Call (RPC) that allows programs to call procedures located on other machines. When a remote procedure is invoked, the calling environment is suspended, the parameters are passed across the network to the environment where the procedure is executed. When the procedure finishes and produces its results, the results are passed back to the calling environment, where execution resumes as if returning from a simple single-machine call. Early middleware, such as Sun ONC, Apollo NCS, and DCE, was tied to C and Unix and not suitable for heterogeneous environments. Decade later, in the 1990s object-oriented(OO) programming has become a dominating methodology for composing a software. Main focus has been put on defining a specific type of relationship between certain fragments of logic and reusing its code in different applications. OO offers classes which can be thought of as a template from which many different individual objects may be generated as a program runs. Objectoriented classes define methods and attributes in order to associate behaviour and data with objects. They provide the four features: abstraction, encapsulation, inheritance and polymorphism. That interest in OO was due to the influence of C++ that introduced object-oriented (OO) features to C. Object-oriented features have been added to many existing languages during that time including Ada, BASIC, Fortran, Pascal, and others. Interest in object-oriented programming pushed for an Object RPC (ORPC). Industry started using object-oriented middleware platforms, such as DCOM[45] and CORBA[52]. The middleware platform took care of the majority of networking chores, such as marshaling and unmarshaling data, mapping logical object addresses to physical transport endpoints, changing the representation of data according to the native machine architecture of client and server and automatically starting servers on demand. DCOM was a Microsoft-only solution that could not be used in heterogeneous networks containing machines running a variety of operating systems. This and due to the overhead of its distributed garbage collection mechanism, DCOM has not been adopted by the industry and Microsoft dropped its development. The Common Object Request Broker Architecture (CORBA) was the Object Management Group’s specification for achieving interoperability between distributed computing nodes. It defined the Interface Definition Language (IDL) and the API that enable client/server object interaction. Both communicating nodes used an Object Request Broker(ORB) which is the middleware that establishes and maintains relationships between distributed objects. After a CORBA 1.0, which was not interoperable and provided only a C mapping, the OMG (Object Management Group) published in 1997 CORBA 2.0 addressing interoperability issues. During CORBA’s growth phase in the mid- and late ’90s, major changes affected the computing landscape, most notably, the advent of Java and the Web. CORBA provided a Java language mapping, but did nothing to cooperate with the rapidly exploding Web. Instead of waiting for CORBA to deliver a solution, compa-.

(17) CHAPTER 2. BACKGROUND AND RELATED WORK. 8. nies turned to other technologies and started building their e-commerce infrastructures based on Web browsers, HTTP, Java, and EJB (Enterprise JavaBeans). It was one of the important factors for CORBA to decline. Being a popular middleware it became a niche technology[51]. During the late ’90s, XML gained its popularity and became the standard as encoding schema, which indirectly led to publication of Simple Object Access Protocol (SOAP). Originally it has been developed by Microsoft, and then passed to W3C for standardization. SOAP uses XML as the on-the-wire encoding for remote procedure calls and XML-based service IDL called Web Services Description Language (WSDL) that defines the service interface as well as its implementation characteristics. Web services offered a new programming model for building distributed applications using open Internet standards. It addresses interoperability issues of which ORPC suffered: uses HTTP protocol to pass firewalls, employs XML as an encoding, uses URLs to address object identification, and what is very important, vendors cooperate together to make their solutions compliant to the standards. Since then, web services became widely adopted standard for building distributed systems and led to the service-orientation concept. SOA in its mature form is agnostic to any technological platform and enterprise is given a freedom to choose appropriate technology of building services. Some principles associated with service-orientation derive from previously mentioned technologies and concepts[36]. These are: reusability, formal contract between services, loosely coupling, abstraction from underlying logic, composability, service autonomy, statelessness, and discoverability: • Services are reusable Regardless of whether immediate reuse opportunities exist, services are designed to support potential reuse; • Services share a formal contract For services to interact, they need not share anything but a formal contract that describes each service and defines the terms of information exchange; • Services are loosely coupled Services must be designed to interact without the need for tight, cross-service dependencies; • Services abstract underlying logic The only part of a service that is visible to the outside world is the part exposed via the service contract. Underlying logic, beyond what is expressed in the descriptions that comprise the contract, is invisible and irrelevant to service requestors; • Services are composable Services may compose other services. This allows logic to be represented at different levels of granularity and promotes reusability and the creation of abstraction layers; • Services are autonomous The logic governed by a service resides within an explicit boundary. The service has control within this boundary and is not dependent on other services to execute its governance;.

(18) CHAPTER 2. BACKGROUND AND RELATED WORK. 9. Figure 2.1: Before and after SOA (SUN Microsystems) • Services are stateless Services should not be required to manage state information, as that can impede their ability to remain loosely coupled. Services should be designed to maximize statelessness even if that means deferring state management elsewhere; • Services are discoverable Services should allow their descriptions to be discovered and understood by humans and service requestors that may be able to make use of their logic. Software vendors that provide tools for building SOA applications, clearly points out the difference between software built before and after SOA. Traditional IT architectures are mostly developed as independent software applications provided by several vendors. These applications are usually incompatible, have separate databases and networks as depicted in Fig.2.1. Users have to navigate between them to find and correlate information they are looking for[98]. From administration point of view, that model of delivering software requires a lot of attention to keep the systems synchronized. In contrary, SOA[58] delivers the data needed for business processes as an integrated service. Users do not need to navigate between applications because all of the necessary data is provided as a single integrated service. SOA provides methods for system development and integration where main effort is put on business processes. SOA infrastructure allows different services to interact with one another in unified manner.. 2.1.1. Service-Oriented Solution Stack. Analysing many projects from 2003 to 2006, IBM research found that most of them express the same architectural template. The result of this finding is the Service-Oriented Solution Stack (S3) [10], which provides a detailed architectural definition of SOA.

(19) CHAPTER 2. BACKGROUND AND RELATED WORK. 10. Figure 2.2: S3 Model across nine layers from business process to operational systems layer. These layers are crossed by integration, quality of service, information architecture and governance layers. Each of them has a logical and physical aspect. Logical aspect includes architectural elements, design decisions, while physical aspect is related to the technology of implementation. S3 Model is depicted in Fig.2.2. Descriptions of these layers are as follows: • Operating systems - This layer includes all applications and hardware assets running in an IT operating environment that supports business activities. This layer includes existing legacy applications, database systems, transaction processing systems and others. Nowadays this layer includes a virtualized IT infrastructure that results in improved resource manageability and utilization; • Service components - This layer contains software components, each of which are the realization of a service or operation on a service. Service components reflect both the functionality and QoS for each service they represent; • Services The service layer consists of all the services defined within SOA. In the broadest sense, services are what providers offer and what consumers or service requesters use. In S3, however, a service is defined as an abstract specification of one or more business-aligned IT functions. The specification provides consumers with sufficient detail to invoke the business functions exposed by a service provider ideally in platform independent way; • Business process - In this layer, the organization assembles the services exposed in the Services layer into composite services that are analogous to key business processes. In the non-SOA world, these business processes are similar to custom applications. On the other hand, SOA supports application construction by introducing a composite service that orchestrates the information flow among a set of services and human actors;.

(20) CHAPTER 2. BACKGROUND AND RELATED WORK. 11. • Consumer - The consumer layer handles interaction with the user or with other programs in the SOA ecosystem; • Integration This layer integrates layers 2 through 4. Its integration capabilities enable mediation, routing and transporting service requests from the service requester to the proper service provider. These capabilities include, but are not limited to, those found in ESB and will be further explained in the following sections; • Quality of service Certain characteristics inherent in SOA exacerbate well-known IT QoS concerns: increased virtualization, loosely coupling, composition of federated services, heterogeneous computing infrastructures, decentralized servicelevel agreements, the need to aggregate IT QoS metrics to produce business metrics, and so on. As a result, SOA clearly requires suitable QoS governance mechanisms; • Information architecture - This layer encompasses key considerations affecting data and information architectures required to develop business intelligence through warehouses. The layer includes stored metadata content required for data interpretation; • Governance and policies The governance and policies layer covers all aspects of managing the business operations’ lifecycle. This layer includes all policies from manual governance to autonomous policy enforcement. It provides guidance and policies for managing service-level agreements including capacity, performance, security and monitoring. As such, the governance and policies layer can be superimposed onto all other S3 layers. From a QoS and performance metric perspective, it is tightly connected to the QoS layer. The layer’s governance framework includes service-level agreements based on QoS and key process indicators, a set of capacity planning and performance management policies to design and tune SOA solutions as well as specific security-enabling guidelines for composite applications.. 2.1.2. State management. State in its abstract meaning refers to the general condition of something. It means that a computer system can also have transition thought different states. As the complexity of service composition increases, amount of activity specific data increases as well. Services are pushed to keep and pass these data one to another. To maximise service scalability, service inventories are required to support the delegation and deferral of the state. General principle is to keep services in stateless state as long as it is possible. In the literature one can find many terms describing different types of state data, however in the work[37] author provides taxonomy: • Session data represents information associated with retaining connection client.

(21) CHAPTER 2. BACKGROUND AND RELATED WORK. 12. and a system. Good example of this type of data is a session identifier that is established to correlate interaction between web browser and the web server; • Business data represents information that is relevant to the business task currently executing. This data is typically transported within a payload of the message. This data does not actually express the state of the service, but is necessary to perform actions by a service; • Context data represents all the information that is passed between services. This goes beyond session type information and is necessary to properly accomplish task. SOA leverage generic design of services advocated by the service reusability principle. It significantly reduces the amount of embedded logic devoted to particular activity, although this places the responsibility of supplying services with activity context data on the message layer. In this concept message contains state data, moreover it may increase processing overhead by requiring additional processing to parse, process and interpret this data. On the other hand, letting services to process its state data led to design activity specific service implementation definitely reducing reusability. SOA architecture emphasizes the preference for services to remain stateless for most of its lifetime.. 2.1.3. SOA Integration. In the SOA technology centre of gravity is moved from development to integration phase. Nowadays, most of the becoming available software is composed from various modules and services from various providers. Web services usually expose operations of certain applications or information systems. Consequently, combining several Web services actually involves the integration of the underlying applications and their functionalities. Web services can be combined using orchestration or choreography[85][84]. Orchestration assumes that central process (which can be another Web service) takes control of the involved Web services and coordinates the execution of different operations on the Web services involved in the operation. The involved Web services are not aware (and do not need to know) that they are involved in a composition process and that they are taking part in a higher-level business process. Only the central coordinator of the orchestration is aware of this goal, so the orchestration is centralized with explicit definitions of operations and the order of invocation of Web services. Business Process Execution Language (BPEL)[8] is an XML-based language defining several constructs to write business processes. It defines a set of basic control structures like conditions or loops as well as elements to invoke web services and receive messages from services. To be used, BPEL requires a process such as Apache ODE[79] that understands its notation and can execute business process. Choreography assumes that each web service involved in the choreography knows exactly when to execute its operations and with whom to interact. Choreography is a collaborative effort focusing on the exchange of messages in public business processes..

(22) CHAPTER 2. BACKGROUND AND RELATED WORK. 13. All participants in the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges. For example, Web Service Choreography Interface (WSCI)[9] is a choreography language that describes the messages exchanged between Web services that participate in a collaborative exchange. A single WSCI describes participation in a message exchange for the single service and there is no single controlling process managing the interaction. Enterprise Application Integration (EAI) is another example of choreographing services which are connected together using patterns. Nevertheless, there is not a single service coordinating execution. Enterprise Application Integration Enterprise Application Integration (EAI) is a business need to make diverse applications in an enterprise. Partner systems communicate to each other to achieve a business objective in a seamless reliable fashion, irrespective of platform and geographical location of these applications. Asynchronous messaging architectures have proven to be the best strategy for enterprise integration because they allow a loosely coupled solution that overcomes the limitations of remote communication, such as latency and unreliability. The trend towards asynchronous messaging has manifested itself in a variety of EAI suites as well as emerging standards for reliable asynchronous Web services. Unfortunately, asynchronous messaging is not without pitfalls. Many of the assumptions that hold true when developing single and synchronous applications are no longer valid. What is needed is vendor-independent design guidance on building robust integration architectures based on asynchronous messaging. Fig.2.3 shows Enterprise Integration Patterns (EIP)[55]. Each pattern poses a specific design problem, discusses the considerations surrounding the problem and presents an elegant solution that balances the various forces or drivers. In most cases, the solution is not the first approach that comes to mind, but one that has evolved through actual use over time. As a result, each pattern incorporates the experience base that senior integration developers and architects have gained by repeatedly building solutions and learning from their mistakes. ESB is natural evolution and convergence of EAI and Message Oriented Middleware (MOM) such as those that implements Java Message Service (JMS)[50]. Integration specialists from vendors like IBM, TIBCO, Microsoft or Oracle point out ESB as a promising technology for composing modern software because of its integration capabilities. Using ESB, one can combine BPEL and EAI in one application.. 2.1.4. Enterprise Service Bus. The Enterprise Service Bus is an integrative technology that allows architects to compose applications with services using various communications protocols. ESB should.

(23) CHAPTER 2. BACKGROUND AND RELATED WORK. 14. Figure 2.3: Enterprise Integration Patterns provide mechanisms for message normalization and routing between selected components. There are several definitions of ESB but the most comprehensive is the one by Roy Schulte from the Gartner who defines ESB as: An Enterprise Service Bus (ESB) is a new architecture that exploits Web services, messaging middleware, intelligent routing, and transformation. ESBs act as a lightweight, ubiquitous integration backbone through which software services and application components flow. This and other[44] definitions used by integration vendors, market analysts, and business users share core functionalities of Enterprise Service Bus that are: • Protocol conversion ESB should be able to seamlessly integrate applications communicating with each other in different transport protocols. For example, JMS to HTTP, or SMTP to TCP; • Message transformation Should provide functionality that allows messages to change their format; • Message routing ESB should determine destination of the message basing on provided address or depending on the message content; • Message enhancement ESB should provide functionality to enhance message by adding extra information by analyzing its content; • Location transparency ESB should provide functionality to access services without knowing its exact location..

(24) CHAPTER 2. BACKGROUND AND RELATED WORK. 15. HTTP. SE. BC. SE. SE. DC. DC. DC. DC. NMR DC. DC. SE. BC HTTP. Figure 2.4: JBI architecture Java Business Integration (JBI)[1] is a specification developed under the Java Community Process (JCP) and specified as Java Specification Request (JSR)208 as an approach to implementing SOA. It defines a standards-based architecture that can be used as the basis for Java-based integration products, in particular an ESB. JBI employs concepts similar to J2EE to extend application packaging and deployment functionality to include JBI components. JBI components are an open-ended class of components that are based on JBI abstract business process metadata. The JBI does not define itself how developers code components. Both standard and proprietary ways of coding components may exist. A specific class of component may provide rich business process functionality, while another class of component may provide a specialized integration function like a data transformation table or support a domain specific business rule encoding. Architecture of JBI is depicted in Fig.2.4. JBI models services are produced and consumed by components which interfaces are described using WSDL[25] versions 1.1 and 2.0. WSDL provides a declarative model of message-based services on two levels as depicted in Fig.2.5. In Abstract service model service is defined using an abstract messaging model, without reference to a particular protocol or wire encoding. In Concrete model an abstract service is bound to a particular protocol and communications endpoint. The concrete service model defines the following items: • Binding types A binding type identifies the type of protocol to which the service is being ”bound”; • Service A service is a collection of endpoints that offer access to the same service and ”implements” a particular service type (interface). A service has the following items: – Service name A qualified name used to indicate the particular service imple-.

(25) CHAPTER 2. BACKGROUND AND RELATED WORK. 16. Figure 2.5: WSDL Component Model Schematic (JSR 208) mentation; – Service type name The name of the interface implemented by the service; – Endpoints The service ”contains” one or more endpoints, which are the individual endpoints providing access to the concrete service.. Normalized Message Exchange JBI uses the concept of a normalized message for interaction between consumers and providers. A normalized message consists of two parts: the abstract XML message and message metadata (referred to as message context data). Abstract XML document conforms to an abstract WSDL message type, without any protocol encoding or formatting. The message context data allows for the association of extra information with a particular message as it is processed by both plug-in components and system components. The metadata can affect message processing as the message moves through the JBI environment. The directly supported interactions which must be supported by JBI implementations are: • In-Only Consumer issues a request to provider with no error (fault) path provided; • Robust In-Only Consumer issues a request to provider. Provider may respond with a fault if it fails to process request; • In-Out Consumer issues a request to provider with expectation of response. Provider may respond with a fault if it fails to process request;.

(26) CHAPTER 2. BACKGROUND AND RELATED WORK. 17. • In Optional-Out Consumer issues a request to provider, which may result in a response. Consumer and provider both have the option of generating a fault in response to a message received during the interaction. Normalized Message Router The normalized message exchange delivery outlined above depends on the Normalized Message Router (NMR) to route message exchanges between service consumers and providers. The NMR supports performing such message delivery with varying qualities of service, depending on application needs and the nature of the messages being delivered. The qualities of service supplied by the NMR, in collaboration with the bindings and engines as needed, are: • Best effort Messages may be dropped or delivered more than once; • At least once Messages may not be dropped, but duplicates may be delivered; • Once and only once Messages are guaranteed to be delivered only once. A Delivery Channel (DC) represents a bidirectional communication pipe used by bindings and engines to communicate with the NMR. The DeliveryChannel forms the API contract between service consumers, providers and the NMR. A service consumer uses its delivery channel to initiate service invocations, while a service provider uses its delivery channel to receive such invocations. JBI Components JBI supports two kinds of components: Service Engines and Binding Components that implement different functionality in JBI: • Service Engines are the business logic drivers of the JBI system. Engines can orchestrate service consumption and provision in the course of, for example, executing long-lived business processes. Other engines can provide simple services, such as data transformation; • Binding Components are used to send and receive messages via particular protocols and transports. They serve to isolate the JBI environment from the particular protocol by providing normalization and denormalization from and to the protocol-specific format, allowing the JBI environment to deal only with normalized messages.. 2.2. Quality Management. Quality management in SOA application is a crucial element as it ensures that system meets its requirements with respect to selected measures. Dealing with QoS is a sign.

(27) CHAPTER 2. BACKGROUND AND RELATED WORK. Client. Observed QoE. Provided QoS. 18. Provider. Figure 2.6: Different ways of perceiving quality that technology is going beyond the stage of initial experimentation to a production deployment. In order to manage quality, a set of metrics has to be defined. It is important to both consumer and provider to understand metric semantics[71]. It must be defined what particular parameters express e.g. time is an average response time or the maximum response time from the last ten minutes. Similarly, the point of measurement is important. Metrics values gathered on the client side would be different then gathered at the service container or at the service itself.. 2.2.1. Metrics importance for SOA. In the Internet age, quality of delivered services is important not only for its provider but also for service user[77]. Let’s think of calculating account balance on the end of the month. Accounting service that is used has 99,9% availability but, once a month for one hour is disabled for maintenance. For someone’s accessing this service during this hour, the service availability would be 0,0%. Analysis of existing frameworks in terms of QoS unveils that this term is used interchangeably for describing quality from provider as well as from client point of view. The author has decided to distinguish QoE from Quality of Service. The idea is presented in Fig. 2.6. Paradoxically system users might have been satisfied with system behaviour that will result with high QoE whereas system might not implement functionality for which clients paid. On the other hand, system may fulfil all the required quality aspects, but users might not be satisfied which will result in low QoE. Importnace of QoE has temporal character as it is observed in a finite time, whereas QoS has a mean character. Client may perceive the system better than the system’s provider. It is very common that these values are completely different. From the business perspective significantly important is influence of subjective metrics to the overall profits from providing services. Quality of Business (QoBiz) metrics are strictly related to the money describing how increasing or decreasing QoS of offered service may influence income. Service Provider Perspective A service provider needs to think of various aspects of QoS, especially Quality of Service policy. Simplest policy of guaranteeing quality is not to make any assumption of guaranteed quality, but delivering services to the best of its capabilities. Another approach is to offer several QoS levels differentiated by cost. Once provider agree on delivering particular QoS, he has to fulfil its commitments..

(28) CHAPTER 2. BACKGROUND AND RELATED WORK. 19. Basic. SOA Metrics. Complex. External. Internal. Static. Dynamic. Figure 2.7: Metrics taxonomy for SOA Service Client Perspective While best effort policy of providing services is acceptable in some cases, it is not, when this service is the main part of composed application. In that case, long-term description of provided quality is necessary, and is regulated by Service Level Agreement (SLA). When provider violates terms of assigned contract, he has to pay compensation to the client. For example, analysing internet shop, QoS metrics would describe number of visiting clients, amount of money they spent and the information about opening hours. From the customer point of view, the same internet shop would be perceived through QoE metrics which describe e.g. time necessary to register or information whether the shop is open when client wants to buy something. Of course, QoE are influenced by QoS metrics but they also incorporate subjective feelings of the system usage. Client and provider are bounded with SLA. It defines the terms and conditions of service quality that provider delivers to the customers. Most important in SLA is the QoS information that consists of several criteria like execution duration, availability, execution time, and many more. SLA constitutes also financial information as a price for using service, and the way in which penalties are compensated. To define quality requirements common understanding of offered quality between users and providers[33] is necessary.. 2.2.2. Metrics Taxonomy for SOA. Several divisions have been introduced during development and testing of SOA applications. Fig.2.7 summarizes these classifications in a metrics taxonomy that has been proposed: • Internal and External Metrics Internal metrics addresses solely aspects of a system which are available exclusively for system architects. They might provide detailed information on source code, or a number of used software modules. External metrics are available for system users and provide information about system.

(29) CHAPTER 2. BACKGROUND AND RELATED WORK. 20. SOA Metrics. Simple Services. Composite Services. Figure 2.8: Metrics for simple and composite services reliability, efficiency or response time. Evaluation of external metrics is more difficult than the internal ones, as usually these metrics have subjective meaning. Additionally, these metrics for products in early stage of development may not express values of final versions; • Static and Dynamic Metrics Static metrics describe invariable parameters. These might be parameters from software documentation or semantic description, or metrics describing source code. Examples of these metrics are the ones regarding configuration and security aspects of a software[54]. Dynamic metrics are evaluated during runtime. Exemplary metrics of that kind are execution time or network throughput; • Basic and Complex Metrics Basic metrics are directly gathered from system monitoring. They might provide simple information about system behaviour like time necessary to deliver a message. Complex metrics are combinations of basic ones. For example, response time might be defined as a time necessary to deliver message to a service plus a time to process a message. There is a number of works trying to organize metrics for SOA[92][53], nevertheless most of them are variations of availability, execution time and throughput. Another issue, as depicted in Fig.2.8, is calculation of metrics values for composite services. Usually it requires additional information that shows how execution of one service may influence execution of another service[74]. Problem is even more complicated if services are invoked parallely. Impact of slow services execution time on the overall response time of a transaction that uses several Web services in parallel may be significant[75]. Problem related to calculation of metrics value for complex services is prediction of that values before invocation[74]. This problem is further elaborated in the next chapter.. 2.3. Autonomic Computing. Complexity of computing systems goes far beyond human capability. Widely available compilers and tools have extended the size and complexity of software and systems that.

(30) CHAPTER 2. BACKGROUND AND RELATED WORK. 21. architects are able to design. Growth of systems is noticeable not only in the complexity but also in the number of devices connected together. As systems become more interconnected and combine number of technologies, complexity is a problem even for the most skilled IT professionals. The most promising option to deal with a such sort of systems is Autonomic Computing (AC) [64] introduced by IBM in 2001 - systems that can manage themselves given high-level goals from administrators. In Autonomic System, operator does not influence system directly, but only defines general policies, which specify system behaviour.. 2.3.1. Self Management. IBM has defined the following four areas of usage: Self-configuration, Self-healing, Selfoptimization and Self-protection. In all of these areas, system is capable to perform self-operations on its own instances. These areas are[63][3]: Self-configuration Installation, configuration and integration of large scale systems is time consuming and error prone task. Installing new system may take even few months. Conversely to current computing, AC systems will configure themselves automatically in order to integrate seamlessly with the rest of system elements. Self-optimization Complex systems may have number of tunable parameters that influence system behaviour undesirably when set incorrectly. Such a systems are often integrated with other, equally complex systems. Tuning that sort of applications is hardly ever easy task and it requires very experienced staff. In contrary, AC will endlessly look for ways to improve its efficiency and cost. Self-healing Large IT companies have large departments devoted to find and solve problems occurring in their systems. It may take programmer weeks or even months to trace roots of some problems. AC systems will detect, localize and solve problems which occurred during system work. The system may only inform administrator of existing problem, suggest solution or what would be most desired, perform operations which eventually solve the problem. Self-protection Protecting computer systems is considered in two separate aspects. One of these is to protect system from malicious attacks and improper use. The second aspect is to analyse system behaviour and inform in advance when something is going wrong with a system..

(31) CHAPTER 2. BACKGROUND AND RELATED WORK. Basic Level 1. Managed Level 2. Predictive Level 3. 22. Adaptive Level 4. Autonomic Level 5. Figure 2.9: Evolution of autonomic systems. 2.3.2. Autonomic Computing maturity levels. The idea of AC goes much beyond most of the current IT solutions. The industry must take evolutionary approach and provide new functionalities for customers step-by-step. Taking revolutionary approach by providing autonomic system would inevitably lead to disaster. Before letting systems to take actions on their own, people should become confident in the usefulness and power of these systems. Fig. 2.9 depicts levels of AC maturity levels. Step from level three to level four is especially intriguing because it allows system to perform inferenced actions. Short description of Autonomic Computing maturity Levels [43] is presented below: • Basic - autonomy is very limited, each system element is managed independently; • Managed - autonomy is still very limited, but administrator is supported by management tools that collect informations, reducing the time it takes for the administrators to make a decision; • Predictive - system monitors, correlates and recommends further actions which are subsequently approved and performed by IT staff; • Adaptive - system monitors, correlates and takes actions; • Autonomic - integrated components are dynamically managed by business rules and policies. On one hand influence of autonomic systems significantly reduces human errors, while on the other hand it might also greatly magnify the consequences of any errors made by humans when preparing goals.. 2.3.3. Autonomic Element. Autonomic Computing model consists of several autonomic elements connected together. Each Autonomic Element (AE)[3] manages its internal behaviour and its relationship with other autonomic elements in accordance with high level goals or human decisions. AE as depicted in Fig. 2.10 consists of Autonomic Manager (AM) and managed resource . Any sort of hardware resource such as CPU or software resource such as database can be managed but it must have constituted management interface. AM is a component which implements control loop that consist of four stages: monitor, analyse, plan and execute..

(32) CHAPTER 2. BACKGROUND AND RELATED WORK. 23. Autonomic manager. Analyze. Monitor. Plan. Knowledge. Execute. Managed element. Figure 2.10: Structure of an autonomic element. In most cases, specified goals will be complex, multidimensional, and mostly conflicting. Even such obvious goals like maximizing efficiency or minimizing cost would require IT specialist’s support to express importance of several parameters which system may influence on. The second problem which has to be faced is system behaviour in situation of system failure or when specified goals may cause instability of managed system. Autonomic system should inform or prevent such behaviours. Researchers investigate several techniques for constructing autonomic managers. One of these is to use control theory for performance control in complex applications such as real-time scheduling, web servers, multimedia, and power control in CPUs[69]. This methodology has been proved as promising foundation but it’s main drawbacks is a necessity of identification and modelling of managed systems. Different approach is to use policies to guide decisions basing on observed system state and its behaviours. This approach is discussed in the next section. It might be interesting to combine these methods in order to achieve accurate results for self-managing systems.. 2.3.4. Policies for Autonomic Computing. In IT industry, the term policy is taken from real world and has its origins in governments and law regulations. Basically it points out an actions selected from other alternatives due to a given conditions. One may notice that this term is used interchangeably to describe regulations, general goals or plans of actions to be taken. That term is adopted also to user access policies, replication policies, load balancing policies and network security policies. There are several languages and specifications designed for that purpose. WS-Policy[13] specification represents a set of specifications that describe the capabilities and constraints of the security (and other business) policies on intermediaries and endpoints (for example, required security tokens, supported encryption algorithms, and privacy rules) and how to associate policies with services and endpoints. The Ponder[30] language provides a common means of specifying security policies that map onto various access control implementation mechanisms for firewalls, operating systems, databases and Java. One may find a formal definition of a policy [6]:.

(33) CHAPTER 2. BACKGROUND AND RELATED WORK. 24. Consider a system S that may behave in many ways. Let B(S) be the set of all possible behaviours the system S can exhibit. Definition: A policy is a set of constraints on the possible behaviours B(S) of a target system S; that is, it defines a subset of B(S) of acceptable behaviours for S. Understanding of the policies varies between researchers and applications, but in this work, the term policy is used to represent a set of considerations to guide a decisions. Policy is provided to a system as a set of rules. A policy information model provides abstract representation of the information needed to define a policy: • Condition-Action Information Model Policy of a system consists of several policy rules that have two elements: conditions and actions. Conditions defines when the policy should be applied. Action defines what have to be done when particular policy rule is applied. Condition-action policy rules takes the form: if [list of conditions] then [list of actions] Such policies are evaluated in a regular periods of time. Even though this information model is very simple, it has some drawbacks. Frequency of policy evaluation has to be defined, which may influence time of system reaction to the occurred events. • Event-Condition-Action Information Model Policies use events as a condition elements. This type of policy model is useful for asynchronous policy evaluation, as a response to events generated by a system. For example state changes or parameters exceeded threshold value. Event-condition-action policy rules takes the form: when [list of events and conditions] then [list of actions] This type of policies are particularly useful for situations when it is hardly possible to define frequency of policy evaluation or when it is intended to have event-driven policies. Policy rules are executed by a rules engines that uses algorithms for efficient pattern matching. Usage of a rules engines have number of advantages: • business logic is separated from the implementation; • ability to change policies without software recompilation; • policy rules might be extended by a new rules without modifying already existing ones;.

(34) CHAPTER 2. BACKGROUND AND RELATED WORK. 25. • rules might be shared among organizations. A naive implementation of an expert system might check each rule against the known facts in the knowledge base, firing that rule if necessary, then moving on to the next rule (and looping back to the first rule when finished). For even moderate sized rules and facts knowledge-bases, the naive approach performs far too slowly. Commonly used rules engines implement Rete[40] that is is an efficient pattern matching algorithm for implementing production rule systems designed to sacrifice memory to increase speed.1 The Rete algorithm provides the basis for a more efficient implementation. A Rete-based expert system builds a network of nodes, where each node (except the root) corresponds to a pattern occurring in the left-hand-side (the condition part) of a rule. The path from the root node to a leaf node defines a complete left-hand-side of a rule. Each node has a memory of facts which satisfies that pattern. This structure is essentially a generalized tree. As new facts are asserted or modified, they propagate along the network, causing nodes to be annotated when that fact matches that pattern. When a fact or combination of facts causes all of the patterns for a given rule to be satisfied, a leaf node is reached and the corresponding rule is triggered. Rete has become the basis for many popular expert system shells, including CLIPS[56], Jess[42], Drools[86], BizTalk Rules Engine[96] and Soar[57].. 2.4. Adaptability. In the last few years, interest in adaptive computing grows significantly. There is variety of techniques of software adaptation developed today. Development of such a systems is driven by appearance of new architectures. One of these is ubiquitous computing which blur the line between humans and mobile computing devices integration. Mobile systems, for example has to adapt to constantly changing wireless network conditions in order to achieve long battery life. Second is the mentioned concept of autonomic computing, which focuses on the development of systems that are managed and selfprotected with noticeable low human guidance. Adaptability enables software to modify its structure and behavior in response to changes in execution environment[73].. 2.4.1. Static versus Dynamic Service Composition. Adaptation can be differentiated according to the time when adaptation takes places. Later composition support more powerful adaptation methods but is also more difficult to verify. When composition takes place at development, or load time, it is easer to ensure that system does not led to unforeseen situations which may make system unusable. Static composition. When adaptive application is composed at development time, its adaptive behaviour is hardwired in the program and can not be modified without 1. The Rete algorithm was designed by Dr Charles L. Forgy of Carnegie Mellon University..