This article has been accepted for inclusion in a future issue of this journal.

Content is final as presented, with the exception of pagination.

IEEE/ACM TRANSACTIONS ON NETWORKING 1

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. I NTRODUCTION
A LONG 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
with different capabilities such as sensors, actuators, smart
Manuscript received January 3, 2016; revised December 25, 2016; accepted
February 13, 2017; approved by IEEE/ACM T RANSACTIONS ON N ETWORK -
ING Editor A. X. Liu. 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
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.
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
a certain event occurs, different services can be triggered
 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
2 IEEE/ACM TRANSACTIONS ON NETWORKING
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. R ELATED W ORKS
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,
 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

CHENG et al.: SITUATION-AWARE DYNAMIC SERVICE COORDINATION IN AN IoT ENVIRONMENT 3

[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
Fig. 1. A typical surgical workflow.
with each other by an information exchange network, which
is constructed based on endocrine mechanism, to accomplish in this dynamic and unpredictable environment. In particular,
the tasks and objectives. For the large-scale IoT scenarios performing a surgery requires extensive information sharing,
(e.g., healthcare, smart cities), [24] proposes a fog-enabled coordination, emergent situation detection, and immediate
orchestration architecture to loosely coordinate the fog nodes reactions. Meeting these requirements is very difficult if no
in IoT environment. Reference [25] proposes a “virtual block” proper technology is used to help monitor patient flows, track
concept (i.e., services), to deal with device heterogeneity and medical devices, and alert personnel to unexpected situations.
to support the orchestration of smart objects in complex IoT Failures in these areas can threaten patient safety, decrease
environment. It also proposes a late binding mechanism for operational efficiency, and increase medical costs.
implementing a context-aware and self-adapting platform of As shown in Fig. 1, a typical surgical workflow is used
physical devices. to illustrate the challenges in performing a surgery. This
workflow generally involves three phases, namely, preoper-
D. IoT Service Adaptation ative, intraoperative, and postoperative. Five groups of partic-
ipants are involved in this procedure, namely patients (P1),
Standardization in web service simplifies the interoper-
porters (P2), nurses (P3), anesthetists (P4), and surgeons (P5).
ability, however, it does not remove the mismatches among
Surgical related locations can include the ward (L1), holding
services due to possible heterogeneity of service inter-
area of the operating suite (L2), operating suite (L3), holding
faces and protocols. Service adaptation provides an effective
area of the operating room (L4), operating room (OR) (L5),
solution to deal with the mismatches by using corrective
recovery room (L6), and intensive care unit (ICU) (L7).
mechanisms [26]. In [27], authors summarize some mismatch
During this surgery process, several emergent events might
patterns on the service interface and protocol levels, and
occur, which if not attended to could cause, among other
propose an adaptation method by developing stand-alone adap-
things, critical surgical instruments to be missing from the OR,
tors. Reference [28] proposes a stigmergic-based approach to
potentially resulting in patient death. Without IoT technology,
model the service composition and adaptation in decentralized
tracking the locations of a patient and instrument in real time
environments. To address dynamic changes in the complex
is impossible and therefore finding both in an emergency can
decentralized system, diversity schemes are incorporated into
be very difficult. Another potential problem can occur when
the proposed approach to promote continuous adaptation
manually checking a patient’s medicine, where human error
features. In IoT environment, especially, many devices use
may directly result in medical accidents. Finally, the proper
different communication protocols and data payload formats,
technology should offer the ability to detect critical situations
which lead to more heterogeneity of IoT services. From
in advance, thus avoiding many potentially serious situations.
the perspective of fault-tolerant capability, [29] proposes an
For example, a nurse may mistakenly send a patient to a
adaptation scheme for IoT devices based on service-oriented
wrong OR, so his/her surgery will be delayed. In addition,
architecture. In the scheme, authors introduce a concept of
during the operation, if there are indications that a patient
virtual service that can use data from more than one sensor
may be in danger of having an unexpected heart attack,
devices to replace the actual service on some faulty device.
an additional medical device might be needed for emergency
use; however, if it does not get sent to the right OR in time,
III. A N A PPLICATION S CENARIO there could be serious consequences. Therefore, this dynamic
The hospital in this scenario is a large, extremely busy, and sometimes unexpected environment raises a number of
and chaotic organization, where hundreds of medical cases are challenges for surgery operations.
treated every day. Hundreds of doctors and other staff members
are walking about constantly; inpatients and outpatients are IV. T HE P ROPOSED A PPROACH
moving around the hospital under surveillance; and medical A situation-aware, dynamically-adaptable IoT service coor-
devices are commonly recalled for emergency use. Although dination system is proposed. First, an important primitive
information systems have been used to support the work of event or a combination of events is detected in the event cloud;
medical professionals, they are not able to accurately track next, the specific service response, such as the generation of
patient flow and asset flow in real time. Thus, sensing and a service call or event notifications, is determined through
responding quickly to critical situations becomes impossible defined business rule matching. During this process, not only
 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
4 IEEE/ACM TRANSACTIONS ON NETWORKING
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 , a2 , . . . , am }, m > 0, is the attribute set of
that specific primitive event, t is the event occurrence time,
and l is the event occurrence location.
Definition 3 (Composite Event): A composite event can be
defined as ec = ec (id, a, c, ts , te ), te ≥ ts , in which the
first two items, id and a, have a similar definition to that of a
primitive event. Furthermore, c = {e1 , e2 , . . . , en }, n > 0 is
TABLE I
SEP RULE S TRUCTURE
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 ts and te are
respectively the beginning and ending times of the event,
that is, the particular event can occur within the time period
from ts and 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, T rigF rom, 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 W here clause in the third line
of the rule structure describes the constraint conditions that
attributes Attr1 , . . . , Attrn (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 ec1 is found to match rule1
(heart_attack), so the complex event “The patient is facing
a heart attack” is detected. Similarly, ec2 is 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
 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
CHENG et al.: SITUATION-AWARE DYNAMIC SERVICE COORDINATION IN AN IoT ENVIRONMENT
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 , Se , In, Out >, where
1) S is the SA’s state set;
2) T ⊆ S × S represents the transition relations between
states, which typically must satisfy certain event con-
straints;
3) Ss is the SA’s initial state;
4) Se is 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
5
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 r is decomposed into one or more event
sequence models MES ; all event sequences (ES) are linear
deterministic automata; every event related to r represents
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 (Ss is the automaton’s
initial state; Se is 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 e arrives, this MES begins
processing following the steps listed in Algorithm 1.
Algorithm 1 Event Automaton Processing (EAP)
1 Initialize the event sequence in MES as ES0 ;
2 if Event e satisfies state transition conditions of MES
then
3 if e can trigger some state si migrating to si+1 then
4 create a copy ESi+1 from this ESi ;
5 Change the state of ESi from si to si+1 ;
6 if exceeded the time constraint then
7 delete this ES and Goto line 2;
8 end
9 if 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 ES0 is 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 ES0 of the
event sequence model M SE1 is at the state of ’wait for
events’. When t = 1, the heart rate H1 enters the automata.
By checking the class, content, and time, it is identified that
H1 satisfies the state transition condition of ES0 . Then, create
ES1 and change its state to HeartBeat; similarly, when t = 2,
H2 enters the automata. Then, create ES2 and change its
 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
6 IEEE/ACM TRANSACTIONS ON NETWORKING
Fig. 4. An illustrative example for the processing procedure of SA.
state to HeartBeat. When t = 4, the arriving event is blood
pressure B1 with location Area5. Since there is no blood
pressure event meeting the conditions located in Area5, B1 is
discarded. When t = 7, since the 5 minute constraint becomes
invalid for the ES1 that is created at t = 1, ES1 can
no longer migrate and is discarded. Meanwhile, the arrival
of H3 leads to the creation of ES3 and its migration to
HeartBeat state. When t = 8 discard ES2 , for the same
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 H3 and B2) has been created.
Similarly, when B3 arrives at t = 9, create ES32 and change
its state to BloodPressure; then the second matched event
model (consisting of H3 and 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 A to 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: Operate A and enter the next state
when the service object receives a triggering event E
and condition C has been satisfied; and
3) E-C n -An pattern: Operate An and enter the next state
only when the service object receives a triggering event
E and condition C n has been satisfied, in which: C n =
{Condition1 C / Condition2 C / ... C/ Conditioni },
/ ∈ {∧, ∨}, i ≥ 1;
C
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 1 completes
action a1 , event e2 is either produced or received, causing
rule 2 to be executed; the completion of action a2 will
similarly cause the state to transfer, causing rule 3 to 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 , events e2 and e2 are produced or received,
 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
CHENG et al.: SITUATION-AWARE DYNAMIC SERVICE COORDINATION IN AN IoT ENVIRONMENT
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 , a2a , e3a ) and (e2 , a2b , e3b ). At the tail end,
the eia and eib produced by branches (ei−1,a , ai−1,a , eia ) and
(ei−1,b , ai−1,b , eib ) 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 2 receives the triggering event e2 , loop
action a2 is executed first, and so forth; then certain commands
are executed according to the sequence to rule i − 1. If the
loop condition of rule i−1 is satisfied, then the system returns
7
Fig. 10. The Do-While loop structure control.
Fig. 11. The While-Do loop structure control.
to rule 2 to 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 2 receives event e2 , condition c2 is 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 ), in which:
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) S denotes 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)}, where Ss ⊆ S is the source service and Sd ⊆ S is
the target service;
4) CP denotes the composite control flow pattern
that exists between services in the collaborative
 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

8 IEEE/ACM TRANSACTIONS ON NETWORKING

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 , a set of event
flow Ef
1 Create a queue Q;
2 foreach ss ∈ Ss (P ) do
3 EN QU EU E(Q, ss );
4 end
5 while Q is not empty do
6 s = DEQU EU E(Q);
Fig. 12. An Event driven service collaboration action model. 7 if process(s) is not assigned then
8 P ← new local processPL ; P rocess(s) := PL ;
process; besides the most common Sequence pattern, 9 end
there also exist two main types: a division pattern 10 foreach ssubsequent ∈ Ssubsequent (s) do
Split(AN D, XOR, OR) and an aggregation pat- 11 EN QU EU E(Q, ssubsequent );
tern Join(AN D, XOR, OR); and 12 end
5) CM : S → SP indicates the control mapping relation 13 next
set from S to SP ; in a single local service domain, 14 foreach spre ∈ Spre (s) do
at least one mapping occurs from S to SP , therefore, 15 if SP (s)
= SP (spre ) then
the relationship between S and SP is either one-to- 16 Ef ← f (spre , s)
one or many-to-one. 17 end
Definition 8 (Control Flow): The control flow of a collabo- 18 else if SP (s) == SP (spre )&&process(s) is not
rative process is a two-element set, Cf = (S  , CF  ), in which assigned then
S  ⊆ S and CF  ⊆ CF are, respectively, the service 19 process(s) := process(spre );
set and execution dependency relationship between services 20 PL ← CFL (spre , s);
in the collaborative process. If completing the execution 21 end
of services1triggers service s2 , then there exists an execu- 22 else if SP (s) == SP (spre )&&process(s)
=
tion dependency relationship between S1 and S2 , that is, process(spre ) then
Depexec(S1 , S2 ) ∼ = Dep(S1 .complete(), S2 .active()). 23 PL = PL \process(spre );
Definition 9 (Local Process): The local process model is 24 foreach s ∈ S(process(spre )) do
similar to the collaborative process model, but it does not con- 25 process(s ) := process(s);
tain a local service domain SP; the local process model can be 26 end
defined as a four-element set: PL = (SL , CFL , CPL , CML ), 27 end
in which SL ⊂ S, but CFL
⊂ CF , because when a global col- 28 end
laborative process is decomposed into many local processes, 29 end
additional service dependency relationships are produced. 30 return (PL , Ef );
Definition 10 (Event Flow): The event flow in a collabora-
tive process is defined as Ef = (SE , E, SD , ER ), where
SE is the source service of the produced event flow Ef , E is (steps 1-4) to the starting service ss ∈ Ss (P ) of the
the event set produced by SE , SD is the target service set collaborative process P . From step 3 to step 29, the algorithm
corresponding to a specific event, and ER : SE → SD is the searches for the control flow and event flow of collaborative
corresponding event flow relation of a service in SE and the process P using a breadth-first search algorithm. For every
relevant services in SD . service s in the sequence, if it is a starting service that does not
As described above, the global collaborative process PC have prior services, then a new local process PL is created, and
describes the collaborative relationship between many organi- s is placed under the newly created local process (steps 7-9).
zations within a service system, representing the macro view Steps 10-12 of the CPD algorithm place the subsequent
of the business process. To obtain the micro view of specific services of s into sequence Q, for the convenience of con-
executable rules, as described by E-ECA, the collaborative tinuing the breadth-first search. Afterward, for every service s
process PC must first be decomposed into a series of local in Q, the service domain to which it belongs is compared with
process PL models under the service domains to which the the service domain of the prior service spre ; if the service
different organizations belong, as well as the interaction event domains are different, then they are considered to belong
flow Ef models between the local processes; then, these to different local processes. Thus, an event f (spre → s)
two types of models can be converted into E-ECA rules from spre to s is created and stored in event flow
 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
CHENG et al.: SITUATION-AWARE DYNAMIC SERVICE COORDINATION IN AN IoT ENVIRONMENT
Fig. 13. An example: the refined surgery management collaborative process.
Ef (steps 14-15). If the service domains of s and spre are the
same, then s and spre belong to the same local process. In this
context, two different situations must be catered for if the
local process to which s belongs has not yet been determined,
then the set of local processes s is equal to that of spre .
Simultaneously, a control flow CFL (spre → s) from spre to
s can be created and stored in the corresponding local process
PL (steps 18-21). If the local process to which s belongs is
determined, and is different from that of spre , 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 PC contains 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 ∈
P SS; S3, S4, S7, S10, S12, S13 ∈ N AS; S5, S6 ∈
AAS; and S8, S9, S11 ∈ P SS.
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
9
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., the XOR-split
control pattern of S5 and S10, and the XOR-join pattern
of S12. However, for more than one control flow conver-
sion or during the service of an event interaction, S4 and
S9 are both AN D-split, and S7, S10, and S11 are all
AN D-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, S1 corresponding to local
process P 1 in the service domain P SS (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, S1 will 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 S2 of local process P 1 that belongs
to the same service domain P SS (i.e., the patient receives
the information that the surgery treatment process has been
entered). The service cycle of S2 is mostly similar to S1;
the difference is in the specific service provided. However,
for S3 in N AS (i.e., the nurse is inspecting the patient’s
identity and physical condition) the beginning flow constraint
 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
10
TABLE II
P ORTION OF THE E-ECA RULE S ET
is that the nurse had received information that the S2 service
was completed through N AS. 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 S3 is 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 S3 is changed to ’Completed.’ The ending flow constraint
of S3 is the production of an internal control flow event that
triggers S4 service, which also belongs to N AS. In S4 (i.e.,
patient transfer), the beginning flow constraint is receiving
information of the completion of S3 through N AS. In the
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 S7 or S10, and the transmission of an event flow
’E-4-5’, which notifies the anesthetist that the patient has
arrived, that is, to begin S5 service 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
IEEE/ACM TRANSACTIONS ON NETWORKING
TABLE III
P ORTION OF THE E-ECA RULE S ET
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.
 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

CHENG et al.: SITUATION-AWARE DYNAMIC SERVICE COORDINATION IN AN IoT ENVIRONMENT 11

Algorithm 3 Rule Mismatch Detection (RMD)

Input: Global rule set RSG {Es , Cs , As }, Action
constraint AC , Interim Action Set
AI = {aI , CI }, New rules
Rnew = (ES−new , CS−new , AS−new );
Output: Mismatch set SMis (e, Ac , RMis ), where e is
the mismatch inducing trigger event, and Ac
and RMis are, respectively, the Action
constraint under the mismatch condition and the
corresponding mismatch rule set;
1 The initial value of SMis is set to naught;
2 Create a temporary condition set AI−new ()
corresponding to Rnew ; Definition 12 (Action Constraint Graph (ACG)):
3 The initial value of AI−new is set to naught; An action constraint graph can be defined as an undirected
4 foreach action a of action set AI−new in Rnew do graph ACG = (P, Saction , Ω), in which P corresponds to
5 if action a under condition C( I − new) is to call a an ECA rule-based service process, Saction is an existing
certain service then service constraint action set registered in that process, and
6 AI−new = AI−new ∪ {(a, CI−new )}; Ω : Saction × Saction is a pair-wise action constraint relation
7 end in the action set.
8 if action a is to produce a certain event etrig and Definition 13 (Global Rule Set (RSG )): The global rule
trigger more rules then set of a process is RSG = ∪1inumberof Rules(RSG ) Ri ,
9 AI−new = AI−new ∪ {(atrig , Ctrig ∧ CI−new )}; where Ri = {ERi , ERi , ERi }, and ERi , ERi , ERi , respec-
tively, correspond to the event set, condition set, and action
10 (atrig , Ctrig ) ∈ AI (etrig );
set contained in Ri .
11 end
Definition 14 (Event Implication Relation): For a sequence
12 end
of two events Eα and Eβ , if the occurrence of Eα implies that
13 foreach event e of event set ES−new in Rnew do
Eβ must also occur, then Eα and Eβ are defined as having an
14 search for the M ost Implicative Event(EMi ) in
implication relation (Eα implies Eβ ,), denoted as Eα → Eβ .
RSG ;
15 end
Definition 15 (AND Satisfiability): Assume that ci is a con-
16 if EMi does not exist then
dition of a certain rule in the RSG of a certain global rule
set; if ci can satisfy all of the rules in RSG , then ci is said
17 jump to line 25 and immediately perform a rule
to have AN D satisfiability relative to that RSG .
mismatch check;
18 end Definition 16 (Rule Mismatch): For a rule set RS, if at
19 else least two service actions belong to Action constraint Ac , then
20 foreach sub-event eimp in EMi do a rule mismatch exists in RS; the rule mismatch can easily
21 AI = AI (eimp ) ∪ AI−new ; induce conflict between rules.
22 end Definition 17 (Rule Mismatch Graph (RMG)): A rule mis-
23 jump to line 25 and perform a rule mismatch check; match graph can be defined as a directed-graph RM G =
24 end
(P, R, RMis ), in which P corresponds to an ECA-based
service process, R is all of the rules registered in that process,
25 For AC , perform the following steps:
and RMis is the rule set in which the mismatch exists.
26 if AC ⊂ {a|(a, C) ∈ AI } then
Based on the above definitions, to ensure effective collabo-
27 AI−Mis = {(a, C) ∈ AI |a ∈ Ac };
ration in subsequent service periods from the stage of rule
28 RMis = {R ∈ RSG |(a, C) ∈ AI−Mis and a ∈ AS };
design, the following rule mismatch detection algorithm is
29 end
proposed and applied to an example for verification.
30 if detect AI−Mis has AN D satisfiability then
31 SMis = SMis ∪ {e, AC , RMis };
32 end
V. P ERFORMANCE M EASUREMENT AND A NALYSIS
33 if SMis is naught then A. The Experimental Setup
34 refresh AI−new (ES−new ); The situation-aware IoT services coordination platform was
35 end installed on a PC server (2.5 GHz Intel Xeon E5420 with
36 else 10 G of RAM). A real operating room (OR)in a hospital
37 return SMis ; is selected as the basic experiment environment; all types
38 end 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
Definition 11 (Action Constraint (AC)): An action con- have been simulated as a semi-physical emulations experiment
straint is a limitation on the concurrence of a set of service environment to evaluate the performance of the proposed IoT
call actions. services coordination platform.
 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
12
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 coordinative method 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
IEEE/ACM TRANSACTIONS ON NETWORKING
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
 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
CHENG et al.: SITUATION-AWARE DYNAMIC SERVICE COORDINATION IN AN IoT ENVIRONMENT
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
13
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. C ONCLUSIONS AND F UTURE W ORK
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.
R EFERENCES
[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.
 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
14
[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.
IEEE/ACM TRANSACTIONS ON NETWORKING
[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.