In a volatile service composition running on a mobile device, services that are participating might appear and disappear at a high rate. We need a taxonomy that describes the possible fault types that can occur in a service participating in the composition at runtime and the effects that are observed as a result of those faults. These observed effects are at the application level and so can be dealt with using a model at runtime that is causally connected to the application.
We have used a fault taxonomy for web service composition proposed by K.S. May Chan et al.(Chan et al., 2007a) as discussed by us in Chapter 2. From the taxonomy, we have identified those ‘Observed Effects’ of faults that will affect services participating in a service composition running on a mobile device that are triggered by volatility inherent in a ubiquitous computing system (see Table 4-1). Thus, this table extends the taxonomy of Chan et al. by mapping the
faults identified by them to the properties of volatility discussed by Coulouris et al.(Coulouris, 2012).
We use the following definitions from Chan et al (Chan et al., 2007a) for possible classes of fault types because we want to extract out only those observed effects that are caused by faults due to volatility. We want our model at runtime to support adaptation to faults that are triggered by volatility only. For example, we do not consider development faults because such faults can be triggered even in the absence of volatility.
a) Physical Faults: These are caused by failures in the network medium or failures on the server side. Communication infrastructure exceptions and failures in correct operation of hosting server’s middleware are also included.
b) Interaction faults: Services forming part of the composition interact with each other. An interaction fault occurs if a service fails frequently or unacceptably severely.
c) Interaction-content fault: This is a type of interaction fault that includes incorrect service, misunderstood behavior, response error, QoS and SLA faults.
In Table 4-1, we first map the ‘Observed Effects’ to those of the above classes of fault types that can cause them as discussed in Chan et al.’s taxonomy(Chan et al., 2007a). Next, we map this fault type itself to the type of volatility (Coulouris, 2012) that can trigger it. Notice that besides volatility, other causes may also trigger the faults. Nevertheless, in this thesis we wish to focus only on volatility in order to answer our research question.
We now explain this mapping:
i. According to Chan et al.’s taxonomy, an ‘Unresponsive Service’ observed effect is caused by one of the following faults as shown in the Table 4-1: Unavailability fault, Timeout fault, Quality of Service (QoS) fault. Next, we map these faults to the volatility properties discussed by Coulouris et al. We identify that the Unavailability and Timeout faults could be caused by volatility resulting from device and communication failures, variation in properties of communication, or destruction of logical communication relationships between software components resident on the devices. A QoS fault could be caused by a slow network because of variation in properties of communication such as bandwidth.
ii. In Chan et al.’s taxonomy, ‘Incorrect Results’ observed effect is caused by one of the following faults as shown in the Table 4-1: Timeout fault, Quality of Service (QoS) fault. Next, we map these faults to the volatility properties discussed by Coulouris et a l.
We identify that the Timeout fault could be caused by volatility resulting from device and communication failures, variation in properties of communication, or destruction of
logical communication relationships between software components resident on the devices. A QoS fault could be caused by a slow network because of variation in properties of communication such as bandwidth.
iii. An ‘Incoherent Results’ observed effect in Chan et al.’s taxonomy is caused by Quality of Service (QoS) fault. Next, we map this fault to the volatility properties discussed by Coulouris et al. We identify that the QoS fault could be caused by volatility resulting from a slow network because of variation in properties of communication such as bandwidth.
iv. According to Chan et al.’s taxonomy, a ‘Slow Service’ observed effect is caused by one of the following faults as shown in the Table 4-1: Unavailability fault, Incorrect Order fault, Timeout fault, Quality of Service (QoS) fault. Next, we map this fault to the volatility properties discussed by Coulouris et al. We identify that the Unavailability and Timeout faults could be caused by volatility resulting from device and communication failures, variation in properties of communication, or destruction of logical communication relationships between software components resident on the devices. Incorrect Order and QoS fault could be caused by a slow network because of variation in properties of communication such as bandwidth.
v. An ‘Outdated Results’ observed effect in Chan et al.’s taxonomy is caused by Quality of Service (QoS) fault. Next, we map this fault to the volatility properties discussed by Coulouris et al. We identify that the QoS fault could be caused by volatility resulting from a slow network because of variation in properties of communication such as bandwidth.
TABL E 4 -1 : MAPPIN G BETWEEN OB SER VED EFFEC TS AN D VOL ATIL ITY.
1.Unresponsive Service Unavailability Fault (Physical Fault), Timeout (Interaction Fault), QoS
2. Incorrect Results Timeout (Interaction Fault), QoS(Interaction-Content fault)
3.Incoherent Results QoS(Interaction-Content fault) Slow network: Variation in
properties of communication such as bandwidth
4.Slow Service Unavailability Fault (Physical Fault), Incorrect Order(Interaction fault),
5.Outdated Results QoS (Interaction-Content fault) Slow network: Variation in
properties of communication such as bandwidth
We assume that a Service Component Architecture (SCA) (Marino and Rowley, 2010) like description of all the services and the service composition is being maintained by a system outside our system boundary. SCA is an architectural specification of a structural composition model for Service –Oriented- Architecture (SOA)(Curbera, 2007). Structural Composition is a model of service composition in SOA which identifies components of a composition that offer services and how those components are connected together (Curbera, 2007), (Marino and Rowley, 2010).
Now that we have mapped ‘Observed Effects’ of Chan et al. to the types of volatility of Coulouris et al. that can trigger a fault, we identify how volatility also effects the frequency, order, and number of these ‘Observed effects’ on a system over and above what we might see in a non-volatile system.
i. The ‘Observed Effects’ on a service due to volatility occur at a high rate at runtime.
ii. In general, we cannot determine in advance the order in which services will suffer from an ‘Observed Effect’ at runtime- essentially they suffer from an ‘Observed Effect’ in an ill-structured fashion.
iii. There are an infinite number of possible reconfigurations of a service composition at runtime. These are triggered by a possibly infinite number of applications of the
‘Observed Effect’ to a composition.
In the next few sections we will describe how we have utilized the above mappings of Table 4-1 in order to design our model at runtime.