Proceedings of the Sixth International Conference on Machine Learning and Cybernetics, Hong Kong, 19-22 August 2007

AN APPROACH FOR HARMONIZING CONFLICTING POLICIES IN MULTIPLE SELF-ADAPTIVE MODULES HUA WANG, JING YING College of Computer Science, Zhejiang University, Hangzhou, Zhejiang, China E-MAIL: [email protected]

Abstract: A recent approach to monitor and adapt system behavior at runtime is to decouple one or more external modules and self-adaptive mechanism from the target system. An important challenge arises when more than one such self-adaptive module is employed: how can we ensure that they cooperate without conflicts in a coherent fashion? This paper describes our initial approach for harmonizing conflicting policies in the presence of multiple self-adaptive modules. The main distribution of the paper is to resolve conflicts using an extended ECA rule paradigm to coordinate self-adaptive actions among multiple external modules. The approach shares advantages with other policy languages, i.e., the declarative and domain-independent semantics of policy rules. However, a key benefit of our approach is that both conflicting actions and influence of actions are considered. We focus on the problem of harmonizing self-adaptation capability by detecting and further resolving policy conflicts using Action-Level Meta Rule and Value-level Meta Rule. Finally, this paper illustrates the efficiency of the approach in a VOD system as a case study, and discusses our future plans.

Keywords: Self-adaptation; ECA rule; Policy; Policy conflict

1.

Introduction

Recently, many software systems increasingly need to be adaptive in response to a host of demands such as resource variability, changing user needs, and system faults. One recent approach to monitor and adapt system behavior at runtime is to decouple one or more external modules and self-adaptive mechanism from the target system. The external modules are used to monitor a managed system, detect problems, determine a course of action and carry out self-adaptive actions. This external approach demands to use an appropriate model to reason about the system’s dynamic behavior. However, the dynamic and malleable nature of these managed systems complicates the task of assuring their correctness, as appropriate adaptive behavior has to be

guaranteed over a collection of dynamically changing policies. An important challenge arises when more than one such self-adaptive (SA) module is employed: how can we ensure that these policies cooperate without conflicts in a coherent fashion? If each module works independently, the resulting of actions could lead to conflicts with one another, and possibly bring the managed system into a broken state. As a result, the harmonization process is indispensable in order to enforce nonconflicting actions. There is a rich body of research [1-5] showing significant promise in self-adaptation paradigm. Nevertheless, to the best of our knowledge, there has been little study on how to harmonize conflicting actions in the presence of multiple SA modules. This problem is also presented but remains unresolved in [6]. Our work addresses this problem with a focus on the aspect of carrying out consistent actions among these modules. Three specific technical challenges to address in satisfying this requirement are to 1) formulate desirable actions, 2) identify possible conflicts, and 3) resolve these conflicts. Policy-based management has become popular for controlling a variety of systems [7-9]. Policies guide the behavior of entities in a system without requiring manual intervention. Moreover, the policy-driven approach decouples the harmonization logic from the managed system, hence can reason about the harmonization logic. Although several existing policy languages could be applied, such as [10-12], a different approach is required in our context for the following reasons. Firstly, a much more dynamic set of policies is required as any SA module may be invoked to adapt any component in the target system. Secondly, policies need to be very expressive but lightweight and easily written and extensible. However, most policy languages are designed only for programmers or technical experts. Finally, a policy expression using XML can be more easily parsed by external tools. In this paper, we propose a harmonization method using extended ECA (Event-Condition-Action) rule paradigm to formulate policies for the sake of addressing the challenge as

1-4244-0973-X/07/$25.00 ©2007 IEEE 2379

Proceedings of the Sixth International Conference on Machine Learning and Cybernetics, Hong Kong, 19-22 August 2007 mentioned before. There are at least three good reasons for using the extended ECA rule paradigm to harmonize conflicts in our context: 1) it is easily written and understood by end-users, 2) it is also conveniently modified and analyzed formally, and 3) it is very expressive to formulate relationship of multiple SA modules. The remainder of this paper is organized as follows: Section 2 introduces the syntax and semantic of extended ECA rules. We discuss the policy conflict detection and conflict resolution in our context in Section 3. In Section 4, we report on a case study on the harmonization method and Section 5 discusses conclusions and directions for future works. 2.

The theoretical basis of extended ECA rule

This section introduces the syntax and semantic of extended ECA rule at first, then discusses the definitions of policy conflict. Finally, two types of Meta Rule are introduced to resolve conflicts. 2.1. Definitions of ECA rules The theoretical basis for ECA rule is given in an extended version and tailored to our immediate purposes. We redefine and extend some primitive definitions of ECA rule as follows: Definition 1. ECA rules based harmonization architecture for resolving conflicting policies in multiple SA modules (ECAHA) is a triple < P, D,W > , where P = {r | i = 1, 2, K , n} is policy rules for self-adaptive i actions defined as follows; D is a detector used to detect and resolve conflicts by reasoning about P; and W is an event and rule warehouse. Definition 2. A policy rule is a four-tuple R =< E , C , A, PV > and expressed as sets of rules using the form: ( on event if condition triggers action ) p property value , where event clause (E) may have attributes of specific type, such as integer, float, string, etc. An event is a function: χ → {true, false} , χ = {e1ω K ω en | ω ∈ {∪, ∩}} ,

where ω must be assigned the same value in a single basic event, i.e., ∪ or ∩ , representing the simultaneous occurrence of the n events and the occurrence of an instance of one of the ei s at time of t , respectively. Each ei is a set of symbol with

n

e ( p1 = v1 , ..., p n = vn ) ,

parameters and each

pi

where e is event is a constant or a

(C)

is

where µ while

a

function

= p1γ ...γ p n , γ ∈ {∪, ∩, ¬} .

,

µ → {true , false}

And γ is a logic operator,

is a predicate of the form c1ϕ c2 , where ϕ is a

pi

comparison operator such as ≠ , = , < , > , etc.

c1

and

c2

can be a constant or a variable. The action clause (A) represents the high-level abstraction actions that are enforced to adapt the target system. Actions are formulated as a set of a ( p1 , ..., pn ) , where a is action symbol and each pi

is a constant or a variable vi with an appropriate type

that appears in the event clause of the policy rule. The property value clause (PV) is a predicate indicating the attribute value of a component, a system or other properties. The attribute value represents the influence on an entity of the adapted system after executing an ECA rule. And PV is optional. Definition 3. Events appearing in a policy rule can be formulated by two types of events, basic event and compound event. Basic events are formulated in the event clause of Definition 2, while compound event are made up of combination of basic or other compound events using the following operators: Table 1 Event Operators Conjunction Disjunction Mutual exclusive Sequence Negative Quantification

AND(e1,e2,…en) OR(e1,e2,…en) XOR(e1,e2,…en) SEQ(e1,e2,…en) NEG(e) ANY(n,e)

Definition 4. An action could be a complex one using the following constructor: (1)Fellow(a1,a2) means action a2 must be performed immediately after action a1;(2)Alternative(a1,a2) implies either action a1 or action a2 can be performed, but not both; and (3)Iteration(a1) represents the sequence of zero or more enforcement of action a1. Definition 5. For policy rules P, APE(P) is all possible A

events occurring simultaneously in P, and 2 denotes the set of all finite sets of triggered actions by P. The semantic of each rule in P can be defined as a transfer function

f

p

: APE ( P ) → 2 P

Definition 6. AMR

A

. are all actions derived from

2

A

by resolving policy conflicts using D in ECAHA to eliminate all conflicting actions.

variable vi with an appropriate type. The condition clause

2380

Proceedings of the Sixth International Conference on Machine Learning and Cybernetics, Hong Kong, 19-22 August 2007 2.2. Definitions of policy conflict and conflict resolution Some conflicting actions must be deleted from P

construct all permitted actions set AMR

2

A

because

to 2

A

possibly contains conflicting actions. It is obvious that 2

A

P

⊇ AMR

.We say a conflict appears if the output of a

policy contains a set of actions specified by the policy maker that cannot occur simultaneously. That is, we can capture the conflicts as violations of action constraints. However, conflicts will still arise if the output actions bring the system into an inconsistent status. To cope with this situation, we further propose value constraint used to resolve conflicts. Conflicts are resolved by defining two types of meta rules: one is Action-Level Meta Rule that specifies the constraint relationship between actions, and the other is Value-Level Meta Rule that expresses the constraint relationship between resulting attribute values after executing rules. Definition 7. Action-Level Meat Rule (AMR): given actions a1,a2 ∈ 2 A , there are three predicates as follows:(1)Sequence(a1,a2): if a1 is performed, then a2 is performed;(2)Exclusive(a1,a2): a1,a2 cannot be performed simultaneously; and (3)Precedence(a1,a2): if a1,a2 are triggered simultaneously, then a1 is to take precedence to be performed. AMR can be defined as “ do action if condition ”, where action is a combination of the above three predicates: amr1,…,amrn. If condition holds, amri is one of terms defined in Table 2. Table 2 Three predicates of AMR Sequence(a1,a2)

P P a1 ∈ AMR ╞ a2 ∈ A MR

Exclusive(a1,a2)

P P ) ¬(a1 ∈ AMR & a2 ∈ AMR

Precedence(a1,a2)

P P a1 ∈ 2 A & a2 ∈ 2 A & a2 ∈ AMR ╞ a1 ∈ A MR

Definition 8. Value-Level Meta Rule (VMR): is a predicate denoting the resulting attribute value is not permitted to be arrived at. VMR is expressed as ¬( v1 & K & v2 ) , where vi is a predicate and could be the attribute value of a component, a system or other properties. Definition 9. Conflict resolution based on AMR is defined as a transfer function: ' A P A f p : 2 → AMR iff for each a ∈ 2 , satisfies AMR

. The output

is all actions without conflicts. Definition 10. A conflict resolution rule based on VMR

is defined as “ assign evalue if condition ” and this can be read: if condition is true, then the attribute value of a component, a system or other properties is assigned the evaluated value. This means that the selected policy rule to be executed will be the one that has the identical “evalue” to PV in the ECA rule. For example, consider the following policy rules: ( on Connect if (less ( BW , thresh )) triggers RestrictService ) p ServiceMode ( content , text ) ( on Connect if ( greater ( Sum ( conn ), 10)) triggers ReceiveService ) p ServiceMode ( content , video )

and the value constraint: ¬( ServiceMode(content , text ) & ServiceMode(content , video))

where BW means bandwidth. A conflict occurs when a connect is requested. There is a resolution rule based on VMR presented below: assign( ServiceMode(content , text )) if (Occ(Connect ) &

ServiceMode(content , text ) & ServiceMode(content , video))

The rule suggests that when a Connect event occurs, the first one of the two conflicting rules will be preferentially executed as it accords with the PV predicate of “ServiceMode(content,text)”. Accordingly, we can generate nonconflicting actions by using a two-step method. Firstly, initial nonconflicting action set is generated by using the transfer function

' f p applying

AMRs. Secondly, if the initial action

set does not satisfy VMRs, then further conflict resolution is demanded by applying conflict resolution rules defined in Definition 10. 3.

Policy conflict management

This section firstly discusses various categories of the policy rules to be applied in such a system that is monitored and adapted by multiple external SA modules. Policy conflict classification is introduced in Section 3.2. In Section 3.3, we propose three distinct strategies on when to detect conflicts. Finally, a harmonization architecture is provided in Section 3.4. 3.1. Software metrics and policy rule classification The self-adaptation modules need to interpret the information obtained from the managed system to make appropriate decision. The information can be addressed from a variety of metrics including performance, resource utilization, reliability, security and cost [13], etc. We keep the details of metrics (focused by SA modules) hidden, as the software metrics that we deal with are situated at the higher level of abstraction. We classify policy rules into five categories in our context, i.e., System Policy, User

2381

Proceedings of the Sixth International Conference on Machine Learning and Cybernetics, Hong Kong, 19-22 August 2007 Policy, Resource Policy, Security Policy and Cost Policy. Detailed definitions are not presented as space is limited. 3.2. Policy conflict classification Multiple SA modules may manage the same entities, either as several tasks share the entities or as different self-adaptive functions are assigned to different roles. This may generate a conflict when the self-adaptive operations to be performed on the target object are not independent. For instance, an update operation may require a service to be temporarily shut down while a GetConfig operation may require it to be in service [8]. Unlike the classification method introduced in [14], we consider conflicts presented in multiple SA modules can be classified into four categories as defined below. (1) Space Modality Conflict It occurs when two or more policy rules in different SA modules operate the same set of entities and attempt to enforce different and conflicting policies over them. It is also defined in [9]. The policy in Section 2.2 is an instance of this kind of conflict. (2) Cost Conflict When multiple SA modules update the target system with a certain component or several components using different policies at the same cost, a Cost Conflict occurs if the different SA module holds the different viewpoint whether the cost is high or low. Also, costs could arise from other actions such as adjusting the size of the server pool. As an example, the following policy rules trigger a Cost Conflict while adding a new component to the target system (the first rule believes the cost is low, which calls for reconfiguration of the system and subsequently halt of the system; the second rule considers the cost is high, which results in no actions and keeps the system running): ( on AddComponent if Cost = $200 triggers Reconfig ) p status ( sys , halt ) ( on AddComponent if Cost = $200 triggers Null ) p status ( sys , run )

and the value constraint: ¬( Status ( sys, run) & Status ( sys, halt ))

(3) Resource Provision Conflict It relates to that an administrator specifies how any resource will be shared among multiple SA modules or how over-provisioned resource is to be reduced. A typical situation is that the sum of the specified resource for various SA modules should not exceed the allowed value of 100%. For instance, consider a policy rule and a value constraint as follows: on Connect if true triggers AllocateBW ( Req1 = BW1 , … , Req m = BWm ) ¬( greater ( Sum ( BW , … , BW )), 100%)

1

m

where BW means bandwidth. It is evident that a conflict arises since the total of BW cannot exceed 100%.

(4) Service Conflict Service Level Agreements (SLAs) are established between a service provider and its customers to formally define the expectations and obligations that exist in their business relationship [10]. SLAs can also be defined between multiple peer service providers who collaborate to provide an integrate service that spans multiple administrative domains. QoS (Quality of Service) provides the demonstration of a metric of SLAs. A Service Conflict occurs if services provided by variant providers cannot achieve consistent services. 3.3. Policy conflict detection The fundamental purpose of detecting a conflict is to analyze the semantic of the policy expressed using extended ECA rules in order to identify conflicts occurring in a system. It is important to provide all potential action constraints and value constraints since we can capture the conflicts as violations of the two types of constraints. Generally speaking, the goals of conflict detection are described as follows: 1) to identify all possible conflicts in the light of the defined action constraints and value constraints; 2) to group the conflicts based on its category; 3) to correspond with a conflict resolution process; and 4) to decide how to resolve conflicts in an appropriate fashion. Conflict detection and resolution can be computationally intensive, time-consuming and hence, prohibitive. As a result, a balanced strategy must be decided on when to detect and further resolve conflicts. We propose three distinct strategies on when to detect conflicts. (1) Passive Conflict Detection It is only invoked when there are explicit adaptive actions taken by SA modules. For example, a new user is added in the context of VOD (Video on Demand). At this time, a resource-sensitive SA module prefers to increase the size of the server pool, while a composite SA module might instead want to reallocate the bandwidth among active users. If each SA module adapts the VOD system simultaneously, a Space Modality Conflict may arise. This passive detection is also considered as reactive conflict detection. (2) Voluntary Conflict Detection It is triggered once the sensed information of the context changes. That is, the detection technique automatically and proactively detects conflicts depending on the current context of users. For instance, there are Gold Service and Silver Service performed by different SA modules at the same time at the peak of transactions. Conflict detection is enforced to identify whether there is a Service Conflict as the two services are assigned to different bandwidth.

2382

Proceedings of the Sixth International Conference on Machine Learning and Cybernetics, Hong Kong, 19-22 August 2007 (3) Predictive Conflict Detection It predicts future conflicts based on the history behavior of multiple SA modules. The detection could be useful only if adaptation actions taken by these SA modules can be predicted correctly. However, redetection will be needed if the behavior of certain SA module is not anticipated. If a policy conflict is detected by employing one of the above techniques, the subsequent step is to resolve the conflict. We can use the two-step method presented in Section 2.2 to address the problem. 3.4. Harmonization architecture Our approach to address the core issue of reaching a single, nonconflicting decision among multiple SA modules can be summarized in a harmonization architecture, shown in Figure 1.

manage a single system. To validate the resulting self-adaptive harmonization, we choose a VOD system as an example target system. The VOD system was a good candidate for applying multiple SA modules as it did not dynamically adapt originally. The performance of our approach have been measured based on our current implementation: two simulative SA modules are built using Java RMI with JDK 1.5. On the other hand, policy rules, action constraints and value constraints have been encoded using the XML. We choose to use XML as we believe this language can be more easily parsed by external tools and enhance interactions between SA modules and applications. Tests were performed on IBM ThinkPad laptop equipped with 512MB RAM, Intel Pentium M processor rated at 1GHz. The operating system is Microsoft’s Windows Professional. We believe this configuration is appropriate to estimate the performance of the approach, as it does not outperform the currently available devices. The first SA module, called SAbw, aims to adjust the quota of bandwidth allocated to two different service levels, i.e., Gold Service and Silver Service respectively. The adaptation is enforced at the peak of transaction. The second SA module, called SApool, focuses on adapting the size of connection pool and total bandwidth that is used by the VOD system. Policy conflicts may occur depending on the service request. In this simple scenario, we illustrate the basic overheads introduced by the conflict resolution mechanism as depicted in Figure 2. 3000

Figure 1. Harmonization architecture

Without conflicts With conflicts

2500

Each SAi gets different metrics of the context from the managed system using the Sensor component. The Common Event Broker constructs events based on the sensed information and then intercepts events on demand from the context. If an event is new, then it is loaded into Event and Policy Warehouse used to store event groups and policy sets. These events are accumulated into a buffer that is maintained by an Aggregator. The aggregator groups events from the buffer into queues, and then selects appropriates queues as the input of the Conflict Detector. Using AMR and VMR rules, the conflict detector identifies conflicts, if any, and all permitted actions are generated applying Conflict Resolution Rules, subsequently returned. Finally, the target system is adapted using resulting actions.

We can conclude that the harmonization mechanism adds a slight overhead over the situation where there are no conflicts.

4.

5.

Case study

Time(ms.)

2000

1500

1000

500

0

0

5 10 Number of Policies

15

Figure 2. Impact of conflict resolution approach

To evaluate our approach, we performed a simple case study where we harmonize two simulative SA modules to

2383

Conclusions and future works In this paper we have presented a harmonization

Proceedings of the Sixth International Conference on Machine Learning and Cybernetics, Hong Kong, 19-22 August 2007 architecture and approach that address the challenge of resolving conflicting polices when more than one SA module is employed. Our approach ensures multiple SA modules cooperate in a consistent fashion to adapt a system by using extended ECA rules. We illustrate our approach by two simulative SA modules in a case study. The experimental results show the efficiency of our approach. However, unresolved issues remain discussed as follows. We believe that metrics from software artifacts are somewhat simple at the high level of abstraction and hence might be not enough to write complicated policies to cope with large-scale applications. We need to employ more sophisticated mechanism to address this problem in future. Another relevant problem is conflicts may result from the policy refinement that is being studied as a means of realizing higher-level policies using lower-level policies. Policy refinement remains a wide open research issue. We believe that capturing and generating action constraints and value constraints automatically are beneficial to the detection and analysis of policy conflicts. Additionally, specifying the new action constraints and value constraints requires evaluation once at specification time, when new policy rules are added. Planning techniques from Artificial Intelligence are the preferred approach. We plan to carry out more performance studies which are needed to ensure that the model does scale to complicated environments. Also, self-optimizing and self-healing capability from IBM’s autonomic computing initiative may be added to the approach. This presents a challenge for future research. Acknowledgements This work has been partially supported by the Fok Ying Tung Education Foundation (No.94030). References [1] J. C. Georgas, A. van der Hoek, and R. N. Taylor, “Architectural Runtime Configuration Management in Support of Dependable Self-Adaptive Software”, Proceeding of the ICSE 2005 Workshop on Architecting Dependable Systems (WADS), pp. 1-6, May 2005. [2] J. C. Georgas and R. N. Taylor, “Towards a Knowledge-Based Approach to Architectural Adaptation Management”, Proceeding of ACM SIGSOFT Workshop on Self-Managed Systems (WOSS), pp. 59-63, October 2004.

[3] J. Zhang and B. H. C. Cheng, “Using temporal logic to specify adaptive program semantics”, Journal of Systems and Software, vol. 79, pp. 1361-1369, 2006. [4] T. Seceleanu and D. Garlan, “Developing adaptive systems with synchronized architectures”, Journal of Systems and Software, vol. 79, pp. 1514-1526, 2006. [5] C. Shang-Wen, D. Garlan, and B. Schmerl, “Architecture-based Self-Adaptation in the Presence of Multiple Objectives”, Proceeding of the ICSE 2006 Workshop on Software Engineering for Adaptive and Self-Managing Systems (SEAMS), 2006. [6] C. Shang-Wen, H. An-Cheng, D. Garlan, B. Schmerl and P. Steenkiste, “An architecture for coordinating multiple self-management systems”, Proceeding of Fourth Working IEEE/IFIP Conference on WICSA, pp. 243-252, 2004. [7] K. J. Turner and L. Blair, “Policies and conflicts in call control”, Journal of Computer Networks, vol. 51, pp. 496-514, 2007. [8] E. C. Lupu and M. Sloman, “Conflicts in policy-based distributed systems management”, Software Engineering, IEEE Transactions on, vol. 25, pp. 852-869, 1999. [9] N. Dunlop, J. Indulska, and K. Raymond, “Methods for conflict resolution in policy-based management systems”, Proceeding of Enterprise Distributed Object Computing Conference, pp. 98-109, 2003. [10] L. Lymberopoulos, E. Lupu, and M. Sloman, “An adaptive policy-based framework for network services management”, Journal of Network and Systems Management, vol. 11, pp. 277-303, 2003. [11] J. Lobo, R. Bhatia and S. Naqvi, “A Policy Description Language”, Proceeding of AAAI Conference, pp. 291-298, July 1999. [12] J. Chomicki, J. Lobo and S. Naqvi, “Conflict resolution using logic programming”, Knowledge and Data Engineering, IEEE Transactions on, vol. 15, pp. 244-249, 2003. [13] V. Lakshmi Narasimhan and B. Hendradjaya, “Some theoretical considerations for a suite of metrics for the integration of software components”, Journal of Information Sciences, Vol. 177, Issue 3, pp. 844-864, February 2007. [14] E. Syukur, S. Wai Loke and P. Stanski, “Methods for Policy Conflict Detection and Resolution in Pervasive Computing Environments”, Proceeding of 14th International World Wide Web Conference, 2005.

2384