Knowledge base

The application needs to store data about the triggers that it will look out for, the different adaptation techniques that it can use, the rules governing the choice of adaptation techniques, and validation statistics to evaluate the adaptation rules. This section describes how this data is stored. 4.2.4.1.Trigger specification

A change trigger is specified in XML notation and comprises of the change type (CType), change properties (CProp) that represent salient aspects of the system together with their associated types (CPType) and a change expression. The trigger expression is represented by the trigger check (CTCheck), and the limit (CTLimit). Examples of trigger types include service failure, resource failure and requirement change. It is worth mentioning that there are numerous reasons why a service can fail including if the service is not available, or has an error or cannot integrate with the other services. The different reasons are represented as the trigger properties. A

79 resource failure trigger for instance could be memory capacity or CPU time described as the trigger property. This is further expressed as an Integer that should be less than a specified limit.

Figure 4.6 Example of trigger specification and threshold values

The different reasons are represented as the trigger properties. Figure 4.6 shows a code snippet of the XML trigger specification. It shows a specification of a runtime trigger that requires memory to be less than 200,000. Additional triggers can be added as required to accommodate new changes and constraints. To ensure that trigger specifications are valid, they are checked against a change meta model that maintains the rules on valid triggers specifications. Figure 4.7 (a) shows part of the meta model description.

<CMRule>

<CType>Env</CType> <CProp>Data</CProp> <CPType>s</CPType> <CTExpress> <CTCheck>==</CTCheck> <CTLimit>M</CTLimit> </CTExpress> </CMRule> <CMRule>

<CType>QoS</CType> <CProp>Mem</CProp> <CPType>I</CPType> <CTExpress>

<CTCheck>&lt;</CTCheck> <CTLimit>200000</CTLimit> </CTExpress>

</CMRule>

change type: aChangeType property{prop1, prop2, …,propn}

property type: {numeric/string/other} trigger expression: {check, checkLimit} check: {&lt, ==, &gt, !=, and, or, not} ckeckLimit: aThresholdValue or aThresholdLabel

Trigger description

80 (a) Change Meta model

(b) Visualization of the change meta model

Figure 4.7 Change Meta-Model

As users and service providers discover additional change triggers and make updates, the change model is validated against an existing Meta model to ensure consistency. A visualization

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="CRule"> <xs:complexType> <xs:sequence>

<xs:element name="CMRule" maxOccurs="unbounded" minOccurs="0"> <xs:complexType>

<xs:sequence>

<xs:element type="xs:string" name="CType"/> <xs:element type="xs:string" name="CProp"/> <xs:element type="xs:string" name="CPType"/> <xs:element name="CTExpress">

<xs:complexType> <xs:sequence>

<xs:element type="xs:string" name="CTCheck"/> <xs:element type="xs:string" name="CTLimit"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType>

81 of this meta model is shownin the Figure 4.7 (b). Figure 4.8 shows how a SAX Parser (Simple API for XML) transformstheXML document into java readable linear events.

Figure 4.8 SAX Parser for the trigger specification

4.2.4.2. Adaptation Techniques

As mentioned in section 4.1.3, adaptation techniques can be self-configuring, self-optimizing, or self-healing. Adaptation techniques are described in the frame work using XML notation as illustrated in Figure 4.2. Each adaptation technique has a category, a description, and an action. For example, the first adaptation technique displayed is a self-optimizing technique, <ATType>,

which works by recommending a certain workflow pattern, <ATDesc>. For each technique the

course of action may require re-organization of the workflow pattern, selection of alternative services, or the use of a wrapper service. In the first adaptation technique the action is re- organizing the workflow pattern so the other options are empty i.e. <ATAltenative> and

<ATWrapper>. The workflow pattern in this case is simply where the client calls the server. In

the second adaptation technique, which also calls for the re-organization of workflow patterns, a broker is used to call the client that in turn calls the server.

Because adaptation techniques are invoked depending on the triggers detected, it is possible that multiple triggers can be detected that call for conflicting adaptation techniques. For instance

82 the user’s geographic location could indicate that users prefer a high reputation service therefore the adaptation technique should call for reconfiguration with high reputation services. For example if the user is located in a big city in the central business district they often need high reputation services. The user on the other hand could be accessing the application for personal use rather than for business and therefore requests a low cost application. This request would call for reconfiguration with low cost services. High reputation services will often cost more than low reputation services therefore there would be a conflict in the adaptation techniques. In such cases a compromise has to be arrived at through the negotiation process described in section 4.1.4 in order to identify the most acceptable adaptation technique.

4.2.4.3. Adaptation Rules

Adaptation rules match a detected trigger to the corresponding adaptation behavior. For example a detected geo-location can be matched to the corresponding health information (self- configuring adaptation technique), or a detected device matched to the corresponding workflow pattern (self-optimizing adaptation technique). The framework implements these adaptation rules as a set of XML rules. Figure 4.9 shows the adaptation rules created for a self-configuring adaptation technique. These adaptation rules are designed from a preliminary survey conducted to show user preferences i.e. what are the health concerns for users in a certain geographical location.

83

Figure 4.9 Self-Configuring Adaptation Rules

To create rules for a self-optimizing adaptation technique, preliminary experiments were conducted that identified four workflow patterns (i.e. WF1, WF2, WF3 and WF4), representing different performance and efficiency trade-offs. These workflow patterns were chosen to represent different architectural styles such as the Client-Server, Message Bus, and Layered Architecture. When the service-oriented system is orchestrated in different ways, some quality aspects of the system were observed to change as illustrated in Figure 4.10. Based on the user’s runtime resource constraints, the appropriate workflow can be invoked. For example, if a user is accessing information from a PC, then the user has sufficient resources and the system does not need to adapt to address resource limitations in the runtime environment. It simply calls the service- oriented system and runs it as it is. If however a user decided to use a mobile phone instead, the system detects that the user is on a platform that has limited resources in terms of memory and possibly bandwidth and must therefore invoke a workflow that uses minimal system resources. The flexibility of the framework allows the user to add additional workflow patterns.

<DRule>

<LiD>1</LiD>

<LName>Ngumba</LName> <LLatt>-1.2332443</LLatt> <LLong>36.885997</LLong> <LRad>1</LRad>

<DName>Cholera</DName>

<DDesc>Water Borne Disease</DDesc> <DLoc>1</DLoc>

</DRule> <DRule>

<LiD>5</LiD>

<LName>Lancaster University</LName> <LLatt>54.010385</LLatt>

<LLong>-2.787772</LLong> <LRad>5</LRad>

<DName>Lyme Disease</DName>

<DDesc>Infectious disease transmitted by ticks</DDesc> <DLoc>5</DLoc>

84 Resource Workflow CPU Performance (milliseconds) MEMORY (Bytes Allocated) WF1 781 245,472 WF2 675 228,312 WF3 758 226,472 WF4 4271 185,856 (a) (b)

Figure 4.10 Self-optimizing Adaptation Rules

From these experimental results sample adaptation rules were developed. The optimization algorithm, based on SMART, recommends WF3 when a mobile phone is detected for high CPU efficiency. WF2 can be an alternative if WF3 fails although it does not perform as well in terms of CPU time thus a trade of on the High CPU efficiency is experienced. For a PC, WF1 is used. The adaptation rules in XML have symbolic numbers to represent this. For example workflow WF2 has a low value, 1, for low CPU time and a high figure, 3, for high memory capacity.

4.2.4.4. Validation Logs

The adaptation component writes the output of the decision process to a file as logs of decision statistics to be used for validation. For purposes of this research, this output is the detected geo- location (LiD) as well as the users accepted decision (sname) i.e. the desired health information.

An extract of this file is illustrated in Figure 4.11 (a).

The validation logs act as a training dataset that will be manipulated by the EM Clustering algorithm for learning and subsequently updating the adaptation techniques. A second copy of these validation logs is also created and stored in CSV format periodically to enable the

<?xmlversion="1.0"encoding="UTF-8"standalone="no"?> <WFRules> <WFRule> <WFlow>1</WFlow> <ETime>3</ETime> <MCap>4</MCap> </WFRule> <WFRule> <WFlow>2</WFlow> <ETime>1</ETime> <MCap>3</MCap> </WFRule>

85 application to validate the adaptation decision using deep learning. Figure 4.11 (b) illustrates an extract of this file. This is performed offline.

(a) EM Clustering validation logs (b) Deep learning validation logs

Figure 4.11 Validation logs