- Email: [email protected]
A hybrid approach to self-management in a pervasive service middleware
Knowledge-Based Systems 67 (2014) 143–161
Contents lists available at ScienceDirect
Knowledge-Based Systems journal homepage: www.elsevier.com/locate/knosys
A hybrid approach to self-management in a pervasive service middleware Weishan Zhang a,⇑, Klaus Marius Hansen b, Mads Ingstrup c a
Department of Software Engineering, China University of Petroleum, No. 66 Changjiang West Road, Qingdao 266580, China University of Copenhagen, Njalsgade 128, 2300 Copenhagen S, Denmark c No Magic, Bangkok, Thailand b
a r t i c l e
i n f o
Article history: Received 3 April 2013 Received in revised form 28 May 2014 Accepted 1 June 2014 Available online 14 June 2014 Keywords: Self-management Architectural styles Component control Goal Management Change Management
a b s t r a c t Self-management capabilities for pervasive computing systems are critical in improving dependability, usability, and autonomicity. However, realizing self-management is not an easy task due to complexities of implementing autonomous behaviors. It has been recognized that a single autonomicity handling mechanism is not sufficient to realize comprehensive self-management capabilities when different technologies are involved. Therefore, we propose a hybrid approach, the ‘LinkSmart Three Layered architectural (LinkSmart-3L) style’, in which different architecture styles are incorporated. The LinkSmart-3L style enables self-management at an architectural level. In our approach, semantic web technologies are used to achieve comprehensive context-awareness and extensibility of self-management capabilities, genetic algorithms are used to achieve configuration optimizations, and a planner is used to compute planning procedures on how to arrive at an optimum system configuration based on current architectural structure of the underlying system using an architectural query language. These technologies are integrated seamlessly based on the service oriented computing (SoC) paradigm. We have extensively evaluated both runtime and development time qualities of our implementation of the style. These evaluations can serve as guidelines for evaluating other middleware systems. We conclude that our approach is usable and effective in achieving these quality attributes. Ó 2014 Elsevier B.V. All rights reserved.
1. Introduction Self-management capabilities are attractive for pervasive computing systems as these systems are becoming more widely deployed, and requirements on dependability increase. Such systems are operated as open systems undergoing dynamic changes in which services and devices may join or leave at any time anywhere, and system resources, e.g., battery levels may fluctuate dynamically. Self-management capabilities as in autonomic computing [1] can potentially make these pervasive systems more user-friendly and energy efficient. For example, to diagnose the source of a failure and then recover to a normal operating state, or to make full use of remaining energy to prolong the runtime of a system. Because of these potential benefits, many efforts have been put into the realization of self-management capabilities [1]. These self-management capabilities are considered as the most important features of future network applications and should be given priority in future research [2]. ⇑ Corresponding author. Tel.: +86 532 86981972. E-mail address: [email protected] (W. Zhang). http://dx.doi.org/10.1016/j.knosys.2014.06.002 0950-7051/Ó 2014 Elsevier B.V. All rights reserved.
Although there is substantial pervasive middleware research such as EU MUSIC [3] and Rainbow [4,5], these efforts have primarily used a single approach to or focused on a single aspect of self-management. For example, the MUSIC project explored architecture based self-adaptation, while paying little attention to other self-management features such as self-protection, and self-optimization. For architecture-based self-adaptation, a critical issue is the choice of an architectural style to represent a target system [5], but the MUSIC project did not focus on this either. Kramer and Magee [6] observe that many early self-managing systems followed the ‘sense-plan-act’ architecture (e.g., Rainbow by Garlan et al. [4]) in which a system conceptually cycles through sense-plan-act phases. Kramer and Magee proposed a three layered architecture style that incorporate these three phases, but this is only an abstract reference model that needs to be verified in practice, and the problem of how to actually derive a software architecture style that can be implemented and used in practice for self-management systems is not addressed. On the other hand, implementing and achieving self-management are not easy tasks [7]. There are many aspects that should be considered in a self-management solution, such as effective
144
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
sensors to detect system status, actuators to accomplish needed changes, change management schemes to react to self-management changes, and reasoning on which actions to take. Furthermore, if an existing scheme cannot fulfill a Quality of Service (QoS) requirement, planning mechanisms should be used to help to find a corresponding (near) optimal configuration, and then this configuration should be enabled dynamically. Thus, the whole selfmanagement process involves quite a number of different tasks which can be realized with different techniques. Correspondingly, a self-management solution should support a hybrid of different techniques technologies at an architecture level in order to integrate these technologies seamlessly. A single mechanism for realizing self-management may be considered as too limited to realize comprehensive autonomic features [7]. In the process of reaching a hybrid solution for self-management, there exist a number of challenges. These include: 1. How to define an architectural style that can be used to achieve self-management at an architectural level [6]. 2. How to verify this architectural style by a practical implementation in order to show usefulness. 3. How to achieve interoperability, modifiability, and extensibility in this architectural style to easily integrate various self-management features including self-protection, self-protection, self-optimization, and self-configuration. Preferably it should be simple to add new self-management features that do not exist. 4. How to make sure that technologies used for various purposes can be integrated in this architectural style. To address these challenges, we propose the LinkSmart Three Layered architectural (LinkSmart-3L) style that features a serviceoriented architecture and seamlessly integrates several technologies to facilitate self-management. In our practical implementation and evaluation, we use pervasive web services [8] and OSGi Declarative Services [9]. The main contributions of our work are: 1. A ‘LinkSmart Three Layered architectural (LinkSmart-3L) style’ is proposed and exemplified. This style combines different architectural styles to enable architecture-level self-management. This makes it possible to bring together benefits from those underlying architectural styles. 2. Our approach is realized such that different self-management technologies can be integrated seamlessly based on the service-oriented computing paradigm. In our implementation, we have integrated Semantic Web technologies, genetic algorithms, an architectural scripting language, and an architectural query language. 3. Our middleware is evaluated in terms of runtime qualities including interoperability, performance, scalability, and development-time qualities including modifiability, testability and, usability, following the quality attributes framework proposed by Bass et al. [10]. We have performed evaluations which can serve as guidelines for evaluating other middleware systems, as currently there are no unified evaluation criteria or methodology. 4. Following the proposed evaluation quality attributes, our approach has been evaluated extensively in the LinkSmart middleware. For interoperability, both the .NET and Java environments are tested. This includes tests of using various available wired and wireless communication protocols. The performance has been tested extensively for various components and a whole self-management life cycle takes less than 4s which is acceptable in a distributed pervasive service environment. The scalability tests show that the needed time to process self-management actions is in linear with the number of events for our
tests. The modifiability tests show that the middleware can be extended with relative ease to add new self-management functions. The testability and usability tests show that the proposed approach is practical in use. 5. To promote the usage of self-management technologies and encourage research in this area, we have released our work including a set of supporting ontologies as open source such that other researchers can explore and potentially further our work. The remainder of this article is organized as follows. First, we present background on self-management, especially architectures for self-management in Section 2. In order to address challenge number 1, we define an architectural style (LinkSmart-3L) based on a set of objectives and constraints for self-management (Section 3) and we discuss key design choices of the LinkSmart-3L style. We then present the LinkSmart-3L architecture that follows a three layered self-management architectural model (Section 4) and we give design details of each layer. We show how to develop a self-managed application in B using a simple case study. Comprehensive evaluations regarding runtime and development time qualities of our approach are presented in Section 5. We discuss related work in Section 6. Conclusions and future work end this paper in Section 7.
2. Software architectures for self-management The task of architecting self-managing systems can be approached from several conceptual perspectives, which lead to different architectures. In one approach, inspiration is sought from nature to build systems with no explicit locus of control. An example is division of labor in a group of robots inspired by the decentralized organization of an ant colony [11]. This approach has particularly been applied to autonomic communications [12], but systems based on it are arguably difficult to engineer [13]. Another conceptual approach is to leverage traditional Artificial Intelligence (AI) by relying on explicit representation of plans as a basis for action. Although this might lead to a system with a central control unit (e.g., an AI planner as in [14]), control can also be distributed, e.g., by using Belief-Desire-Intention (BDI) agents [15]. A third conceptual approach is inspired by the model used to engineer control systems [16]. While it is orthogonal to the first two approaches in that it assumes nothing about representation of plans, it does require a certain level of centralized control in so far as measured system output must be compared with the desired output in order to compute the control measure needed to align the two. Many early architectures for autonomous robotics [17] follow the ‘‘sense-plan-act’’ architecture, which suffers from difficulties in maintaining precise ‘‘world models’’. Brook’s subsumption architecture [18] avoided this by following the slogan ‘‘the world is its own best model’’ and relying extensively on sensors, but it did not provide sufficient means to handle complexity. The three layer (3L) architecture described by Gat [17] combines ideas from both, in that the stateless and low complexity online control algorithms reside in the bottom layer, while the top layer employs traditional modeling and high-complexity planning algorithms, with the middle layer acting as interface between the two. This architecture has become a de facto standard architecture in autonomous robotics. The self-management approach of LinkSmart follows the three layered reference model proposed by Kramer and Magee [6] which is adapted from Gat’s 3L architecture. An overview is shown in Fig. 1.
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
145
different users that may have diverse mobility profiles. This means that their availability is unpredictable and that the software must be robust to unpredicted unavailability of devices. Further, devices frequently belong to different administrative domains, and thus the maintenance of software running on them is less coordinated and must be more loosely coupled than what is acceptable in more traditional (e.g., enterprise information) systems. For this reason loose coupling is an important sub-objective for modifiability in our target domain. Further, to increase the range of its potential use, middleware must make as few assumptions as possible about the application domain while still providing useful support to application developers. For self-management this implies that the means made available for developers to specify self-management schemes for their applications must be expressive and powerful, so that it is both possible and requires little effort to extend a self-management system with new functionality.
Fig. 1. Three layer architecture model for self-management.
The lowest layer is the Component Control layer. It is responsible for retrieving information about the state of the system, e.g., which services exist and what their states are. It is also responsible for actuating low-level change commands issued from higher layers, e.g., installing and starting a service. The middle layer is the Change Management layer. It is responsible for detecting situations that need to be managed, and to perform that management according to pre-determined schemes by issuing commands to the Component Control layer. A scheme in this context can be a plan such as a sequence of actions, or a component such as parts of a Petri Net [19] or rules processed by a rule engine. The top layer is the Goal Management or planning layer. When a situation is detected for which there is no applicable pre-existing scheme in the Change Management layer, the Goal Management layer is responsible for computing a new scheme, or plan. For example, an AI planner can be used to dynamically generate a reconfiguration plan that is sensitive to the constraints set by the current system states and policies. Ideally, high-level policies express what plans to create. 3. The LinkSmart three layered architectural style The three-layered reference model as proposed by Kramer and Magee is a logical reference model, and it does not as such constitute a clearly defined architectural style. In the following we remedy that by defining the concrete styles that are realized by our implementation architecture. We follow Fielding’s and Taylor’s [20] definition of an architectural style as ‘‘a coordinated set of architectural constraints that restricts the roles and architectural elements, and the allowed relationships among those elements within any architecture that conforms to the style’’. We use the definition with the understanding that constraints in a style are chosen to favor particular architectural objectives. 3.1. Objectives The LinkSmart-3L style seeks to achieve the following objectives in the system as a whole: 3.1.1. Modifiability The software deployed in a pervasive computing environment is distributed across a potentially large number of devices. They have
3.1.2. Performance (efficiency) Further, to make self-management usable and practical in pervasive systems, self-management processes must respond reasonably fast to changes. Since we know that there may be highcomplexity algorithms involved in self-management activities, these algorithms should be able to execute independently as part of the slower processes such as planning and optimization, while the parts of self-management that monitor, actuate and execute plans should be efficient. 3.1.3. Scalability A pervasive computing system may involve just a few devices and services while others may involve hundreds and thousands of devices and services in for example a large scale smart traffic monitoring system. Therefore, it is important that the middleware can scale well in different configurations with respect to the number of devices and services involved. This also means that the performance for executing a self-management task must have reasonable efficiency in different scales of configurations. 3.2. Constraints When defining our architectural style, it is important to be clear about whether the individual design objective, constraint, and assumption apply to the middleware itself or to the set of applications that can be built with it. We use the term constraint when they apply to our middleware, and the term assumption when the constraint must be satisfied for the system as a whole. The following constraints and assumptions are set by the LinkSmart-3L style: LS: Layered (constraint). The middleware shall use a layered style in order to tackle the complexities of self-management in a flexible manner. PS: Publish/Subscribe (constraint). To decouple event sources and consumers, and to enable the distribution of self-management components, the middleware shall use a publish/subscribe event mechanism. SAR: Sensor and Actuator-based Reflection in the Component Control layer (constraint). The middleware shall be able to collect system runtime status using various hardware and software sensors, and enable self-managing activities through corresponding actuators. SOA: Service-Oriented Architecture (constraint and assumption). The service orientation paradigm can help in achieving the ‘‘divide-and-conquer’’ idea for managing the complexities and self-management functionalities.
146
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
REP: Repository (constraint). To share knowledge among different components, a knowledge repository shall be used in the middleware. SI: Semantic Introspection (constraint). Knowledge about the system shall be explicitly categorized and modeled in Semantic Web ontologies to enable automated reasoning and enhance the intelligence of self-managing systems. PO: Planning-based Optimization (constraint). The middleware shall support the search for optimal runtime states and decide on how to reach an optimal state. The relationships between the constraints and the objectives are shown in Fig. 2 and explained below.
3.2.1. Layered style The first constraint we include is that the middleware must be divided into three layers following the work proposed by Kramer and Magee [6]. Organizing the system into layers helps reduce coupling among components in different layers [21]. It also helps managing complexity by introducing a higher level of abstraction, the layer, which encapsulates well-defined behaviors. The three layers are those already described earlier in Section 3.
3.2.2. Publish/subscribe style Using the publish/subscribe communication paradigm for event-based communication between layers promotes low coupling among components by decoupling them with respect to time, space (distribution), and synchronization [22]. This de-coupling further promotes modifiability/extensibility, since it is easy to add new components capable of receiving relevant events simply by adding them as subscribers, with no modification of the publishers being necessary. Publish/subscribe mechanism provides a convenient way to decouple a service provider and a service consumer, and ensures good scalability required for handling dynamics of pervasive systems. This event system also ensures extensibility for adding new self-management functionalities.
scalability, LS
+PS
+REP
scalability +SAR
+SI
+SOA
+PO
interoperability
LinkSmart-3L
Fig. 2. Derivation of the LinkSmart-3L style, showing how each constraint contributes to the objectives.
3.2.3. Sensor- and actuator-based reflection To avoid the complexity and overhead of maintaining a complete and centralized system model—the technique that became a weakness of the sense-plan-act architecture for autonomous robotics, the introspection implementation should be based on distributed sensors which can be queried to retrieve only actually used meta-data, and only at time when the data is actually required. This is important in the context of self management because we assume systems to be distributed, and particularly so in pervasive computing systems that frequently include devices with very limited bandwidth and power. For the intercession aspect of reflection (that allows modifications), the actuation of a change must be based on actuators present on the local devices where changes should take effect. A uniform interface makes it simpler to realize principled coordination of system-wide changes. Supporting runtime changes directly helps to achieve modifiability. It does so directly as it provides a way to modify a system, but also because it means configuration and re-configuration can be externalized rather than hard coded into the individual components. Thus the same components can be more easily used in a variety of configuration contexts. 3.2.4. Service-oriented architecture Both the system under management and the middleware follows Service-Oriented Architecture principles. SOA [23] is appealing as it promotes reuse, modularity, composability, componentization and dynamic interoperability in a standardized way. It enables the architectural principles of service encapsulation, loose coupling, service autonomy, and service discovery through welldefined service contracts and service abstraction. This both helps promote modifiability and separation of different concerns as self-management typically involves complex sense-plan-execute tasks. Service oriented architecture also helps to separate different aspect of a task, for example, software connectors [24] can be applied to separate the component communications from component functionalities, especially components residing in different layers. 3.2.5. Repository style Self-management works based on the awareness of various contexts which are shared among different components, and on efficient access to these contexts. In the LinkSmart project, a context-awareness based self-management is adopted [25,26]. A repository component using the repository style [21], is adequate for managing these contexts in the Change Management layer. Context information can be added to the repository using dedicated context ontologies and/or rule bases. The repository provides access to the semantics of an underlying system, including system/ device status, system structure and communication topologies. It helps to achieve low coupling of components and ensure extensibility. 3.2.6. Semantic introspection Self-management works based on knowledge about the system under management. In order to manage this in a principled way, introspective information is categorized according to well defined ontologies in the repository. The usage of ontologies ensures that the semantics of system knowledge is made explicit. This makes it easier to modify existing components or add new ones because self-management components rely critically on the correct interpretation of system meta data. The usage of ontologies further enables reasoning to augment the knowledge retrieved from lower layers. 3.2.7. Planning-based optimization Very often various self-management functionality can be reduced to finding an optimal target following multiple, even
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Goal Management
Change Management Event Manager
SeMaPS
Component Control
Fig. 3. LinkSmart self-management system model.
conflicting constraints from a large number of candidate solutions. For example, a self-managed system should consume the least battery energy but with the highest performance in a large smart city application where a large number of devices and events may be involved. In such a case, an efficient mechanism is needed to find optimal configurations for device communication protocols and decide appropriate services necessary to meet the QoS requirements. It is also essential to decide what necessary steps/procedures are to arrive to the optimal configurations.
4. Design of self-management in LinkSmart Based on the above introduced LinkSmart-3L architectural style, we describe the architecture of the LinkSmart self-management architecture using the approach of Clements et al. [27]. Our overall system model is shown as a deployment view in Fig. 3. The deployment follows Kramer’s and Magee’s model with each layer deployed on a node, and uses a publish/subscribe implementation (‘‘Event Manager’’) as an implementation of an event connector and it uses Web Ontology Language (OWL; 1) ontologies (‘‘SeMaPS’’) as data connectors. The set of ontologies used in LinkSmart is called SeMaPS (Self-Management for Pervasive Services). We now describe each of the three layers in details. 4.1. Component control The Component Control layer contains elements that provide the base functionality of a system. As such, in LinkSmart, it is composed of communicating domain- and application-specific web services [8,28] internally structured as components. Typically, these components are implemented using OSGi [29]. OSGi has become a widespread implementation framework for Java-based (pervasive computing) services. Furthermore, it provides a flexible modularization mechanism as well as a dynamic service platform. Internally on nodes, we implement topic-based publish/subscribe using the OSGi Event Admin service. The Component Control layer also contains facilities to interact with upper layers. This interaction is made in two ways: 1. Through sensors, sensing the current state of the functional elements, e.g., reporting if the current configuration of elements cannot meet design goals 2. Through actuators, allowing upper layers to change the current configuration so as to meet design goals Sensors in LinkSmart may be one of the following three types: 1
http://www.w3.org/2004/OWL/.
147
1. State sensors monitor the internal state of a service. Typically embedded services fulfill a state machine specification, and we report state changes to upper layers via events 2. Communication sensors monitor the communication between services, i.e., which messages are sent between which services 3. Configuration sensors monitor the configuration of services and components implementing the services in a system 4.1.1. State sensing The state and communication sensors are generated by the LinkSmart Service Compiler [8]. State sensing is based on an OWL description of a UML state machine for the service. Following the idea of SA-WSDL,2 we extend Web Service Description Language (WSDL) descriptions of web services to reference an OWL description of the service including a state machine description and use this when generating web services. Fig. 4 shows an excerpt of a WSDL description of a thermometer (TH03). The thermometer service defines an operation getTemperature, but furthermore defines a reference to a device description (in
http://www.w3.org/2002/ws/sawsdl/.
148
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
starting, stopping, updating, and undeploying. We have implemented a binding to OSGi that allows for architectural scripts that change an OSGi deployment. An example ASL script is shown in Fig. 8. The script initializes the variable aql_s to reference a service from the AQL component (line 1–3), stops the service (line 4), and eventually uninstalls the component (line 5). ASL plays an integral role in reconfiguration as effected by the upper layers in our architecture. We will return to this in Section 4.3. In summary, Fig. 9 shows a deployment view of the Component Control layer of LinkSmart self-management architecture. Furthermore, Fig. 10 summarizes a Component & Connector view of the interaction among components focusing on the Component Control layer. 4.2. Change management The Change Management layer is concerned with reacting to changes in states in the Component Control layer, changing parameters and behaviors according to a set of plans. In our case, plans are realized using OWL ontologies with behaviors represented as SWRL3 rules built on top of the SeMaPS ontologies. An overview of the ontologies is shown in Fig. 11. Our SeMaPS runtime implementation uses the Protégé framework4 for providing functionality to load/manipulate/save ontologies, for SWRL rule processing, and for SQWRL5 query processing. Continuing the thermometer example from Section 4.1, a plan may state which communication protocol a device should use in a given context for reasons of, e.g., energy consumption, goodput, or throughput [35]. As an example, an SWRL-based plan may state that a battery-operated device must use Bluetooth6 as a communication protocol if the battery level is below a certain threshold. This is an example of communication protocol adaptation as shown in the following Rule 1. Rule 1. A protocol adaption rule
dev ice : Thermometerð?dev ice1Þ dev ice : hasHardwareð?dev ice1; ?hardwareÞ
^ ^
hardware : supportProtocolð?hardware; ?protocolÞ network : nameð?protocol; ?nameÞ swrlb : containsIgnoreCaseð?name; BluetoothÞ hardware : primaryBatteryð?hardware; ?batÞ
^ ^ ^ ^
hardware : batteryLev elð?bat; ?lev elÞ swrlb : lessThanð?lev el; 0:15Þ dev ice : hasStateMachineð?dev ice1; ?statemachineÞ
^ ^ ^
stateMachine : hasStatesð?statemachine; ?stateÞ abox : hasURIð?state; ?uriÞ swrlb : containsIgnoreCaseð?uri; measuringÞ
^ ^ ^
stateMachine : isCurrentð?state; ?curÞ swrlb : equalð?cur; trueÞ ! sqwrl : selectð?dev ice1; ?lev elÞ ^
^
dev ice : currentCommunicationProtocolð?dev ice1; BluetoothÞ
In this example, a Thermometer that (i) supports Bluetooth, (ii) contains a battery with level less than 15%, and (iii) is in the measuring state, should change its communication protocol to Bluetooth (for energy usage reasons). Plans may easily conflict with each other. For example, a requirement to optimize for energy 3 4 5 6
http://www.w3.org/Submission/SWRL/. http://protege.stanford.edu/. http://protege.cim3.net/cgi-bin/wiki.pl?SQWRL. https://www.bluetooth.org.
usage coupled with a requirement to optimize for throughput may conflict. This might, e.g., lead to plans simultaneously selecting Bluetooth and UDP for communication in our example. Resolving such conflicts is the responsibility of the Goal Management layer discussed in Section 4.3. In the example above, the execution of the plan is triggered by events from the Component Control layer on the state of the device and the battery level of that device. Publication of the device state is supported by state machine generation whereas the publication of battery level is an application-specific feature (unless it is connected to a state change). Such a sequence of events is shown in Fig. 12. Finally, Fig. 13 shows a deployment view of the Change Management layer of the LinkSmart self-management implementation, illustrating that SeMaPS is deployed on the same node as the Reasoner component. 4.3. Goal Management Goal Management is concerned with producing plans for how to reach a goal state given a high-level goal and a current system state. In our realization, the Goal Management layer consists of two main components (see Fig. 18 for a typical deployment): 1. An Optimizer that will find a goal system configuration given a set of optimization constraints. It defines functions for defining self-management problems and implementations of genetic algorithm-based optimizations. 2. A Planner that will find a plan (consisting of ASL scripts that can be executed by ASL Interpreters) for going from a current system configuration to a desired/goal system configuration. Both components rely on having an up-to-date view of the system configuration. This is achieved by querying SeMaPS for system states and by listening to events published by the AQL sensors. AQL provides a query-based interface to retrieve information describing the runtime architecture of a system. The query in Fig. 14 illustrates the usage of AQL. It provides means to select which parts of the query should be evaluated locally, and which parts globally. A Global modifier cannot be contained within a Local modifier. The data source, the AQL tables residing locally on each device, are specified in the innermost pairs of parentheses. The tables in this case are ClientEndpoints and ServerEndpoints. The ClientEndpoints table contains the columns named (DeviceID, ClientID, TargetEndpoint, Protocol). It contains a tuple for each active client-connection, specifying the device id of the client (DeviceID) the local identifier of the client on that device (ClientID), the target endpoint for the service (e.g., for TCP it is the IP address and port number), and the protocol (Protocol). The ServerEndpoints contains the columns (DeviceID, ServingEndpoint, Protocol). ServingEndpoint denotes the endpoints on the server on which the service is reachable (for TCP/UDP, that is the IP address and port number the server socket is bound to). There is one tuple for each protocol/endpoint combination at which a service is available on this server. In this query, the tables with endpoints for clients and servers are each prepared locally, renaming the columns TargetEndpoint and ServingEndpoint, respectively, to Address, and renaming the device id columns to ClientDID and ServerDID in order to allow convenient usage of natural join. The result of the local step is thus, conceptually at least, two tables with columns named (ClientDID, ClientID, Address, Protocol) and (ServerDID, Address, Protocol).The natural join of these yields a new table (ClientDID, ServerDID, ClientID, Address, Protocol) specifying the details of each active channel in the current system configuration.
149
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Fig. 4. WSDL description of thermometer service.
Fig. 5. OWL description of thermometer device.
Goal Management
Change Management Event Manager
Fig. 6. State machine for thermometer device.
Component Control
:Service :Component :Component
AQL Sensor
ASL Interpreter
Fig. 9. Deployment view of the Component Control layer. Fig. 7. Partial OWL description of state machine for the TH03 thermometer device.
The Optimizer uses genetic algorithms to find a solution given a set of constraints [36]. The formulation of optimization problems are application-specific. An example in the thermometer case is a multi-objective optimization trading off energy consumption with throughput, where the fitness function in the genetic algorithm is based on specific choices of protocols for the communication between service providers and consumers. Given a current configuration and a goal configuration (as provided by the Optimizer), the Planner will attempt to construct an ASL script that transforms the current configuration into the given goal configuration. Planning problems are described in the Planning Domain Definition Language (PDDL) [37]. A planning problem in PDDL consists of a domain description and a problem description. The domain description in a self-managed deployment consists of two parts that describe the operations that may be applied to architectural operations and as such defines the semantics of ASL operations:
A generic part with ASL operations that apply to all applications. This includes operations such as deploying, starting, stopping, updating, and undeploying components [33]. An application-specific part with ASL operations that have specialized semantics for a domain. In our protocol change example, a set_property operation has been defined that when set for a client of a service will cause that client to subsequently use the protocol that the property points to. This is further described in B. Fig. 15 shows the definition of the component undeploy operation in ASL: given a device (d) and a component (c), the component may be undeployed from the device if it already exists at that device (as specified in the :precondition). The results (i.e., the :effect) is then that all packages that c provides are no longer available on the device, d (unless other components provide them). Planning problems described in PDDL are defined by the goal that the Optimizer has provided. A simple excerpt is shown in
Fig. 8. An ASL script.
150
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Fig. 10. Component & connector view of the Component Control layer.
Fig. 11. SeMaPS ontologies.
Goal Management
Change Management Event Manager
Reasoner
SeMaPS
Fig. 12. Component & connector view of Change Management layer.
Fig. 16. As a result of solving the planning problem, on the client device (Dc), the following script will need to be executed:
Component Control
set_property (propertykey, udptype); And correspondingly, on the server device (Ds), the following script installing a UDP protocol component (Cudp) and starting a corresponding service (sudp) will need to be executed: deploy_component (Cudp); init_service (Cudp, Sudp); start_service (Sudp);
Fig. 13. Deployment view of Change Management layer.
These scripts are then communicated to lower layers, using the Event Manager. This behavior is illustrated in Fig. 17 and a deployment is shown in Fig. 18.
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
151
Fig. 14. An AQL query.
Fig. 15. PDDL definition of the ‘‘undeploy’’ ASL operation.
4.4. The overall LinkSmart self-management architecture The overall LinkSmart self-management architecture is shown in Fig. 19. The three layers are interacting through events, using a publish-subscribe component called the Event Manager, which means that the interaction of components in the architecture is independent of how they are distributed. 5. Evaluation There are neither unified evaluation guidelines nor methodologies for autonomic middleware systems [26]. However, the recent version of the quality attribute framework proposed by Bass et al. [10] is comprehensive and widely adopted for evaluating software architectures and we base our evaluation on this. Considering the characteristics of pervasive computing systems and pervasive service middleware, and also our objectives for the LinkSmart 3L architectural style, we propose to evaluate middleware by considering both runtime and development time quality attributes. The runtime quality attributes should include at least performance, interoperability, and scalability (a form of ‘‘modifiability’’ in [10]); and the development time quality attributes should include at least modifiability, usability, and testability. For performance, middleware should function and react quickly in order to be usable in practice. For interoperability, middleware must be usable across different hardware and software platforms. Due to the possible large number of devices involved in an application using the middleware, scalability is an important factor for evaluating a middleware. To make middleware evolvable in order to make enhancements and add new functionalities, modifiability is desirable. To make middleware practical, the middleware system should be relatively easy to use for developers, and not hard to test, which leads to requirements for the usability and testability. In the following, we describe our evaluations using this framework. 5.1. Runtime quality For the runtime quality measurements, the following software platform is used: JVM 1.6.20-b02 running on 64 bit Windows 7.
The hardware platform is a Thinkpad W700 T9400 2.53G CPU with a 7200 rpm hard disk and 4G DDR2 RAM. The time measurements are in millisecond. We use the default Java heap memory size. 5.1.1. Interoperability For LinkSmart, pervasive web services are implemented using SOAP in order to integrate various embedded and networked systems. This enables interoperability among different platforms (such as .NET and Java). Even in the LinkSmart middleware itself, the device discovery and service management components are developed with .NET components. We have developed applications in three domains including agriculture, smart building, and ehealth for yearly project reviews, and all these applications are developed using different .NET and Java components and various hardware including weight scales, thermometers, and pumps [35]. There were few problems for the interactions between these devices and applications due to SOAP differences on platforms, and they were resolved. The downside of SOAP web service is the processing time for a web service call, which takes around 300 ms for a round trip call for a simple invocation such as temperature retrieval. Additionally, for pervasive middleware, it is critical that different wired and wireless communication protocols can interact. For this, we used UPnP in LinkSmart and wrapped other protocols in UPnP. In this way, we have integrated and tested with among others Zigbee7 and Bluetooth. 5.1.2. Scalability In our case, scalability is evaluated through clients continuously publishing their states (thermometer states in our running example) as events. In the test, each client sends events as quickly as possible in a loop. We then measure how long time it takes to process an event, starting from the publication and until the end of inference and publication of the result of inference. The time needed is shown in Fig. 20 on the Y axis. The X axis shows the number of events. We can see that the time taken for the test is a linear function of the events need to be processed. 7
https://www.zigbee.org.
152
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Fig. 16. PDDL definition of planning problem.
Fig. 17. Component & connector view of Goal Management layer.
Change and Goal Management Planner Event Manager
Optimizer
SeMaPS
5.1.3.1. Ontology-related performance. Based on previous experiments, we know that the loading of the SeMaPS ontologies usually takes more than 3 s. Thus, to achieve good performance, several strategies are adopted: Loading the SeMaPS ontologies during components initialization and activation as ontology loading is a slow process. Initializing static contexts by executing ontology queries in advance. Using SWRL rule grouping.
Component Control
Fig. 18. Deployment view of Goal Management layer.
The second measurement of scalability we perform is to publish events in parallel. Every device publishes 10 events in parallel and waits until the end of event processing. We then measure this duration. This is shown on the Y axis in Fig. 21. We can see that for this test the LinkSmart middleware has reasonable scalability. 5.1.3. Performance We have measured the performance for all critical LinkSmart components including the Optimizer, Reasoner, AQL, and ASL. As the Semantic Web and its supporting tools and technologies are still at the infancy stage, it is critical to make sure that we can get acceptable performance in a middleware system. Therefore, we first need to measure the ontology-related performance.
We need to investigate whether the complexity of underlying ontologies have large consequences with respect to performance for ontology updating and reasoning (including SWRL inference and SQWRL query). The complexity of an ontology is measured in terms of defined classes, object properties, data type properties, restrictions (including ‘‘cardinality’’ or ‘‘existential’’), total size (bytes) of an ontology or an ontology set, and rules. Please note that usually the update of an ontology property takes only a few milliseconds. As we are using the Observer pattern to observe ontology property changes inside the ontology components, inference will happen immediately after the updates, and the update time will be more or less the same as the inference time. Table 1 shows the performance effect of complexity of ontologies. In Table 1, ‘OP’ stands for object properties, ‘DTP’ stands for data type properties, ‘Restr.’ stands for restrictions, ‘Stdev’ stands for Standard Deviation, ‘Time1’ to ‘Time5’ stands for the inference time for 5 different rules. For every configuration, we measure five times as shown in the lines of Table 1. From this table, we can see that there is little performance overhead when the complexity of
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
153
Fig. 19. Overview of the LinkSmart 3L architecture.
ontologies increases. For example, the number of classes increases almost eight times, object properties, and number of data type properties doubles, but the average time for inference varies only little, which means that the complexities of ontologies have little effect on performance in our tests. Table 2 shows the performance of rule inferring using rule grouping when only a subset of rules is evaluated. The ontology complexity configuration is shown in the second group (as in Table 1). The performance of three rule groups (namely ‘RuleGroup1, RuleGroup2, and RuleGroup3’) are shown. We can see that the performance improves (average 3173.4 ms versus 2057.8 ms) with around 35%. 5.1.3.2. Optimizer performance. Table 3 shows the performance of the Optimizer, with maximum evaluations of 2000, population size 64, and crossover probability (CVP) as 0.8, 0.9 and 1. We can see on average it takes around 1.5 s to find optimal solutions. 5.1.3.3. Performance of a complete optimization cycle. An optimization cycle is adequate for validation as it involves all components in the self-management system. It starts when the Reasoner
detects a need for reconfiguration, and it involves the components executing the following steps: 1. Sensing. AQL is used to retrieve the current system configuration. This is fed through the Event Manager to the Optimizer. 2. Optimization. The Optimizer solves the optimization problem given by the state of the system and the current fitness function that reflects the current qualitative QoS preferences for the system. 3. Planning. The result of optimization is a desired target configuration. The target configuration, along with the current system configuration from step 1 constitutes a planning problem. 4. Actuation. The result of planning is an ASL script transforming the system from its current configuration to the goal configuration. The result of planning is published by the planner through the EventManager, and received by the ASL interpreter which executes it. The combined execution time for an optimization cycle is thus:
T total ¼ T sense þ T reason þ T optimize þ T plan þ T actuate þ 3 T ev ent
Fig. 20. Scalability with respect to the number of events.
154
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Fig. 21. Processing parallel events.
Table 1 Performance consequences of ontology complexity (times are in ms). Classes
OP
DTP
Restr.
Size
Time1
Time2
Time3
Time4
Time5
Average
Stdev
73
39
58
46
105745
606
89
105
154
326,233
609
106
154
89
343,494
1841 2225 2588 1910 2167 2264 1707 1678 2365 2352 2184 2137 2431 1544 1662
3607 4140 4261 3194 3781 3668 2653 3096 4396 3906 2214 2902 2268 2372 2829
3482 3393 3348 3405 2691 3422 2653 2934 4202 3890 1326 2153 2371 2341 1493
2643 3621 2967 3394 2991 3942 4555 3319 3414 3068 2240 2685 1300 2528 2454
2413 3482 3524 2964 3631 3336 1228 3807 4022 3459 2526 2341 3550 2389 2337
2797.2 3372.2 3337.6 2973.4 3052.2 3326.4 2559.2 2966.8 3679.8 3335 2098 2443.6 2384 2234.8 2155
743.4 703.6 629.8 621.0 667.8 639.1 1274.7 792.0 821.9 649.4 452.8 338.2 798.5 392.8 560.8
where the 3 T ev ent is the time required to forward events among the components in between steps 1 to 4. Table 4 lists the measured values for each of the components in the above formula in a setting with four devices. Using the numbers in the table yields a total time of 3738.5 ms, which is within the acceptable limit for interactive applications. It is clear from the results that improvement to this number can only be achieved by reducing the time needed for reasoning and optimization, as the time consumption of the other sub-components of our self-management approach are insignificant in comparison. 5.2. Development-time quality Development-time quality addresses how the quality of a system from a developer perspective. For this, we have evaluated the modifiability by extending the LinkSmart 3L architecture through the addition of new features iteratively. Furthermore, project partners were invited to use the LinkSmart 3L architecture in order to evaluate its usability. 5.2.1. Modifiability Modifiability is evaluated in a number of ways. The first one is to add new devices to a self-diagnosis for a ‘‘SmartHome’’ system. We started the development of diagnosis with the rule for temperature monitoring. After finishing the implementation and testing, we then try to handle a camera diagnosis rules. The steps involved are:
Add the camera device to the SmartHome System concept in the Device ontology. Add the camera state machine instance to the StateMachine ontology. Add the camera state machine instance to the hasStateMachine property of the ‘‘camera’’ device. Add camera diagnosis rule to the DeviceRule ontology. After this, no line of the LinkSmart code needs to be changed. The addition of new device instances to a certain system is very straightforward and is conducted at runtime. If the rules for the new devices already exist, then self-management (here we tested self-diagnosis) will work directly. The reason is that the diagnosis strategy is directly encoded in the Device ontology. The second type of modifiability evaluation is based on how we evolved the self-management features of the LinkSmart 3L architecture. We initially built the LinkSmart 3L architecture with support for self-diagnosis, then we added self-protection, and finally we added self-adaptation of communication protocols (cf. the SWRL rule in Section 4.2). The above evaluations support that the LinkSmart middleware has good modifiability.
5.2.2. Usability In order to check the usability of the Semantic Web-based change management presented in the previous sections, we asked project partners to use the ontologies we created. It was possible to
155
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161 Table 2 Performance after using rule grouping (times in ms).
Average
Table 3 Optimizer performance (times in ms).
RuleGroup1
RuleGroup2
RuleGroup3
CVP = 0.8
CVP = 0.9
CVP = 1
1778 1685 3090 2059 1560 1404 1778 1513 2231 1654 1749 2242 1951 1889 2606 1817 1684 1965 2193 1279 1314 2052 1754 1790 1779 2528 2044 2154 1780 1966 1327 1701 1827 2107 1795 1624 1826 2627 2154 2793 2216 1861 2263 2230 2162 2247 1889 1545 1873 1842 2246 2570 1873 3190 2587
2090 2465 1530 1919 2184 1638 1702 1544 1155 1935 1778 2543 2480 1997 1825 1856 1950 3182 1794 1684 1561 1701 1529 1856 1374 1202 2029 2560 1654 1779 1373 1592 1639 1561 1998 1561 1498 2076 1780 1810 2653 1499 2154 2247 2435 1903 1764 3137 1934 1811 1857 2279 2496 1826 2387
1420 2124 1733 2544 2396 1789 2923 1747 2461 1933 2175 1874 2653 2873 2601 2091 1881 1903 2318 1950 2360 2225 2150 1894 1994 2720 2772 2030 3183 1871 2400 1872 1686 2014 3332 2331 1877 2617 2152 2029 2146 2128 3018 1950 2104 1732 1713 2528 2275 2199 2684 2742 2901 3181 1904
1993.9
1923.0
2256.4
952 1277 873 1545 1452 1081 858 1373 1295 1397 1318 1078 1498 1680 1039 1264 891 1451 968 796 999 1436 1782 1171 1014 1313 1069 1108 477 1371 999 1451 1908 1642 1299 959 1162 1606 2622 2999 2987 2316 2013 2123 1974 2319 2019 1694 1484 1896 1983 1656 1497 1613 1628 1363 1048 2439 2298 2392 2361 967 1447 1447 1275 1652
1654 999 1092 2029 1498 1014 828 826 1513 1109 905 1062 952 967 1796 1045 951 1936 468 2184 1889 983 952 1873 2216 2029 1857 2200 1140 2264 2092 2420 2327 1967 1561 1530 1983 1562 1859 1656 1108 1639 2107 2341 1202 1577 1187 1140 1562 531 1561 1296 1109 1077 1218 1873 921 1656 1014 1311 1343 1031 1280 1312 764 874
1201 827 421 671 1232 1175 905 842 1482 1702 718 1457 1513 1374 733 1467 1545 1450 889 1466 1326 1488 655 1757 1211 808 983 1654 1794 1879 1006 1061 1724 1202 1763 1248 1873 1553 2056 1940 1357 1169 2215 1673 1343 1123 828 1171 1045 1506 1413 1308 1486 1597 1826 1217 1364 1427 1165 1190 906 702 501 437 780 806
1518.6
1488.1
1329.3
create a model of an HTC P3300 device including a state machine within half day by an ontology engineer unfamiliar with the device and the associated services. The ontology was created using the Topbraid Composer ontology tool.8 The feedback was that the ontologies for software and hardware device properties need to be very well documented, and also for a developer, who is not familiar with the domain, it is hard (or in some cases even impossible) to create suitable representation of device properties, without precise specification on meaning of these concepts. Thus these models need to be created by someone who is both familiar with ontologies and
8
http://www.topquadrant.com/products/TB_Composer.html.
Average
the specific device. Based on these comments, we have improved the modeling and documentation of the ontologies through a better classification of devices. This has been evaluated by partners again, and is now easier to use.
156
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Table 4 Performance of a complete optimization cycle. Parameter
Value (ms)
Measurements
Devices
T sense T reason T optimize T plan T actuate T ev ent
66.9 2057.8 1445 7 100 20.6
100 55 5 20 20 100
4 – – – – 4
5.2.3. Testability To make the LinkSmart 3L architecture properly testable, it should be possible to control each component’s inputs and then to observe its outputs. As recommended in [10], we mainly adopted the ‘‘Record/Playback’’ tactic, capturing information using a logging utility from OSGi. We also used a ‘‘Localize State Storage’’ tactic, where we use state machines for recording the device and system states. These two tactics work well currently, but we will improve testability in the future by adding more recommended tactics in the future, for example execution assertions.
Considering the condition that a full self-management life cycle will not be constantly running in an application, the performance of the component appears reasonable. However it should be noted that planning problems are inherently complex, so it is to be expected that when the planning problem instances increase in size, the performance of the Planner will be reduced. This confirms the allocation of the planning component to the top-layer, the Goal Management layer, along with the Optimizer. The evaluation of using GAs showed that although the performance may decrease when the size of the problem increases, the performance is still acceptable for moderate complexity problems [38]. We have evaluated our LinkSmart 3L architectural style realization based on the quality framework proposed in [10]. This can also be used as guidelines for evaluating other middleware. Based on the self-management features we have realized and their evaluation, we conclude that our work addresses the interoperability, modifiability/extensibility, integration challenges we mentioned in Section 1. The LinkSmart source code as a whole is available from its release website in SourceForge,9 so that researchers can use it and make improvements. The LinkSmart project as such was and it is still evolving. The middleware has been used in a number of EU projects,10 including GreenCom,11 REACTION,12 inCASA,13 and EBBITS.14
5.3. Support for comprehensive self-management capabilities Besides the self-diagnosis shown in this paper, the LinkSmart middleware has been also evolved to include the capabilities of cover a full spectrum of self-management capabilities: 1. Self-protection using security ontologies considering QoS properties of different security protocols [36]. This mainly involved the extension of context ontologies to include security concepts and properties, and defining the related optimization objectives for the genetic algorithms. 2. Self-configuration considering QoS properties of to-be-configured services [38]. This includes adding services instances to the service ontologies, self-configuration was managed to achieve best configuration of different middleware components, and will be actuated by ASL scripts [36]. 3. Self-adaptation of communication protocols considering QoS properties of different communication protocols used for pervasive web services, including TCP, UDP, and Bluetooth [35]. The QoS properties of different communication protocols are modeled in context ontologies and in order to adapt the used communication protocols, an optimized configuration from the planning layer is computed and a switch of protocols is made at runtime. 4. Self-optimization was used to realize various self-management objectives as shown by self-protection, self-configuration and self-adaptation [38,35,36]. As can been from the self-management functionality we have realized, except for self-diagnosis, self-management usually involves obtaining optimized configurations of services, protocols, or other properties. Knowledge of these as built in the context ontologies play key roles to achieve self-management.
5.4. Discussion The evaluations confirm the soundness of the proposed LinkSmart 3-L architectural style. A key rationale in this architectural style is that efficient algorithms should reside in lower layers. This is indeed the case as the components residing in the Component Control layer (sensing, actuation) performs significantly faster than the components in the above layer.
6. Related work Large Internet of Things (IoT), Internet of Services (IoS), and Internet of People (IoP) applications are gaining increasing attention. This brings us increasing complexities for management due to the large number of involved devices, events and contexts, heterogeneity of networking, hardware and software, and so on. These challenges call for useful self-managing capabilities to alleviate problems. Therefore, quite some work on self-managing middleware has been reported and we relate our work to some of this in the following. The MUSIC middleware [3,39] follows a layered architectural style, and mainly focuses on self-adaptation. The MUSIC project planned to used GAs for optimization, but based on the released software packages15 it appears that GAs had not been applied. The work we have done in LinkSmart-3L architectural style incorporated a number of architectural styles and supports component control, change management, and Goal Management. In contrast, the MUSIC project is focusing on architecture-based self-adaptation. There are several demonstration applications available to show the usage of the MUSIC middleware, and based on these applications, it appears that MUSIC has good modifiability and good interoperability (as well as plugins for web services), but there is currently little experimental evaluation to show, e.g., its scalability and testability. We have evaluated these aspects based on a proposed quality framework. The Rainbow architecture by Garlan et al. [4,5] produces an architectural model of a system in order to support self-management. This model consists of components, connectors, properties associated with the components and connectors, and constraints. In our approach, we do have explicit components and connectors, constraints and properties, which are encoded in related ontologies and OSGi meta files. The OWL-based approach arguably provides more reasoning capabilities for component configurations [40] than other approaches, and fits the open nature of pervasive 9 10 11 12 13 14 15
http://sourceforge.net/projects/linksmart/. http://www.hydramiddleware.eu/viewpage.php?page_id=13. http://www.greencom-project.eu/. http://www.reaction-project.eu. http://www.incasa-project.eu/. http://www.ebbits-project.eu/. http://ist-music.berlios.de/site/.
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
systems well [41]. Additionally, the planning layer in the LinkSmart 3L architecture makes it possible to create optimized configurations. Rainbow follows sense-plan-act cycles. The LinkSmart 3L architecture is not limited to simply doing cycles of sense-plan-act. In our case, each layer is loosely coupled and can work independently. Rainbow is evaluated in terms of generality, cost-effectiveness, transparency [42]. Also performance, development time, and security of applications are assessed. The authors of [42] consider that scalability is not an issue for Rainbow as probes and gauges are deployable on distributed nodes, but we think this needs to be evaluated as we did for LinkSmart. We have not rigorously recorded our development time for a typical self-management application which remains as future work. IBM’s ‘‘autonomic computing’’ approach to self-management [1] proposed four concrete types of ‘‘managers’’, namely managers for self-configuration, self-optimization, self-healing, and self-protection. We do not explicitly have these managers in our architecture, but have realized them in a generic way by having different types of self-management rules as described in [26]. We have a dedicated optimization engine which has the capability to find a global optimal solution to configuration problems. The architectural model in LinkSmart-3L is managed by both a component ontology and runtime monitoring of architectural changes with AQL, and thus it supports distributed monitoring. In Curry and Grace’s work [43], the Model-View-Controller pattern is adopted to improve concerns separation by encapsulating state, analysis, and realization of self-management operations. The MVC pattern becomes a general design guideline, which improves flexibility, customization, and portability of self-representation for an autonomic system. We have also adopted the MVC principle to some extent in our design and implementation: the models are implemented using OWL ontologies, the controller parts are the corresponding Java classes for model manipulation, the views are different self-management features (encoded with SWRL as DL-safe rules [44]) that operate on existing instances in the ontologies. These are triggered by the update of OWL models. The pattern is reinforced in our case by a repository architectural style, and a layered architectural style. The three-layered model was proposed by Kramer and Magee in [6] as a reference model. Sykes et al. continued this work as in [45] for self-management. Goals expressed in a temporal logic are used to generate reactive plans, and then domain-specific software components are configured based on these plans. In LinkSmart 3L, we used an IPP planner to generate the plans to reach an optimal state computed by the optimization engine, based on an AQL query of the current architecture status. In the future, we will explore the usage of state machine-based self-management further based on our initial work [46] and work in [47]. We have also used a formal approach in the planner, SWRL rules and Petri Nets in specifying self-management rules, and formalized ASL with Alloy [34]. In the future, we will explore other formal methods to regulate selfmanagement tasks [48]. Some architectural style requirements for self-healing were discussed in [49], including adaptability, dynamics, awareness, autonomy, robustness, distribution, mobility, and traceability. These requirements are suitable not only for self-healing systems but also applicable to self-managed systems in general. The LinkSmart-3L architecture supports adaptability through actuators, and further use state sensors to support dynamics. Awareness is supported by a set of SeMaPS ontologies and AQL sensors. Distribution is realized through the usage of pervasive web services and a publish-subscribe mechanism. Autonomy is an intrinsic feature throughout the planning layer and enacted by the actuators. Traceability is supported by a logging mechanism in an ontology and will be extended in the future. Robustness is referred to as
157
fault-tolerance for self-healing in [49], which is supported through an ontology and topic based events. We have not specifically explored mobility in the LinkSmart-3L architecture, but we will make use of the OSGi framework to support it in the future. The PitM architectural style [49] and the work in [50] based on the Prism-MW middleware [51] promote an adaptive layered style based on meta-components. Three types of specialized metacomponents are designed [50] corresponding to the typical sense-act-control paradigm, which is incorporated in our architecture. The LinkSmart 3L style has incorporated additional architecture patterns, and provides loosely coupled sense, plan, and act components that provide flexibility. A collaborative auctioning algorithm [52] is used to get an optimal deployment in [50]. Another early work called CARISMA [53] used reflection to enhance the construction of adaptive and context-aware mobile applications, and used sealed-bid auctions inspired by micro-economics to dynamically resolve possible policy conflicts during context changes. Poladian et al. [54] used an analytical approach similar to combinatorial auctions in project Aura to adaptively support everyday tasks of users. In our experiences and tests, we have used GAs as the main approach for finding global optimized solutions as it often finds better quality solutions with reasonable performance compared to auction algorithms. Some architectural styles can facilitate self-management as discussed in [55,56]. These include event-based, service-oriented, REST-based and peer-to-peer styles. We have incorporated event-based and service-oriented styles into our LinkSmart-3L architectural style, together with the Repository style that has shown its advantages for sharing knowledge across the system. The LinkSmart project is using a peer-to-peer style in the network layer [57], which can be integrated into our work reported in this paper. The REST style is investigated in the LinkSmart project, and will be explored in the future. A reference model for decentralized self-adaptation was proposed in [58], in which meta-level computations operate on meta-level models. The meta-level models cover a system model, a concern model, a working model, and a coordination model. A system model in the LinkSmart-3L architecture is covered thoroughly by the SeMaPS component and Device ontologies in one layer, and the AQL sensors in the bottom layers for knowing dynamics system models. The concern model is managed by the goals in the planning layer through the optimization engine, plus events that are sent to trigger planning activities. The corresponding self-management rules are also part of the concern models. A working model is handled through the planner, which calculates a sequence of steps to reach to the optimal configuration that is enacted by ASL scripts. For the current implementation, we use events for the coordination between components, and we use heartbeat to coordinate monitoring. The recent middleware work, FRASCATI [59], provides a Service Component Architecture with dynamic reconfiguration capabilities and run-time management features. The work has evaluated its platform performance, and also performance of an application based on FRASCATI. The time consumption of invocation of messages is comparable to our experiments, which is around 300 ms. FRASCATI is not evaluated in terms of other quality attributes, and the work is not focusing on architectural styles for self-management per se.
7. Conclusions and future work Realizing autonomicity for pervasive service computing is increasingly important as self-management capabilities can enable high dependability, intelligence, and quality of a large pervasive system. Although there is considerable research work on this topic,
158
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
integrating existing technologies into a self-management system remains problematic. In particular, there is little open source work that explores self-management activities. In this paper, we have proposed a hybrid approach to the realization of self-management in an open source pervasive service middleware. In this hybrid approach, different architecture styles, including the layered architecture style, repository style, and the service-oriented architecture style, are integrated into a ‘‘LinkSmart-3L’’ architectural style. We have implemented the LinkSmart-3L architectural style based on the OSGi framework as part of the LinkSmart middleware. We incorporate OWL ontologies supported context-awareness, genetic algorithm-based optimizations, architectural query language-based sensing, architectural scriptingbased actuation, and IPP-based planning to derive necessary steps to reach an optimal state. The proposed approach has been successfully validated in terms of both runtime and development time qualities through a set of experiments using a SmartHome application. Our implementation has been released to open source in order to promote the research and development of self-management for pervasive computing systems. In the future, we will further test the effects of device and service mobility, which was not a focus in the LinkSmart project. This means also that we need to add mobility-related fault tolerance features to our design and implementation. SOAP-based web service is the primary interaction approach in LinkSmart, but RESTful web services will be considered and explored in further self-management work, together with the experiments on the usage of a peer-to-peer style. Another direction is to explore the mobile cloud computing [60] and pervasive cloud paradigms [61] in order to handle compute intensive tasks, and distribute the knowledge base across different cloud nodes to facilitate distributed intelligence and flexibility for managing tasks in a pervasive cloud environment [62].
Acknowledgments The research reported in this paper had been supported by the Hydra EU project (IST-2005-034891) which build the LinkSmart middleware. The research is also supported by ‘‘Key Technologies Development Plan of Qingdao Technical Economic Development Area’’. Weishan Zhang has been supported by ‘‘the Fundamental Research Funds for the Central Universities’’ and also the startup funds for ‘‘Academic Top-Notch Professors in China University of Petroleum’’. We would like to thank to Martin O’Connor and Timothy Redmond from the Protégé team from Stanford University for their kind help on using the Protégé OWL/SWRL APIs. We also thank Antonio J. Nebro and Juan J. Durillo from Malaga University for their kind help on using the JMetal framework. Thanks are also given to the anonymous reviewers for their thoughtful and constructive comments which helped to improve the paper.
Appendix A. More usages of SeMaPS ontologies The usage of the SeMaPS ontologies and SWRL rules in the Change Management layer makes sure that the LinkSmart selfmanagement architecture has good modifiability/extensibility for new self-managementa features. We have shown an example of self-adaptation of communication protocols in Section 4.2 in which a developer can use the SeMaPS ontologies and reasoning APIs to write new SWRL rules for handling new self-management features. For example, we can develop a self-diagnosis rule as part of a selfhealing feature based on the SeMaPS ontologies as shown in the following Rule 2.
Rule 2. A self-diagnosis rule for environment monitoring
dev ice : hasStateMachineðdev ice : PicoTh03O utdoor; ?statemachineÞ ^ statemachine : hasStatesð?statemachine; ?stateÞ ^ statemachine : doActiv ityð?state; ?actionÞ ^ statemachine : actionResultð?action; ?resultÞ ^ statemachine : historicalResult1ð?action; ?Result1Þ ^ statemachine : historicalResult2ð?action; ?Result2Þ ^ statemachine : historicalResult3ð?action; ?Result3Þ ^ swrlb : addð?tempav erage; ?Result1; ?Result2; ?Result3Þ ^ swrlb : div ideð?av erage; ?tempav erage; 3Þ ^ swrlb : subtractð?temp1; ?result; ?Result1Þ ^ swrlb : subtractð?temp2; ?Result1; ?Result2Þ ^ swrlb : subtractð?temp3; ?Result2; ?Result3Þ ^ swrlb : addð?temp; ?temp1; ?temp2; ?temp3Þ ^ swrlb : greaterThanð?av erage; 15:0Þ ^ swrlb : lessThanð?av erage; 30:0Þ ^ swrlb : lessThanð?temp; 0Þ ^ dev ice : hasStateMachineðdev ice : PicoTh03I ndoor; ?statemachineb Þ ^ statemachine : hasStatesð?statemachineb ; ?stateb Þ ^ statemachine : doActiv ityð?stateb ; ?actionb Þ ^ statemachine : actionResultð?actionb ; ?result b Þ ^ statemachine : historicalResult1ð?actionb ; ?Result1b Þ ^ statemachine : historicalResult2ð?actionb ; ?Result2b Þ ^ statemachine : historicalResult3ð?actionb ; ?Result3b Þ ^ swrlb : subtractð?temp1b ; ?result b ; ?Result1b Þ ^ swrlb : subtractð?temp2b ; ?Result1b ; ?Result2b Þ ^ swrlb : subtractð?temp3b ; ?Result2b ; ?Result3b Þ ^ swrlb : addð?tempb ; ?temp1b ; ?temp2b ; ?temp3b Þ ^ swrlb : greaterThanð?tempb ; 0Þ ! error : currentMalfunctionðdev ice : VentilatorMY0193; error : PowerDownÞ
Here, thermometers named ‘‘PicoTh03_Outdoor’’ and ‘‘PicoTh03_Indoor’’ respectively are used to measure both an indoor and an outdoor temperature. In the period with a conformable temperature, i.e., when the outdoor temperature is between 15 and 30 °C. The indoor temperature should follow the same trend as the outdoor temperature. Otherwise, we can infer that the ventilator is down. The processing of this rule will obtain the trends via the difference of continuous temperature measurements of both the indoor and outdoor temperatures. If the trends are different, an instance of the ‘‘currentMalfunction’’ property (‘‘VentilatorDown’’) of concept ‘‘MalDevice’’ (malfunctioning device, which is ‘‘VentilatorMY0193’’ in this case) will be inferred. Then the Malfunction ontology will be checked for the resolution of the problem based on the malfunction cause. In our case, the Malfunction ontology would give us the suggestion: ‘‘power supply off because a fuse is blown’’. Besides modifiability/extensibility, the usage of Semantic Web ontologies can bring the benefits of context modeling and reasoning capabilities. For example, we can specify a GPS distance calculation with SWRL in order to define a farAwayFromHome context (e.g., 5 miles away from home using the GPS distance calculation formula16), as shown in the following Rule 3. Then this new context can be used to take actions, for example, a surveillance system can be switched to the highest security level with all cameras turned on.
16 How to calculate the distance between two points on the Earth. http:// www.meridianworlddata.com/Distance-Calculation.asp.
159
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Rule 3. A GPS distance calculation rule Thermometer
Thermometer person : hasHomeð?person; ?homeÞ ^ person : inLocationð?person; ?coord1Þ ^ loc : hasCoordinatesð?home; ?coord2Þ ^ coord : latitudeð?coord1; ?lan1Þ ^ coord : latitudeð?coord2; ?lan2Þ ^ swrlb : subtractð?sub1; ?lan1; ?lan2Þ ^ swrlb : multiplyð?squaresublan; ?sub1; ?sub1Þ ^ swrlb : multiplyð?par1; ?squaresublan; 4774:81Þ ^ coord : longitudeð?coord1; ?long1Þ ^ coord : longitudeð?coord2; ?long2Þ ^ swrlb : subtractð?sub2; ?long1; ?long2Þ ^ swrlb : multiplyð?squaresublong; ?sub2; ?sub2Þ ^ swrlb : multiplyð?par2; ?squaresublong; 2809Þ ^ swrlb : addð?parameter; ?par1; ?par2Þ ^ swrlm : sqrtð?distance; ?parameterÞ ^ swrlb : greaterThanð?distance; 5Þ ^ swrlb : StringConcatð?str00; true00Þ
TH03 Server
TH03 Server
Bluetooth
Bluetooth OSGi
OSGi
802.11 (UDP/TCP)
Environment Monitor
802.11 (UDP/TCP)
TH03 Client
OSGi
! sqwrl : selectð?person; ?home; ?distanceÞ ^ farAwayFromHomeð?person; ?strÞ Fig. B.22. Deployment for thermometers in the SmartHome scenario.
To summarize, the Semantic Web technologies and the components built based on them have powerful context modeling and reasoning capabilities on the one hand, and ensure good modifiability and extensibility on the other hand. The usage of OSGi components and pervasive web services in a service oriented computing paradigm helps to achieve seamless integration of different technologies.
2. For the Change Management layer, extend the SeMaPS ontologies to model the application concepts and plans 3. For the Goal Management layer, create application-specific optimization problems and extend the ASL domain descriptions to cover the application if necessary In the following, we describe what needs to be done for each layer in more details.
Appendix B. Implementing a self-managed application To show how to build a self-managed application, we use the following scenario (partially used in the previous sections): John owns a SmartHome system, which is equipped with environment monitoring, self-managed heating, ventilation and home surveillance subsystems. The devices in the smart home system include 5 surveillance IP cameras, and 10 thermometers, equipped with both WiFi and Bluetooth connections. While he is abroad for an academic conference, his home security system automatically turns on to the highest security level when it detects that he is far away from home. Also the whole SmartHome system is self-configured and self-adapted to minimize power consumption. The SmartHome also has an Environment Monitor that measures temperature which is running on a gateway device that connects to the Internet either using WiFi or a wired connection. John has a mobile phone with him and can use it to check that everything is fine at home, this includes retrieving captured pictures from all surveillance IP cameras, and reading the temperature to make sure that his cat is living a comfortable life while he is away. The intended deployment in the scenario is shown in Fig. B.22. The TH03 Client communicates with a number of TH03 Servers on Thermometers through SOAP. Both the client and the servers are OSGi bundles deployed in an OSGi container. The connections between the client and servers can be both IEEE 802.11-based (giving high speed and throughput) and Bluetooth-based (giving longer battery life). These bundles are intended to run in the Component Control layer of LinkSmart and we are interested in managing the type of connections used between clients and servers. Assuming this intended deployment, the steps involved in developing the application are: 1. For the Component Control layer, create the base application. Prepare the application for being controlled if necessary
B.1. Implementing the Component Control layer for the TH03 thermometer The TH03 Server is defined using a WSDL file (as described in Section 4.1 skeleton is generated via the Service Compiler. The application developer furthermore needs to develop the actual functionality, in the TH03 case extracting temperature data to be returned. To facilitate changing server protocol at runtime, the developer may use a set of Service Compiler runtime components that replace a standard OSGi HTTP Service implementation, enabling server protocols to be changed by changing bindings to protocol services. Finally, the developer needs to publish energy level events using the Event Manager (which may be accessed by a bridge from the OSGi Event Admin to the LinkSmart Event Manager). The TH03 Client is also generated from the WSDL description and the developer needs to implement the behavior of the temperature sensing, including using the right protocol when requesting temperatures. The client protocol change logic is supported by skeleton classes generated by the Service Compiler. B.2. Implementing the Change Management layer To enable reasoning on devices and services from the Environment Monitoring, the SeMaPS ontologies are updated with concepts and rules for plans (see Section 4.2). The Change Management layer needs to react to battery level change events from the Component Control layer. To do this a Protocol Reasoner bundle is implemented and deployed (see Fig. B.23). The Protocol Reasoner subscribes to battery level change events, applies level changes to the SeMaPS ontologies and decides the action to take (e.g., re-planning) after plans have been executed.
160
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Change and Goal Management Protocol Optimizer
Planner
Protocol Reasoner
Protocol SeMaPS
Optimizer
Reasoner
Event Manager
Environment Monitor
ASL
AQL
Thermometer
TH03 Client
ASL
AQL
TH03 Server
Fig. B.23. Final TH03 deployment. Gray components are tailored/specific to the application.
B.3. Implementing the Goal Management layer To enable application-specific optimization in the Goal Management layer, a Protocol Optimizer bundle is implemented. The bundle reads the necessary information from SeMaPS ontologies (in this case the information includes all devices and current protocols used), constructs an optimization problem, and handles optimization results. To define an optimization problem, a solution needs to be described. In our application, this is a vector of protocol choices per device-device connection involved, and protocol choices are evaluated based on latency and energy usage of a protocol. The problem definition is then used as the basis for multi-objective optimization. In our implementation, we used JMetal framework [63] to realize optimization problems definition and results handling. Finally, the planning domain (for defining ASL operations) needs to be extended. In our case, this involves defining operations for setting protocol properties, resulting in the installation/activation of protocol bundles (see Section 4.3). The final deployment is shown in Fig. B.23.
References [1] J. Kephart, D. Chess, The vision of autonomic computing, IEEE Comput. (2003) 41–50. [2] A. Metzger, C. Cassales Marquezan, Future internet APPS: the next wave of adaptive service-oriented systems?, Towards Service-Based Internet (2011) 230–241 [3] R. Rouvoy, P. Barone, Y. Ding, F. Eliassen, S.O. Hallsteinsen, J. Lorenzo, A. Mamelli, U. Scholz, Music: middleware support for self-adaptation in ubiquitous and service-oriented environments, in: B.H.C. Cheng, R. deLemos, H. Giese, P. Inverardi, J. Magee (Eds.), Software Engineering for Self-Adaptive Systems, Lecture Notes in Computer Science, vol. 5525, Springer, 2009, pp. 164–182. [4] D. Garlan, S.W. Cheng, A.C. Huang, B. Schmerl, P. Steenkiste, Rainbow: architecture-based self-adaptation with reusable infrastructure, Computer 37 (10) (2004) 46–54. http://dx.doi.org/10.1109/MC.2004.175. [5] D. Garlan, B. Schmerl, S.-W. Cheng, Software architecture-based selfadaptation, in: Autonomic Computing and Networking, Springer, 2009, pp. 31–55. [6] J. Kramer, J. Magee, Self-managed systems: an architectural challenge, in: International Conference on Software Engineering, 2007, pp. 259–268. [7] B. Cheng, R. de Lemos, H. Giese, P. Inverardi, J. Magee, J. Andersson, B. Becker, N. Bencomo, Y. Brun, B. Cukic, et al., Software engineering for self-adaptive systems: a research roadmap, Software Eng. Self-Adapt. Syst. (2009) 1–26. [8] K.M. Hansen, W. Zhang, J. Fernandes, OSGi based and ontology-enabled generation of pervasive web services, in: 15th Asia-Pacific Software Engineering Conference (APSEC 2008), Beijing, China, 2008, pp. 135–142.
[9] R. Hall, K. Pauls, S. McCulloch, D. Savage, OSGi in Action: Creating Modular Applications in Java, Manning Publications Co., 2011. [10] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, AddisonWesley, 2012. [11] T.H. Labella, M. Dorigo, J.-L. Deneubourg, Division of labor in a group of robots inspired by ants’ foraging behavior, ACM Trans. Auton. Adapt. Syst. 1 (1) (2006) 4–25. http://dx.doi.org/10.1145/1152934.1152936. [12] S. Dobson, S. Denazis, A. Fernández, D. Gaïti, E. Gelenbe, F. Massacci, P. Nixon, F. Saffre, N. Schmidt, F. Zambonelli, A survey of autonomic communications, ACM Trans. Auton. Adapt. Syst. 1 (2) (2006) 223–259. http://dx.doi.org/ 10.1145/1186778.1186782. [13] J.M. Ottino, Engineering complex systems, Nature 427 (6973) (2004) 399. http://dx.doi.org/10.1038/427399a. [14] A. Ranganathan, R.H. Campbell, Autonomic pervasive computing based on planning, in: Proceedings of International Conference on Autonomic Computing, 2004, pp. 80–87. http://dx.doi.org/10.1109/ICAC.2004.1301350. [15] A. Rao, M. Georgeff, BDI agents: from theory to practice, in: Proceedings of the first international conference on multi-agent systems (ICMAS-95), San Francisco, 1995, pp. 312–319. [16] Y. Diao, J.L. Hellerstein, S. Parekh, R. Griffith, G.E. Kaiser, D. Phung, A control theory foundation for self-managing computing systems, IEEE J. Select. Areas Commun. 23 (12) (2005) 2213–2222. http://dx.doi.org/10.1109/JSAC.2005. 857206. [17] E. Gat, On three-layer architectures, Artif. Intell. Mobile Robots (1998) 195– 210. [18] R.A. Brooks, Intelligence without representation, Artif. Intell. 47 (1-3) (1991) 139–159. http://dx.doi.org/10.1016/0004-3702(91)90053-M. [19] K. Hansen, W. Zhang, M. Ingstrup, Towards self-managed executable petri nets, in: Second IEEE International Conference on Self-Adaptive and SelfOrganizing Systems, SASO’08, 2008, pp. 287–296. [20] R.T. Fielding, R.N. Taylor, Principled design of the modern web architecture, ACM Trans. Internet Technol. 2 (2) (2002) 115–150. http://dx.doi.org/10.1145/ 514183.514185. [21] M. Shaw, D. Garlan, Software Architecture: Perspectives on an Emerging Discipline, Prentice-Hall, 1996. [22] P.T. Eugster, P.A. Felber, R. Guerraoui, A.-M. Kermarrec, The many faces of publish/subscribe, ACM Comput. Surv. 35 (2) (2003) 114–131. http:// dx.doi.org/10.1145/857076.857078. [23] T. Erl, Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall PTR Upper Saddle River, NJ, USA, 2005. [24] N. Mehta, N. Medvidovic, S. Phadke, Towards a taxonomy of software connectors, in: Proceedings of the 22nd International Conference on Software Engineering, 2000, pp. 178–187. [25] W. Zhang, K.M. Hansen, Semantic web based self-management for a pervasive service middleware, in: Second IEEE International Conference on Self-Adaptive and Self-Organizing Systems (SASO 2008), Venice, Italy, 2008, pp. 245–254. [26] W. Zhang, K.M. Hansen, Using context awareness for self management in pervasive service middleware, in: F.M. Nak-Young Chong (Ed.), Handbook of Research on Ambient Intelligence and Smart Environments: Trends and Perspectives, IGI Global, 2011, pp. 248–271. [27] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, J. Stafford, Documenting Software Architectures: Views and Beyond, AddisonWesley, Boston, 2003. [28] K.M. Hansen, W. Zhang, G. Soares, Ontology-enabled generation of embedded web services, in: Proceedings of the 20th International Conference on Software Engineering and Knowledge Engineering (SEKE 2008), Redwood City, San Francisco Bay, USA, 2008, pp. 345–350.
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161 [29] Kriens, P. (Ed), OSGi Service Platform Core Specification. Release 4, The OSGi Alliance, August 2005. [30] P. Dolog, Model-driven navigation design for semantic web applications with the uml-guide, in: Maristella Matera, Sara Comai (eds.), Engineering Advanced Web Applications. [31] W. Zhang, K. Hansen, Semantic web based self-management for a pervasive service middleware, in: Second IEEE International Conference on Self-Adaptive and Self-Organizing Systems, SASO’08, 2008, pp. 245–254. [32] M. Ingstrup, K.M. Hansen, A declarative approach to architectural reflection, in: 5th Working IEEE/IFIP Conference on Software Architecture, WICSA, 2005, pp. 149–158. http://dx.doi.org/10.1109/WICSA.2005.6. [33] M. Ingstrup, K.M. Hansen, Modeling architectural change: architectural scripting and its applications to reconfiguration, in: WICSA/ECSA, IEEE, 2009, pp. 337–340. [34] K.M. Hansen, M. Ingstrup, Modeling and analyzing architectural change with alloy, in: S.Y. Shin, S. Ossowski, M. Schumacher, M.J. Palakal, C.-C. Hung (Eds.), SAC, ACM, 2010, pp. 2257–2264. [35] W. Zhang, K. Hansen, J. Fernandes, J. Schutte, F. Lardies, Qos-aware selfadaptation of communication protocols in a pervasive service middleware, in: Green Computing and Communications (GreenCom), 2010 IEEE/ACM Int’l Conference on & Int’l Conference on Cyber, Physical and Social Computing (CPSCom), IEEE, 2010, pp. 17–26. [36] W. Zhang, J. Schutte, M. Ingstrup, K.M. Hansen, Towards optimized selfprotection in a pervasive service middleware, in: 7th International Conference on Service Oriented Computing, Joint ICSOC & ServiceWave 2009 Conference, Springer LNCS 5900, Stockholm, Sweden, November 24–27 2009, pp. 404–419. [37] D. Mcdermott, The 1998 AI planning systems competition, AI Mag. 21 (2) (2000) 35–55. http://www.aaai.org/ojs/index.php/aimagazine/article/view/1506. [38] W. Zhang, K. Hansen, An evaluation of the NSGA-II and MOCell genetic algorithms for self-management planning in a pervasive service middleware, in: 14th IEEE International Conference on Engineering Complex Computer Systems (ICECCS 2009), IEEE Computer Society, Springer, Washington, DC, USA, 2009, pp. 192–201. [39] K. Geihs, M. Wagner, Context-awareness for self-adaptive applications in ubiquitous computing environments, in: Context-Aware Systems and Applications, Springer, 2013, pp. 108–120. [40] K.M. Hansen, W. Zhang, J. Fernandes, M. Ingstrup, Semantic web ontology for ambient intelligence: Runtime monitoring of semantic component constraints., in: The Internet of Things and Services, 1st International Research Workshop, Sophia Antipolis, French, 2008. [41] W. Zhang, K.M. Hansen, J. Fernandes, Towards openworld software architectures with semantic architectural styles, components and connectors, in: 14th IEEE International Conference on Engineering of Complex Computer Systems, IEEE, 2009, pp. 40–49. [42] S.-W. Cheng, Rainbow: cost-effective software architecture-based selfadaptation, ProQuest, 2008. [43] E. Curry, P. Grace, Flexible self-management using the model-view-controller pattern, IEEE Software 25 (3) (2008) 84–90. [44] B. Motik, U. Sattler, R. Studer, Query answering for OWL-DL with rules, Web Semantics: Sci. Serv. Agents World Wide Web 3 (1) (2005) 41–60. [45] D. Sykes, W. Heaven, J. Magee, J. Kramer, From goals to components: a combined approach to self-management, in: Proceedings of the 2008 International Workshop on Software Engineering for Adaptive and SelfManaging Systems, ACM, 2008, pp. 1–8. [46] W. Zhang, K.M. Hansen, An OWL/SWRL based diagnosis approach in a web service-based middleware for embedded and networked systems, in: The 20th International Conference on Software Engineering and Knowledge Engineering (SEKE 2008), Redwood City, San Francisco Bay, USA, 2008, pp. 893–898.
161
[47] L. Mostarda, D. Sykes, N. Dulay, A state machine-based approach for reliable adaptive distributed systems, in: 2010 Seventh IEEE International Conference and Workshops on Engineering of Autonomic and Autonomous Systems, IEEE, 2010, pp. 91–100. [48] J. Zhang, H. Goldsby, B. Cheng, Modular verification of dynamically adaptive systems, in: Proceedings of the 8th ACM International Conference on AspectOriented Software Development, ACM New York, NY, USA, 2009, pp. 161–172. [49] M. Mikic-Rakic, N. Mehta, N. Medvidovic, Architectural style requirements for self-healing systems, in: Proceedings of the First Workshop on Self-healing Systems (WOSS 2002), ACM, 2002, pp. 49–54. [50] G. Edwards, J. Garcia, H. Tajalli, D. Popescu, N. Medvidovic, G. Sukhatme, B. Petrus, Architecture-driven self-adaptation and self-management in robotics systems, in: Software Engineering for Adaptive and Self-Managing Systems, 2009. ICSE Workshop on SEAMS’09, Springer, 2009, pp. 142–151. [51] S. Malek, M. Mikic-Rakic, N. Medvidovic, A style-aware architectural middleware for resource-constrained, distributed systems, IEEE Trans. Software Eng. (2005) 256–272. [52] S. Malek, M. Mikic-Rakic, N. Medvidovic, A decentralized redeployment algorithm for improving the availability of distributed systems, Comp. Deploy. (2005) 99–114. [53] L. Capra, W. Emmerich, C. Mascolo, Carisma: context-aware reflective middleware system for mobile applications, IEEE Trans. Software Eng. 29 (10) (2003) 929–945. [54] V. Poladian, J. Sousa, D. Garlan, B. Schmerl, M. Shaw, Task-based adaptation for ubiquitous computing, IEEE Trans. Syst. Man, Cybernet. Part C: Appl. Rev. 36 (3) (Special Issue on Engineering Autonomic Systems). [55] P. Oreizy, N. Medvidovic, R.N. Taylor, Runtime software adaptation: framework, approaches, and styles, in: Companion of the 30th International Conference on Software Engineering (ICSE 2008), ACM, 2008, pp. 899–910. [56] R. Taylor, N. Medvidovic, P. Oreizy, Architectural styles for runtime software adaptation, in: Software Architecture, 2009 & European Conference on Software Architecture, Joint Working IEEE/IFIP Conference on WICSA/ECSA 2009, IEEE, 2009, pp. 171–180. [57] F. Milagro, P. Antolin, J. Fernandes, W. Zhang, K.M. Hansen, P. Kool, Deploying pervasive web services over a p2p overlay, in: 18th IEEE International Workshops on Enabling Technologies: Infrastructures for Collaborative Enterprises, WETICE’09, IEEE, 2009, pp. 240–245. [58] D. Weyns, S. Malek, J. Andersson, On decentralized self-adaptation: lessons from the trenches and challenges for the future, in: Proceedings of the 2010 ICSE Workshop on Software Engineering for Adaptive and Self-Managing Systems, ACM, 2010, pp. 84–93. [59] L. Seinturier, P. Merle, R. Rouvoy, D. Romero, V. Schiavoni, J.-B. Stefani, A component-based middleware platform for reconfigurable service-oriented architectures, Software: Practice and Experience 42 (5) (2012) 559– 583. [60] H. Dinh, C. Lee, D. Niyato, P. Wang, A survey of mobile cloud computing: architecture, applications, and approaches, Wireless Commun. Mobile Comput. [61] W. Zhang, L. Chen, Q. Lu, Y. Rao, J. Zhou, Towards an OSGi based pervasive cloud infrastructure, in: 2013 IEEE International Conference on Internet of Things (iThings2013), IEEE, Beijing, China, 2013, pp. 418–425. [62] W. Zhang, L. Chen, X. Liu, Q. Lu, P. Zhang, S. Yang, An OSGi-based flexible and adaptive pervasive cloud infrastructure, Sci. China Inform. Sci. 57 (3) (2014) 1– 11. http://dx.doi.org/10.1007/s11432-014-5070-3. [63] J.J. Durillo, A.J. Nebro, jmetal: a java framework for multi-objective optimization, Adv. Eng. Software 42 (2011) 760–771. http:// www.sciencedirect.com/science/article/pii/S0965997811001219.
Contents lists available at ScienceDirect
Knowledge-Based Systems journal homepage: www.elsevier.com/locate/knosys
A hybrid approach to self-management in a pervasive service middleware Weishan Zhang a,⇑, Klaus Marius Hansen b, Mads Ingstrup c a
Department of Software Engineering, China University of Petroleum, No. 66 Changjiang West Road, Qingdao 266580, China University of Copenhagen, Njalsgade 128, 2300 Copenhagen S, Denmark c No Magic, Bangkok, Thailand b
a r t i c l e
i n f o
Article history: Received 3 April 2013 Received in revised form 28 May 2014 Accepted 1 June 2014 Available online 14 June 2014 Keywords: Self-management Architectural styles Component control Goal Management Change Management
a b s t r a c t Self-management capabilities for pervasive computing systems are critical in improving dependability, usability, and autonomicity. However, realizing self-management is not an easy task due to complexities of implementing autonomous behaviors. It has been recognized that a single autonomicity handling mechanism is not sufficient to realize comprehensive self-management capabilities when different technologies are involved. Therefore, we propose a hybrid approach, the ‘LinkSmart Three Layered architectural (LinkSmart-3L) style’, in which different architecture styles are incorporated. The LinkSmart-3L style enables self-management at an architectural level. In our approach, semantic web technologies are used to achieve comprehensive context-awareness and extensibility of self-management capabilities, genetic algorithms are used to achieve configuration optimizations, and a planner is used to compute planning procedures on how to arrive at an optimum system configuration based on current architectural structure of the underlying system using an architectural query language. These technologies are integrated seamlessly based on the service oriented computing (SoC) paradigm. We have extensively evaluated both runtime and development time qualities of our implementation of the style. These evaluations can serve as guidelines for evaluating other middleware systems. We conclude that our approach is usable and effective in achieving these quality attributes. Ó 2014 Elsevier B.V. All rights reserved.
1. Introduction Self-management capabilities are attractive for pervasive computing systems as these systems are becoming more widely deployed, and requirements on dependability increase. Such systems are operated as open systems undergoing dynamic changes in which services and devices may join or leave at any time anywhere, and system resources, e.g., battery levels may fluctuate dynamically. Self-management capabilities as in autonomic computing [1] can potentially make these pervasive systems more user-friendly and energy efficient. For example, to diagnose the source of a failure and then recover to a normal operating state, or to make full use of remaining energy to prolong the runtime of a system. Because of these potential benefits, many efforts have been put into the realization of self-management capabilities [1]. These self-management capabilities are considered as the most important features of future network applications and should be given priority in future research [2]. ⇑ Corresponding author. Tel.: +86 532 86981972. E-mail address: [email protected] (W. Zhang). http://dx.doi.org/10.1016/j.knosys.2014.06.002 0950-7051/Ó 2014 Elsevier B.V. All rights reserved.
Although there is substantial pervasive middleware research such as EU MUSIC [3] and Rainbow [4,5], these efforts have primarily used a single approach to or focused on a single aspect of self-management. For example, the MUSIC project explored architecture based self-adaptation, while paying little attention to other self-management features such as self-protection, and self-optimization. For architecture-based self-adaptation, a critical issue is the choice of an architectural style to represent a target system [5], but the MUSIC project did not focus on this either. Kramer and Magee [6] observe that many early self-managing systems followed the ‘sense-plan-act’ architecture (e.g., Rainbow by Garlan et al. [4]) in which a system conceptually cycles through sense-plan-act phases. Kramer and Magee proposed a three layered architecture style that incorporate these three phases, but this is only an abstract reference model that needs to be verified in practice, and the problem of how to actually derive a software architecture style that can be implemented and used in practice for self-management systems is not addressed. On the other hand, implementing and achieving self-management are not easy tasks [7]. There are many aspects that should be considered in a self-management solution, such as effective
144
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
sensors to detect system status, actuators to accomplish needed changes, change management schemes to react to self-management changes, and reasoning on which actions to take. Furthermore, if an existing scheme cannot fulfill a Quality of Service (QoS) requirement, planning mechanisms should be used to help to find a corresponding (near) optimal configuration, and then this configuration should be enabled dynamically. Thus, the whole selfmanagement process involves quite a number of different tasks which can be realized with different techniques. Correspondingly, a self-management solution should support a hybrid of different techniques technologies at an architecture level in order to integrate these technologies seamlessly. A single mechanism for realizing self-management may be considered as too limited to realize comprehensive autonomic features [7]. In the process of reaching a hybrid solution for self-management, there exist a number of challenges. These include: 1. How to define an architectural style that can be used to achieve self-management at an architectural level [6]. 2. How to verify this architectural style by a practical implementation in order to show usefulness. 3. How to achieve interoperability, modifiability, and extensibility in this architectural style to easily integrate various self-management features including self-protection, self-protection, self-optimization, and self-configuration. Preferably it should be simple to add new self-management features that do not exist. 4. How to make sure that technologies used for various purposes can be integrated in this architectural style. To address these challenges, we propose the LinkSmart Three Layered architectural (LinkSmart-3L) style that features a serviceoriented architecture and seamlessly integrates several technologies to facilitate self-management. In our practical implementation and evaluation, we use pervasive web services [8] and OSGi Declarative Services [9]. The main contributions of our work are: 1. A ‘LinkSmart Three Layered architectural (LinkSmart-3L) style’ is proposed and exemplified. This style combines different architectural styles to enable architecture-level self-management. This makes it possible to bring together benefits from those underlying architectural styles. 2. Our approach is realized such that different self-management technologies can be integrated seamlessly based on the service-oriented computing paradigm. In our implementation, we have integrated Semantic Web technologies, genetic algorithms, an architectural scripting language, and an architectural query language. 3. Our middleware is evaluated in terms of runtime qualities including interoperability, performance, scalability, and development-time qualities including modifiability, testability and, usability, following the quality attributes framework proposed by Bass et al. [10]. We have performed evaluations which can serve as guidelines for evaluating other middleware systems, as currently there are no unified evaluation criteria or methodology. 4. Following the proposed evaluation quality attributes, our approach has been evaluated extensively in the LinkSmart middleware. For interoperability, both the .NET and Java environments are tested. This includes tests of using various available wired and wireless communication protocols. The performance has been tested extensively for various components and a whole self-management life cycle takes less than 4s which is acceptable in a distributed pervasive service environment. The scalability tests show that the needed time to process self-management actions is in linear with the number of events for our
tests. The modifiability tests show that the middleware can be extended with relative ease to add new self-management functions. The testability and usability tests show that the proposed approach is practical in use. 5. To promote the usage of self-management technologies and encourage research in this area, we have released our work including a set of supporting ontologies as open source such that other researchers can explore and potentially further our work. The remainder of this article is organized as follows. First, we present background on self-management, especially architectures for self-management in Section 2. In order to address challenge number 1, we define an architectural style (LinkSmart-3L) based on a set of objectives and constraints for self-management (Section 3) and we discuss key design choices of the LinkSmart-3L style. We then present the LinkSmart-3L architecture that follows a three layered self-management architectural model (Section 4) and we give design details of each layer. We show how to develop a self-managed application in B using a simple case study. Comprehensive evaluations regarding runtime and development time qualities of our approach are presented in Section 5. We discuss related work in Section 6. Conclusions and future work end this paper in Section 7.
2. Software architectures for self-management The task of architecting self-managing systems can be approached from several conceptual perspectives, which lead to different architectures. In one approach, inspiration is sought from nature to build systems with no explicit locus of control. An example is division of labor in a group of robots inspired by the decentralized organization of an ant colony [11]. This approach has particularly been applied to autonomic communications [12], but systems based on it are arguably difficult to engineer [13]. Another conceptual approach is to leverage traditional Artificial Intelligence (AI) by relying on explicit representation of plans as a basis for action. Although this might lead to a system with a central control unit (e.g., an AI planner as in [14]), control can also be distributed, e.g., by using Belief-Desire-Intention (BDI) agents [15]. A third conceptual approach is inspired by the model used to engineer control systems [16]. While it is orthogonal to the first two approaches in that it assumes nothing about representation of plans, it does require a certain level of centralized control in so far as measured system output must be compared with the desired output in order to compute the control measure needed to align the two. Many early architectures for autonomous robotics [17] follow the ‘‘sense-plan-act’’ architecture, which suffers from difficulties in maintaining precise ‘‘world models’’. Brook’s subsumption architecture [18] avoided this by following the slogan ‘‘the world is its own best model’’ and relying extensively on sensors, but it did not provide sufficient means to handle complexity. The three layer (3L) architecture described by Gat [17] combines ideas from both, in that the stateless and low complexity online control algorithms reside in the bottom layer, while the top layer employs traditional modeling and high-complexity planning algorithms, with the middle layer acting as interface between the two. This architecture has become a de facto standard architecture in autonomous robotics. The self-management approach of LinkSmart follows the three layered reference model proposed by Kramer and Magee [6] which is adapted from Gat’s 3L architecture. An overview is shown in Fig. 1.
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
145
different users that may have diverse mobility profiles. This means that their availability is unpredictable and that the software must be robust to unpredicted unavailability of devices. Further, devices frequently belong to different administrative domains, and thus the maintenance of software running on them is less coordinated and must be more loosely coupled than what is acceptable in more traditional (e.g., enterprise information) systems. For this reason loose coupling is an important sub-objective for modifiability in our target domain. Further, to increase the range of its potential use, middleware must make as few assumptions as possible about the application domain while still providing useful support to application developers. For self-management this implies that the means made available for developers to specify self-management schemes for their applications must be expressive and powerful, so that it is both possible and requires little effort to extend a self-management system with new functionality.
Fig. 1. Three layer architecture model for self-management.
The lowest layer is the Component Control layer. It is responsible for retrieving information about the state of the system, e.g., which services exist and what their states are. It is also responsible for actuating low-level change commands issued from higher layers, e.g., installing and starting a service. The middle layer is the Change Management layer. It is responsible for detecting situations that need to be managed, and to perform that management according to pre-determined schemes by issuing commands to the Component Control layer. A scheme in this context can be a plan such as a sequence of actions, or a component such as parts of a Petri Net [19] or rules processed by a rule engine. The top layer is the Goal Management or planning layer. When a situation is detected for which there is no applicable pre-existing scheme in the Change Management layer, the Goal Management layer is responsible for computing a new scheme, or plan. For example, an AI planner can be used to dynamically generate a reconfiguration plan that is sensitive to the constraints set by the current system states and policies. Ideally, high-level policies express what plans to create. 3. The LinkSmart three layered architectural style The three-layered reference model as proposed by Kramer and Magee is a logical reference model, and it does not as such constitute a clearly defined architectural style. In the following we remedy that by defining the concrete styles that are realized by our implementation architecture. We follow Fielding’s and Taylor’s [20] definition of an architectural style as ‘‘a coordinated set of architectural constraints that restricts the roles and architectural elements, and the allowed relationships among those elements within any architecture that conforms to the style’’. We use the definition with the understanding that constraints in a style are chosen to favor particular architectural objectives. 3.1. Objectives The LinkSmart-3L style seeks to achieve the following objectives in the system as a whole: 3.1.1. Modifiability The software deployed in a pervasive computing environment is distributed across a potentially large number of devices. They have
3.1.2. Performance (efficiency) Further, to make self-management usable and practical in pervasive systems, self-management processes must respond reasonably fast to changes. Since we know that there may be highcomplexity algorithms involved in self-management activities, these algorithms should be able to execute independently as part of the slower processes such as planning and optimization, while the parts of self-management that monitor, actuate and execute plans should be efficient. 3.1.3. Scalability A pervasive computing system may involve just a few devices and services while others may involve hundreds and thousands of devices and services in for example a large scale smart traffic monitoring system. Therefore, it is important that the middleware can scale well in different configurations with respect to the number of devices and services involved. This also means that the performance for executing a self-management task must have reasonable efficiency in different scales of configurations. 3.2. Constraints When defining our architectural style, it is important to be clear about whether the individual design objective, constraint, and assumption apply to the middleware itself or to the set of applications that can be built with it. We use the term constraint when they apply to our middleware, and the term assumption when the constraint must be satisfied for the system as a whole. The following constraints and assumptions are set by the LinkSmart-3L style: LS: Layered (constraint). The middleware shall use a layered style in order to tackle the complexities of self-management in a flexible manner. PS: Publish/Subscribe (constraint). To decouple event sources and consumers, and to enable the distribution of self-management components, the middleware shall use a publish/subscribe event mechanism. SAR: Sensor and Actuator-based Reflection in the Component Control layer (constraint). The middleware shall be able to collect system runtime status using various hardware and software sensors, and enable self-managing activities through corresponding actuators. SOA: Service-Oriented Architecture (constraint and assumption). The service orientation paradigm can help in achieving the ‘‘divide-and-conquer’’ idea for managing the complexities and self-management functionalities.
146
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
REP: Repository (constraint). To share knowledge among different components, a knowledge repository shall be used in the middleware. SI: Semantic Introspection (constraint). Knowledge about the system shall be explicitly categorized and modeled in Semantic Web ontologies to enable automated reasoning and enhance the intelligence of self-managing systems. PO: Planning-based Optimization (constraint). The middleware shall support the search for optimal runtime states and decide on how to reach an optimal state. The relationships between the constraints and the objectives are shown in Fig. 2 and explained below.
3.2.1. Layered style The first constraint we include is that the middleware must be divided into three layers following the work proposed by Kramer and Magee [6]. Organizing the system into layers helps reduce coupling among components in different layers [21]. It also helps managing complexity by introducing a higher level of abstraction, the layer, which encapsulates well-defined behaviors. The three layers are those already described earlier in Section 3.
3.2.2. Publish/subscribe style Using the publish/subscribe communication paradigm for event-based communication between layers promotes low coupling among components by decoupling them with respect to time, space (distribution), and synchronization [22]. This de-coupling further promotes modifiability/extensibility, since it is easy to add new components capable of receiving relevant events simply by adding them as subscribers, with no modification of the publishers being necessary. Publish/subscribe mechanism provides a convenient way to decouple a service provider and a service consumer, and ensures good scalability required for handling dynamics of pervasive systems. This event system also ensures extensibility for adding new self-management functionalities.
scalability, LS
+PS
+REP
scalability +SAR
+SI
+SOA
+PO
interoperability
LinkSmart-3L
Fig. 2. Derivation of the LinkSmart-3L style, showing how each constraint contributes to the objectives.
3.2.3. Sensor- and actuator-based reflection To avoid the complexity and overhead of maintaining a complete and centralized system model—the technique that became a weakness of the sense-plan-act architecture for autonomous robotics, the introspection implementation should be based on distributed sensors which can be queried to retrieve only actually used meta-data, and only at time when the data is actually required. This is important in the context of self management because we assume systems to be distributed, and particularly so in pervasive computing systems that frequently include devices with very limited bandwidth and power. For the intercession aspect of reflection (that allows modifications), the actuation of a change must be based on actuators present on the local devices where changes should take effect. A uniform interface makes it simpler to realize principled coordination of system-wide changes. Supporting runtime changes directly helps to achieve modifiability. It does so directly as it provides a way to modify a system, but also because it means configuration and re-configuration can be externalized rather than hard coded into the individual components. Thus the same components can be more easily used in a variety of configuration contexts. 3.2.4. Service-oriented architecture Both the system under management and the middleware follows Service-Oriented Architecture principles. SOA [23] is appealing as it promotes reuse, modularity, composability, componentization and dynamic interoperability in a standardized way. It enables the architectural principles of service encapsulation, loose coupling, service autonomy, and service discovery through welldefined service contracts and service abstraction. This both helps promote modifiability and separation of different concerns as self-management typically involves complex sense-plan-execute tasks. Service oriented architecture also helps to separate different aspect of a task, for example, software connectors [24] can be applied to separate the component communications from component functionalities, especially components residing in different layers. 3.2.5. Repository style Self-management works based on the awareness of various contexts which are shared among different components, and on efficient access to these contexts. In the LinkSmart project, a context-awareness based self-management is adopted [25,26]. A repository component using the repository style [21], is adequate for managing these contexts in the Change Management layer. Context information can be added to the repository using dedicated context ontologies and/or rule bases. The repository provides access to the semantics of an underlying system, including system/ device status, system structure and communication topologies. It helps to achieve low coupling of components and ensure extensibility. 3.2.6. Semantic introspection Self-management works based on knowledge about the system under management. In order to manage this in a principled way, introspective information is categorized according to well defined ontologies in the repository. The usage of ontologies ensures that the semantics of system knowledge is made explicit. This makes it easier to modify existing components or add new ones because self-management components rely critically on the correct interpretation of system meta data. The usage of ontologies further enables reasoning to augment the knowledge retrieved from lower layers. 3.2.7. Planning-based optimization Very often various self-management functionality can be reduced to finding an optimal target following multiple, even
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Goal Management
Change Management Event Manager
SeMaPS
Component Control
Fig. 3. LinkSmart self-management system model.
conflicting constraints from a large number of candidate solutions. For example, a self-managed system should consume the least battery energy but with the highest performance in a large smart city application where a large number of devices and events may be involved. In such a case, an efficient mechanism is needed to find optimal configurations for device communication protocols and decide appropriate services necessary to meet the QoS requirements. It is also essential to decide what necessary steps/procedures are to arrive to the optimal configurations.
4. Design of self-management in LinkSmart Based on the above introduced LinkSmart-3L architectural style, we describe the architecture of the LinkSmart self-management architecture using the approach of Clements et al. [27]. Our overall system model is shown as a deployment view in Fig. 3. The deployment follows Kramer’s and Magee’s model with each layer deployed on a node, and uses a publish/subscribe implementation (‘‘Event Manager’’) as an implementation of an event connector and it uses Web Ontology Language (OWL; 1) ontologies (‘‘SeMaPS’’) as data connectors. The set of ontologies used in LinkSmart is called SeMaPS (Self-Management for Pervasive Services). We now describe each of the three layers in details. 4.1. Component control The Component Control layer contains elements that provide the base functionality of a system. As such, in LinkSmart, it is composed of communicating domain- and application-specific web services [8,28] internally structured as components. Typically, these components are implemented using OSGi [29]. OSGi has become a widespread implementation framework for Java-based (pervasive computing) services. Furthermore, it provides a flexible modularization mechanism as well as a dynamic service platform. Internally on nodes, we implement topic-based publish/subscribe using the OSGi Event Admin service. The Component Control layer also contains facilities to interact with upper layers. This interaction is made in two ways: 1. Through sensors, sensing the current state of the functional elements, e.g., reporting if the current configuration of elements cannot meet design goals 2. Through actuators, allowing upper layers to change the current configuration so as to meet design goals Sensors in LinkSmart may be one of the following three types: 1
http://www.w3.org/2004/OWL/.
147
1. State sensors monitor the internal state of a service. Typically embedded services fulfill a state machine specification, and we report state changes to upper layers via events 2. Communication sensors monitor the communication between services, i.e., which messages are sent between which services 3. Configuration sensors monitor the configuration of services and components implementing the services in a system 4.1.1. State sensing The state and communication sensors are generated by the LinkSmart Service Compiler [8]. State sensing is based on an OWL description of a UML state machine for the service. Following the idea of SA-WSDL,2 we extend Web Service Description Language (WSDL) descriptions of web services to reference an OWL description of the service including a state machine description and use this when generating web services. Fig. 4 shows an excerpt of a WSDL description of a thermometer (TH03). The thermometer service defines an operation getTemperature, but furthermore defines a reference to a device description (in
http://www.w3.org/2002/ws/sawsdl/.
148
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
starting, stopping, updating, and undeploying. We have implemented a binding to OSGi that allows for architectural scripts that change an OSGi deployment. An example ASL script is shown in Fig. 8. The script initializes the variable aql_s to reference a service from the AQL component (line 1–3), stops the service (line 4), and eventually uninstalls the component (line 5). ASL plays an integral role in reconfiguration as effected by the upper layers in our architecture. We will return to this in Section 4.3. In summary, Fig. 9 shows a deployment view of the Component Control layer of LinkSmart self-management architecture. Furthermore, Fig. 10 summarizes a Component & Connector view of the interaction among components focusing on the Component Control layer. 4.2. Change management The Change Management layer is concerned with reacting to changes in states in the Component Control layer, changing parameters and behaviors according to a set of plans. In our case, plans are realized using OWL ontologies with behaviors represented as SWRL3 rules built on top of the SeMaPS ontologies. An overview of the ontologies is shown in Fig. 11. Our SeMaPS runtime implementation uses the Protégé framework4 for providing functionality to load/manipulate/save ontologies, for SWRL rule processing, and for SQWRL5 query processing. Continuing the thermometer example from Section 4.1, a plan may state which communication protocol a device should use in a given context for reasons of, e.g., energy consumption, goodput, or throughput [35]. As an example, an SWRL-based plan may state that a battery-operated device must use Bluetooth6 as a communication protocol if the battery level is below a certain threshold. This is an example of communication protocol adaptation as shown in the following Rule 1. Rule 1. A protocol adaption rule
dev ice : Thermometerð?dev ice1Þ dev ice : hasHardwareð?dev ice1; ?hardwareÞ
^ ^
hardware : supportProtocolð?hardware; ?protocolÞ network : nameð?protocol; ?nameÞ swrlb : containsIgnoreCaseð?name; BluetoothÞ hardware : primaryBatteryð?hardware; ?batÞ
^ ^ ^ ^
hardware : batteryLev elð?bat; ?lev elÞ swrlb : lessThanð?lev el; 0:15Þ dev ice : hasStateMachineð?dev ice1; ?statemachineÞ
^ ^ ^
stateMachine : hasStatesð?statemachine; ?stateÞ abox : hasURIð?state; ?uriÞ swrlb : containsIgnoreCaseð?uri; measuringÞ
^ ^ ^
stateMachine : isCurrentð?state; ?curÞ swrlb : equalð?cur; trueÞ ! sqwrl : selectð?dev ice1; ?lev elÞ ^
^
dev ice : currentCommunicationProtocolð?dev ice1; BluetoothÞ
In this example, a Thermometer that (i) supports Bluetooth, (ii) contains a battery with level less than 15%, and (iii) is in the measuring state, should change its communication protocol to Bluetooth (for energy usage reasons). Plans may easily conflict with each other. For example, a requirement to optimize for energy 3 4 5 6
http://www.w3.org/Submission/SWRL/. http://protege.stanford.edu/. http://protege.cim3.net/cgi-bin/wiki.pl?SQWRL. https://www.bluetooth.org.
usage coupled with a requirement to optimize for throughput may conflict. This might, e.g., lead to plans simultaneously selecting Bluetooth and UDP for communication in our example. Resolving such conflicts is the responsibility of the Goal Management layer discussed in Section 4.3. In the example above, the execution of the plan is triggered by events from the Component Control layer on the state of the device and the battery level of that device. Publication of the device state is supported by state machine generation whereas the publication of battery level is an application-specific feature (unless it is connected to a state change). Such a sequence of events is shown in Fig. 12. Finally, Fig. 13 shows a deployment view of the Change Management layer of the LinkSmart self-management implementation, illustrating that SeMaPS is deployed on the same node as the Reasoner component. 4.3. Goal Management Goal Management is concerned with producing plans for how to reach a goal state given a high-level goal and a current system state. In our realization, the Goal Management layer consists of two main components (see Fig. 18 for a typical deployment): 1. An Optimizer that will find a goal system configuration given a set of optimization constraints. It defines functions for defining self-management problems and implementations of genetic algorithm-based optimizations. 2. A Planner that will find a plan (consisting of ASL scripts that can be executed by ASL Interpreters) for going from a current system configuration to a desired/goal system configuration. Both components rely on having an up-to-date view of the system configuration. This is achieved by querying SeMaPS for system states and by listening to events published by the AQL sensors. AQL provides a query-based interface to retrieve information describing the runtime architecture of a system. The query in Fig. 14 illustrates the usage of AQL. It provides means to select which parts of the query should be evaluated locally, and which parts globally. A Global modifier cannot be contained within a Local modifier. The data source, the AQL tables residing locally on each device, are specified in the innermost pairs of parentheses. The tables in this case are ClientEndpoints and ServerEndpoints. The ClientEndpoints table contains the columns named (DeviceID, ClientID, TargetEndpoint, Protocol). It contains a tuple for each active client-connection, specifying the device id of the client (DeviceID) the local identifier of the client on that device (ClientID), the target endpoint for the service (e.g., for TCP it is the IP address and port number), and the protocol (Protocol). The ServerEndpoints contains the columns (DeviceID, ServingEndpoint, Protocol). ServingEndpoint denotes the endpoints on the server on which the service is reachable (for TCP/UDP, that is the IP address and port number the server socket is bound to). There is one tuple for each protocol/endpoint combination at which a service is available on this server. In this query, the tables with endpoints for clients and servers are each prepared locally, renaming the columns TargetEndpoint and ServingEndpoint, respectively, to Address, and renaming the device id columns to ClientDID and ServerDID in order to allow convenient usage of natural join. The result of the local step is thus, conceptually at least, two tables with columns named (ClientDID, ClientID, Address, Protocol) and (ServerDID, Address, Protocol).The natural join of these yields a new table (ClientDID, ServerDID, ClientID, Address, Protocol) specifying the details of each active channel in the current system configuration.
149
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Fig. 4. WSDL description of thermometer service.
Fig. 5. OWL description of thermometer device.
Goal Management
Change Management Event Manager
Fig. 6. State machine for thermometer device.
Component Control
:Service :Component :Component
AQL Sensor
ASL Interpreter
Fig. 9. Deployment view of the Component Control layer. Fig. 7. Partial OWL description of state machine for the TH03 thermometer device.
The Optimizer uses genetic algorithms to find a solution given a set of constraints [36]. The formulation of optimization problems are application-specific. An example in the thermometer case is a multi-objective optimization trading off energy consumption with throughput, where the fitness function in the genetic algorithm is based on specific choices of protocols for the communication between service providers and consumers. Given a current configuration and a goal configuration (as provided by the Optimizer), the Planner will attempt to construct an ASL script that transforms the current configuration into the given goal configuration. Planning problems are described in the Planning Domain Definition Language (PDDL) [37]. A planning problem in PDDL consists of a domain description and a problem description. The domain description in a self-managed deployment consists of two parts that describe the operations that may be applied to architectural operations and as such defines the semantics of ASL operations:
A generic part with ASL operations that apply to all applications. This includes operations such as deploying, starting, stopping, updating, and undeploying components [33]. An application-specific part with ASL operations that have specialized semantics for a domain. In our protocol change example, a set_property operation has been defined that when set for a client of a service will cause that client to subsequently use the protocol that the property points to. This is further described in B. Fig. 15 shows the definition of the component undeploy operation in ASL: given a device (d) and a component (c), the component may be undeployed from the device if it already exists at that device (as specified in the :precondition). The results (i.e., the :effect) is then that all packages that c provides are no longer available on the device, d (unless other components provide them). Planning problems described in PDDL are defined by the goal that the Optimizer has provided. A simple excerpt is shown in
Fig. 8. An ASL script.
150
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Fig. 10. Component & connector view of the Component Control layer.
Fig. 11. SeMaPS ontologies.
Goal Management
Change Management Event Manager
Reasoner
SeMaPS
Fig. 12. Component & connector view of Change Management layer.
Fig. 16. As a result of solving the planning problem, on the client device (Dc), the following script will need to be executed:
Component Control
set_property (propertykey, udptype); And correspondingly, on the server device (Ds), the following script installing a UDP protocol component (Cudp) and starting a corresponding service (sudp) will need to be executed: deploy_component (Cudp); init_service (Cudp, Sudp); start_service (Sudp);
Fig. 13. Deployment view of Change Management layer.
These scripts are then communicated to lower layers, using the Event Manager. This behavior is illustrated in Fig. 17 and a deployment is shown in Fig. 18.
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
151
Fig. 14. An AQL query.
Fig. 15. PDDL definition of the ‘‘undeploy’’ ASL operation.
4.4. The overall LinkSmart self-management architecture The overall LinkSmart self-management architecture is shown in Fig. 19. The three layers are interacting through events, using a publish-subscribe component called the Event Manager, which means that the interaction of components in the architecture is independent of how they are distributed. 5. Evaluation There are neither unified evaluation guidelines nor methodologies for autonomic middleware systems [26]. However, the recent version of the quality attribute framework proposed by Bass et al. [10] is comprehensive and widely adopted for evaluating software architectures and we base our evaluation on this. Considering the characteristics of pervasive computing systems and pervasive service middleware, and also our objectives for the LinkSmart 3L architectural style, we propose to evaluate middleware by considering both runtime and development time quality attributes. The runtime quality attributes should include at least performance, interoperability, and scalability (a form of ‘‘modifiability’’ in [10]); and the development time quality attributes should include at least modifiability, usability, and testability. For performance, middleware should function and react quickly in order to be usable in practice. For interoperability, middleware must be usable across different hardware and software platforms. Due to the possible large number of devices involved in an application using the middleware, scalability is an important factor for evaluating a middleware. To make middleware evolvable in order to make enhancements and add new functionalities, modifiability is desirable. To make middleware practical, the middleware system should be relatively easy to use for developers, and not hard to test, which leads to requirements for the usability and testability. In the following, we describe our evaluations using this framework. 5.1. Runtime quality For the runtime quality measurements, the following software platform is used: JVM 1.6.20-b02 running on 64 bit Windows 7.
The hardware platform is a Thinkpad W700 T9400 2.53G CPU with a 7200 rpm hard disk and 4G DDR2 RAM. The time measurements are in millisecond. We use the default Java heap memory size. 5.1.1. Interoperability For LinkSmart, pervasive web services are implemented using SOAP in order to integrate various embedded and networked systems. This enables interoperability among different platforms (such as .NET and Java). Even in the LinkSmart middleware itself, the device discovery and service management components are developed with .NET components. We have developed applications in three domains including agriculture, smart building, and ehealth for yearly project reviews, and all these applications are developed using different .NET and Java components and various hardware including weight scales, thermometers, and pumps [35]. There were few problems for the interactions between these devices and applications due to SOAP differences on platforms, and they were resolved. The downside of SOAP web service is the processing time for a web service call, which takes around 300 ms for a round trip call for a simple invocation such as temperature retrieval. Additionally, for pervasive middleware, it is critical that different wired and wireless communication protocols can interact. For this, we used UPnP in LinkSmart and wrapped other protocols in UPnP. In this way, we have integrated and tested with among others Zigbee7 and Bluetooth. 5.1.2. Scalability In our case, scalability is evaluated through clients continuously publishing their states (thermometer states in our running example) as events. In the test, each client sends events as quickly as possible in a loop. We then measure how long time it takes to process an event, starting from the publication and until the end of inference and publication of the result of inference. The time needed is shown in Fig. 20 on the Y axis. The X axis shows the number of events. We can see that the time taken for the test is a linear function of the events need to be processed. 7
https://www.zigbee.org.
152
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Fig. 16. PDDL definition of planning problem.
Fig. 17. Component & connector view of Goal Management layer.
Change and Goal Management Planner Event Manager
Optimizer
SeMaPS
5.1.3.1. Ontology-related performance. Based on previous experiments, we know that the loading of the SeMaPS ontologies usually takes more than 3 s. Thus, to achieve good performance, several strategies are adopted: Loading the SeMaPS ontologies during components initialization and activation as ontology loading is a slow process. Initializing static contexts by executing ontology queries in advance. Using SWRL rule grouping.
Component Control
Fig. 18. Deployment view of Goal Management layer.
The second measurement of scalability we perform is to publish events in parallel. Every device publishes 10 events in parallel and waits until the end of event processing. We then measure this duration. This is shown on the Y axis in Fig. 21. We can see that for this test the LinkSmart middleware has reasonable scalability. 5.1.3. Performance We have measured the performance for all critical LinkSmart components including the Optimizer, Reasoner, AQL, and ASL. As the Semantic Web and its supporting tools and technologies are still at the infancy stage, it is critical to make sure that we can get acceptable performance in a middleware system. Therefore, we first need to measure the ontology-related performance.
We need to investigate whether the complexity of underlying ontologies have large consequences with respect to performance for ontology updating and reasoning (including SWRL inference and SQWRL query). The complexity of an ontology is measured in terms of defined classes, object properties, data type properties, restrictions (including ‘‘cardinality’’ or ‘‘existential’’), total size (bytes) of an ontology or an ontology set, and rules. Please note that usually the update of an ontology property takes only a few milliseconds. As we are using the Observer pattern to observe ontology property changes inside the ontology components, inference will happen immediately after the updates, and the update time will be more or less the same as the inference time. Table 1 shows the performance effect of complexity of ontologies. In Table 1, ‘OP’ stands for object properties, ‘DTP’ stands for data type properties, ‘Restr.’ stands for restrictions, ‘Stdev’ stands for Standard Deviation, ‘Time1’ to ‘Time5’ stands for the inference time for 5 different rules. For every configuration, we measure five times as shown in the lines of Table 1. From this table, we can see that there is little performance overhead when the complexity of
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
153
Fig. 19. Overview of the LinkSmart 3L architecture.
ontologies increases. For example, the number of classes increases almost eight times, object properties, and number of data type properties doubles, but the average time for inference varies only little, which means that the complexities of ontologies have little effect on performance in our tests. Table 2 shows the performance of rule inferring using rule grouping when only a subset of rules is evaluated. The ontology complexity configuration is shown in the second group (as in Table 1). The performance of three rule groups (namely ‘RuleGroup1, RuleGroup2, and RuleGroup3’) are shown. We can see that the performance improves (average 3173.4 ms versus 2057.8 ms) with around 35%. 5.1.3.2. Optimizer performance. Table 3 shows the performance of the Optimizer, with maximum evaluations of 2000, population size 64, and crossover probability (CVP) as 0.8, 0.9 and 1. We can see on average it takes around 1.5 s to find optimal solutions. 5.1.3.3. Performance of a complete optimization cycle. An optimization cycle is adequate for validation as it involves all components in the self-management system. It starts when the Reasoner
detects a need for reconfiguration, and it involves the components executing the following steps: 1. Sensing. AQL is used to retrieve the current system configuration. This is fed through the Event Manager to the Optimizer. 2. Optimization. The Optimizer solves the optimization problem given by the state of the system and the current fitness function that reflects the current qualitative QoS preferences for the system. 3. Planning. The result of optimization is a desired target configuration. The target configuration, along with the current system configuration from step 1 constitutes a planning problem. 4. Actuation. The result of planning is an ASL script transforming the system from its current configuration to the goal configuration. The result of planning is published by the planner through the EventManager, and received by the ASL interpreter which executes it. The combined execution time for an optimization cycle is thus:
T total ¼ T sense þ T reason þ T optimize þ T plan þ T actuate þ 3 T ev ent
Fig. 20. Scalability with respect to the number of events.
154
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Fig. 21. Processing parallel events.
Table 1 Performance consequences of ontology complexity (times are in ms). Classes
OP
DTP
Restr.
Size
Time1
Time2
Time3
Time4
Time5
Average
Stdev
73
39
58
46
105745
606
89
105
154
326,233
609
106
154
89
343,494
1841 2225 2588 1910 2167 2264 1707 1678 2365 2352 2184 2137 2431 1544 1662
3607 4140 4261 3194 3781 3668 2653 3096 4396 3906 2214 2902 2268 2372 2829
3482 3393 3348 3405 2691 3422 2653 2934 4202 3890 1326 2153 2371 2341 1493
2643 3621 2967 3394 2991 3942 4555 3319 3414 3068 2240 2685 1300 2528 2454
2413 3482 3524 2964 3631 3336 1228 3807 4022 3459 2526 2341 3550 2389 2337
2797.2 3372.2 3337.6 2973.4 3052.2 3326.4 2559.2 2966.8 3679.8 3335 2098 2443.6 2384 2234.8 2155
743.4 703.6 629.8 621.0 667.8 639.1 1274.7 792.0 821.9 649.4 452.8 338.2 798.5 392.8 560.8
where the 3 T ev ent is the time required to forward events among the components in between steps 1 to 4. Table 4 lists the measured values for each of the components in the above formula in a setting with four devices. Using the numbers in the table yields a total time of 3738.5 ms, which is within the acceptable limit for interactive applications. It is clear from the results that improvement to this number can only be achieved by reducing the time needed for reasoning and optimization, as the time consumption of the other sub-components of our self-management approach are insignificant in comparison. 5.2. Development-time quality Development-time quality addresses how the quality of a system from a developer perspective. For this, we have evaluated the modifiability by extending the LinkSmart 3L architecture through the addition of new features iteratively. Furthermore, project partners were invited to use the LinkSmart 3L architecture in order to evaluate its usability. 5.2.1. Modifiability Modifiability is evaluated in a number of ways. The first one is to add new devices to a self-diagnosis for a ‘‘SmartHome’’ system. We started the development of diagnosis with the rule for temperature monitoring. After finishing the implementation and testing, we then try to handle a camera diagnosis rules. The steps involved are:
Add the camera device to the SmartHome System concept in the Device ontology. Add the camera state machine instance to the StateMachine ontology. Add the camera state machine instance to the hasStateMachine property of the ‘‘camera’’ device. Add camera diagnosis rule to the DeviceRule ontology. After this, no line of the LinkSmart code needs to be changed. The addition of new device instances to a certain system is very straightforward and is conducted at runtime. If the rules for the new devices already exist, then self-management (here we tested self-diagnosis) will work directly. The reason is that the diagnosis strategy is directly encoded in the Device ontology. The second type of modifiability evaluation is based on how we evolved the self-management features of the LinkSmart 3L architecture. We initially built the LinkSmart 3L architecture with support for self-diagnosis, then we added self-protection, and finally we added self-adaptation of communication protocols (cf. the SWRL rule in Section 4.2). The above evaluations support that the LinkSmart middleware has good modifiability.
5.2.2. Usability In order to check the usability of the Semantic Web-based change management presented in the previous sections, we asked project partners to use the ontologies we created. It was possible to
155
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161 Table 2 Performance after using rule grouping (times in ms).
Average
Table 3 Optimizer performance (times in ms).
RuleGroup1
RuleGroup2
RuleGroup3
CVP = 0.8
CVP = 0.9
CVP = 1
1778 1685 3090 2059 1560 1404 1778 1513 2231 1654 1749 2242 1951 1889 2606 1817 1684 1965 2193 1279 1314 2052 1754 1790 1779 2528 2044 2154 1780 1966 1327 1701 1827 2107 1795 1624 1826 2627 2154 2793 2216 1861 2263 2230 2162 2247 1889 1545 1873 1842 2246 2570 1873 3190 2587
2090 2465 1530 1919 2184 1638 1702 1544 1155 1935 1778 2543 2480 1997 1825 1856 1950 3182 1794 1684 1561 1701 1529 1856 1374 1202 2029 2560 1654 1779 1373 1592 1639 1561 1998 1561 1498 2076 1780 1810 2653 1499 2154 2247 2435 1903 1764 3137 1934 1811 1857 2279 2496 1826 2387
1420 2124 1733 2544 2396 1789 2923 1747 2461 1933 2175 1874 2653 2873 2601 2091 1881 1903 2318 1950 2360 2225 2150 1894 1994 2720 2772 2030 3183 1871 2400 1872 1686 2014 3332 2331 1877 2617 2152 2029 2146 2128 3018 1950 2104 1732 1713 2528 2275 2199 2684 2742 2901 3181 1904
1993.9
1923.0
2256.4
952 1277 873 1545 1452 1081 858 1373 1295 1397 1318 1078 1498 1680 1039 1264 891 1451 968 796 999 1436 1782 1171 1014 1313 1069 1108 477 1371 999 1451 1908 1642 1299 959 1162 1606 2622 2999 2987 2316 2013 2123 1974 2319 2019 1694 1484 1896 1983 1656 1497 1613 1628 1363 1048 2439 2298 2392 2361 967 1447 1447 1275 1652
1654 999 1092 2029 1498 1014 828 826 1513 1109 905 1062 952 967 1796 1045 951 1936 468 2184 1889 983 952 1873 2216 2029 1857 2200 1140 2264 2092 2420 2327 1967 1561 1530 1983 1562 1859 1656 1108 1639 2107 2341 1202 1577 1187 1140 1562 531 1561 1296 1109 1077 1218 1873 921 1656 1014 1311 1343 1031 1280 1312 764 874
1201 827 421 671 1232 1175 905 842 1482 1702 718 1457 1513 1374 733 1467 1545 1450 889 1466 1326 1488 655 1757 1211 808 983 1654 1794 1879 1006 1061 1724 1202 1763 1248 1873 1553 2056 1940 1357 1169 2215 1673 1343 1123 828 1171 1045 1506 1413 1308 1486 1597 1826 1217 1364 1427 1165 1190 906 702 501 437 780 806
1518.6
1488.1
1329.3
create a model of an HTC P3300 device including a state machine within half day by an ontology engineer unfamiliar with the device and the associated services. The ontology was created using the Topbraid Composer ontology tool.8 The feedback was that the ontologies for software and hardware device properties need to be very well documented, and also for a developer, who is not familiar with the domain, it is hard (or in some cases even impossible) to create suitable representation of device properties, without precise specification on meaning of these concepts. Thus these models need to be created by someone who is both familiar with ontologies and
8
http://www.topquadrant.com/products/TB_Composer.html.
Average
the specific device. Based on these comments, we have improved the modeling and documentation of the ontologies through a better classification of devices. This has been evaluated by partners again, and is now easier to use.
156
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Table 4 Performance of a complete optimization cycle. Parameter
Value (ms)
Measurements
Devices
T sense T reason T optimize T plan T actuate T ev ent
66.9 2057.8 1445 7 100 20.6
100 55 5 20 20 100
4 – – – – 4
5.2.3. Testability To make the LinkSmart 3L architecture properly testable, it should be possible to control each component’s inputs and then to observe its outputs. As recommended in [10], we mainly adopted the ‘‘Record/Playback’’ tactic, capturing information using a logging utility from OSGi. We also used a ‘‘Localize State Storage’’ tactic, where we use state machines for recording the device and system states. These two tactics work well currently, but we will improve testability in the future by adding more recommended tactics in the future, for example execution assertions.
Considering the condition that a full self-management life cycle will not be constantly running in an application, the performance of the component appears reasonable. However it should be noted that planning problems are inherently complex, so it is to be expected that when the planning problem instances increase in size, the performance of the Planner will be reduced. This confirms the allocation of the planning component to the top-layer, the Goal Management layer, along with the Optimizer. The evaluation of using GAs showed that although the performance may decrease when the size of the problem increases, the performance is still acceptable for moderate complexity problems [38]. We have evaluated our LinkSmart 3L architectural style realization based on the quality framework proposed in [10]. This can also be used as guidelines for evaluating other middleware. Based on the self-management features we have realized and their evaluation, we conclude that our work addresses the interoperability, modifiability/extensibility, integration challenges we mentioned in Section 1. The LinkSmart source code as a whole is available from its release website in SourceForge,9 so that researchers can use it and make improvements. The LinkSmart project as such was and it is still evolving. The middleware has been used in a number of EU projects,10 including GreenCom,11 REACTION,12 inCASA,13 and EBBITS.14
5.3. Support for comprehensive self-management capabilities Besides the self-diagnosis shown in this paper, the LinkSmart middleware has been also evolved to include the capabilities of cover a full spectrum of self-management capabilities: 1. Self-protection using security ontologies considering QoS properties of different security protocols [36]. This mainly involved the extension of context ontologies to include security concepts and properties, and defining the related optimization objectives for the genetic algorithms. 2. Self-configuration considering QoS properties of to-be-configured services [38]. This includes adding services instances to the service ontologies, self-configuration was managed to achieve best configuration of different middleware components, and will be actuated by ASL scripts [36]. 3. Self-adaptation of communication protocols considering QoS properties of different communication protocols used for pervasive web services, including TCP, UDP, and Bluetooth [35]. The QoS properties of different communication protocols are modeled in context ontologies and in order to adapt the used communication protocols, an optimized configuration from the planning layer is computed and a switch of protocols is made at runtime. 4. Self-optimization was used to realize various self-management objectives as shown by self-protection, self-configuration and self-adaptation [38,35,36]. As can been from the self-management functionality we have realized, except for self-diagnosis, self-management usually involves obtaining optimized configurations of services, protocols, or other properties. Knowledge of these as built in the context ontologies play key roles to achieve self-management.
5.4. Discussion The evaluations confirm the soundness of the proposed LinkSmart 3-L architectural style. A key rationale in this architectural style is that efficient algorithms should reside in lower layers. This is indeed the case as the components residing in the Component Control layer (sensing, actuation) performs significantly faster than the components in the above layer.
6. Related work Large Internet of Things (IoT), Internet of Services (IoS), and Internet of People (IoP) applications are gaining increasing attention. This brings us increasing complexities for management due to the large number of involved devices, events and contexts, heterogeneity of networking, hardware and software, and so on. These challenges call for useful self-managing capabilities to alleviate problems. Therefore, quite some work on self-managing middleware has been reported and we relate our work to some of this in the following. The MUSIC middleware [3,39] follows a layered architectural style, and mainly focuses on self-adaptation. The MUSIC project planned to used GAs for optimization, but based on the released software packages15 it appears that GAs had not been applied. The work we have done in LinkSmart-3L architectural style incorporated a number of architectural styles and supports component control, change management, and Goal Management. In contrast, the MUSIC project is focusing on architecture-based self-adaptation. There are several demonstration applications available to show the usage of the MUSIC middleware, and based on these applications, it appears that MUSIC has good modifiability and good interoperability (as well as plugins for web services), but there is currently little experimental evaluation to show, e.g., its scalability and testability. We have evaluated these aspects based on a proposed quality framework. The Rainbow architecture by Garlan et al. [4,5] produces an architectural model of a system in order to support self-management. This model consists of components, connectors, properties associated with the components and connectors, and constraints. In our approach, we do have explicit components and connectors, constraints and properties, which are encoded in related ontologies and OSGi meta files. The OWL-based approach arguably provides more reasoning capabilities for component configurations [40] than other approaches, and fits the open nature of pervasive 9 10 11 12 13 14 15
http://sourceforge.net/projects/linksmart/. http://www.hydramiddleware.eu/viewpage.php?page_id=13. http://www.greencom-project.eu/. http://www.reaction-project.eu. http://www.incasa-project.eu/. http://www.ebbits-project.eu/. http://ist-music.berlios.de/site/.
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
systems well [41]. Additionally, the planning layer in the LinkSmart 3L architecture makes it possible to create optimized configurations. Rainbow follows sense-plan-act cycles. The LinkSmart 3L architecture is not limited to simply doing cycles of sense-plan-act. In our case, each layer is loosely coupled and can work independently. Rainbow is evaluated in terms of generality, cost-effectiveness, transparency [42]. Also performance, development time, and security of applications are assessed. The authors of [42] consider that scalability is not an issue for Rainbow as probes and gauges are deployable on distributed nodes, but we think this needs to be evaluated as we did for LinkSmart. We have not rigorously recorded our development time for a typical self-management application which remains as future work. IBM’s ‘‘autonomic computing’’ approach to self-management [1] proposed four concrete types of ‘‘managers’’, namely managers for self-configuration, self-optimization, self-healing, and self-protection. We do not explicitly have these managers in our architecture, but have realized them in a generic way by having different types of self-management rules as described in [26]. We have a dedicated optimization engine which has the capability to find a global optimal solution to configuration problems. The architectural model in LinkSmart-3L is managed by both a component ontology and runtime monitoring of architectural changes with AQL, and thus it supports distributed monitoring. In Curry and Grace’s work [43], the Model-View-Controller pattern is adopted to improve concerns separation by encapsulating state, analysis, and realization of self-management operations. The MVC pattern becomes a general design guideline, which improves flexibility, customization, and portability of self-representation for an autonomic system. We have also adopted the MVC principle to some extent in our design and implementation: the models are implemented using OWL ontologies, the controller parts are the corresponding Java classes for model manipulation, the views are different self-management features (encoded with SWRL as DL-safe rules [44]) that operate on existing instances in the ontologies. These are triggered by the update of OWL models. The pattern is reinforced in our case by a repository architectural style, and a layered architectural style. The three-layered model was proposed by Kramer and Magee in [6] as a reference model. Sykes et al. continued this work as in [45] for self-management. Goals expressed in a temporal logic are used to generate reactive plans, and then domain-specific software components are configured based on these plans. In LinkSmart 3L, we used an IPP planner to generate the plans to reach an optimal state computed by the optimization engine, based on an AQL query of the current architecture status. In the future, we will explore the usage of state machine-based self-management further based on our initial work [46] and work in [47]. We have also used a formal approach in the planner, SWRL rules and Petri Nets in specifying self-management rules, and formalized ASL with Alloy [34]. In the future, we will explore other formal methods to regulate selfmanagement tasks [48]. Some architectural style requirements for self-healing were discussed in [49], including adaptability, dynamics, awareness, autonomy, robustness, distribution, mobility, and traceability. These requirements are suitable not only for self-healing systems but also applicable to self-managed systems in general. The LinkSmart-3L architecture supports adaptability through actuators, and further use state sensors to support dynamics. Awareness is supported by a set of SeMaPS ontologies and AQL sensors. Distribution is realized through the usage of pervasive web services and a publish-subscribe mechanism. Autonomy is an intrinsic feature throughout the planning layer and enacted by the actuators. Traceability is supported by a logging mechanism in an ontology and will be extended in the future. Robustness is referred to as
157
fault-tolerance for self-healing in [49], which is supported through an ontology and topic based events. We have not specifically explored mobility in the LinkSmart-3L architecture, but we will make use of the OSGi framework to support it in the future. The PitM architectural style [49] and the work in [50] based on the Prism-MW middleware [51] promote an adaptive layered style based on meta-components. Three types of specialized metacomponents are designed [50] corresponding to the typical sense-act-control paradigm, which is incorporated in our architecture. The LinkSmart 3L style has incorporated additional architecture patterns, and provides loosely coupled sense, plan, and act components that provide flexibility. A collaborative auctioning algorithm [52] is used to get an optimal deployment in [50]. Another early work called CARISMA [53] used reflection to enhance the construction of adaptive and context-aware mobile applications, and used sealed-bid auctions inspired by micro-economics to dynamically resolve possible policy conflicts during context changes. Poladian et al. [54] used an analytical approach similar to combinatorial auctions in project Aura to adaptively support everyday tasks of users. In our experiences and tests, we have used GAs as the main approach for finding global optimized solutions as it often finds better quality solutions with reasonable performance compared to auction algorithms. Some architectural styles can facilitate self-management as discussed in [55,56]. These include event-based, service-oriented, REST-based and peer-to-peer styles. We have incorporated event-based and service-oriented styles into our LinkSmart-3L architectural style, together with the Repository style that has shown its advantages for sharing knowledge across the system. The LinkSmart project is using a peer-to-peer style in the network layer [57], which can be integrated into our work reported in this paper. The REST style is investigated in the LinkSmart project, and will be explored in the future. A reference model for decentralized self-adaptation was proposed in [58], in which meta-level computations operate on meta-level models. The meta-level models cover a system model, a concern model, a working model, and a coordination model. A system model in the LinkSmart-3L architecture is covered thoroughly by the SeMaPS component and Device ontologies in one layer, and the AQL sensors in the bottom layers for knowing dynamics system models. The concern model is managed by the goals in the planning layer through the optimization engine, plus events that are sent to trigger planning activities. The corresponding self-management rules are also part of the concern models. A working model is handled through the planner, which calculates a sequence of steps to reach to the optimal configuration that is enacted by ASL scripts. For the current implementation, we use events for the coordination between components, and we use heartbeat to coordinate monitoring. The recent middleware work, FRASCATI [59], provides a Service Component Architecture with dynamic reconfiguration capabilities and run-time management features. The work has evaluated its platform performance, and also performance of an application based on FRASCATI. The time consumption of invocation of messages is comparable to our experiments, which is around 300 ms. FRASCATI is not evaluated in terms of other quality attributes, and the work is not focusing on architectural styles for self-management per se.
7. Conclusions and future work Realizing autonomicity for pervasive service computing is increasingly important as self-management capabilities can enable high dependability, intelligence, and quality of a large pervasive system. Although there is considerable research work on this topic,
158
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
integrating existing technologies into a self-management system remains problematic. In particular, there is little open source work that explores self-management activities. In this paper, we have proposed a hybrid approach to the realization of self-management in an open source pervasive service middleware. In this hybrid approach, different architecture styles, including the layered architecture style, repository style, and the service-oriented architecture style, are integrated into a ‘‘LinkSmart-3L’’ architectural style. We have implemented the LinkSmart-3L architectural style based on the OSGi framework as part of the LinkSmart middleware. We incorporate OWL ontologies supported context-awareness, genetic algorithm-based optimizations, architectural query language-based sensing, architectural scriptingbased actuation, and IPP-based planning to derive necessary steps to reach an optimal state. The proposed approach has been successfully validated in terms of both runtime and development time qualities through a set of experiments using a SmartHome application. Our implementation has been released to open source in order to promote the research and development of self-management for pervasive computing systems. In the future, we will further test the effects of device and service mobility, which was not a focus in the LinkSmart project. This means also that we need to add mobility-related fault tolerance features to our design and implementation. SOAP-based web service is the primary interaction approach in LinkSmart, but RESTful web services will be considered and explored in further self-management work, together with the experiments on the usage of a peer-to-peer style. Another direction is to explore the mobile cloud computing [60] and pervasive cloud paradigms [61] in order to handle compute intensive tasks, and distribute the knowledge base across different cloud nodes to facilitate distributed intelligence and flexibility for managing tasks in a pervasive cloud environment [62].
Acknowledgments The research reported in this paper had been supported by the Hydra EU project (IST-2005-034891) which build the LinkSmart middleware. The research is also supported by ‘‘Key Technologies Development Plan of Qingdao Technical Economic Development Area’’. Weishan Zhang has been supported by ‘‘the Fundamental Research Funds for the Central Universities’’ and also the startup funds for ‘‘Academic Top-Notch Professors in China University of Petroleum’’. We would like to thank to Martin O’Connor and Timothy Redmond from the Protégé team from Stanford University for their kind help on using the Protégé OWL/SWRL APIs. We also thank Antonio J. Nebro and Juan J. Durillo from Malaga University for their kind help on using the JMetal framework. Thanks are also given to the anonymous reviewers for their thoughtful and constructive comments which helped to improve the paper.
Appendix A. More usages of SeMaPS ontologies The usage of the SeMaPS ontologies and SWRL rules in the Change Management layer makes sure that the LinkSmart selfmanagement architecture has good modifiability/extensibility for new self-managementa features. We have shown an example of self-adaptation of communication protocols in Section 4.2 in which a developer can use the SeMaPS ontologies and reasoning APIs to write new SWRL rules for handling new self-management features. For example, we can develop a self-diagnosis rule as part of a selfhealing feature based on the SeMaPS ontologies as shown in the following Rule 2.
Rule 2. A self-diagnosis rule for environment monitoring
dev ice : hasStateMachineðdev ice : PicoTh03O utdoor; ?statemachineÞ ^ statemachine : hasStatesð?statemachine; ?stateÞ ^ statemachine : doActiv ityð?state; ?actionÞ ^ statemachine : actionResultð?action; ?resultÞ ^ statemachine : historicalResult1ð?action; ?Result1Þ ^ statemachine : historicalResult2ð?action; ?Result2Þ ^ statemachine : historicalResult3ð?action; ?Result3Þ ^ swrlb : addð?tempav erage; ?Result1; ?Result2; ?Result3Þ ^ swrlb : div ideð?av erage; ?tempav erage; 3Þ ^ swrlb : subtractð?temp1; ?result; ?Result1Þ ^ swrlb : subtractð?temp2; ?Result1; ?Result2Þ ^ swrlb : subtractð?temp3; ?Result2; ?Result3Þ ^ swrlb : addð?temp; ?temp1; ?temp2; ?temp3Þ ^ swrlb : greaterThanð?av erage; 15:0Þ ^ swrlb : lessThanð?av erage; 30:0Þ ^ swrlb : lessThanð?temp; 0Þ ^ dev ice : hasStateMachineðdev ice : PicoTh03I ndoor; ?statemachineb Þ ^ statemachine : hasStatesð?statemachineb ; ?stateb Þ ^ statemachine : doActiv ityð?stateb ; ?actionb Þ ^ statemachine : actionResultð?actionb ; ?result b Þ ^ statemachine : historicalResult1ð?actionb ; ?Result1b Þ ^ statemachine : historicalResult2ð?actionb ; ?Result2b Þ ^ statemachine : historicalResult3ð?actionb ; ?Result3b Þ ^ swrlb : subtractð?temp1b ; ?result b ; ?Result1b Þ ^ swrlb : subtractð?temp2b ; ?Result1b ; ?Result2b Þ ^ swrlb : subtractð?temp3b ; ?Result2b ; ?Result3b Þ ^ swrlb : addð?tempb ; ?temp1b ; ?temp2b ; ?temp3b Þ ^ swrlb : greaterThanð?tempb ; 0Þ ! error : currentMalfunctionðdev ice : VentilatorMY0193; error : PowerDownÞ
Here, thermometers named ‘‘PicoTh03_Outdoor’’ and ‘‘PicoTh03_Indoor’’ respectively are used to measure both an indoor and an outdoor temperature. In the period with a conformable temperature, i.e., when the outdoor temperature is between 15 and 30 °C. The indoor temperature should follow the same trend as the outdoor temperature. Otherwise, we can infer that the ventilator is down. The processing of this rule will obtain the trends via the difference of continuous temperature measurements of both the indoor and outdoor temperatures. If the trends are different, an instance of the ‘‘currentMalfunction’’ property (‘‘VentilatorDown’’) of concept ‘‘MalDevice’’ (malfunctioning device, which is ‘‘VentilatorMY0193’’ in this case) will be inferred. Then the Malfunction ontology will be checked for the resolution of the problem based on the malfunction cause. In our case, the Malfunction ontology would give us the suggestion: ‘‘power supply off because a fuse is blown’’. Besides modifiability/extensibility, the usage of Semantic Web ontologies can bring the benefits of context modeling and reasoning capabilities. For example, we can specify a GPS distance calculation with SWRL in order to define a farAwayFromHome context (e.g., 5 miles away from home using the GPS distance calculation formula16), as shown in the following Rule 3. Then this new context can be used to take actions, for example, a surveillance system can be switched to the highest security level with all cameras turned on.
16 How to calculate the distance between two points on the Earth. http:// www.meridianworlddata.com/Distance-Calculation.asp.
159
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Rule 3. A GPS distance calculation rule Thermometer
Thermometer person : hasHomeð?person; ?homeÞ ^ person : inLocationð?person; ?coord1Þ ^ loc : hasCoordinatesð?home; ?coord2Þ ^ coord : latitudeð?coord1; ?lan1Þ ^ coord : latitudeð?coord2; ?lan2Þ ^ swrlb : subtractð?sub1; ?lan1; ?lan2Þ ^ swrlb : multiplyð?squaresublan; ?sub1; ?sub1Þ ^ swrlb : multiplyð?par1; ?squaresublan; 4774:81Þ ^ coord : longitudeð?coord1; ?long1Þ ^ coord : longitudeð?coord2; ?long2Þ ^ swrlb : subtractð?sub2; ?long1; ?long2Þ ^ swrlb : multiplyð?squaresublong; ?sub2; ?sub2Þ ^ swrlb : multiplyð?par2; ?squaresublong; 2809Þ ^ swrlb : addð?parameter; ?par1; ?par2Þ ^ swrlm : sqrtð?distance; ?parameterÞ ^ swrlb : greaterThanð?distance; 5Þ ^ swrlb : StringConcatð?str00; true00Þ
TH03 Server
TH03 Server
Bluetooth
Bluetooth OSGi
OSGi
802.11 (UDP/TCP)
Environment Monitor
802.11 (UDP/TCP)
TH03 Client
OSGi
! sqwrl : selectð?person; ?home; ?distanceÞ ^ farAwayFromHomeð?person; ?strÞ Fig. B.22. Deployment for thermometers in the SmartHome scenario.
To summarize, the Semantic Web technologies and the components built based on them have powerful context modeling and reasoning capabilities on the one hand, and ensure good modifiability and extensibility on the other hand. The usage of OSGi components and pervasive web services in a service oriented computing paradigm helps to achieve seamless integration of different technologies.
2. For the Change Management layer, extend the SeMaPS ontologies to model the application concepts and plans 3. For the Goal Management layer, create application-specific optimization problems and extend the ASL domain descriptions to cover the application if necessary In the following, we describe what needs to be done for each layer in more details.
Appendix B. Implementing a self-managed application To show how to build a self-managed application, we use the following scenario (partially used in the previous sections): John owns a SmartHome system, which is equipped with environment monitoring, self-managed heating, ventilation and home surveillance subsystems. The devices in the smart home system include 5 surveillance IP cameras, and 10 thermometers, equipped with both WiFi and Bluetooth connections. While he is abroad for an academic conference, his home security system automatically turns on to the highest security level when it detects that he is far away from home. Also the whole SmartHome system is self-configured and self-adapted to minimize power consumption. The SmartHome also has an Environment Monitor that measures temperature which is running on a gateway device that connects to the Internet either using WiFi or a wired connection. John has a mobile phone with him and can use it to check that everything is fine at home, this includes retrieving captured pictures from all surveillance IP cameras, and reading the temperature to make sure that his cat is living a comfortable life while he is away. The intended deployment in the scenario is shown in Fig. B.22. The TH03 Client communicates with a number of TH03 Servers on Thermometers through SOAP. Both the client and the servers are OSGi bundles deployed in an OSGi container. The connections between the client and servers can be both IEEE 802.11-based (giving high speed and throughput) and Bluetooth-based (giving longer battery life). These bundles are intended to run in the Component Control layer of LinkSmart and we are interested in managing the type of connections used between clients and servers. Assuming this intended deployment, the steps involved in developing the application are: 1. For the Component Control layer, create the base application. Prepare the application for being controlled if necessary
B.1. Implementing the Component Control layer for the TH03 thermometer The TH03 Server is defined using a WSDL file (as described in Section 4.1 skeleton is generated via the Service Compiler. The application developer furthermore needs to develop the actual functionality, in the TH03 case extracting temperature data to be returned. To facilitate changing server protocol at runtime, the developer may use a set of Service Compiler runtime components that replace a standard OSGi HTTP Service implementation, enabling server protocols to be changed by changing bindings to protocol services. Finally, the developer needs to publish energy level events using the Event Manager (which may be accessed by a bridge from the OSGi Event Admin to the LinkSmart Event Manager). The TH03 Client is also generated from the WSDL description and the developer needs to implement the behavior of the temperature sensing, including using the right protocol when requesting temperatures. The client protocol change logic is supported by skeleton classes generated by the Service Compiler. B.2. Implementing the Change Management layer To enable reasoning on devices and services from the Environment Monitoring, the SeMaPS ontologies are updated with concepts and rules for plans (see Section 4.2). The Change Management layer needs to react to battery level change events from the Component Control layer. To do this a Protocol Reasoner bundle is implemented and deployed (see Fig. B.23). The Protocol Reasoner subscribes to battery level change events, applies level changes to the SeMaPS ontologies and decides the action to take (e.g., re-planning) after plans have been executed.
160
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161
Change and Goal Management Protocol Optimizer
Planner
Protocol Reasoner
Protocol SeMaPS
Optimizer
Reasoner
Event Manager
Environment Monitor
ASL
AQL
Thermometer
TH03 Client
ASL
AQL
TH03 Server
Fig. B.23. Final TH03 deployment. Gray components are tailored/specific to the application.
B.3. Implementing the Goal Management layer To enable application-specific optimization in the Goal Management layer, a Protocol Optimizer bundle is implemented. The bundle reads the necessary information from SeMaPS ontologies (in this case the information includes all devices and current protocols used), constructs an optimization problem, and handles optimization results. To define an optimization problem, a solution needs to be described. In our application, this is a vector of protocol choices per device-device connection involved, and protocol choices are evaluated based on latency and energy usage of a protocol. The problem definition is then used as the basis for multi-objective optimization. In our implementation, we used JMetal framework [63] to realize optimization problems definition and results handling. Finally, the planning domain (for defining ASL operations) needs to be extended. In our case, this involves defining operations for setting protocol properties, resulting in the installation/activation of protocol bundles (see Section 4.3). The final deployment is shown in Fig. B.23.
References [1] J. Kephart, D. Chess, The vision of autonomic computing, IEEE Comput. (2003) 41–50. [2] A. Metzger, C. Cassales Marquezan, Future internet APPS: the next wave of adaptive service-oriented systems?, Towards Service-Based Internet (2011) 230–241 [3] R. Rouvoy, P. Barone, Y. Ding, F. Eliassen, S.O. Hallsteinsen, J. Lorenzo, A. Mamelli, U. Scholz, Music: middleware support for self-adaptation in ubiquitous and service-oriented environments, in: B.H.C. Cheng, R. deLemos, H. Giese, P. Inverardi, J. Magee (Eds.), Software Engineering for Self-Adaptive Systems, Lecture Notes in Computer Science, vol. 5525, Springer, 2009, pp. 164–182. [4] D. Garlan, S.W. Cheng, A.C. Huang, B. Schmerl, P. Steenkiste, Rainbow: architecture-based self-adaptation with reusable infrastructure, Computer 37 (10) (2004) 46–54. http://dx.doi.org/10.1109/MC.2004.175. [5] D. Garlan, B. Schmerl, S.-W. Cheng, Software architecture-based selfadaptation, in: Autonomic Computing and Networking, Springer, 2009, pp. 31–55. [6] J. Kramer, J. Magee, Self-managed systems: an architectural challenge, in: International Conference on Software Engineering, 2007, pp. 259–268. [7] B. Cheng, R. de Lemos, H. Giese, P. Inverardi, J. Magee, J. Andersson, B. Becker, N. Bencomo, Y. Brun, B. Cukic, et al., Software engineering for self-adaptive systems: a research roadmap, Software Eng. Self-Adapt. Syst. (2009) 1–26. [8] K.M. Hansen, W. Zhang, J. Fernandes, OSGi based and ontology-enabled generation of pervasive web services, in: 15th Asia-Pacific Software Engineering Conference (APSEC 2008), Beijing, China, 2008, pp. 135–142.
[9] R. Hall, K. Pauls, S. McCulloch, D. Savage, OSGi in Action: Creating Modular Applications in Java, Manning Publications Co., 2011. [10] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, AddisonWesley, 2012. [11] T.H. Labella, M. Dorigo, J.-L. Deneubourg, Division of labor in a group of robots inspired by ants’ foraging behavior, ACM Trans. Auton. Adapt. Syst. 1 (1) (2006) 4–25. http://dx.doi.org/10.1145/1152934.1152936. [12] S. Dobson, S. Denazis, A. Fernández, D. Gaïti, E. Gelenbe, F. Massacci, P. Nixon, F. Saffre, N. Schmidt, F. Zambonelli, A survey of autonomic communications, ACM Trans. Auton. Adapt. Syst. 1 (2) (2006) 223–259. http://dx.doi.org/ 10.1145/1186778.1186782. [13] J.M. Ottino, Engineering complex systems, Nature 427 (6973) (2004) 399. http://dx.doi.org/10.1038/427399a. [14] A. Ranganathan, R.H. Campbell, Autonomic pervasive computing based on planning, in: Proceedings of International Conference on Autonomic Computing, 2004, pp. 80–87. http://dx.doi.org/10.1109/ICAC.2004.1301350. [15] A. Rao, M. Georgeff, BDI agents: from theory to practice, in: Proceedings of the first international conference on multi-agent systems (ICMAS-95), San Francisco, 1995, pp. 312–319. [16] Y. Diao, J.L. Hellerstein, S. Parekh, R. Griffith, G.E. Kaiser, D. Phung, A control theory foundation for self-managing computing systems, IEEE J. Select. Areas Commun. 23 (12) (2005) 2213–2222. http://dx.doi.org/10.1109/JSAC.2005. 857206. [17] E. Gat, On three-layer architectures, Artif. Intell. Mobile Robots (1998) 195– 210. [18] R.A. Brooks, Intelligence without representation, Artif. Intell. 47 (1-3) (1991) 139–159. http://dx.doi.org/10.1016/0004-3702(91)90053-M. [19] K. Hansen, W. Zhang, M. Ingstrup, Towards self-managed executable petri nets, in: Second IEEE International Conference on Self-Adaptive and SelfOrganizing Systems, SASO’08, 2008, pp. 287–296. [20] R.T. Fielding, R.N. Taylor, Principled design of the modern web architecture, ACM Trans. Internet Technol. 2 (2) (2002) 115–150. http://dx.doi.org/10.1145/ 514183.514185. [21] M. Shaw, D. Garlan, Software Architecture: Perspectives on an Emerging Discipline, Prentice-Hall, 1996. [22] P.T. Eugster, P.A. Felber, R. Guerraoui, A.-M. Kermarrec, The many faces of publish/subscribe, ACM Comput. Surv. 35 (2) (2003) 114–131. http:// dx.doi.org/10.1145/857076.857078. [23] T. Erl, Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall PTR Upper Saddle River, NJ, USA, 2005. [24] N. Mehta, N. Medvidovic, S. Phadke, Towards a taxonomy of software connectors, in: Proceedings of the 22nd International Conference on Software Engineering, 2000, pp. 178–187. [25] W. Zhang, K.M. Hansen, Semantic web based self-management for a pervasive service middleware, in: Second IEEE International Conference on Self-Adaptive and Self-Organizing Systems (SASO 2008), Venice, Italy, 2008, pp. 245–254. [26] W. Zhang, K.M. Hansen, Using context awareness for self management in pervasive service middleware, in: F.M. Nak-Young Chong (Ed.), Handbook of Research on Ambient Intelligence and Smart Environments: Trends and Perspectives, IGI Global, 2011, pp. 248–271. [27] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, J. Stafford, Documenting Software Architectures: Views and Beyond, AddisonWesley, Boston, 2003. [28] K.M. Hansen, W. Zhang, G. Soares, Ontology-enabled generation of embedded web services, in: Proceedings of the 20th International Conference on Software Engineering and Knowledge Engineering (SEKE 2008), Redwood City, San Francisco Bay, USA, 2008, pp. 345–350.
W. Zhang et al. / Knowledge-Based Systems 67 (2014) 143–161 [29] Kriens, P. (Ed), OSGi Service Platform Core Specification. Release 4, The OSGi Alliance, August 2005. [30] P. Dolog, Model-driven navigation design for semantic web applications with the uml-guide, in: Maristella Matera, Sara Comai (eds.), Engineering Advanced Web Applications. [31] W. Zhang, K. Hansen, Semantic web based self-management for a pervasive service middleware, in: Second IEEE International Conference on Self-Adaptive and Self-Organizing Systems, SASO’08, 2008, pp. 245–254. [32] M. Ingstrup, K.M. Hansen, A declarative approach to architectural reflection, in: 5th Working IEEE/IFIP Conference on Software Architecture, WICSA, 2005, pp. 149–158. http://dx.doi.org/10.1109/WICSA.2005.6. [33] M. Ingstrup, K.M. Hansen, Modeling architectural change: architectural scripting and its applications to reconfiguration, in: WICSA/ECSA, IEEE, 2009, pp. 337–340. [34] K.M. Hansen, M. Ingstrup, Modeling and analyzing architectural change with alloy, in: S.Y. Shin, S. Ossowski, M. Schumacher, M.J. Palakal, C.-C. Hung (Eds.), SAC, ACM, 2010, pp. 2257–2264. [35] W. Zhang, K. Hansen, J. Fernandes, J. Schutte, F. Lardies, Qos-aware selfadaptation of communication protocols in a pervasive service middleware, in: Green Computing and Communications (GreenCom), 2010 IEEE/ACM Int’l Conference on & Int’l Conference on Cyber, Physical and Social Computing (CPSCom), IEEE, 2010, pp. 17–26. [36] W. Zhang, J. Schutte, M. Ingstrup, K.M. Hansen, Towards optimized selfprotection in a pervasive service middleware, in: 7th International Conference on Service Oriented Computing, Joint ICSOC & ServiceWave 2009 Conference, Springer LNCS 5900, Stockholm, Sweden, November 24–27 2009, pp. 404–419. [37] D. Mcdermott, The 1998 AI planning systems competition, AI Mag. 21 (2) (2000) 35–55. http://www.aaai.org/ojs/index.php/aimagazine/article/view/1506. [38] W. Zhang, K. Hansen, An evaluation of the NSGA-II and MOCell genetic algorithms for self-management planning in a pervasive service middleware, in: 14th IEEE International Conference on Engineering Complex Computer Systems (ICECCS 2009), IEEE Computer Society, Springer, Washington, DC, USA, 2009, pp. 192–201. [39] K. Geihs, M. Wagner, Context-awareness for self-adaptive applications in ubiquitous computing environments, in: Context-Aware Systems and Applications, Springer, 2013, pp. 108–120. [40] K.M. Hansen, W. Zhang, J. Fernandes, M. Ingstrup, Semantic web ontology for ambient intelligence: Runtime monitoring of semantic component constraints., in: The Internet of Things and Services, 1st International Research Workshop, Sophia Antipolis, French, 2008. [41] W. Zhang, K.M. Hansen, J. Fernandes, Towards openworld software architectures with semantic architectural styles, components and connectors, in: 14th IEEE International Conference on Engineering of Complex Computer Systems, IEEE, 2009, pp. 40–49. [42] S.-W. Cheng, Rainbow: cost-effective software architecture-based selfadaptation, ProQuest, 2008. [43] E. Curry, P. Grace, Flexible self-management using the model-view-controller pattern, IEEE Software 25 (3) (2008) 84–90. [44] B. Motik, U. Sattler, R. Studer, Query answering for OWL-DL with rules, Web Semantics: Sci. Serv. Agents World Wide Web 3 (1) (2005) 41–60. [45] D. Sykes, W. Heaven, J. Magee, J. Kramer, From goals to components: a combined approach to self-management, in: Proceedings of the 2008 International Workshop on Software Engineering for Adaptive and SelfManaging Systems, ACM, 2008, pp. 1–8. [46] W. Zhang, K.M. Hansen, An OWL/SWRL based diagnosis approach in a web service-based middleware for embedded and networked systems, in: The 20th International Conference on Software Engineering and Knowledge Engineering (SEKE 2008), Redwood City, San Francisco Bay, USA, 2008, pp. 893–898.
161
[47] L. Mostarda, D. Sykes, N. Dulay, A state machine-based approach for reliable adaptive distributed systems, in: 2010 Seventh IEEE International Conference and Workshops on Engineering of Autonomic and Autonomous Systems, IEEE, 2010, pp. 91–100. [48] J. Zhang, H. Goldsby, B. Cheng, Modular verification of dynamically adaptive systems, in: Proceedings of the 8th ACM International Conference on AspectOriented Software Development, ACM New York, NY, USA, 2009, pp. 161–172. [49] M. Mikic-Rakic, N. Mehta, N. Medvidovic, Architectural style requirements for self-healing systems, in: Proceedings of the First Workshop on Self-healing Systems (WOSS 2002), ACM, 2002, pp. 49–54. [50] G. Edwards, J. Garcia, H. Tajalli, D. Popescu, N. Medvidovic, G. Sukhatme, B. Petrus, Architecture-driven self-adaptation and self-management in robotics systems, in: Software Engineering for Adaptive and Self-Managing Systems, 2009. ICSE Workshop on SEAMS’09, Springer, 2009, pp. 142–151. [51] S. Malek, M. Mikic-Rakic, N. Medvidovic, A style-aware architectural middleware for resource-constrained, distributed systems, IEEE Trans. Software Eng. (2005) 256–272. [52] S. Malek, M. Mikic-Rakic, N. Medvidovic, A decentralized redeployment algorithm for improving the availability of distributed systems, Comp. Deploy. (2005) 99–114. [53] L. Capra, W. Emmerich, C. Mascolo, Carisma: context-aware reflective middleware system for mobile applications, IEEE Trans. Software Eng. 29 (10) (2003) 929–945. [54] V. Poladian, J. Sousa, D. Garlan, B. Schmerl, M. Shaw, Task-based adaptation for ubiquitous computing, IEEE Trans. Syst. Man, Cybernet. Part C: Appl. Rev. 36 (3) (Special Issue on Engineering Autonomic Systems). [55] P. Oreizy, N. Medvidovic, R.N. Taylor, Runtime software adaptation: framework, approaches, and styles, in: Companion of the 30th International Conference on Software Engineering (ICSE 2008), ACM, 2008, pp. 899–910. [56] R. Taylor, N. Medvidovic, P. Oreizy, Architectural styles for runtime software adaptation, in: Software Architecture, 2009 & European Conference on Software Architecture, Joint Working IEEE/IFIP Conference on WICSA/ECSA 2009, IEEE, 2009, pp. 171–180. [57] F. Milagro, P. Antolin, J. Fernandes, W. Zhang, K.M. Hansen, P. Kool, Deploying pervasive web services over a p2p overlay, in: 18th IEEE International Workshops on Enabling Technologies: Infrastructures for Collaborative Enterprises, WETICE’09, IEEE, 2009, pp. 240–245. [58] D. Weyns, S. Malek, J. Andersson, On decentralized self-adaptation: lessons from the trenches and challenges for the future, in: Proceedings of the 2010 ICSE Workshop on Software Engineering for Adaptive and Self-Managing Systems, ACM, 2010, pp. 84–93. [59] L. Seinturier, P. Merle, R. Rouvoy, D. Romero, V. Schiavoni, J.-B. Stefani, A component-based middleware platform for reconfigurable service-oriented architectures, Software: Practice and Experience 42 (5) (2012) 559– 583. [60] H. Dinh, C. Lee, D. Niyato, P. Wang, A survey of mobile cloud computing: architecture, applications, and approaches, Wireless Commun. Mobile Comput. [61] W. Zhang, L. Chen, Q. Lu, Y. Rao, J. Zhou, Towards an OSGi based pervasive cloud infrastructure, in: 2013 IEEE International Conference on Internet of Things (iThings2013), IEEE, Beijing, China, 2013, pp. 418–425. [62] W. Zhang, L. Chen, X. Liu, Q. Lu, P. Zhang, S. Yang, An OSGi-based flexible and adaptive pervasive cloud infrastructure, Sci. China Inform. Sci. 57 (3) (2014) 1– 11. http://dx.doi.org/10.1007/s11432-014-5070-3. [63] J.J. Durillo, A.J. Nebro, jmetal: a java framework for multi-objective optimization, Adv. Eng. Software 42 (2011) 760–771. http:// www.sciencedirect.com/science/article/pii/S0965997811001219.