Since the sensors can capture events and contexts, we use them as triggers of the service. In this paper, we write sensor-driven service to represent any HNS service triggered by a sensor. For example, let us take Automatic Light Control Service (ALC) in Section 1. The condition ��the brightness is lower than both 200 lx�� can be evaluated by a light sensor. Thus, ALC can be implemented as a program which invokes API Light.on() when the reading of the light sensor becomes less than 200.The sensor-driven services are smart and convenient in the sense that they do not require human operations. However, if many services are deployed in the same environment, they often cause unexpected service chains, as seen in Section 1.
Since the Inhibitors,Modulators,Libraries number of potential service chains grows combinatorially in the number of services, we need a systematic method to detect and resolve the service chains.2.3. Previous Work: Feature Interactions in HNSIn our previous work [3,4], we proposed an object-oriented modeling method to formalize and detect feature interactions in the HNS. In this method, we modeled every appliance (or an environment) as an object with properties and methods. The properties characterize the internal state of the appliance (or the environment), while the methods correspond to the API. Also, we defined every service as a sequence m1(); m2(); ��; mn() of the appliance methods. Then, we defined that a feature interaction between services s1 and s2 Inhibitors,Modulators,Libraries occurs if a method m() of s1 and another method m��() of s2 conflict, either locally on an appliance object (called, appliance interaction) or indirectly via an environment object (called, environment interaction).
However, this method assumed that every service is triggered manually by the user. Thus, the sensor-driven services and the Inhibitors,Modulators,Libraries incidental service chains were beyond the scope.3.?Modeling Sensor-Driven Services and Service Chains3.1. Describing Sensor-Driven Services with ECA RulesIn order to capture the nature of the sensor-driven Inhibitors,Modulators,Libraries services, we here introduce the ECA (event, condition, action) rules [6] for the service description. A sensor-driven service S is defined by S = (ES, CS, AS) whereES is an event that triggers S, which is defined by a condition over a single environment property.CS is an enabling condition to determine the execution of S. On detecting ES, S is actually executed only when CS is satisfied.
Dacomitinib CS is defined by a condition over appliance properties and environment properties.AS is an action to be executed, which is defined by a sequence m1(); m2(); ��; mn() of appliance methods.This model newly involves the event and condition, kinase inhibitor MEK162 compared to the one in the previous work.Figure 1 shows service descriptions of seven sensor-driven services, including the 4 services seen in Section 1 and 3 more described below.Figure 1.Service description of sensor-driven services with ECA rules.