Reasoning-based Capability Configuration Management in Adaptable Service Systems
Thesis for the degree philosophiae doctor Trondheim, January 2008
Norwegian University of Science and Technology Faculty of Information Technology,
Mathematics and Electrical Engineering Department of Telematics
Paramai Supadulchai
NTNU
Norwegian University of Science and Technology Thesis for the degree philosophiae doctor Faculty of Information Technology, Mathematics and Electrical Engineering Department of Telematics
© Paramai Supadulchai
ISBN 978-82-471-6020-6 (printed version) ISBN 978-82-471-6034-3 (electronic version) ISSN 1503-8181
Doctoral theses at NTNU, 2008:10 Printed by NTNU-trykk
Abstract
Abstract
Networked Service Systems are considered. Services are realized by service components, which by their inter-working, provide a service in the role of a ser- vice provider to service users. During more than two decades, networked ser- vice systems have been an important research topic. Focus was on efficiency in the definition, deployment and execution of services. This focus now has been changed into adaptability.
Adaptable service systems are service systems that are able to adapt dy- namically to changes in time and position related to users, nodes, capabilities, system performance, changed service requirements and policies.
This thesis has focus on adaptability aspects related to capabilities. A ca- pability is defined here as an inherent property of a node, which is used as a ba- sis for implementing a service.
Goal adaptability properties of an adaptable service system can be classi- fied as general and core properties. The general properties are requirement to the architectural framework while the core properties are requirement to the functionality. The core properties are classified as i) re-arrangement flexibility, ii) failure robustness and iii) resource load awareness and control properties.
The realization of the goal adaptability properties both needs an appropri- ate architectural framework as well as management functionality. This thesis presents a solution framework for reasoning-based capability configuration management for adaptable service systems. This framework is defined to con- sist of five contributions. Each contribution consists of sub-contributions; each of which represents contributed concept, model or mechanism. The contribu- tions are:
• C1: Capability-based computing architecture
• C2: Policy-based reasoning
• C3: Capability configuration management
• C4: Concept model and data representation
• C5: Scenarios - experimentation and simulation
Capability-based computing architecture is a capability and QoS-based architectural framework intended to be used for the specification and execution of any service functionality. Policy-based reasoning is a support functionality that makes adaptable service systems being able to take decisions based on flex- ible and expressive behavioral specification. Capability configuration manage- ment is a functionality related to capability specifications, configuration, alloca- tion, re-allocation and optimization. Concept model and data representation is the data model applied for the formalization and representation of the concepts applied for the capability configuration management based on policy-based rea- soning. Scenarios – experimentation and simulation shows the experiments and simulations that have been conducted for validating the other contributions.
My PhD work and thesis is related to TAPAS (Telematics Architecture for
Play-based Adaptable Service Systems). This thesis is structured into two main
parts: Part I – Introduction and Part II – Selected publications. Part I is intended
for the reader to get an overview of the publications included in Part II.
Preface
Preface
This thesis is submitted as partial fulfillment of the requirements for ob- taining the Doctor of Philosophy degree (Ph.D.) at the Department of Telemat- ics (ITEM), Norwegian University of Science and Technology (NTNU), Trond- heim, Norway. Funded by NTNU, the work presented in this thesis has been worked out in the period of January 2003 – November 2007 under the supervi- sion of Professor Finn Arve Aagesen. The work has been related to the Telemat- ics Architecture for Play-based Adaptable Service System (TAPAS) project.
TAPAS is a research project intended to study architecture concepts, which were initially related to dynamic Plug-and-Play (PaP) but now related to adapt- able service systems. Presently the aim of the project is not only to specify, de- velop and perform experiment with parts of architecture concepts for adaptable service systems but also to find out how to increase the efficiency of, and to simplify installation, deployment, operation, management, maintenance and evolution of adaptable service systems. The project has been divided into sever- al tasks. This thesis is associated with the concepts capability, QoS, perfor- mance and reasoning utilized in adaptable service systems.
The main part of this thesis consists of nine main publications, seven of
which were submitted, published and presented in the proceeding of interna-
tional conferences. One paper is being prepared for submission. One is pub-
lished as a technical report. The papers have been written in collaboration with
other researchers, mainly my supervisor. In the papers that I’m the first author, I
have contributed to all parts of the paper, including the definition of research
hypothesis, defining the architectural concepts, creating the formalisms and de-
veloping/performing the simulation- and/or analytical results, discussing the re-
sults, evaluating the research hypothesis, writing the papers, and presenting the
paper. However, in Paper B and G, where I’m the second author, my contribu-
tions include: the creation of the formalisms, developing/performing the simula-
tion- and/or analytical results, discussing the results, evaluating the research hy-
pothesis and writing the paper.
Acknowledgements
Several persons have contributed to the success of my study and the smoothness of my stay at Norwegian University of Science and Technology (NTNU), Trondheim, Norway. First of all, I would like to gratefully acknowl- edge my supervisor Professor Finn Arve Aagesen at the Department of Tele- matics (ITEM). Finn Arve has always been a person with full understanding, care, patience and available to give me helpful supports whenever I needed. I’m convinced that his advises and comments have significantly enhanced the quali- ty of my work. I would also love to thank Jittima Charoenpanich who made me want to pursue the Ph.D. for the first time.
As a perfect stranger to the kingdom of Norway in 2003, I would like to spread my sincere gratitude to the people who have always helped me neatly settle down during my stay. These people include, but not limited to, my super- visor himself, the Thai society in Trondheim, my Norwegian language teacher and classmates and people that I have been living and spending time with.
Without them I wouldn’t be able to adapt myself easily to the new place, new climate, new people, new food, new culture and new language.
My thankful gratitude goes to NTNU for funding my financial support, and to the people in TAPAS projects including Prof. Finn Arve Aagesen, Mazen Malek Shiaa, Shanshan Jiang, Cyril Carrez and Patcharee Thongtra as well as the other members of the networked system working research group at ITEM that have given me constructive comments and suggestions throughout my five- years research period. Special thanks to Mazen Malek Shiaa for being my sup- portive roommate and to Randi Schrøder Flønes and Mona Nordaune for help- ing me with all administrative tasks I’m not and will never be familiar with, Pål Sturla Sæther, Jarle Kotsbak and Asbjørn Karstensen for being the most talented and understanding technical team I have ever met.
Thanks to my family and my girl friend for being very supportive through-
put the Ph.D. period. Last, but not least, I would love to express my deep grati-
tude to Venerable Dhammajayo Bhikku for always teaching and reminding me
the important truth of life and that there are more important things to do in my
life than writing the thesis.
Contents
Contents
Abstract ... iii
Preface ... v
Acknowledgements ... vi
Contents... vii
List of figures ... x
List of tables ... xi
List of publications ... xii
Part I – Introduction ... 1
1.
Overview ... 2
1.1
Adaptable Service Systems – Definitions and Goal Properties ... 2
1.2
Outline of the thesis ... 5
1.3
Guideline for reading ... 7
2.
Research method and framework... 9
2.1
Research objectives ... 9
2.2
Scope ... 9
2.3
Problem statements ... 9
2.4
TAPAS ... 10
2.5
Research cycle ... 15
3.
The solution framework ... 19
3.1
The solution framework contributions ... 19
3.2
The realization of the problem statements ... 34
4.
Description of the publications in Part II ... 38
4.1
Paper A - An Approach to Capability and Status Modeling ... 38
4.2
Paper B – Configuration Management for Adaptable Service Systems 40
4.3Paper C – A Framework for Dynamic Service Composition ... 42
4.4
Paper D - Autonomic Service Configuration by a Combined State Machine and Reasoning Engine-based Actor ... 43
4.5
Paper E - Policy-based Adaptable Service Systems Architecture ... 45
4.6
Paper F - Towards Policy-Supported Adaptable Service Systems ... 48
4.7
Paper G - A Capability-based Service Framework for Adaptable Service Systems ... 49
4.8
Paper H – Autonomous Production of Parameters of an Autonomous Capability Allocation Adaptation Model ... 52
4.9
Report I – NxET Reasoning Machine ... 55
4.10
Relationship and overlap between the publications ... 57
5.
Related works ... 59
5.1
Related paradigms ... 59
5.1.1
Autonomic Systems and Autonomic Communications ... 59
5.1.2
Pervasive and ubiquitous computing ... 60
5.1.3
Context-aware Systems and Services ... 60
5.2
Related papers ... 61
5.2.1
Contributions C1 and C4 ... 61
5.2.2
Contributions C2 ... 64
5.2.3
Contributions C3 and C2 ... 66
Contents
6.
Summary, conclusions and further work ... 69
6.1
Summary ... 69
6.2
Conclusions ... 70
6.3
Further work ... 71
Bibiography ... 73
Part II – Selected publications ... 83
Paper A ... 85
Paper B ... 101
Paper C ... 125
Paper D ... 137
Paper E ... 153
Paper F ... 171
Paper G ... 187
Paper H ... 201
Report I ... 221
Abbreviations ... 237
List of figures
Figure 1 – The core properties A1, A2 and A3 ... 4
Figure 2 – Guidelines for reading ... 7
Figure 3 – The theatre metaphor ... 11
Figure 4 – TAPAS Service architecture ... 13
Figure 5 - TAPAS computing archtecture in 2003 and 2007 ... 15
Figure 6 - TAPAS service architecture in 2003 and 2007 ... 15
Figure 7 – Research cycle overview ... 17
Figure 8 - The reasoning-based capability configuration management framework ... 20
Figure 9 – The capability-based computing architecture ... 21
Figure 10 – SLA Mapping ... 22
Figure 11 - The generic reasoning model ... 23
Figure 12 - Reasoning cluster types ... 25
Figure 13 – Capability initialization ... 27
Figure 14 - Capability allocation adaptation ... 28
Figure 15 – Dynamic policies for capability allocation adaptation ... 29
Figure 16 – Parameter production for capability allocation adaptation ... 30
Figure 17 – The RM-related data entities ... 32
Figure 18 – Problem statements, contributions and publications ... 37
Figure 19 – The relation between the selected publications ... 58
List of tables
List of tables
Table 1 – Overview of the papers included in Part II of this thesis ... xii
Table 2 – Overview of the papers published but not included in this thesis. ... xiii
Table 3 – Capability-based computing architecture related work ... 63
Table 4 – Policy-based reasoning related work comparison ... 65
Table 5 – Capability configuration management related work comparison; ... 67
List of publications
The publications constituting Part II of this thesis are listed in Table 1. Ta- ble 2 shows additional papers published as a part of my doctoral work, but that is not included in this thesis.
Table 1 – Overview of the papers included in Part II of this thesis Paper A
[Sup04]
An Approach to Capability and Status Modeling
P. Supadulchai, F.A. Aagesen, in Proceedings of Norwegian Informatics Conference (NIK 2003), Stavanger, Norway, 2004.
Paper B
[Aag05]
Configuration Management for Adaptable Service Systems
F.A. Aagesen, P. Supadulchai, C. Anutariya, M.M. Shiaa, in Proceedings of IFIP In- ternational Conference on Metropolitan Area Network, Architecture, Protocols, Con- trol and Management (MAN 2005), Ho Chi Minh City, Vietnam, 2005.
Paper C
[Sup05a]
A Framework for Dynamic Service Composition
P. Supadulchai, F.A. Aagesen, in Proceedings of 1st International IEEE Workshop on Autonomic Communication and Computing (ACC 2005), Taormina, Italy, 2005.
Paper D
[Sup05b]
Autonomic Service Configuration by a Combined State Machine and Reasoning Engine-based Actor
P. Supadulchai, F.A. Aagesen, in Proceedings of the 2005 IFIP International Confe- rence on Intelligence in Communication Systems (INTELLCOMM 2005), Delta Cen- tre-Ville Hotel, Montréal, Canada, 2005.
Paper E
[Sup07a]
Policy-based Adaptable Service Systems Architecture
P. Supadulchai, F.A. Aagesen, in Proceedings of the IEEE 21st International Confe- rence on Advanced Information Networking and Applications (AINA-07), Niagara Falls, Canada, 2007.
Paper F
[Sup07b]
Towards Policy-Supported Adaptable Service Systems
P. Supadulchai, F.A. Aagesen, in Proceedings of the 13th Eunice Open European Summer School and IFIP TC6.6 Workshop on Dependable and Adaptable Networks and Services, University of Twente, the Netherlands, 2007.
List of publications
Paper G
[Aag07]
A Capability-based Service Framework for Adaptable Service Sys- tems
F.A. Aagesen, P. Supadulchai, in Proceedings of The 2nd International Conference on Advances in Information Technology (IAIT2007), Bangkok, Thailand, 2007.
Paper H
[Sup07c]
Autonomous Production of Parameters of an Autonomous Capabil- ity Allocation Adaptation Model
P. Supadulchai, F.A. Aagesen, prepared for a submission.
Report I
[Sup07d]
NxET Reasoning Engine
P. Supadulchai, Plug-and-play Technical Report, Department of Telematics, NTNU, ISSN 1500-3868.
Table 2 – Overview of the papers published but not included in this thesis.
Paper X
A Dynamic Configuration Architecture
F. A. Aagesen, C. Anutariya, M. M. Shiaa, B. E. Helvik and P. Supadulchai, in Pro- ceedings of IEEE/IFIP Network Operations and Management Symposium
(NOMS'2004), Seoul, South Korea, 2004.
Paper Y
An XML based Framework for Dynamic Service Management
M.M. Shiaa, S. Jiang, P. Supadulchai and J. J. Vila-Armenegol, in Proceedings of IFIP International Conference, INTELLCOMM 2004, Bangkok, Thailand, 2004.
Part I – Introduction
1. Overview
1.1 Adaptable Service Systems – Definitions and Goal Proper
ties
etworked services are considered. Networked services are offered by service systems consisting of service components, which by their inter- working, provide a service in the role of a service provider to a service user. Service users can be human users as well as software and/or hardware components. Service components are executed as software components in nodes, which are physical processing units such as servers, routers, switches, PCs and mobile phones. A service framework is defined here as the overall structural and behavior framework for service specification and service execu- tion. Service specification concerns how to formally define the structure and the behavior of a service system, which constitutes the service. Service execution is the execution of the implementation of the defined service specifications.
During more than two decades, networked service systems have been an important research topic. Example topics include Intelligent Networks [Ino99], TINA (Tele-communication Information Networking Architecture) [ITU92], Mobile Agents [Woo02], and Active and Programmable Networks [Ten97] in the 80-ies and 90-ies. Topics in the late 90-ies include Pervasive and Ubiquitous Computing [Lew04]. Today’s topics include Web Services [Alo03] and Auto- nomic Systems and Communication [Dob06]. Focus was on efficiency in the definition, deployment and execution of services. This focus now has been shifted into adaptability – how networked service systems can adapt to changes in their environments. We have entered an era with a higher degree of flexibili- ty. To utilize the potential of these features, the properties of services, nodes and node capabilities must be formalized, stored and made available. Also, the poli- cies and mechanisms that manipulate and exploit these properties must be worked out.
Adaptability is a concept widely used in Biology to describe the agility of biological entities that are able to adapt to changes in the environment [Sus05].
N
Overview
Adaptability in service systems is defined in a similar way, however, with a dif- ferent perspective.
Adaptable service systems are in Paper H defined as service systems that are able to adapt dynamically to changes in time and position related to users, nodes, capabilities, system performance, changed service requirements and pol- icies.
A capability is defined here as an inherent property of a node, which is used as a basis for implementing a service. Capabilities can be classified as re- sources, functions and data. Examples of general capabilities are CPU, memory, transmission link, available programs and user profiles. Examples of specific capabilities are medical equipment related to networked medical services.
Capability performance measures are in Paper H classified as i) Capacity measures, ii) State measures and iii) QoS measures. Capacity measure examples are transmission channel capacity, CPU processing speed and disk size. State measure examples are the number of available streaming connections and the number of packets discarded in a specific buffer. Quality of Service (QoS) is the degree of satisfaction of the users of a service. QoS measures can be traffic measures and dependability measures. Important traffic measure examples are capability throughput and capability utilization. Important dependability meas- ure examples are capability availability and capability recovery time.
Service performance measures are measures related to the service. These can comprise i) state measures and ii) QoS measures. State measure examples are the number of users waiting to use the service, the number of users that are using the service and the status of the service; i.e. normal state, performance- degraded state. Concerning QoS measures, traffic measure examples are service connection time, service transfer time, service waiting time, service throughput and service utilization. Important dependability measure examples are service availability and service recovery time.
The concept system performance is used as a common concept for capa-
bility and service performance. As defined in Paper G, The service provider and
service users can have common agreements related to the provided functionali-
ty, capabilities, system performance as well as payment. Such an agreement can
be expressed in a Service Level Agreement (SLA). SLA is a formal negotiated
agreement between a service provider and service users [Try05].
To precisely describe the properties of adaptable service systems, goal adaptability properties consisting of general and core properties are defined.
The general properties are properties of the architectural framework, while the core properties are properties of the functionalities.
General properties are in Paper G defined as follows: 1) There must be a flexible and common way of modeling services, 2) The framework must be flexible with respect to the adding of adaptability properties and features, 3) The service concepts must be flexible and powerful, 4) The software mechanisms must be flexible and powerful, and 5) There must be an easy mapping of service models to software models.
The core properties defined in Paper B and later in Paper G are illustrated in Figure 1.The core properties are grouped into three classes:
A1:
Rearrangement flexibility
A2:Failure robustness
A3:
Resource load awareness and control
Figure 1 – The core properties A1, A2 and A3
Rearrangement flexibility means that the system structure and the functionality
are not fixed. Nodes, users, services, service components, capabilities, can be
added, moved, removed according to needs. Mobility of persons, sessions,
Overview
nodes, terminals is further seamlessly handled. New nodes and capabilities are found automatically when introduced, and needed information about changes is propagated. There is a continuous adaptation to changed environments and op- eration strategies/policies.
Failure robustness
means that the architecture is dependable and distributed, and that the system can reconfigure itself in the presence of failures. Resources and functionality are duplicated, hardware and software component failures must be detected and reconfiguration and re-initialization must take place dur- ing system operation.
Resource load awareness and control means that there is functionality for ne-
gotiation about QoS and optimum resource allocation, monitoring of resource utilization, and actions for reallocation of resources.
The general properties as well as property A1 define the basic flexibility features of the architecture. Property A2 and property A3 set requirements to concepts and features that are needed as a foundation for the specification and implementation of the functionalities defined by these properties. The core properties will, from now on, be referred as A1, A2 and A3 throughout this the- sis.
1.2 Outline of the thesis
The thesis is structured into two main parts: Part I – Introduction and Part
II – Selected Publications. Part I is furthered structured as follows:Section 1 presents definitions and goal properties of adaptable systems, an
outline of the thesis as well as a guideline for reading. Section 2 presents re-
search method and framework. This includes objectives, scope, problem state-
ments, a presentation of TAPAS, and the research cycle of the work presented
in this thesis. The research cycle visualizes the research methodology, the evo-
lution of this research and the relations with the TAPAS architecture. Section 3
presents the solution framework, the contributions and finally the realization of
the problem statements defined in Section 2. Section 4 gives a summary of the
papers of Part II as well as the relationship between them. Section 5 presents
the related work. Section 6 presents summary, conclusions and further work.
The publications included in Part II are the followings:
Paper A
An Approach to Capability and Status Modeling
P. Supadulchai, F.A. Aagesen, in Proceedings of Norwegian Informatics Conference (NIK 2003), Stavanger, Norway, 2004.
Paper B
Configuration Management for Adaptable Service Systems
F.A. Aagesen, P. Supadulchai, C. Anutariya, M.M. Shiaa, in Proceedings of IFIP In- ternational Conference on Metropolitan Area Network, Architecture, Protocols, Con- trol and Management (MAN 2005), Ho Chi Minh City, Vietnam, 2005.
Paper C
A Framework for Dynamic Service Composition
P. Supadulchai, F.A. Aagesen, in Proceedings of 1st International IEEE Workshop on Autonomic Communication and Computing (ACC 2005), Taormina, Italy, 2005.
Paper D
Autonomic Service Configuration by a Combined State Machine and Reasoning Engine-based Actor
P. Supadulchai, F.A. Aagesen, in Proceedings of the 2005 IFIP International Confe- rence on Intelligence in Communication Systems (INTELLCOMM 2005), Delta Cen- tre-Ville Hotel, Montréal, Canada, 2005.
Paper E
Policy-based Adaptable Service Systems Architecture
P. Supadulchai, F.A. Aagesen, in Proceedings of the IEEE 21st International Confe- rence on Advanced Information Networking and Applications (AINA-07), Niagara Falls, Canada, 2007.
Paper F
Towards Policy-Supported Adaptable Service Systems
P. Supadulchai, F.A. Aagesen, in Proceedings of the 13th Eunice Open European Summer School and IFIP TC6.6 Workshop on Dependable and Adaptable Networks and Services, University of Twente, the Netherlands, 2007.
Paper G
A Capability-based Service Framework for Adaptable Service Sys- tems
F.A. Aagesen, P. Supadulchai, in Proceedings of The 2nd International Conference on Advances in Information Technology (IAIT2007), Bangkok, Thailand, 2007.
Paper H
Autonomous Production of Parameters of an Autonomous Capabil- ity Allocation Adaptation Model
P. Supadulchai, F.A. Aagesen, prepared for a submission.
Overview
Report I
NxET Reasoning Engine
P. Supadulchai, Plug-and-play Technical Report, Department of Telematics, NTNU, ISSN 1500-3868.
1.3 Guideline for reading
The publications presented in Part II are self-contained. They are refor- matted to improve readability when published in a smaller-size book. Since the papers have some overlapped contents and can also be linked, the reader is sug- gested to follow the depicted sequence illustrated in Figure 2.
Figure 2 – Guidelines for reading
Research method and framework
2. Research method and framework
This section describes the research objectives, problem statements, TAPAS as well as the research cycle of the work presented in this thesis. Section 2.1 states the overall research objectives. Section 2.2 presents the problem state- ments. Section 2.3 presents TAPAS, while the research cycle is presented in Section 2.4.
2.1 Research objectives
The context of this thesis is capabilities in adaptable service systems. The main research objectives are “to study and analyze concepts, models and me- chanisms for the realization of the general and the core properties related to capabilities, and further to specify, construct, evaluate and validate a frame- work for capability configuration management.”
2.2 Scope
Concerning the design of the capability configuration management frame- work, the emphasis is not on distribution and dependability aspects. The capa- bility configuration management functionality is not itself designed to meet the core property A2 or to support the design of the core property A2 besides needed concepts. The capability configuration management functionality is de- fined to support the core properties A1, A2 and A3, but its design is based on a centralized and non-dependable architecture.
2.3 Problem statements
The following initial problem statements
P1, P2, P3, P4, P5 and P6 aredefined.
• P1: How to include capabilities as well as additional needed concepts in
the architectural framework?
• P2:
How to include capability management in an architectural frame-
work?
• P3: Which concepts, features and mechanism are appropriate for auto-
nomic capability management?
• P4:
What is the ontology to be used? How to model and represent the concepts of the ontology?
• P5: How to model capability management functionality when considering
modularity, reusability, expressive power and flexibility?
• P6: How to evaluate and validate the proposed framework?
2.4 TAPAS
The work in this thesis is related to TAPAS architecture (TAPAS = Tele- matics Architecture for Play-based Adaptable Service Systems). The original architecture has focus on the adaptability properties of plug-and-play systems [Aag99a]. Since then several participants have contributed to the concepts, de- signs, implementations and demonstrations [Shi05]. The PhD work presented in this thesis has also contributed with new TAPAS concepts, models and mechan- isms. TAPAS as it was by the time this PhD study commenced has been im- proved and extended. This section presents the scope of the thesis considered from the TAPAS perspective. Necessary features and concepts of the TAPAS architecture will be presented. Contributions from the work reported in this the- sis will also be given.
2.4.1.1 TAPAS computing and service architectures
To meet the general properties as defined in Section 1, the TINA architec- ture principle [ITU92] was followed. TAPAS has a computing architecture and a service architecture dimensions.
The service architecture has focus on the service functionality independent
of implementation. The computing architecture has focus on the modeling of
functionality with respect to implementation, but independent of the nature of
the service functionality. The properties of the computing architecture, however,
are the fundament for the creation of services with needed goal adaptability
properties.
Research method and framework
TAPAS computing architecture
The computing architecture is founded on a theatre metaphor as illustrated in Figure 3. Actors perform roles according to manuscripts. Actors are software components in the nodes that can download manuscripts defining the roles to be played. An actor will constitute a role figure by behaving according to a manu- script. A play consists of several actors playing different roles, each possibly having different requirements on capabilities.
Figure 3 – The theatre metaphor
Figure 9 in Section 3.1 illustrates the present version of the TAPAS com-
puting architecture. The computing architecture has three views: the service
view, play view and physical view. In the service view, a service system provid-
ing a service is constituted by conceptual service components, each of which
can also be considered as a service system and can be further constituted by ser-
vice components. A service component that cannot be further de-composed is
Leaf service components in the service view are constituted by role fig- ures. A role figure can have dialogues with other role figures. A play consisting of role figures and dialogues is a service system instance as seen from the play view.
Considering the physical view, actors are executed as operating system soft- ware components in nodes, which are physical processing units such as servers, routers, switches and user terminals. The core platform is a platform supporting the execution of service functionality based on the computing architecture func- tionality. The core platform has a manuscript execution functionality and a basic communication functionality between nodes. In the original version denoted as the classical actor model, a manuscript is based on Extended Finite State Ma- chine (EFSM). The communication functionality can be based on Java RMI [Aag01a], socket-based [Lüh04] and XML web services [Vil04].
The three view model is not a layered service model. A service system and its service components have models and model parameters related to the service view, play view and physical view. The visibility of physical view parameters in the service view is a design decision rather than a model restriction.
TAPAS service architecture
The service architecture is illustrated in Figure 4. In addition to the pri- mary service provisioning functionality for application service systems, there must be functionality for management of the networked service systems. This management functionality comprises:
•
Service management: Service specification, implementation, deploy- ment, invocation, exhibition, discovery and access.
•
Mobility management: The handling of mobility and mobility compo- nents. Mobility components can be persons, services, dialogues and ses- sions, terminals, nodes, capabilities, data and programs.
•
Capability and service performance administration: Monitoring and registration of available and allocated capabilities, monitoring and regis- tration of system performance, and the provisioning of a repository of available capabilities, capability performance and service performance.
•
Capability configuration management: The allocation, re-allocation, de-
allocation and optimization of the use of capabilities.
Research method and framework
Figure 4 – TAPAS Service architecture
Regarding the service architecture, this thesis focuses on and has contribu- tion mainly to capability configuration management. The studies of the other functionality parts of the adaptable service system can be found in the related work by the other participants in the TAPAS project. A comprehensive study on the mobility management aspects can be found in Mazen Malek Shiaa’s thesis [Shi05]. A study on the service management aspects can be found in Shanshan Jiang’s work [Jia03, Jia06, Jia07], which is a part of an on-going PhD study.
2.4.1.2 This thesis’s contributions to TAPAS
At the starting point of this PhD study, the architecture had a core plat- form, which is a generic software component for executing the so-called Ex- tended Finite State Machine (EFSM)-based specifications. In addition to the core platform, the major service functionalities that had been contributed to the architecture were related to the mobility management functionality [Shi05]. The architecture itself had limited features related to the capability concepts.
The capability concept was defined in [Aag99b] and a configuration man- agement framework for capability configurations was introduced in [Aag02a]
and [Aag02b]. However, the configuration management functionality was li-
mited.
The work in this thesis has contributed concepts, models and mechanisms to the TAPAS architecture. The computing as well as the service architecture has been extended and revised. In addition to the revisions and improvement of the concept model constituting the computing architecture, new concepts such as capability performance, service performance, SLA, Reasoning Machine (RM) and RM manuscript have been added. The core platform has also been improved with the ability to execute policy-based specifications, which is more flexible and powerful than EFSM-based specifications. The RM applied in the core platform, which is more thoroughly described in Report I, is one of my contributions to the core platform. The other main contribution to the core plat- form is the concept model and data representation as is described in Section 3.
Concerning the service architecture, the capability configuration manage- ment is extended from the configuration management framework in [Aag02b]
and [Aag03] with respect to capability performance, service performance and SLA. In addition to extending the functionality area of capability configuration management, policy-based adaptability models based on feedback loops are in- troduced. The RMs handling the adaptation is controlled by policies and para- meters. Policies are rules and actions, while the parameters are constraints as well as reasoning conditions (See the RM-related data entities in Section 3).
Dynamic policies allows policies used by the capability allocation adaptation to be changed by another policy-based system based on some goodness criteria.
Parameter production allows parameters of the capability allocation adaptation to be re-produced based on some goodness criteria.
The complete solution framework and its contributions will be given in
Section 3. However, a brief comparison between TAPAS at the starting point of
this thesis (TAPAS 2003) and the present TAPAS architecture (TAPAS 2007)
is illustrated in Figure 5 and Figure 6. Figure 5 compares the TAPAS computing
architecture in 2003 and 2007 with respects to the capability, capability perfor-
mance, service performance, SLA concepts and the core platform. Figure 6
compares the TAPAS service architecture in 2003 and 2007 with respects to the
capability configuration management and adaptation models.
Research method and framework
Figure 5 - TAPAS computing archtecture in 2003 and 2007
Figure 6 - TAPAS service architecture in 2003 and 2007
2.5 Research cycle
The research cycle used for the work in this thesis is based on common scientific iterative research cycle method [Bri91] and [Aag01b] as follows:
Solution proposition
Concepts, models and mechanisms are proposed for the problem state-
ments as defined in 2.3.
Modeling and formalization
A solution framework consisting of the proposed concepts, models and mechanisms is formulated. The concepts, models, mechanisms are further for- malized to ensure integrity, soundness, consistency and completeness. Using formalized concepts, models and mechanisms, it is easier to improve and add new functionality than using the non-formalized ones.
Evaluation and validation
Demonstration and simulation have been applied for validating and im- proving the proposed solution framework. Demonstration is a method for illu- strating how the proposed models and mechanisms perform in a real environ- ment. Simulation is a method for testing the proposed models and mechanisms.
The demonstration method has been used when the system performance evalua- tion is not the main focus. Simulations have been used when real-environment demonstrations have not been satisfactory and when the applications of the sys- tem models were needed to give more detailed results with respect to system performance. Simulations can also be easily reproduced as opposite to real-scale demonstrations.
Concerning the demonstration method, Paper A, Paper B, Paper C and Pa- per D present several scenarios for adaptable service systems. The formalized and executable specifications in these scenarios are demonstrated by the solu- tion framework. Demonstrations illustrate the execution mechanism and vali- date the obtained results.
Concerning the simulation method, Paper E, Paper F and Paper H presents the simulation results based on the proposed models and mechanisms. The si- mulation method is preferred because QoS and performance of the service sys- tems in the scenarios are the main focus. Model simulation is more feasible and efficient than large scale real-environment demonstrations.
There is no formal proof of the models and mechanisms. The validation is done by the demonstration and simulation methods.
Result discussion
Results, which are gathered from the evaluation and validation, are used
for further discussing the models and mechanisms. If the results are not as ex-
Research method and framework
pected, the models and mechanisms will be improved or some assumptions will be changed. This may subsequently lead to a new problem statement or a new solution and begin a new iterative research sequence.
Figure 7 illustrates an overview of the research cycle used in this thesis, which consists of solution proposition, modeling and formalization, evaluation and validation and result discussion.
Figure 7 – Research cycle overview
The solution framework
3. The solution framework
The solution framework is defined to consist of four contributions. Each contribution consists of sub-contributions; each of which represents contributed concept, model or mechanism. The contributions are:
C1: Capability-based computing architecture C2: Policy-based reasoning
C3: Capability configuration management C4: Concept model and data representation C5: Scenarios - experimentation and simulation
Section 3.1 presents the contributions. The relationship between contribu- tions and the problem statements defined in Section 2.3 is discussed in Section 3.2.This section also presents the relationship between the contributions and the publications in Part II.
3.1 The solution framework contributions
Figure 8 illustrates the sub-contributions of the four contributions C1-C4.
These contributions are not independent. The ontology-based capability selec-
tion mechanism, dynamic policies and parameter production, for examples, are
related to both policy-based reasoning and capability configuration manage-
ment. The content of the contributions defined by their sub-contributions are
presented in more details below. The contribution C5 contains the applications
of the solution framework. Thus C5 is not included in Figure 8.
Figure 8 - The reasoning-based capability configuration management framework C1: Capability-based computing architecture
Capability, capability performance, service performance, SLA and RM- functionality
The capability-based computing architecture, which is illustrated in Figure 9, extends the previous versions of the TAPAS computing architecture. The im- portant roles of capabilities are made clearly visible and QoS-related concepts such as: capability performance, service performance and SLA are also in- cluded. The core platform has also been improved with the ability to execute policy-based RM specifications. These concepts are formalized and made visi- ble in the computing architecture as illustrated Figure 9.
The orange boxes in Figure 9 depict the contributed concepts. Capability and capability performance measures defined in the physical view are also visi- ble in the play view as well as the service view. The service performance meas- ures and SLA defined in the service view are also visible in the play view. This is not explicitly illustrated in Figure 9.
SLA classifies service users into different classes, each of which represents
the agreed priority, functionality, performance, payment and penalties functions
The solution framework
for a group of users with the same degree of satisfaction and costs. The capabili- ty allocation adaptation is the mechanism used to allocate and re-allocate capa- bilities with respect to the SLA defined.
SLA Mapping
SLA mapping is a transformation of SLA into the parameters of the capa- bility allocation adaptation model. In addition to C1, SLA mapping is also re- lated to the parameter production in C2 and the capability allocation adaptation in C3. The parameters to be produced include the system constraints as well as the reasoning conditions of the RM-based role figure handling the capability al- location adaptation. The mapping is based on the parameter production that is handled by the parameter producer as illustrated in Figure 10. An example of the SLA mapping has been dealt in Paper H.
Figure 9 – The capability-based computing architecture
To further create satisfaction for the service provider, income and cost
of the service provider while the cost function determines instantaneous cost of the service provider. The income and cost functions are also considered parame- ters of a capability allocation adaptation model. Examples can be found in Paper E, Paper F, Paper G and Paper H.
Figure 10 – SLA Mapping C2: Policy-based reasoning
Policy-based reasoning is a support functionality related to the ability of adaptable service systems to take decision based on flexible and expressive be- havioral specification. The contribution consists of generic reasoning model, RM-based role figures, generic policy system definition, ontology-based capa- bility selection mechanism, dynamic policies and parameter production. Policy- based reasoning is a contribution to be found in all Papers. The formalization of the policy-based reasoning including the generic reasoning model and RM- based role figures can be found in Paper E, Paper F, Paper G and Paper H.
Generic reasoning model
The generic reasoning model has a reasoning procedure for transforming an initial transformation clause to final transformation clause(s), which are me- diums for the transformation. The reasoning procedure uses policies, facts and system constraints. Policies are used to manage the behavior of service systems.
A policy system consists of rules and actions. The rules are used to transform an
initial transformation clause to final transformation clause(s), which can contain
The solution framework
suggested actions. These actions will be applied for managing the adaptable service system behavior. The facts are inherent data gathered from the system.
Examples are inherent capability performance, inherent service performance and SLA. The system constraints are used to model application-specific service system requirements with respect to capability, capability performance and ser- vice performance.
The generic reasoning model can be used to form a feedback loop. An ex- ample feedback loop is the capability allocation adaptation model, which will be described later in this section. Reasoning conditions are used by an EFSM- based role figure to activate and de-activate the feedback loop for the capability allocation adaptation. The feedback loop parameters are the system constraints and the reasoning conditions. These parameters can be produced.
Figure 11 illustrates the generic reasoning model. The system constraints, rules and actions can have variables. The result of the reasoning can, in addition to actions, give instantiated variables. The facts contain no variable.
The generic reasoning model has been used in all papers. The implementa- tion of the reasoning procedure is discussed in Report I.
Figure 11 - The generic reasoning model RM-based role figures
As introduced in Section 2, manuscripts are the specification of roles to be
played by actors. An actor can have two types of manuscripts: the EFSM-based
specification or the combination of the EFSM-based and RM-based specifica-
tion. Concerning the role figures, there are also two role figure types: i) EFSM-
based role figures and ii) RM-based role figures. The EFSM-based role figure
has its role defined by an EFSM specification. The RM-based role figure has its
role defined by the combination of an EFSM-based and the RM-based specifi- cation.
The functionality domain of RM-based role figures can be separated into two cases. In the first case, the RMs of a service system have no access to capa- bility and service performance measures of the service system. In this case, the RM provides an ordinary procedural reasoning service only; i.e. the reasoning service does not include the capability configuration management. In the second case, RMs of the service system have access to capability and service perfor- mance data of the service system. These RMs take part in the capability confi- guration management for managing other EFSM-based role figures. For the second case, RMs can be used as:
A. a procedural reasoning service for capability initialization and re- initialization based on capability performance measures
B. a feedback loop service for capability allocation adaptation based on ca- pability and system performance measures
C. a feedback loop service constituting dynamic policies and parameter pro- duction for the capability allocation adaptation model in B
A reasoning cluster is an independent unit with respect to reasoning. It is a
collection of EFSM-based service components with an associated reasoning
system constituted by one or more RM-based service components. A reasoning
cluster has associated RM-related data entities and considers them as common
data shared among EFSM-based and RM-based role figures. In addition to the
EFSM-based service components in the cluster, a reasoning machine has an as-
sociated cooperating EFSM, which will invoke the reasoning machine. Depend-
ing of the nature of the cluster and the nature of the reasoning, a dedicated
EFSM denoted as E
Σcan be needed to inspect the reasoning conditions and to
activate the RMs associated EFSM. Three reasoning cluster types (A, B and C)
corresponding to the functionality domain cases A-C defined above are illu-
strated in Figure 12.
The solution framework
Figure 12 - Reasoning cluster types
In all cluster types, an RM-based capability manager R
CM, gives suggested actions to an EFSM-based capability manager E
CMfor managing capabilities. In the cluster type A, R
CMis a procedural service for capability initialization and re-initialization. Re-initialization is initiated by E
Σ.
Generic policy system definition
Generic policy system definition defines policies that are applicable for any adaptable service systems. Constraints specific to an individual application ser- vice system will be separated from policies. The separation makes the policies generic. However, a condition is required. A policy system to be made generic must represent behaviors that are independent of the nature of any service sys- tem. These generic behavior examples can be self-x autonomic functionality such as self-healing, self-protection and self-optimization.
Example of policy systems that have been made generic is the policy sys-
tem for the capability initialization and the policy system for the parameter pro-
duction. The generic policies system for capability initialization can be found in
Paper C while the generic policy system for parameter production can be found
in Paper H.
Concerning the policy systems for capability re-initialization, capability al- location adaptation and dynamic policies, these policy systems depend on the adaptability nature of service systems. To make generic policy systems, generic behaviors representing the adaptability nature of any service system must be de- fined and formalized.
Ontology-based capability selection mechanism
Ontology-based capability selection mechanism is a mechanism for explor- ing the relationship of capabilities and determining the equivalence of capabili- ties based on a defined capability ontology model. The ontology-based capabili- ty selection mechanism has been dealt with in Paper A.
Dynamic policies
Dynamic policies mean the policies are not fixed while the fixed policies are denoted as static policies. Dynamic policies can be changed based on the consequences when the policies are used, which will be calculated from certain goodness criteria. Feedbacks as well as the income and cost functions of the ap- plication service systems can be used as the goodness criteria. Income functions indicate the present income of the service provider. Cost functions indicate the present expense of the service provider. The formalized model and mechanism of the dynamic policies can be found in Paper E, Paper F and Paper G.
Parameter production
The parameters system constraints and the reasoning conditions of RM- based role figures can be reproduced based on changes in the environment, as defined in the definition of adaptable service systems, and goodness criteria.
The formalized model and mechanism of the parameter production can be found in Paper H.
C3: Capability configuration management
This contribution is about the capability configuration management in the
TAPAS service functionality architecture. The capability configuration man-
agement comprises i) capability initialization and re-initialization and ii) capa-
bility allocation adaptation.
The solution framework
Capability initialization
The capability initialization is the allocation of the capabilities for the EFSM-based service components to be distributed and instantiated. The confi- guration of the capability initialization is autonomously generated by an RM- based role figure. The capability initialization configuration consists of EFSM service component types and the targeted actors to instantiate these EFSM ser- vice component types. The instantiated EFSM service component types are de- noted as EFSM service component instances.
To generate the capability initialization configuration, the required capabil- ities and capability performances of EFSM service component types are matched with the offered capabilities and capability performance as illustrated in Figure 13. The capability initialization has been dealt with in Paper B and Paper C.
Figure 13 – Capability initialization Capability re-initialization
The capability re-initialization is the re-distribution and re-instantiation of
service components and capabilities during the situations when the instantiated
service systems are unable to adapt satisfactorily as well as when capabilities
are moved or relocated. In case of failures, capability re-initialization finds
equivalent capabilities to replace the failed ones based on the ontology-based
capability selection mechanism. With the equivalent capabilities, the service
system can still offer services with the same level of performance or slightly
degraded performance. The capability re-initialization has been dealt with in Paper B and Paper D.
Capability allocation adaptation
The capability allocation adaptation is the monitoring of the performance of the executing service system and the reallocation of capabilities within the executing service systems. A capability allocation adaptation system is formed by a feedback loop as illustrated in Figure 14. The system has policies and pa- rameters. The parameters are system constraints and reasoning conditions. The RM-based capability manager
RCM, gives suggested actions to an invoking EFSM-based capability manager E
CMbased on the policies and parameters. A dedicated EFSM E
Σactivates and de-activates the E
CMbased on the reasoning procedure.
Figure 14 - Capability allocation adaptation
The policies and parameters of the capability initialization, re-initialization and allocation adaptation can be changed. The changes of policies and parame- ters of these policy-based adaptation models are based on the dynamic policies and the parameter production respectively. An additional feedback loop is used to evaluate the consequences of the used policies and parameters. In the solution framework, the dynamic policies and the parameter production have been used with the capability allocation adaptation. However, it is possible use the para- meter production with the capability initialization and re-initialization as well.
Note that this PhD study does not intend to obtain the optimized policies and
parameters for the capability allocation adaptation. The dynamic policies and
The solution framework
parameter production, nevertheless, serve as a flexible tool for the experimenta- tion with alternative policies with respect to optimization.
Figure 15 illustrates the dynamic policies for capability allocation adapta- tion. An additional feedback loop is formed by an EFSM-based and an RM- based policy composer. The policies of the capability allocation adaptation model will be composed. Transformation constraints used by the policy com- poser consist of rules and actions, which will constitute the policies of the capa- bility allocation adaptation model. The policy composer uses transformation policies to compose and give the policies of the capability allocation adaptation model as the output. The facts are the inherent capability and service perfor- mance measures, which are feedbacks from the service system being controlled by capability allocation adaptation.
Figure 15 – Dynamic policies for capability allocation adaptation
Figure 16 illustrates the parameter production for capability allocation
adaptation. An additional feedback loop is formed by an EFSM-based and an
RM-based parameter producer. The system constraints and the reasoning con-
ditions will be produced. The parameter producer takes an SLA as the input and
produces a system performance requirement model and a physical performance
requirement model as the output. Then, the parameter producer takes the pro-
duced system performance requirement model and a physical performance re-
quirement model as the inputs and produces the system constraints and the rea-
soning conditions as the outputs. The transformation is based on the transforma- tion policies. The facts are the inherent capability and service performance measures, which are feedbacks from the service system being controlled by ca- pability allocation adaptation.
Figure 16 – Parameter production for capability allocation adaptation
The capability allocation adaptation can be found in Paper E, Paper F, Pa- per G and Paper H. The dynamic policies for the capability allocation adapta- tion can be found in Paper E, Paper F and Paper G. The parameter production for the capability allocation adaptation can be found in Paper H.
C4: Concept model and data representation
A concept model and a data representation are applied for modeling and formalizing necessary concepts. This contribution consists of the concept ontol- ogy and the unified XML-based data representation sub-contributions.
Concept ontology
The concept ontology describes the ontology model for the concepts,
which are capability, capability performance, service performance, SLA, EFSM
and RM. Concerning the capability, capability performance and service perfor-
mance, there are various representation standards. Examples are Common In-
The solution framework
formation Model (CIM) [Dmt07a], Simple Network Management Protocol - Management Information Base (SNMP-MIBs) and Management Information Format (MIF). CIM is a conceptual information model for modeling capabilities regardless of the implementation model. SNMP-MIBs are databases for storing information related to capabilities of targeted nodes. MIF is a format used by Desktop Management Interface to store capabilities of desktop or notebook node types. However, the concept ontology is based on CIM because CIM is in- dependent of implementation. It is also possible to map CIM models to SNMP- MIBs as well as MIFs if needed.
The direct use of CIM does not give features that will satisfy all the core functional adaptability requirements. So to model capability requirements, addi- tional modeling language such as UML is needed. UML can provide a set of predefined constructs, such as subClassOf, minCardinality and maxCadinality.
However, UML lacks functionality to representing inherent relationships and complex constraints. Moreover, the specification based on CIM and UML needs to be transformed into executable specifications that are recognized by reason- ing machines, which may introduce complexity and errors caused from the transformation process. Semantic web languages such as RDF [W3c04a], RDFS [W3c04b] as well as OWL [W3c04c] can also be applied for additional con- structs for describing more expressive ontology models of the capability, capa- bility performance, service performance and SLA. The capability, capability performance, service performance ontology has been dealt in Paper A and Paper B.
As defined earlier, SLA is modeled as classes; each of which represents the agreed priority, functionality, performance, payment and penalties functions for a group of users with the same degree of satisfaction and costs.
An EFSM-based specification consists of EFSM-related data entities that are a set of states, an initial state, variables, parameters, input signal with para- meters, output signal with parameters, state transitions, output functions and the functions and tasks performed during a specific state.
An RM-based specification consists of RM-related data entities as illu-
strated in Figure 17. These data entities are facts, policies, reasoning conditions,
constraints and transformation clauses, which have been defined in the generic
reasoning model sub-contribution. In this thesis, the use of policies is related to
policies, capability re-initialization policies and capability allocation adaptation policies. Reasoning conditions represent the conditions that activate and de- activate reasoning machines. The capability configuration management condi- tions are related to the capability allocation adaptation, the capability allocation with dynamic policies and the capability allocation with parameter production.
Initial requests such as capability initialization request, capability re- initialization request and capability allocation adaptation request will be formu- lated as transformation clauses that will be transformed until final transforma- tion clause(s) are derived.
The EFSM-based and RM-based data entities have been dealt with in Pa- per E, Paper F, Paper G, Paper H and Report I.
Figure 17 – The RM-related data entities Data representations
The data representations of capability, capability performance, service per- formance are based on xmlCIM [Dmt07b]. The data representation of SLA is RDF, which is chosen because of none of the standards can represent the com- plete set of ontology attributes that are required to model an SLA class.
The representations of the EFSM- and RM-based specifications are based on XML-based constructers. There are four types of XML-based constructers:
ordinary XML, XML expressions, XML clauses and XML rules. An ordinary
XML is just ordinary XML elements without variables. XML expressions are
XML documents that consist of variables. The XML expressions are expressive
and used to model implicit knowledge. An XML clause consists of XML ex-
The solution framework
pressions and used to represent certain knowledge during a capability configura- tion. XML rules are used by reasoning machines to transform an XML clause until the final clause representing the answers is obtained. The facts are mod- eled by ordinary XML. The reasoning conditions, constraints are modeled by XML expressions. The transformation clauses are modeled by XML clauses.
The policies are modeled by XML rules.
The RM-based data representation has been dealt with in Paper A, Paper G, Paper E and Report I.
C5: Scenarios – experimentation and simulation
Five scenarios (S1-S5) have been designed for the evaluation and valida- tion of the other contributions. The scenarios are adaptable service system ap- plications that are created based on the concepts, models and mechanisms of the solution framework. These scenarios are as follows:
S1: Ontology-based capability selection for a Tele-school application
Ontology-based capability reasoning for a Tele-school application is pre- sented in Paper A. The sound capability of the clients in the Tele-school appli- cation is considered. By the use of RDFS’s subClassOf, the sound capability and the loudspeaker capability are defined as substitutable. Based on the dem- onstration method, the reasoning result shows that the mobile clients having ca- pabilities that are sub-class of the sound capability must switch off the capabili- ties when entering the classroom.
S2: Printing system capability initialization and re-initialization
Capability initialization and re-initialization of Intelligent Printing Man- agement (IPM) service system has been demonstrated in Paper B and Paper C.
The scenario illustrates the autonomous generation of capability configuration and re-configuration plans of the roles of IPM. Each role has different require- ments. The proposed capability initialization and re-initialization policies de- termine the appropriate node to instantiate each role.
S3: Capability re-initialization of RM-based role figures
