Content uploaded by Bo Cheng
Author content
All content in this area was uploaded by Bo Cheng on Jul 28, 2018
Content may be subject to copyright.
2082 IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 25, NO. 4, AUGUST 2017
Situation-Aware Dynamic Service Coordination
in an IoT Environment
Bo Cheng, Member, IEEE, Ming Wang, Shuai Zhao, Zhongyi Zhai, Da Zhu, and Junliang Chen
Abstract— The Internet of Things (IoT) infrastructure with
numerous diverse physical devices are growing up rapidly,
which need a dynamic services coordination approach that can
integrate those heterogeneous physical devices into the context-
aware IoT infrastructure. This paper proposes a situation-aware
dynamic IoT services coordination approach. First, focusing on
the definition of formal situation event pattern with event selec-
tion and consumption strategy, an automaton-based situational
event detection algorithm is proposed. Second, the enhanced
event-condition-action is used to coordinate the IoT services
effectively, and also the collaboration process decomposing algo-
rithm and the rule mismatch detection algorithms are proposed.
Third, the typical scenarios of IoT services coordination for smart
surgery process are also illustrated and the measurement and
analysis of the platform’s performance are reported. Finally,
the conclusions and future works are given.
Index Terms—Situation-aware, dynamic, service coordination,
IoT environment.
I. INTRODUCTION
ALONG with the rapid development of embedded comput-
ing and new sensor technologies, the goals of information
and communication technology have evolved to include the
ability to connect to anyone or any object at any time, from
any place. People wish to closely relate the virtual world
established by computation facilities to the physical world,
so that computation equipments can be seamlessly integrated
into their lives and to provide more intelligent universal ser-
vices through real-time sensing and dynamic interaction with
the physical world. It is within this context that the Internet
of Things (IoT) technology has emerged, in which a large
number of physical entities are interconnected and integrated
into the information space, and the supply and consumption
of information are realized through the Internet [1]–[4]. In this
respect, successful solutions are expected to embody a huge
number of smart objects identified by unique addressing
schemes providing services to end-users through standard
communication protocols. Accordingly, the huge numbers of
objects connected to the Internet and that permeate the envi-
ronment we live in, are expected to grow considerably, causing
the production of an enormous amount of data that must be
processed and made available in a continuous, efficient, and
easily interpretable manner. A massive number of devices
Manuscript received January 3, 2016; revised December 25, 2016; accepted
February 13, 2017; approved by IEEE/ACM TRANSACTIONS ON NETWORK-
ING Editor A. X. Liu. Date of publication August 1, 2017; date of current
version August 16, 2017. This work was supported by the National High-tech
Research and Development Program of China (863 Program) under Grant
2013AA102301. (Corresponding author: Bo Cheng.)
The authors are with the State Key Laboratory of Networking and
Switching Technology, Beijing University of Posts and Telecommunications,
Beijing 100876, China (e-mail: chengbo@bupt.edu.cn; wangming_bupt@
bupt.edu.cn; zhaoshuaiby@bupt.edu.cn; chjl@bupt.edu.cn).
Digital Object Identifier 10.1109/TNET.2017.2705239
with different capabilities such as sensors, actuators, smart
objects, and servers can interconnect and give rise to the
development of compelling services and applications. Each
IoT device can be perceived as an edge-node of a cyber-
physical ecosystem with the ability to dynamically cooperate
and make its service resources available in order to reach a
complex goal, i.e., the execution of one or more tasks assigned
to the network. The acquisition, distribution and integration
of large-scale, multi-source information, along with the need
to appropriately respond to dynamic changes in the physical
world in real time, which pose new technological challenges to
the provision of IoT services. First, the heterogeneous nature
of sensory devices require an abstraction from the lower device
level layer to a common access layer for other applications,
which need an abstraction instance as it has the capability to
gather and connect the data from different sensor platforms.
Second, with the huge amounts of data to be made available
from the edge of the sensor networks or electronic devices
to the applications to be available anywhere at any time,
how to dispatch, assemble/integrate those sensory data among
the distributed, loosely coupled information systems across
different business fields or even organizations. Third, support
the rapid coordination of manpower and business processes to
interact with physical entities across business domains, or even
across organizations, thereby endowing the IoT service system
with the characteristics of real-time dynamic variation.
In recent years, researchers have incorporated Service-
Oriented Architecture (SOA) [5]–[7] technology into IoT ser-
vice coordination to resolve the heterogeneity of services
and physical entities to facilitate interoperability and dynamic
service discovery. However, the traditional SOA standards
and technologies are designed primarily for the integra-
tion of enterprise-class heavyweight services in an Internet
environment, and the traditional SOA is unable to resolve
dynamic multi-service collaboration issues that are triggered
by complex events. Primarily, SOA begins by decoupling
the system, focuses on decomposing the entire application
into a series of independent services and defines various
standards and infrastructures to facilitate the reuse of these
services; i.e., to allow them to be used easily by applications
on various platforms. The resolution must be achieved by
the IoT service provider using a mechanism that precisely
coordinates the real-time interaction and collaboration between
multiple coupled systems. Therefore, another technical chal-
lenge faced by IoT service providers is the approach used
to resolve flexible and distributed service collaboration across
business domains, or even across organizations. Event Driven
Architecture (EDA) [8]–[10] uses an asynchronous event com-
munication mode, whereby the generation of an event can
trigger the concurrent execution of one or more services. When
1063-6692 © 2017 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
CHENG et al.: SITUATION-AWARE DYNAMIC SERVICE COORDINATION IN AN IoT ENVIRONMENT 2083
a certain event occurs, different services can be triggered
automatically, endowing the system with the capability of real-
time sensing and rapid response to events in a loosely coupled,
distributed computing environment. In general, pure SOA and
EDA have their own limitations, but could complement each
other; that is, a certain degree of service coordination can be
achieved among mutually independent service systems through
the event mechanism. This complementarity is well suited
to the characteristics of IoT, which has a characteristics for
high autonomy inside a domain and efficient coordination
across domains; furthermore, it both improves the real-time
response to constantly changing business requirements and
minimizes the impact on the existing application system to
allow a large-scale, distributed IoT service application to be
easily developed and maintained. In this paper, an event-driven
and service-oriented situation-aware IoT service coordination
approach is proposed, and the on-demand distribution of
situation-aware information and dynamic, event-driven service
coordination are implemented by integrating the advantages of
SOA and EDA. The contributions of this paper are as follows:
1) A comprehensive and systematic event-driven, service-
oriented IoT service coordination platform architecture,
which effectively integrates the advantages of SOA
and EDA, is proposed. SOA technology is used to
resolve interoperability issues among large numbers of
heterogeneous services and physical entities as well as
application reusability issues in a large-scale distributed
IoT environment; EDA technology is used to address
the problem of the cross-business-domain, or even cross-
organization, on-demand distribution of sensed informa-
tion as well as the problem of dynamic event-driven
service coordination.
2) A situational event pattern is designed. Various types of
information monitored by sensors are defined as atomic
events, and a series of concise and strictly temporal event
operators are used to define complex event pattern with
rich semantics; simultaneously, flexible event selection
and consumption strategies are provided for users to
create flexible configurations, and an automaton-based
situational event detection algorithm is proposed.
3) A situational event-driven service coordination behavior
model is proposed. This model is based on an extended
event-condition-action (ECA) trigger mechanism, which
translates the service global process model into a series
of local processes and event flow models to generate a
set of executable ECA rules and define a coordinated
execution sequence for global services to implement
situational event-triggered active coordination for the
global coordination process.
The remainder of the paper is organized as follows. The
related work to this study is briefly reviewed and dis-
cussed in Section II. Section III describes the application
scenario. Section IV describes the proposed architecture.
Finally, conclusions and possibilities for future work are
described in section V.
II. RELATED WORKS
A. Context-Aware Service for Internet of Things
In IoT environment, the context-aware information is nor-
mally collected and extracted from sensor data, and can be
used to improve the service quality of IoT [11]. Reference [12]
proposes a new context-aware paradigm for IoT, called Con-
text of Things, that can acquire the context information from
two aspects of user’s description and sensor reports. Based
on the Context of Things, a smart IoT service is imple-
mented to analyze the thing’s need intelligently. Reference [13]
proposes a context-aware approach for trust management of
IoT service network. This approach can dynamically predict
trustworthiness of a service provider based on its behavior
in response to context changes. To deal with the resource-
constraints, scalability, mobility and real-time requirements of
IoT environments, [14] introduce the semantic representation
approach for IoT nodes, and utilize the semantic IoT knowl-
edge for reasoning actionable knowledge with Semantic Web
technologies. Reference [15] proposes an adaptive approach
that can dynamically integrate heterogeneous devices into the
context-aware IoT infrastructure.
B. Physical Mashup
Physical mashup inherits the basic paradigm of Web
Mashup that can assist users to create IoT applications rapidly
by composing virtual and physical services. Reference [16]
proposes a user-centric composition framework of IoT services
based on device resources in urban-computing environments.
In this framework, the IoT services are implemented as smart
objects from the perspective of users, and a task-oriented
computing approach is also presented to handle the compo-
sition of IoT services in a spontaneous manner to achieve the
user task. To reduce the bandwidth and processing time of
embedded devices, a new integrated framework is proposed
for the embedded applications [17]. This framework adopts
the CoAP (Constrained Application Protocol) / EXI (Efficient
XML Interchange) technology stack to be suitable to develop
resource-constrained embedded applications. Reference [18]
presents a model-based interface description scheme that can
automatically generate the user interface of IoT devices. In the
scheme, a self-defined description language should be used to
describe the interaction semantics of interactive components.
To overcome the heterogeneity of IoT devices, [19] proposes
a mashup model of services in IoT environment. This mashup
model can be used to develop IoT applications following
the model-driven architecture, and finally implemented based
on the cloud environment. Reference [20] proposes a light-
weight physical mashup approach for IoT applications. In the
approach, the physical devices in the lower layer are repack-
aged as RESTful services based on CoAP, and provided to the
composition layer in a graphical manner, so that non-experts
could use them to develop personalized IoT applications.
C. Dynamic IoT Service Orchestration
The dynamic service orchestration provides a flexible coor-
dination pattern for physical devices in IoT environment.
Reference [21] proposes a service-oriented collaboration
approach for smart home to address the heterogeneity and
late binding of physical devices. This approach is imple-
mented based on AI planning technologies to dynamically
orchestrate the IoT service processes at runtime according to
function requirements and contextual information. Similarly,
2084 IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 25, NO. 4, AUGUST 2017
[22] presents a goal-driven service orchestration approach
for IoT environment, in which a semantic metadata spec-
ification of RESTful is defined for IoT services, and a
reasoning mechanism is constructed as an orchestrator. In con-
trast to the process-driven service orchestration (e.g.,BPMN,
BEPL), this approach can dynamically orchestrate the service
processes based on users’ goal and contextual information.
Reference [23] proposes a self-organizing scheme for smart
devices in IoT environment inspired by the endocrine mech-
anism. In IoT environment, a smart device is an autonomous
area that can work independently according to its own status
and dynamic circumstance. The smart devices can coordinate
with each other by an information exchange network, which
is constructed based on endocrine mechanism, to accomplish
the tasks and objectives. For the large-scale IoT scenarios
(e.g., healthcare, smart cities), [24] proposes a fog-enabled
orchestration architecture to loosely coordinate the fog nodes
in IoT environment. Reference [25] proposes a “virtual block”
concept (i.e., services), to deal with device heterogeneity and
to support the orchestration of smart objects in complex IoT
environment. It also proposes a late binding mechanism for
implementing a context-aware and self-adapting platform of
physical devices.
D. IoT Service Adaptation
Standardization in web service simplifies the interoper-
ability, however, it does not remove the mismatches among
services due to possible heterogeneity of service inter-
faces and protocols. Service adaptation provides an effective
solution to deal with the mismatches by using corrective
mechanisms [26]. In [27], authors summarize some mismatch
patterns on the service interface and protocol levels, and
propose an adaptation method by developing stand-alone adap-
tors. Reference [28] proposes a stigmergic-based approach to
model the service composition and adaptation in decentralized
environments. To address dynamic changes in the complex
decentralized system, diversity schemes are incorporated into
the proposed approach to promote continuous adaptation
features. In IoT environment, especially, many devices use
different communication protocols and data payload formats,
which lead to more heterogeneity of IoT services. From
the perspective of fault-tolerant capability, [29] proposes an
adaptation scheme for IoT devices based on service-oriented
architecture. In the scheme, authors introduce a concept of
virtual service that can use data from more than one sensor
devices to replace the actual service on some faulty device.
III. ANAPPLICATION SCENARIO
The hospital in this scenario is a large, extremely busy,
and chaotic organization, where hundreds of medical cases are
treated every day. Hundreds of doctors and other staff members
are walking about constantly; inpatients and outpatients are
moving around the hospital under surveillance; and medical
devices are commonly recalled for emergency use. Although
information systems have been used to support the work of
medical professionals, they are not able to accurately track
patient flow and asset flow in real time. Thus, sensing and
responding quickly to critical situations becomes impossible
Fig. 1. A typical surgical workflow.
in this dynamic and unpredictable environment. In particular,
performing a surgery requires extensive information sharing,
coordination, emergent situation detection, and immediate
reactions. Meeting these requirements is very difficult if no
proper technology is used to help monitor patient flows, track
medical devices, and alert personnel to unexpected situations.
Failures in these areas can threaten patient safety, decrease
operational efficiency, and increase medical costs.
As shown in Fig. 1, a typical surgical workflow is used
to illustrate the challenges in performing a surgery. This
workflow generally involves three phases, namely, preoper-
ative, intraoperative, and postoperative. Five groups of partic-
ipants are involved in this procedure, namely patients (P1),
porters (P2), nurses (P3), anesthetists (P4), and surgeons (P5).
Surgical related locations can include the ward (L1), holding
area of the operating suite (L2), operating suite (L3), holding
area of the operating room (L4), operating room (OR) (L5),
recovery room (L6), and intensive care unit (ICU) (L7).
During this surgery process, several emergent events might
occur, which if not attended to could cause, among other
things, critical surgical instruments to be missing from the OR,
potentially resulting in patient death. Without IoT technology,
tracking the locations of a patient and instrument in real time
is impossible and therefore finding both in an emergency can
be very difficult. Another potential problem can occur when
manually checking a patient’s medicine, where human error
may directly result in medical accidents. Finally, the proper
technology should offer the ability to detect critical situations
in advance, thus avoiding many potentially serious situations.
For example, a nurse may mistakenly send a patient to a
wrong OR, so his/her surgery will be delayed. In addition,
during the operation, if there are indications that a patient
may be in danger of having an unexpected heart attack,
an additional medical device might be needed for emergency
use; however, if it does not get sent to the right OR in time,
there could be serious consequences. Therefore, this dynamic
and sometimes unexpected environment raises a number of
challenges for surgery operations.
IV. THE PROPOSED APPROACH
A situation-aware, dynamically-adaptable IoT service coor-
dination system is proposed. First, an important primitive
event or a combination of events is detected in the event cloud;
next, the specific service response, such as the generation of
a service call or event notifications, is determined through
defined business rule matching. During this process, not only
CHENG et al.: SITUATION-AWARE DYNAMIC SERVICE COORDINATION IN AN IoT ENVIRONMENT 2085
Fig. 2. The concept model for IoT service coordination.
can every service exchange with other services through
information-based calling, but a service can also achieve self-
adaptive collaboration based on either other services or an
event notification produced by the event source. The service
referred to here can be a single Web service or a combination
of services. The business rule structure is based on the
expanded ECA paradigm; this paradigm can perform proactive
service responses based on events that satisfy specific condi-
tions. The concept model for the situation-aware, dynamically-
adaptable IoT service coordination is shown in Fig. 2.
A. The Event Model and Event Pattern Detection
The patient monitoring systems and radio-frequency iden-
tification (RFID) reader produce continuous streams of data
that need to be processed and analyzed in real-time to detect
events. There is also a need to process the continuous data
streams.
Definition 1 (Event): An event is a specific activity or a
change of a subject’s state, where a specific event instance is
expressed as e. Every event notification contains a correspond-
ing event type, attribute, and time of occurrence. A specific
event can be distinguished as a primitive event or a composite
event.
Definition 2 (Primitive Event): A primitive event is atomic,
i.e., cannot be further divided, and occurs at a specific time.
A primitive event can be expressed as ep=ep(id,a,t,l),
in which id is the unique identification number of the primitive
event, a={a1,a
2,..., a
m},m > 0, is the attribute set of
that specific primitive event, tis the event occurrence time,
and lis the event occurrence location.
Definition 3 (Composite Event): A composite event can be
defined as ec=ec(id,a,c,t
s,t
e),t
e≥ts,inwhichthe
first two items, id and a, have a similar definition to that of a
primitive event. Furthermore, c={e1,e
2,..., e
n},n>0is
TAB L E I
SEP RULE STRUCTURE
an event set that contains a number of primitive events or com-
posite events, where all elements in the event set constitute
that particular composite event. Quantities tsand teare
respectively the beginning and ending times of the event,
that is, the particular event can occur within the time period
from tsand te.
Definition 4 (Composite Event Operator): In general,
arithmetic operators that express event relationships can exist
for a single event, or between multiple events. For example,
a monocular mode that describes a single event includes an
average value event, a maximum value event, a recurring
event, and a regionally occurring event; whereas a multicast-
ing mode that describes the inter-event relationships includes
the time sequence relation and aggregation relationship. More
details about composite event operators are described in
previous work [30].
Definition 5 (Situational Event Pattern): The pattern of an
event, Pe, is a conditional expression of an event. Any event
pattern of a relevant event must be captured from a sequence
of events in a period of dynamic extension; moreover, only
a matched event pattern can satisfy the semantic constraints
described in the rule. The Situation Event Pattern (SEP)
defines the event rule structure as shown in Table I.
In the above rule structure, the first line, Situation,defines
the event structure of a specific scenario, the parameters of
which are formed by the attributes of the event and their
attribute type (the attribute type is optional). The second
line, TrigFrom, defines the pattern structure of a complex
event that is formed by a series of simple events, which can
be connected by logical connectors such as ‘and’ or ‘or’.
Together, these two lines denote a scenario event and its
component composition. The Where clause in the third line
of the rule structure describes the constraint conditions that
attributes Attr1,...,Attr
n(corresponding to an event) must
satisfy. The final item, Consuming, is optional and is used
to define an event consumption strategy.
Here, a heart attack situation during the surgery process sit-
uation is presented. Fig. 3 shows how basic events, composite
events, and complex events relate to each other.
By correlating basic events and matching them with
predefined rules, it is possible to detect emergent situa-
tions, make quick decisions and take immediate actions. For
instance, the composite event ec1is found to match rule1
(heart_attack), so the complex event “The patient is facing
a heart attack” is detected. Similarly, ec2is detected to
match rule2(instrument_missing) so the critical situation
“The patient located in OR01 is facing a heart attack and
needs instrument OXRB which is missing” is detected.
B. The Situational Event Detection Algorithm
An RFID-enabled smart hospital can generate a variety of
data streams that are in different formats and need to be
2086 IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 25, NO. 4, AUGUST 2017
Fig. 3. An illustration of basic, composite and complex events.
processed in a timely manner. For example, an RFID tracking
system consistently generates data about the location and
time of tagged items, which is in low-level semantics and
not directly useful. Moreover, embedded sensors and devices
continuously generate environmental or medical related data.
Complex situational event processing, which aims at process-
ing multiple streams of data continuously and identifying
meaningful events in real-time, has been introduced to process
and correlate these data. Consequently, a hospital needs to
handle a large amount of data originating from a variety of
sources, and needs to detect medically significant events in
good time by considering both RFID and non-RFID data.
The core concept of SEP is to use strict temporal logic
to describe sequences of events. Confirmation of any event
profile must wait for the occurrence of the final event in the
event sequence corresponding to the relevant rule. To support
SEP, an automaton-based situational event detection method
is proposed. First, a situational event automaton model is
provided:
Definition 6 (Situational Event Automata): A situational
event automaton (SA) is defined as a six-tuple SA =<S,
T, Ss,S
e,In,Out>,where
1) Sis the SA’s state set;
2) T⊆S×Srepresents the transition relations between
states, which typically must satisfy certain event con-
straints;
3) Ssis the SA’s initial state;
4) Seis the acceptable state for the SA,i.e., the state for
which a matching event profile is detected;
5) In is the event stream that enters the SA; and
6) Out is the successfully detected composite event stream.
The primary design principle of automaton-based detection
is to construct corresponding automata for each composite
event profile and to obtain the corresponding state set and
transition set, the corresponding input event domain for each
state, and the corresponding event domain for each transition;
then, when a primitive event arrives, these constraints are used
for matching. If an acceptable state without an outward transi-
tion is eventually reached, then a successful match is obtained,
and a composite event is successfully detected. To identify
the SEP rule, a specific rule should first be translated into
an automaton model; this model is determined by the events’
occurrence order and the various constraints specified by the
rule and consists of one or more specific event sequence
models. The general procedure is as follows: based on the
rule definition, rule ris decomposed into one or more event
sequence models MES; all event sequences (ES) are linear
deterministic automata; every event related to rrepresents
a state in the sequence model; and the event contents and
time constraints that can trigger state transitions between the
sequence’s different states are shown (Ssis the automaton’s
initial state; Seis the final state). After the rule is decomposed
into event sequence models based on the different states’
constraints and relations as defined by rule r, all sequences are
assembled into a common automaton model. To describe how
SEP rule-based automata can be used to identify a specific
situation, a processing algorithm for a single MES is first
provided. When a certain event earrives, this MES begins
processing following the steps listed in Algorithm 1.
Algorithm 1 Event Automaton Processing (EAP)
1Initialize the event sequence in MES as ES0;
2if Event esatisfies state transition conditions of MES
then
3if ecan trigger some state simigrating to si+1 then
4create a copy ESi+1 from this ESi;
5Change the state of ESifrom sito si+1;
6if exceeded the time constraint then
7delete this ES and Goto line 2;
8end
9if si+1 is not the final state of MES then
10 Goto line 2;
11 end
12 else
13 return the detection result;
14 end
15 end
16 end
17 else
18 Discard e;
19 end
It should be noted that after the creation of ES, the original
ES (not ES0) is still in state si; if a certain ES exceeds
the time constraint during the process, then ES is discarded.
The earliest initialized ES0is always in the state that is not
triggered by an event, thus it is never necessary to discard it.
For example, consider a query that monitors physiological data
streams; i.e., "report the heart rate and blood pressure values
when the heart rate is >100 and the blood pressure is <70
over a period of 60 seconds". This is illustrated in Fig. 4.
At the moment of t=0, an initial sequence ES0of the
event sequence model MSE1is at the state of ’wait for
events’. When t=1, the heart rate H1enters the automata.
By checking the class, content, and time, it is identified that
H1satisfies the state transition condition of ES0. Then, create
ES1and change its state to HeartBeat; similarly, when t=2,
H2enters the automata. Then, create ES2and change its
CHENG et al.: SITUATION-AWARE DYNAMIC SERVICE COORDINATION IN AN IoT ENVIRONMENT 2087
Fig. 4. An illustrative example for the processing procedure of SA.
state to HeartBeat. When t=4, the arriving event is blood
pressure B1with location Area5. Since there is no blood
pressure event meeting the conditions located in Area5, B1is
discarded. When t=7, since the 5 minute constraint becomes
invalid for the ES1that is created at t=1,ES1can
no longer migrate and is discarded. Meanwhile, the arrival
of H3leads to the creation of ES3and its migration to
HeartBeat state. When t=8discard ES2,forthesame
reason as above. Due to the arrival of B2, create ES31 and
change its state to BloodPressure. Thus far, the first matched
event model (consisting of H3and B2) has been created.
Similarly, when B3arrives at t=9, create ES32 and change
its state to BloodPressure; then the second matched event
model (consisting of H3and B3) is created.
In the above processing procedure, all the event sequences
in an active state store all the event information, triggering
its transition to their current states. For instance, the time
and content of events; where the former could be used for
determining when to check the effectiveness of some event,
and the latter could be used for checking whether relevant
attribute values accord with the conditions defined by the rules,
e.g., the heart rate value and blood pressure value.
C. The Enhanced E-ECA for Process Flow Control
Complex situational event detection involves a continuous
processing and analysis of high-volume and high-speed data
streams such as RFID data. It also correlates distributed data
to detect and respond to business-critical situations in real
time. Then, it helps to deal with a variety of data streams
to deliver actionable information. After the occurrence of a
certain event, and assuming that certain conditions have been
satisfied, then general ECA process steps include a set of
corresponding rule bodies that are automatically triggered;
moreover, their corresponding codes will be executed to realize
the possible actions. As shown in the previous section, during
collaborative service process control, there exist composite
control flow patterns, such as AND-split, AND-join, and
XOR-split, in addition to sequence control flow patterns.
However, an ECA rule model cannot express these patterns.
To enhance the functions of ECA rules, Fig. 5 gives an
enhanced ECA (E-ECA) rule expression method. The method
involves the addition of an Action option to certain business
rules, based on the foundation of ECA.
In general, the E-ECA execution follows the following
patterns:
Fig. 5. An illustration of the E-ECA expression method.
Fig. 6. Sequence structure control.
1) E-A pattern: When the service object receives a trig-
gering event E, execute operation Ato enter the next
state; that is, execute the Then portion of the action once
an event meeting the conditions has occurred;
2) E-C-A pattern:OperateAand enter the next state
when the service object receives a triggering event E
and condition Chas been satisfied; and
3) E-Cn-Anpattern:OperateAnand enter the next state
only when the service object receives a triggering event
E and condition Cnhas been satisfied, in which: Cn=
{Condition1/C Condition2/C ... /C Conditioni},
/C ∈{∧,∨},i≥1;
An={Action1£Action2£... £Actionj},£∈
{∧,∨},j≥1.
To model service control flow, consider the following main
control flow scenarios: sequence structure control, parallel
actions, alternating actions, and repeated iteration actions.
These are now explained.
Sequence Structure Control
When using E-ECA rules to achieve service flow control
for a sequence structure, the flow transfers to the next rule
state after the execution of the corresponding actions of each
E-ECA rule, as shown in Fig. 6.
From Fig. 6, it can be seen that when rule 1completes
action a1,evente2is either produced or received, causing
rule 2to be executed; the completion of action a2will
similarly cause the state to transfer, causing rule 3to be
executed. The flow control of the business process sequence
structure is realized by repeating the same steps.
Parallel Branch Structure Control
The parallel branch structure can also be called an And-
branch structure. From the viewpoint of the AND-split pattern,
one type involves the execution of rules that belong to different
service domains, and is triggered by the same event, as shown
in the left side of Fig. 7; the other type entails either multiple
events produced by the completion of an action, triggering
subsequent parallel actions, or the parallel actions of the same
event triggered by different conditions.
From Fig. 7, it can be seen that after the starting rule
completes action a1,eventse2and e2are produced or received,
2088 IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 25, NO. 4, AUGUST 2017
Fig. 7. Parallel branch structure controls.
Fig. 8. The XOR branch structure control.
Fig. 9. The OR branch structure control.
simultaneously triggering two different rules and thus realizing
two branches, (e2,a
2a,e
3a)and (e2,a
2b,e
3b). At the tail end,
the eia and eib produced by branches (ei−1,a,a
i−1,a,e
ia)and
(ei−1,b,a
i−1,b,e
ib)trigger and realize the AND-join pattern.
Choice Branch Structure Control
The choice branch structure can be further divided into the
XOR branch structure and OR branch structure; the former
refers to cases in which one of many variations can be chosen
for execution during flow progression to reach the next state.
An E-ECA rule based on an ON-IF-THEN-ELSE pattern can
be used to realize the XOR branch control. As shown in Fig. 8,
the completion path can use two events triggered by two
different branches as the disjunction E, triggering subsequent
actions. Fig. 9 shows one expression method of the XOR
branch structure control, in which a certain set of rules is
triggered by the same event under different conditions.
Loop Structure Control
The use of E-ECA rules to control a loop structure consists
of two parts. The first is the control of a DO-WHILE type
loop, and the second is the control of a WHILE-DO type loop;
both can use the XOR-split pattern to facilitate control. The
DO-WHILE type loop is shown in Fig. 10. From Fig. 10, it can
be seen that after rule 2receives the triggering event e2, loop
action a2is executed first, and so forth; then certain commands
are executed according to the sequence to rule i −1.Ifthe
loop condition of rule i−1is satisfied, then the system returns
Fig. 10. The Do-While loop structure control.
Fig. 11. The While-Do loop structure control.
to rule 2to execute the loop; otherwise, if the condition is not
satisfied, then the loop is exited after the execution of a(i−1)
and instead, executes rule i. In WHILE-DO loop control, when
rule 2receives event e2, condition c2is analyzed; if satisfied,
the loop is executed, otherwise the loop is exited immediately
after the action has been executed, as shown in Fig. 11.
D. The Collaboration Process Decomposing Algorithm
The IoT business process should be able to process large
amounts of events, and provides functions to monitor, steer
and optimize business processes in real-time, which can auto-
matically discover and analyze business situations or excep-
tions and can create reactive and proactive responses. These
would include generating early warnings, preventing damage,
loss or excessive cost, exploiting time-critical business oppor-
tunities, or adapting collaboration processes with minimal
latency. An event driven service collaboration action model
can realize global viewpoint-based service programming and
local viewpoint-based service scheduling, based on the event
communication and ECA triggering mechanism. The global
programming can be decomposed into numerous local service
scheduling sequences; based on this model, the unification
of service programming and scheduling can be achieved.
An event driven service collaboration action model is shown
in Fig. 12.
Definition 7 (Global Collaborative Process): A collabora-
tive process is defined as a five-element set: PC=
(SP,S,CF,CP,CM),inwhich:
1) SP is the local service domain set that forms the
global collaborative process; a collaborative process
is composed of many local service processes, in which
every local service process belongs to a service domain;
2) Sdenotes all participating service sets in the collabo-
rative process;
3) CF is the control flow set between all services in the
collaborative process; the control flow between any two
services can be expressed as C:= {(Ss⊆S)→(Sd⊆
S)},whereSs⊆Sis the source service and Sd⊆Sis
the target service;
4) CP denotes the composite control flow pattern
that exists between services in the collaborative
CHENG et al.: SITUATION-AWARE DYNAMIC SERVICE COORDINATION IN AN IoT ENVIRONMENT 2089
Fig. 12. An Event driven service collaboration action model.
process; besides the most common Sequence pattern,
there also exist two main types: a division pattern
Split(AND, XOR, OR)and an aggregation pat-
tern Join(AND, XOR, OR); and
5) CM :S→SP indicates the control mapping relation
set from Sto SP; in a single local service domain,
at least one mapping occurs from S to SP, therefore,
the relationship between Sand SP is either one-to-
one or many-to-one.
Definition 8 (Control Flow): The control flow of a collabo-
rative process is a two-element set, Cf=(S,CF
),inwhich
S⊆Sand CF⊆CF are, respectively, the service
set and execution dependency relationship between services
in the collaborative process. If completing the execution
of services1triggers service s2, then there exists an execu-
tion dependency relationship between S1and S2, that is,
Depexec(S1,S
2)∼
=Dep(S1.complete(),S
2.active()).
Definition 9 (Local Process): The local process model is
similar to the collaborative process model, but it does not con-
tain a local service domain SP; the local process model can be
defined as a four-element set: PL=(SL,CF
L,CP
L,CM
L),
in which SL⊂S,butCFL⊂ CF, because when a global col-
laborative process is decomposed into many local processes,
additional service dependency relationships are produced.
Definition 10 (Event Flow): The event flow in a collabora-
tive process is defined as Ef=(SE,E,S
D,E
R),where
SEis the source service of the produced event flow Ef,Eis
the event set produced by SE,SDis the target service set
corresponding to a specific event, and ER:SE→SDis the
corresponding event flow relation of a service in SEand the
relevant services in SD.
As described above, the global collaborative process PC
describes the collaborative relationship between many organi-
zations within a service system, representing the macro view
of the business process. To obtain the micro view of specific
executable rules, as described by E-ECA, the collaborative
process PCmust first be decomposed into a series of local
process PLmodels under the service domains to which the
different organizations belong, as well as the interaction event
flow Efmodels between the local processes; then, these
two types of models can be converted into E-ECA rules
that can be executed in an active rule engine. To achieve
the decomposition of the collaborative process model PC,
the Collaborative Process Decomposing (CPD) algorithm
is given in Algorithm 2. The CPD adds a sequence Q
Algorithm 2 Collaborative Process Decomposing (CPD)
Input: a collaborative process P
Output: a set of local processes PL,asetofevent
flow Ef
1Create a queue Q;
2foreach ss∈Ss(P)do
3ENQUEUE(Q, ss);
4end
5while Qis not empty do
6s=DEQUEU E(Q);
7if process(s)is not assigned then
8P←new local processPL;Process(s):=PL;
9end
10 foreach ssubsequent ∈Ssubseq uent (s)do
11 ENQUEUE(Q, ssubsequent );
12 end
13 next
14 foreach spre ∈Spr e(s)do
15 if SP(s)=SP(spre)then
16 Ef←f(spre,s)
17 end
18 else if SP(s)==SP(spre )&&process(s)is not
assigned then
19 process(s):=process(spre );
20 PL←CFL(spre ,s);
21 end
22 else if SP(s)==SP(spre )&&process(s)=
process(spre )then
23 PL=PL\process(spre );
24 foreach s∈S(process(spre )) do
25 process(s):=process(s);
26 end
27 end
28 end
29 end
30 return (PL,E
f);
(steps 1-4) to the starting service ss∈Ss(P)of the
collaborative process P. From step 3 to step 29, the algorithm
searches for the control flow and event flow of collaborative
process Pusing a breadth-first search algorithm. For every
service sin the sequence, if it is a starting service that does not
have prior services, then a new local process PLis created, and
sis placed under the newly created local process (steps 7-9).
Steps 10-12 of the CPD algorithm place the subsequent
services of sinto sequence Q, for the convenience of con-
tinuing the breadth-first search. Afterward, for every service s
in Q, the service domain to which it belongs is compared with
the service domain of the prior service spre;iftheservice
domains are different, then they are considered to belong
to different local processes. Thus, an event f(spre →s)
from spre to sis created and stored in event flow
2090 IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 25, NO. 4, AUGUST 2017
Fig. 13. An example: the refined surgery management collaborative process.
Ef(steps 14-15). If the service domains of sand spr e are the
same, then sand spre belong to the same local process. In this
context, two different situations must be catered for if the
local process to which sbelongs has not yet been determined,
then the set of local processes sis equal to that of spre .
Simultaneously, a control flow CFL(spre →s)from spre to
scan be created and stored in the corresponding local process
PL(steps 18-21). If the local process to which sbelongs is
determined, and is different from that of spr e, then the two
should be combined, because both local processes belong to
the same service domain and the same collaborative process.
Thus, the process of the prior service spre is discarded, and
all local processes of s∈S(process(spre )) are set to be the
same as s. This kind of refresh situation usually occurs when
more than one prior service is possible for a certain service,
and these prior services belong to different local processes.
During the surgery process, every patient is equipped
with an RFID-embedded wristband (REW) (a type of device
belonging to the patient support system (PSS)). Every REW
corresponds to an unique ID, which corresponds to a given
patient. If the medical personnel carry out a certain operation
to match the REW to a specific patient, then the smart auxiliary
device of the medical personnel will display the detailed
information of that patient. The full model for the collaborative
process of surgery management and the refined collaborative
process is shown in Fig. 13.
The entire collaborative process PCcontains 13 sub-
services (S1-S13) and 13 control flow conversions, among
which two XOR-split patterns are involved. All services
belong to four different service domains: PSS, nurse assis-
tant system (NAS), anesthetist assistant system (AAS), and
surgeon assistant system (SAS). Specifically: S1,S13 ∈
PSS;S3,S4,S7,S10,S12,S13 ∈NAS;S5,S6∈
AAS;and S8,S9,S11 ∈PSS.
To apply the CPD algorithm in the surgery management
collaborative process, the local process model, event flow
model, and their relationship after decomposition are shown
in Fig. 14.
Every service domain has a corresponding local process.
Within a certain local process, it is possible that event flow
exists between some of the services and those of other local
processes, while these processes themselves represent the far
end or the target end. The control flow pattern CP in the
Fig. 14. The Decomposed Local process and event flow model.
collaborative process model remains unchanged after decom-
position into the local process models, e.g.,theXOR-split
control pattern of S5and S10,andtheXOR-join pattern
of S12. However, for more than one control flow conver-
sion or during the service of an event interaction, S4and
S9are both AND-split,andS7,S10,and S11 are all
AND-join control patterns.
After extracting several local processes and event flows
from the collaborative process using the CPD algorithm, these
models can be converted into executable ECA rules. In the
smart service environment, three types of rules are most
critical: the flow constraint rule, E-Service interaction rule,
and S-Service event detection rule. Among these, the flow
constraint rule is mainly used to establish flow control within
the management service domain and cross service domain
events; the E-Service interaction rule is mainly used for service
information system oriented calls and response triggers; and
the S-Service event detection rule is used for RFID in the
smart service environment, or for the triggering of other smart
devices used in real-time detection events. The portion of the
E-ECA rule set that applies to the smart surgery management
collaborative process is shown in Table II and Table III.
First, the beginning and ending constraints of the service
must be defined. For example, S1corresponding to local
process P1in the service domain PSS (i.e., the patient was
told that surgery preparation was complete) is the first service
in the entire collaborative process and does not have beginning
constraints; for this service, the initial state is ’Ready’. The
transmission of the information that preparation has been
completed to the hospital information center through E-Service
type services then begins execution. After the information
has been transmitted, S1will transmit an internal event that
indicates conversion into the ’Completed’ state; the ending
constraint is the transmission of an internal event to trigger
the next service, which is S2of local process P1that belongs
to the same service domain PSS (i.e., the patient receives
the information that the surgery treatment process has been
entered). The service cycle of S2is mostly similar to S1;
the difference is in the specific service provided. However,
for S3in NAS (i.e., the nurse is inspecting the patient’s
identity and physical condition) the beginning flow constraint
CHENG et al.: SITUATION-AWARE DYNAMIC SERVICE COORDINATION IN AN IoT ENVIRONMENT 2091
TAB L E I I
PORTION OF THE E-ECA RULE SET
is that the nurse had received information that the S2service
was completed through NAS. During the execution of S3,
based on the E-Service interaction rule, patient.identification()
service is called, and at the same time, the state of S3is set
to ’Executing.’ When service.response (patient.identification)
is received (i.e., the inspection of the patient’s identity and
physical condition by the nurse has been completed), the state
of S3is changed to ’Completed.’ The ending flow constraint
of S3is the production of an internal control flow event that
triggers S4service, which also belongs to NAS.InS4(i.e.,
patient transfer), the beginning flow constraint is receiving
information of the completion of S3through NAS.Inthe
intermediate state, based on the E-Service interaction rule,
E-Service: patient.transport() is executed. The ending flow
constraint is the transmission of two control flow information
steps that are in the same service domain, ’E-4-7’and
’E-4-10’; that is, for the nurse, the next step can execute
either S7or S10, and the transmission of an event flow
’E-4-5’, which notifies the anesthetist that the patient has
arrived, that is, to begin S5service in the AAS service domain
(i.e., confirmation of relevant patient information).
Service S10 (i.e., transfer the patient to a recovery room and
track the patient’s physical condition) involves the S-Service
event detection rule. The detection of important information
regarding the medical equipment used for patient monitoring
is started at the same time as when S10 is in ’Ready’
state. If there is no occurrence of an emergency situation
within the action time of the medical monitoring equipment,
the S-Service event detection rule transfers the state of S10
TABLE III
PORTION OF THE E-ECA RULE SET
to ’Completed,’ and S10 finishes execution. If an emergency
situation occurs during the period, the definition of the emer-
gency rule is invoked; such as the occurrence of the patient
hypovolemia danger warning rule as follows:
According to this rule, if the heart beat rate of the patient
increases in excess of 5% within a five minute period, coupled
with a decrease in blood pressure by more than 6%, a warning
is issued to the medical personnel. In this case, S10 executes
the ELSE branch of the E-ECA control structure ON-IF-
THEN-ELSE; then, that branch transmits an external warning
event to S11, triggering that service. At the same time,
another internal event is produced to bring about the end of
service S10.
E. The Rule Mismatch Detection (RMD) Algorithm
IoT services exist in a diverse environment that has tem-
poral and spatial constraints and is subject to dynamic and
ever-changing features. To match the environment and service
scenarios, the realized ECA rules can be defined by different
users and can be changed and registered on different distrib-
uted smart devices. This can cause differences between the
rules used for different realized collaborative actions; when
the rules are triggered and executed in a distributive manner,
conflict can occur. Therefore, the consistency of the service
collaboration actions must be verified, to ensure that the
service collaborative process is executed smoothly. The Rule
Mismatch Detection (RMD) algorithm is given in Algorithm 3.
2092 IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 25, NO. 4, AUGUST 2017
Algorithm 3 Rule Mismatch Detection (RMD)
Input: Global rule set RSG{Es,C
s,A
s}, Action
constraint AC, Interim Action Set
AI={aI,C
I},Newrules
Rnew =(ES−new ,C
S−new,A
S−new);
Output: Mismatch set SMis(e, Ac,R
Mis),whereeis
the mismatch inducing trigger event, and Ac
and RMis are, respectively, the Action
constraint under the mismatch condition and the
corresponding mismatch rule set;
1The initial value of SMis is set to naught;
2Create a temporary condition set AI−new()
corresponding to Rnew ;
3The initial value of AI−new is set to naught;
4foreach action aof action set AI−new in Rnew do
5if action aunder condition C(I−new)is to call a
certain service then
6AI−new =AI−new ∪{(a, CI−new )};
7end
8if action ais to produce a certain event etrig and
trigger more rules then
9AI−new =AI−new ∪{(atr ig ,C
trig ∧CI−new )};
10 (atrig ,C
trig )∈AI(etrig );
11 end
12 end
13 foreach event eof event set ES−new in Rnew do
14 search for the Most Implicative Event(EMi)in
RSG;
15 end
16 if EMi does not exist then
17 jump to line 25 and immediately perform a rule
mismatch check;
18 end
19 else
20 foreach sub-event eimp in EMi do
21 AI=AI(eimp)∪AI−new ;
22 end
23 jump to line 25 and perform a rule mismatch check;
24 end
25 For AC, perform the following steps:
26 if AC⊂{a|(a, C)∈AI}then
27 AI−Mis ={(a, C)∈AI|a∈Ac};
28 RMis ={R∈RSG|(a, C)∈AI−Mis and a ∈AS};
29 end
30 if detect AI−Mis has AND satisfiability then
31 SMis =SMis ∪{e, AC,R
Mis};
32 end
33 if SMis is naught then
34 refresh AI−new(ES−new );
35 end
36 else
37 return SMis;
38 end
Definition 11 (Action Constraint (AC)): An action con-
straint is a limitation on the concurrence of a set of service
call actions.
Definition 12 (Action Constraint Graph (ACG)):
An action constraint graph can be defined as an undirected
graph ACG =(P, Saction,Ω), in which P corresponds to
an ECA rule-based service process, Saction is an existing
service constraint action set registered in that process, and
Ω:Saction ×Saction is a pair-wise action constraint relation
in the action set.
Definition 13 (Global Rule Set (RSG)): The global rule
set of a process is RSG=∪1inumberof Rules(RSG)Ri,
where Ri={ERi,E
Ri,E
Ri}, and ERi ,ERi ,ERi, respec-
tively, correspond to the event set, condition set, and action
set contained in Ri.
Definition 14 (Event Implication Relation): For a sequence
of two events Eαand Eβ, if the occurrence of Eαimplies that
Eβmust also occur, then Eαand Eβare defined as having an
implication relation (Eαimplies Eβ,), denoted as Eα→Eβ.
Definition 15 (AND Satisfiability): Assume that ciis a con-
dition of a certain rule in the RSGof a certain global rule
set; if cican satisfy all of the rules in RSG,thenciis said
to have AND satisfiability relative to that RSG.
Definition 16 (Rule Mismatch): For a rule set RS,ifat
least two service actions belong to Action constraint Ac,then
a rule mismatch exists in RS; the rule mismatch can easily
induce conflict between rules.
Definition 17 (Rule Mismatch Graph (RMG)): A rule mis-
match graph can be defined as a directed-graph RMG =
(P, R, RMis),inwhichPcorresponds to an ECA-based
service process, Ris all of the rules registered in that process,
and RMis is the rule set in which the mismatch exists.
Based on the above definitions, to ensure effective collabo-
ration in subsequent service periods from the stage of rule
design, the following rule mismatch detection algorithm is
proposed and applied to an example for verification.
V. PERFORMANCE MEASUREMENT AND ANALYSIS
A. The Experimental Setup
The situation-aware IoT services coordination platform was
installed on a PC server (2.5 GHz Intel Xeon E5420 with
10 G of RAM). A real operating room (OR)in a hospital
is selected as the basic experiment environment; all types
of parameters were collected and transmitted to the remote
monitoring center for analysis to provide decision-making
information for clients. Furthermore, 10 other identical ORs
have been simulated as a semi-physical emulations experiment
environment to evaluate the performance of the proposed IoT
services coordination platform.
CHENG et al.: SITUATION-AWARE DYNAMIC SERVICE COORDINATION IN AN IoT ENVIRONMENT 2093
Fig. 15. An accuracy comparison.
Fig. 16. The processing time comparison.
B. The Accuracy for Situational Event Detection
The first experiment is to measure the performance of
the situational event detection algorithm. Here, Esper [31] is
another independent similar product, which aims for complex
event processing and event series analysis, and offers a domain
specific language for processing events. Therefore, Esper
is used for comparison the performance of situation event
detection. Fig. 15 shows the accuracy comparison between
our proposed situation event detection approach and Esper.
It can be observed from Fig. 15, the accuracy of situation
event detection for our proposed approach is higher than Esper.
This is because our approach provides powerful capabilities
for situation event pattern expression. The processing time for
situation event detection shows in Fig. 16.
It is observed from Fig. 16, as the number of events is
increasing, our approach shows a better performance than
Esper. The reason is that our approach stores many basic
situation event matching results, therefore reducing the number
of duplicated matching calculations while maintaining a high
event detection rate. However, the processing time for our
approach is higher than Esper when the number of events is
growing up to 25 thousand.
C. The Speed of the Service Coordination
Speed is an important feasibility measurement index of
dynamic service coordinativemethod of IoT. A viable dynamic
service coordinative method of IoT should able to rapidly
assemble atomic services within the service library to form
large-grained services to satisfy the user request. To illustrate
the feasibility of E-ECA based dynamic service coordinative
method of IoT, we construct a simulation experiment to
Fig. 17. The time comparison of service combination with different scale
of rule libraries.
Fig. 18. The mean time comparison of generating complete rule library with
different scale of rule libraries.
evaluate the method’s time expenditure of service coordi-
nation, which using service rule sets with different scale.
We generate 6 different scale coordinative service rule sets,
which include 100, 200, 500, 1000, 2000, 5000 different rules
respectively. Each user request’s processing time has been
recorded firstly, then calculate the mean time of processing
satisfiable, and unsatisfiable user requests, both of which using
different service rules. The result is shown in Fig. 17.
We can infer from Fig. 17 that for the satisfiable user
requests, the service coordination using different scale rule sets
could obtain user-satisfied flow service in seconds level. And
the expenditure of time are very close when using different
scale rule sets, and are not significantly increased along with
the increasing rules number of the sets. The best matching
rules could be found for the satisfiable user requests, and no
need to construct a complete scene rule library for each output
of user request, thus saving a great deal of time.
As real-time building scene rule library is the critical step of
the proposed dynamic service coordinative method, we real-
time constructing complete scene rule library for the scene
object, and record each complete rule library’s generating time,
then calculate the mean generating time and obtain statistical
results which are shown in Fig. 18.
The results show that the time expenditure of building
complete scene rules library is increasing with the growing
scale of rule library, and the time is increasing linearly.
This is consistent with that the unsatisfiable user requests’
mean processing time is also a linear growth which is
shown in Figure 17. This is because the unsatisfiable user
2094 IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 25, NO. 4, AUGUST 2017
Fig. 19. A comparison of transactions per second.
Fig. 20. A comparison of the response times.
request’s processing time includes constructing scene rules
many times, thus the growth trend is basically the same. The
above mentioned two groups of results present that scene-
based dynamic service coordinative method can response to
whatever satisfiable or unsatisfiable user request in a short
time. Especially for satisfiable user request, this method is
able to rapidly generate a executable combination service to
satisfy the user request.
D. The Response Time for Service Coordination
A typical surgical workflow process is used to test the per-
formance of Event Driven SOA-based (EDSOA), framework-
based (e.g., ReCEPtor [32]), CHEVICHE [33] conventional
request-response-based and framework-based IoT services
coordination approaches. In this test, the Apache Orchestration
Director Engine (ODE) is used as the centralized Web services
orchestration and coordination engine. The BPEL language is
used to orchestrate a request-response-based coal mine safety
alarm disposal service process. Fig. 19 shows the number of
transactions per second (TPS) for different approaches.
As shown in Fig. 19, in the case of the conventional
re-quest-response services coordination approach, the max-
imum number of TPS is 74, and the average number of
TPS is 64. In the case of the framework-based services
coordination approach, the maximum number of TPS is 118,
and the average number of TPS is 88. However, in the case of
the event driven SOA-based services coordination approach,
the maximum number of TPS is 167, and the average number
of TPS is 130. Fig. 20 shows the corresponding response times
for these three different approaches.
As shown in Fig. 20, in the case of the conventional
re-quest-response services coordination approach, the max-
imum response time is 150 ms, and the average response
time is 134 ms. In the case of the framework based ser-
vices coordination approach, the maximum response time is
90 ms, and the average response time is 78 ms. However, for
the event driven SOA-based services coordination approach,
the maximum response time is 42 ms, and the average response
time is 30 ms. Thus, the processing speed of event-driven
SOA-based services coordination is below that of the conven-
tional request-response and framework based services coordi-
nation approaches. The reason is that there is a central control
point that handles the “request-response” BPEL process, which
may cause all messages to propagate along a longer route
and wait in a central queue for processing. In contrast,
event-driven SOA-based services coordination uses the
event’s asynchronous communication mechanism to support
the concurrent coordinated execution of multiple services.
Furthermore, the event driven SOA-based services coordi-
nation approach has several advantages over a framework-
oriented approach at developing dynamically adapting
business processes, which provides general models that need to
be instantiated and customized before they are implemented.
Since those models operate at a higher-level of abstraction
than frameworks, they impose fewer initial constraints upon
the system being developed. Therefore, the event driven
SOA-based services coordination approach is more suitable
for IoT application scenarios that are highly delay sensitive
and demand a strict real-time response.
VI. CONCLUSIONS AND FUTURE WORK
This paper proposed a situation-aware dynamic IoT services
coordination approach. The formal situation event pattern
with event selection and consumption strategy is defined,
and an automaton-based situational event detection algo-
rithm is proposed. Also, an Enhanced Event-Condition-Action
(E-ECA)is used to coordinate the IoT services effectively,
and the rule mismatch detection algorithm is implemented.
The result demonstrated that the situation-aware IoT service
coordination approach works efficiently. Nevertheless, there
are some problems still to be addressed. First, it is important
to optimize the real-time data distribution service for large-
scale IoT application. Second, it is essential to create a uni-
form resource access framework for different physical sensory
devices. Third, it should provide an easy and open API for
users, such as RESTful interface, all those works are currently
in progress in our lab.
REFERENCES
[1] J. Zheng, D. Simplot-Ryl, C. Bisdikian, and H. T. Mouftah,
“The Internet of Things,” IEEE Commun. Mag., vol. 49, no. 11,
pp. 30–31, Nov. 2011.
[2] B. Cheng, X. Cheng, and J. Chen, “Lightweight monitoring and control
system for coal mine safety using REST style,” ISA Trans., vol. 54,
no. 1, pp. 229–239, 2015.
[3] J. Kim et al., “Standard-based IoT platforms interworking: Implemen-
tation, experiences, and lessons learned,” IEEE Commun. Mag., vol. 54,
no. 7, pp. 48–54, Jul. 2016.
[4] B. Cheng, S. Zhao, S. Wang, and J. Chen, “Lightweight mashup
middleware for coal mine safety monitoring and control automation,”
IEEE Trans. Autom. Sci. Eng., vol. 14, no. 2, pp. 1245–1255, Apr. 2017.
[5] J.-S. Leu, C.-F. Chen, and K.-C. Hsu, “Improving heterogeneous
SOA-based IoT message stability by shortest processing time schedul-
ing,” IEEE Trans. Serv. Comput., vol. 7, no. 4, pp. 575–585, Oct. 2014.
[6] D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, and D. Savio, “Interacting
with the SOA-based Internet of Things: Discovery, query, selection, and
on-demand provisioning of Web services,” IEEE Trans. Serv. Comput.,
vol. 3, no. 3, pp. 223–235, Jul./Sep. 2010.
CHENG et al.: SITUATION-AWARE DYNAMIC SERVICE COORDINATION IN AN IoT ENVIRONMENT 2095
[7] R. T. Tiburski, L. A. Amaral, E. De Matos, and F. Hessel,
“The importance of a standard security architecture for SOA-based
IoT middleware,” IEEE Commun. Mag., vol. 53, no. 12, pp. 20–26,
Dec. 2015.
[8] A. G. De Prado, G. Ortiz, and J. Boubeta-Puig, “CARED-SOA:
A context-aware event-driven service-oriented Architecture,” IEEE
Access, vol. 5, pp. 4646–4663, 2017.
[9] B. Medjahed, “Dissemination protocols for event-based service-oriented
architectures,” IEEE Trans. Serv. Comput., vol. 1, no. 3, pp. 155–168,
Jul. 2008.
[10] S. Overbeek, B. Klievink, and M. Janssen, “A flexible, event-driven,
service-oriented architecture for orchestrating service delivery,” IEEE
Intell. Syst., vol. 24, no. 5, pp. 31–41, May 2009.
[11] C. Perera, A. Zaslavsky, P. Christen, and D. Georgakopoulos, “Context
aware computing for the Internet of Things: A survey,” IEEE Commun.
Surveys Tuts., vol. 16, no. 1, pp. 414–454, 1st Quart., 2014.
[12] J. He, Y. Zhang, G. Huang, and J. Cao, “A smart Web service based
on the context of things,” ACM Trans. Internet Technol., vol. 11, no. 3,
p. 13, 2012.
[13] Y. Wang et al., “CATrust: Context-aware trust management for
service-oriented ad hoc networks,” IEEE Trans. Serv. Comput.,
to be published, doi: 10.1109/TSC.2016.2587259.
[14] A. Maarala, X. Su, and J. Riekki, “Semantic reasoning for context-aware
Internet of Things applications,” IEEE Internet Things J., vol. 4, no. 2,
pp. 461–473, Apr. 2017.
[15] H. Tter and A. Sztajnberg, “Adapting heterogeneous devices into an IoT
context aware infrastructure,” in Proc. IEEE/ACM 11th Int. Symp. Softw.
Eng. Adapt. Self-Manag. Syst., Austin, TX, USA, May 2016, pp. 64–74.
[16] I.-Y. Ko, H.-G. Ko, A. J. Molina, and J.-H. Kwon, “SoIoT: Toward a
user-centric IoT-based service framework,” ACM Trans. Internet Tech-
nol., vol. 16, no. 2, p. 8, 2016.
[17] R. Kyusakov, P. P. Pereira, J. Eliasson, and J. Delsing, “EXIP: A frame-
work for embedded Web development,” ACM Trans. Internet Technol.,
vol. 8, no. 4, p. 23, p. 2016.
[18] S. Mayer et al., “User interfaces for smart things—A generative
approach with semantic interaction descriptions,” ACM Trans. Comput.
Human Interaction, vol. 21, no. 2, p. 12, 2014.
[19] J. Im, S. Kim, and D. Kim, “IoT Mashup as a service: Cloud-based
mashup service for the Internet of Things,” in Proc. IEEE Int. Conf.
Services Comput., Jun. 2013, pp. 462–469.
[20] L. Mainetti, V. Mighali, and A. L. Patrono, “A software architecture
enabling the Web of Things,” IEEE Internet Things J., vol. 2, no. 6,
pp. 445–454, Jun. 2015.
[21] E. Kaldeli, E. U. Warriach, A. Lazovik, and M. Aiello, “Coordinating
the Web of services for a smart home,” ACM Trans. Web, vol. 7, no. 2,
p. 10, 2013.
[22] S. Mayer, R. Verborgh, M. Kovatsch, and F. Mattern, “Smart configu-
ration of smart environments,” IEEE Trans. Autom. Sci. Eng., vol. 13,
no. 3, pp. 1247–1255, Mar. 2016.
[23] Y. Ding, Y. Jin, L. Ren, and K. Hao, “An intelligent self-organization
scheme for the Internet of Things,” IEEE Comput. Intell. Mag.,vol.8,
no. 3, pp. 41–53, Aug. 2013.
[24] Z. Wen, R. Yang, P. Garraghan, T. Lin, J. Xu, and M. Rovatsos,
“Fog orchestration for Internet of Things services,” IEEE Internet
Comput., vol. 21, no. 2, pp. 16–24, Feb. 2017.
[25] M. Stecca, C. Moiso, M. Fornasa, P. Baglietto, and M. Maresca,
“A platform for smart object virtualization and composition,” IEEE
Internet Things J., vol. 2, no. 6, pp. 604–613, Jun. 2015.
[26] R. Mateescu, P. Poizat, and G. Salaün, “Adaptation of service protocols
using process algebra and on-the-fly reduction techniques,” IEEE Trans.
Softw. Eng., vol. 38, no. 4, pp. 755–777, Apr. 2012.
[27] W. Kongdenfha, H. R. Motahari-Nezhad, B. Benatallah, F. Casati, and
R. Saint-Paul, “Mismatch patterns and adaptation aspects: A foundation
for rapid development of Web service adapters,” IEEE Trans. Serv.
Comput., vol. 2, no. 2, pp. 94–107, Apr. 2009.
[28] A. Moustafa, M. Zhang, and Q. Bai, “Trustworthy stigmergic service
compositionand adaptation in decentralized environments,” IEEE Trans.
Services Comput., vol. 9, no. 2, pp. 317–329, Mar./Apr. 2016.
[29] S. Zhou, K.-J. Lin, J. Na, C.-C. Chuang, and C.-S. Shih, “Supporting
service adaptation in fault tolerant Internet of Things,” in Proc. IEEE
8th Int. Conf. Service-Oriented Comput. Appl. (SOCA), vol. 21. Rome,
Italy, Oct. 2015, pp. 65–72.
[30] B. Cheng, D. Zhu, S. Zhao, and J. Chen, “Situation-aware IoT service
coordination using the event-driven SOA paradigm,” IEEE Tran. Netw.
Services Manag., vol. 13, no. 2, pp. 349–361, Jun. 2016.
[31] Esper Product. Open Source Project, Version 5.1.0,
accessed on Oct. 2014. [Online]. Available: http://www.
espertech.com
[32] M. Wei, I. Ari, J. Li, and M. Dekhil. ReCEPtor: Sensing Complex Events
in Data Streams for Service-Oriented Architectures, accessed on 2007.
[Online]. Available: http://www.hpl.hp.com/techreports/2007/HPL-
2007-176.html
[33] G. Hermosillo, L. Seinturier, and L. Duchien, “Using complex event
processing for dynamic business process adaptation,” in Proc. IEEE
SCC, Jul. 2010, pp. 466–473.
Bo Cheng received the Ph.D. degree in computer
science from the University of Electronics Science
and Technology of China in 2006. He is currently a
Professor of the State Key Laboratory of Networking
and Switching Technology, Beijing University of
Posts and Telecommunications. His research inter-
ests include multimedia communications and ser-
vices computing.
Ming Wang received the master’s degree from
the University of Science and Technology Beijing
in 2011. He is currently pursuing the Ph.D. degree
in computer science and technology with the State
Key Laboratory of Networking and Switching Tech-
nology, Beijing University of Posts and Telecommu-
nications. His research interests include multimedia
networking and media processing.
Shuai Zhao is currently a Post-Doctoral Fellow with
the State Key Laboratory of Networking and Switch-
ing Technology, Beijing University of Posts and
Telecommunications. His current research interests
include Internet of Things and service computing.
Zhongyi Zhai is currently pursuing the Ph.D.
degree in computer science and technology with the
State Key Laboratory of Networking and Switching
Technology, Beijing University of Posts and
Telecommunications. His current research interests
include service mashup, end-user programming,
mobile computing, and Web technology.
Da Zhu is currently pursuing the Ph.D. degree with
the State Key Laboratory of Networking and Switch-
ing, Beijing University of Posts and Telecommunica-
tions, Beijing, China. His current research interests
include Web service composition, communication
Web service, and Internet of Things.
Junliang Chen is currently a Professor of the
Beijing University of Posts and Telecommunica-
tions. His research interests are in the area of service
creation technology. He was elected as a member
of the Chinese Academy of Science in 1991 and
a member of the Chinese Academy of Engineering
in 1994.
