NETWORKS & SECURITY

An Open IoT Framework Based on Microservices

Architecture
Long Sun*1, Yan Li2, Raheel Ahmed Memon3,4
1
College of Computer Science, Sichuan University, Chengdu 610064, China.
2
College of manufacturing Science and Engineering, Sichuan University, Chengdu 610064, China.
3
School of Computer Science, University of Engineering Science and Technology, Chengdu 610064, China
4
Department of Computer Science, Sukkur Institute of Business Administration, Sukkur, Sindh, Pakistan
*
The corresponding author

Abstract: With the continuous development new, there have been several different names
and evolvement of Internet of Things (IoT), and one of such names is “Internet of Infinite
monolithic application becomes much larger Things”, the dreamworld which everything
in scale and even more complex in structure. may communicate with each other. Today, we
This leads to poor scalability, extensibility and have a large number of physical entities inter-
maintainability. In response to those challeng- connected and integrated into the information
es, microservice architecture has been intro- space to interchange generated data using
duced in the field of IoT application, due to communication technologies. Previously a
its flexibility, lightweight and loose coupling. number of research work [3-4] focused on the
However, the existing IoT framework of mi- connectivity challenges. However, with newly
croservice mainly focus on a specific domain, developed systems, the existing structure has
therefore, this greatly limits its application. In given birth to several new research challenges.
this paper, we propose a general microservice With the development of technology, the IoT
system framework for the IoT application, applications [5-11] have started to consider
which is a better scalable, extendable and how to integrate the existing network facilities
maintainable architecture. We introduce its and the openness and scalability of the system
system design and related microservices, and design. Compared with existing services, such
emphasize on core service and device commu- as telecommunication services or Internet
nication from service layer to physical layer. It applications, IoT service faces with new sit-
has better capacity to support interoperability uation. The huge information collected from
and accommodate heterogeneous objects. In perception layer (involving a large number of
addition, this framework can easily achieve sensors) is further processed and delivered to
more application integration such as automa- different applications according to the require-
tion, intelligence, Geo service and Big Data. ments, then is used to trigger the correspond-
Keywords: Internet of things; IoT; micro ser- ing collaborative business system. As the IoT
vice; software architecture technology is widely used in daily life, the
events produced by sensors and objects are
I. INTRODUCTION becoming astronomical. The task is enormous
Received: Jun. 08,2016
and immense services response to the requests. Revised: Oct. 19. 2016
The term IoT (Internet of things) is not very IoT services system should coordinate man- Editor: Mugen Peng

China Communications • February 2017 154

 power and business process to quickly interact programmers can enjoy the freedom of coding
In this paper, a generic with the physical entities across the business with simplified integration
comparison between domains, even across the organizations based In a nutshell, with the development of IoT
two architectures has on the processing and integrating of distribut- technology, traditional architecture can’t meet
been discussed. Based
ed multisource sensing information. Because the requirements of heterogeneous, interoper-
on these foundations,
the authors have pro-
of the variety of business process, personal able, customizable and scalable systems. To
posed a microservice and physical entities involved, physical world deal with above challenges, we put forward
system framework for continuously changes, IoT services are char- an open IoT framework by decomposing IoT
the IoT. acterized by real time changes. It brings new system into microservices to perform different
technical challenges to IoT services such kinds of tasks. By using message driven and
as: heterogeneity of hardware, network and registry/discovery mechanism in core service,
operating system, interoperability between the framework can easily extend, evolve and
applications and services, fusion of massive integrate third party applications to support
heterogeneous data, scalability and continuous interoperability and scalability. Moreover, the
integration. system uses device plugins to shield the differ-
Heterogeneity of hardware, network and ences of hardware facilities in order to support
operating system. Available IoT devices more heterogeneous platforms. In particular,
(sensors and actuators) are vendors specific as integrated with a series of microservices,
where the communication protocols and data the framework delivers strong mechanism for
exchange formats vary from device to device. fusing heterogeneous data through hierarchical
The complexity increases exponentially when preprocessing mass sensors data.
simple devices are integrated to form a com- The paper is organized as follows: Section 2
plex network and it is difficult to provide a introduces the related research about the archi-
unified solution for IoT application. tecture of monolithic and microservice of IoT
Interoperability between applications and application. Section 3 deals with the suggested
services. In the IoT application, many actors microservice IoT system architecture. Section
comprising human and nonhuman objects and 4 presents how to implement the system and
many systems are designed for specific appli- makes a comparison among the related IoT
cations, adopting specific data standards and system. Finally, Section 5 presents a conclusion
communication platforms. Different platforms on the advantages and the limits of the micros-
lead to great inconvenience for achieving in- ervice IoT system, and the future work.
teroperability and mutual communication in
IoT applications. II. RELATED WORK
Fusion of massive heterogeneous data.
While data collected in the IoT generates bil- The previous research of IoT system mainly
lion pieces of information with hundreds of includes two categories: monolithic and mi-
data formats, it’s hard to classify vast amount croservice architecture.
of raw data by a complex module in traditional
2.1 Monolithic architecture
architecture, and it also easily leads to system
overload if a large number of redundant data In the monolithic architecture [1] software
directly goes to the application layer. system is deployed as a single solution, in
Scalability and continuous integration. IoT which functionally distinguishable aspects
aims to keep on growing all the time and it are all interwoven [2]. The natural advantages
has generated a lot of complex code. Devel- of monolithic architecture are module inde-
opers with different technological skills often pendent, uniform standards and technology
concern differently and everyone has their stack. Many researches offer solutions from
own limitations. So a good and independent perspective of monolithic architecture. Earlier
architecture can offer a mechanism that the IoT studies mainly focus on hardware network

155 China Communications • February 2017

and low-level software technology [3]. For be easily deployed and released internally to
instance, Wireless Sensor Networks (WSN) the production environment in isolation and
[4] is a major approach of IoT, but it has lim- the modification of services would not affect
ited capacity and weak scalablity. To address the whole system. Any applicable tools and
these issues, some researches like ubiSOAP languages can quickly realize a specific ser-
[5] WoT/SDN [6] focus on high-level IoT ap- vice. Compared with the traditional monolithic
plication programming, which uses standard architecture, the microservice architecture has
middleware to implement a layered communi- obvious advantages, such as complexity under
cation. However, these systems are low reus- control, independent deployment, more choic-
ability and portability. TinySOA [7], Servilla es for technology stack and fault tolerance,
[8] and a series of typical Service Oriented Ar- which will facilitate the development of IoT
chitectures (SOA) [9] have been applied in dif- applications on large scale.
ferent applica-tions. To improve the scalablity Many researchers begin to provide IoT
of SOA, an Event-Driven SOA (EDSOA) IoT solution using microservice architecture. For
technology [10] has also been put forward. In example, Vresk and Tomislav [13] present
addition, OpenIoT [11] expands the concept of a microservice based architecture focusing
SOA, and implements Web of Things (WoT). on connecting with heterogeneous devices,
However, with the increasing of the sys- where the system confines to data model as-
tem functions, the IoT becomes more and pect. Krylovskiy et al. [14] discusses how to
more complex in the distributed environment. apply microservice architecture to design a
Monolithic architecture has some inevitable Smart City IoT platform. Bak et al [15] pres-
defects. First, the entire system is a united ap- ents three cloud microservices: contextual
plication; only multiple deployments can im- triggering microservice, visualization micros-
prove the system performance, while the over- ervice, and anomaly detection and root cause
loaded functions create bottleneck, which is a microservice, to accelerate and facilitate the
waste of computing resources. Second, in the development of context and location based
case of the change and evolution of the sys- applications. However, the above mentioned
tem, a change in a function may affect other microservice IoT systems only consider a spe-
functions due to high dependencies. This also cific application. Therefore, it is necessary to
brings complexity for re-deployment, mainte- design a more generic and open framework in
nance and continuous integration. Finally, the IoT system.
whole system uses a sole technology stack and
development standards, which in turn limits III. SYSTEM ARCHITECTURE
the methods to solve the problem of physical
heterogeneity.
3.1 System design
2.2 Microservice architecture
The design of a new generation of IoT frame-
To overcome the drawbacks of monolithic work considers the integration and reusability
architecture, many researchers started to adopt of existing information service system with
microservice architecture [12]. Micro service high cohesion and loose coupling in open and
architecture is a new system software design scalable platform design. The core idea of the
pattern. It suggests that a single large and design is adopting the concept of microservice
complex application should be divided into architecture, based on the analyse of the exist-
small manageable groups, where each group ing IoT system, reconstructing all the business
deals with the related services. According to functions of the system by decoupling them
its specific business responsibilities, each mi- into independent and specific services. The
cro service is dedicated for a single business design is using lightweight communication
function. Therefore, independent services can mechanism to interact between services with a

China Communications • February 2017 156

 minimal overload. are wired together to provide a complete IoT
The proposed design uses a central service platform. The design is consists of eight micro
named as core service to control and coordi- services and one core service coordinating
nate the other microservice in the system; it with all, the microservices are as follows:
is also used to bootstraps one or more tenant Geo, Security, Tenant, Devices, Bigdata, Auto-
engines, which handle most of the other pro- mation, AI and Application. The system is not
cessing logic. The system adopts REST design limited to these services; its design is flexible
pattern to facilitate the access to object data which can be modified or extended according
and to support interoperability with other to the applications requirements.
network. Core communication service encom- 1. Geo Microservice: The service is de-
passes the communication with the objects signed for organize devices by spatial correla-
nodes between the microservices and external tion in order that the events of the devices can
networks. It is provided by a broker micro ser- be gathered into groups in this way, such as lo-
vice to provide asynchronous communication. cation-aware devices. A Geo service provides
In the development of the communication GIS layer to implement map API for render
service, we adopt REST to communicate with location data on it. The service provides REST
client applications. API to invoke map UI library and renders a
Apart from using REST interfaces to in- layer or creates a layer dynamically.
teract with microservices, the system also 2. Security Microservice: The service pro-
implements publish subscribe model to notify vides user/group/role management, authenti-
the clients about the interest events from their cation and authorization, access control, single
subscribed topics, where all the subscribed sign-on and federation, identity governance
topics of a client would push the upcoming and administration. It also supports security
event notification on client side application. monitoring, reporting and auditing. User cre-
From the core service broker, a client can dentials are required for accessing the REST
subscribe multiple interest topics in order to services. When performing create/update op-
receive notifications from multiple services. erations on entities, the access control policies
Fig 1 shows the architecture of proposed of the authenticated user are stored to indicate
microservice IoT system. The overall system which action can be performed by the user.
is composed of different micro services that 3. Tenant Microservice: Based on the mul-
titenant design, the service provides support
for multiple IoT applications by a single core
cmp System architecture service instance. An independent data store
and processing pipeline is owned by each
GEO service Application 20.23 AI tenant, thus data and processing will not
geoserver client UI data mining
mapserver mobile app graph computing blended between tenants. Most components
openlayers SEO semantic web
are also designed as multitenant enabled. This
Security Core Automation supports logic isolation of processing and data
audit
SSO
event process
plugin management
CEP engine
workflow
from different tenants.
user manage registry
4. Device Microservice: The device service
manages various kinds of device plugins, and
Tenant Devices Bigdata
asset kairosDB
implements different communication proto-
actuator
cloud sensor MongoDB
Redis
cols with low level hardware of how to collect
data from sensors and execute command to
actuators. This service provides interface for
core service to invoke plugins callback. It
uses metadata that contains extend context to
Fig.1 The architecture of the proposed IoT framework specific device components. Based on speci-

157 China Communications • February 2017

fications which contain device metadata and includes: (i) event management; (ii) plugin
unique information like hardware identifica- management; and (iii) resource discovery. The
tion, we can assign device plugins associated event manager is responsible for the commu-
with physical objects. More details will be nication among microservices and devices.
introduced in the following subsection. Core service is completely based on events,
5. Bigdata Microservice: The Bigdata any microservice interaction or any change in
service provides support for many kinds of the environment will generate events. Events
scalable persistence to store data. It interacts can be trapped by trigger when are published
with storage implementations by a consistent on channel. By defining in automation micro-
encapsulated API set. By this way, it is easy to service, each trigger is linked to one or more
add new storage technologies to the system. commands. From this architecture, it follows
When operating database, the system never di- that the program behavior is not predetermined
rectly manipulates database. On the contrary, but is fully modificable at runtime, making it
the system provides a set of CRUD API to extremely flexible and adaptable to any possi-
perform data retrieving and storing. ble use in building automation.
6. Automation Microservice: The funda- Core service is provided by the following
mental function is processing events generated components, depicted in Fig. 2: BusMsgLis-
by various event sources, analyses them and tener implements a series of bus listener
notifies appropriate participants according to routine which receives message from objects
the user specified queries. It supports events and sends it to its BusConsumer. Message-
filtering, joining, aggregation, grouping, win- Subscriber subscribes/unsubscribes a message
dow function etc. topic and registers on a channel. BusService
7. Artifical Intelligence Microservice: The provides convenience methods for sending or
AI service based on the IoT bigdata, provides replying messages on a logic channel. Trigger
a series of Artificial Intelligence tools includ- is a kind of event filter. It listens to the events
ing machine learning, data mining, graph which subscribes through the channel. If the
computing, etc. event satisfies the conditions provided by the
8. Application Microservice: This service trigger, it will invoke BehaviorManager which
provides components to support various client translates a generic request, one or more logic
interaction interfaces, such as web UI, PC cli- commands, into a series of hardware com-
ent or moblie app etc. mands to ObjAction. Then these commands
9. Core service. The core service provides will be sent to the corresponding actuator au-
support for data exchanging by message com- tomatically.
munication with the devices. The service uses
broker to obtain/transform/preprocess mes-
class Core Service
sages that produces by objects. Data can be
obtained from many sources including COAP, JoinPlugin
PluginsRepository
Plugin
AMQP, WebSockets, MQTT, socket connec- AutoDiscovery

tions, etc. Commands can be sent to devices

with various protocols such as MQTT, COAP, BusBroker BusService
BehaviorManger

and other protocols. More details will be intro-

duced in the following subsection. MessageProducer
BusMsgListener
3.2 Core microservice specification
MessageSubscriber Trigger ObjAction

Core microservice is a very important microser-

vice in this system, because we use it to handle
all functions related to interacting with devices
and related microservices. Its responsibilities Fig.2 Core microservice UML class diagram

China Communications • February 2017 158

 The plugin components mount bundles will be created accordingly as a part of sys-
from external device microsevice which reg- tem and will start to accept the new incoming
isters in PluginsRepository at runtime. All the events. In this system, each hardware device
sensors and actuators supported in device mi- should have an only identification in order to
croservice are registered in PluginsRepository. be individually addressable. When a device
The resource discovery service is based on boot for the first time, it connects to the core
the Buservice and AutoDiscovery component. service network, a registration event will be
This service is responsible for identifying new triggered when establishing the connection
nodes in the network and loading the hardware with core service. Then the device micros-
triggers and commands mapping from the ervice retrieves corresponding plugins and
metadata retrieved in the device microservice registers it to core service, in response, core
through plugin component. service sends a message to the device service
indicating the registration result.
3.3 Device microservice
2. Devices events handling
This system can manage many heterogeneous After successful registration, devices can
devices through extensible plugins. Sensor interchange various types of events to core
and actuator plugins are tiny software package service. These events may include: location
which can handle low level device communi- updates, temperature, humidity and other data
cation and provide API to microservices. Each obtaining from the sensors, or alerts. Events
plugin is managed by device microservice and are delivered to core service by means of
loaded and initialized automatically at sys- plugins which provides a modular approach
tem startup. The communication between the to support new functions for manipulating in-
plugin and core microservice is automatically coming data.
managed through message middleware. De- 3.Commands delivery
vice microservice mainly supports functions Each hardware managed in a device service
as following: has an associated hardware type specification.
1. Devices registration. The specification links to a list of executable
Devices can be manually created by means commands corresponding to the devices. The
of API calls or by self-registration. The hard- commands and parameters can be modified
ware provides a unique identification to the by the administrative console or by REST
device service, and then a new device record calls. As the commands execute, a plugin will
encode the commands in a predefined format
and send them by specified protocol. Fig. 3
sd Device service
Plugin PluginsRepository Broker Device illustrates the work process of device service:
microservice
application

1.
register
Symbols and means
query
(DeviceId, URI)
2.
(DeviceId)
search
DeviceId: the unique id of the hardware.
(DeviceId)
config
URI: the internet address of the device.
(metadata)
mount Metadata: the metadata which contains the
(DeviceId, URI)
hardware device information.
return(URI,
metadata) Data: the data provided and consumed by
subscribe
(topic)
devices.
3. publish(topic,
data) Topic: the topic of the Data.
publish(topic,
data)

Work process
1. Initialize and register the device
a) Device microservice register (DeviceId,
Fig.3 Device microservice sequence diagram URI) to PluginsRepository in Core service.

159 China Communications • February 2017

 2. Query device connecting to the framework and manipulating
a) An application sends query to plugin text messages.
component by (DeviceId) .
b) Plugin component searches device plugin IV. IMPLEMENTATION AND
registry information in PluginsRepository by COMPARISON
(DeviceId).
c) PluginsRrepository returns config of the In the development of this system, we use
device (MetaData). Docker and Kubernetes as microservice
d) Based on the device metadata, plugin container. The core service is developed on
component mounts device plugin with (Devi- J2EE platform and implemented using Jboss
ceId, URI). as application server and Resteasy for the
e) Plugin returns device (MetaData, URI) creation of REST interface; Asynchronous
to application. communication is developed using ActiveMQ.
3. Communication among device and mi- The security services are based on Jasig CAS
croservice component. Esper component is used for com-
a) Application begins to subscribe a (Topic) plex event processing (CEP) and event series
on event broker. analysis in automation service. In AI service,
b) The device service publishes (Topic, Apache Spark is adopted for data mining and
Data). graph computing. GEO service is developed
c) When the data meets the specific topic, on GeoServer and Openlayers components.
the application gets (Topic, Data). Apache Solr is used for SEO application. In
 Bigdata service, we adopt Redis for photo data
storage, kairosDB for time series data storage,
3.4 Physical layer
MongDB for document storage. As above
As mentioned previously, the device service mentioned, the system supports various kinds
uses plugins to shield the differences of hard- of hardware platforms, so it’s easy to develop
ware platform and provides a uniform inter- the target software in hardware device system
face to core service, so the system can support and related plugins in service side system.
various hardware device platforms, such as Service API Implementation
Arduino, Raspberry Pi, Andriod and a series The system supports REST service which
of embedded OS. For quick and easy integrat- indicates the CRUD operation by standard
ing of those popular platforms, the proposed HTTP verbs as fig. 8.
system provides the features as following: We demonstrate some REST API call of
device identification, connection orientation, device service as following:
registering new devices, event processing Create a new device. The hardware needs
and commands interface. This allows users a unique identification for addressing in sys-
to focus on building applications rather than tem.
struggling with infrastructure. The SDK main- Request URI
tains an internal data structure to represent POST /iotmicservice/devices/
the environment, objects in it and their state. Request header (brief):
Making this data available to external clients {
in a language independent way (XML, JSON, “devicename” : “temperature sensor”
POJOs, ...), is just like that they can see the “hardwareId” : “57d99d89-caab-482a-
same environment map the user sees; as a de- a0e9-a0a803eed3ba”,
veloper you can forget hardware level factors “plugin” : “com.plugins.devices.tempera-
and related issues, and focus on the business ture”,
process. From this, developers can develop }
applications in their favorite language, just Add trigger for a Device. Measurements

China Communications • February 2017 160

Table I Microservice IoT framework REST APIs “results” : [ {
REST verb URI Parameter Specification “eventid” : “239472398473”,
serviceUrl “eventType” : “numerical”,
GET Lists resources
/objects “hardwareId” : “57d99d89-caab-482a-
serviceUrl Gets information about a0e9-a0a803eed3ba”,
Depends on object function
/objects/{Id} an object “value” : 55}]
serviceUrl To show the benefits of the microservice
POST hardwareId, device metadata Creates a new entity
/objects/
IoT system, we make the comparison of the
serviceUrl Measurement, logic, time, affects some part of the
current IoT systems in Table 2. From the com-
/objects/{Id} signal, etc. system
parison we can see the benefits of this IoT sys-
serviceUrl Updates the addressed
PUT Entity metadata tem that includes more flexibility, scalability,
/objects/{Id} entity
serviceUrl Deletes the addressed
maintainability. It fully supports continuous
DELETE delivery and development technology.
/objects/{Id} entity

Table II Comparison results V. CONCLUSION & FUTURE WORK

Proposed
Feature ubiSOAP Servilla TinySOA OpenIoT In this paper, we propose a new microservice
framework
Heteroge- Partially Support by Support by IoT framework that has improved features
tinyos Only tinyos
neity support wrapper device plugin than existing IoT system such as: monolithic
Application Application Applica- Microservice and microserivce system. The proposed sys-
Application
Scalability &sensor &sensor tion &device tem provides a more generic microservice IoT
&sensor
Small scale Small scale &sensor Large scale architecture on a module approach, it is much
Device Device Device Device better than existing approaches in terms of
Discovery device
service Service service service
flexibility, scalability and platform indepen-
Partially
CEP Not support Not support Not support Full support dency. In addition, we have also introduced
support
the functions of the key components and il-
DevOps difficult difficult hard difficult easy
lustrated their applications. In the proposed
microservice IoT framework, all IoT devices
like temperature, humidity, or locations etc. and objects are abstracted as resource plugin
can be added for a device trigger in a request. inside the system.
Request URI The allocation of microservices to devices
POST /iotmicservice/devices/{hardwareId} works dynamically by interacting with core ser-
Request header (brief): vice, where the core service interacts with the
{ device by using the related plugins, the device
“hardwareId” : “57d99d89-caab-482a- plugins can be mounted or unmounted dynami-
a0e9-a0a803eed3ba”, cally, upgradation of the plugins is also possible
“temperature” : [ { without affecting the overall system, or even
“eventDate” : “2016-11-21”, the whole module of a microservice can be
“value” : 65.0 freely replaced. Thus, the system not only pro-
} ], vides the best IoT service but also has a good
“trigger” :”alarm” support for the Web of Things and has stronger
} adaptability, scalability and interoperability.
List events of a device: According to the For the practice of microservice architec-
given criteria, Lists all events that are assigned ture, there are still many problems to be stud-
to the device. ied, such as cooperative transaction process-
Request URI ing, network delay, faults in network, message
GET /iotmicservice/device/{hardwareId}/ serialization and other issues. Moreover, the
events application of microservice IoT in machine

161 China Communications • February 2017

learning, search engine optimization and other teroperable IoT platform based on microser-
vices,” in 2016 39th International Convention on
distributed computing scenarios are also need-
Information and Communication Technology,
ed to be continuously explored and studied in Electronics and Microelectronics (MIPRO), 2016,
future. pp. 1196–1201.
[14] A. Krylovskiy, M. Jahn, and E. Patti, “Designing
References a Smart City Internet of Things Platform with
[1] D. Namiot and M. Sneps-Sneppe, “On Mi- Microservice Architecture,” in 2015 3rd Interna-
cro-services Architecture,” International Journal tional Conference on Future Internet of Things
of Open Information Technologies, vol. 2, no. 9, and Cloud, 2015, pp. 25–30.
pp. 24–27, Sep. 2014. [15] P. Bak, R. Melamed, D. Moshkovich, Y. Nardi, H.
[2] R. Stephens, Beginning Software Engineering, Ship, and A. Yaeli, “Location and Context-Based
1st ed. Birmingham, UK, UK: Wrox Press Ltd., Microservices for Mobile and Internet of Things
2015. Workloads,” in 2015 IEEE International Confer-
[3] M. Weyrich and C. Ebert, “Reference Architec- ence on Mobile Services, 2015, pp. 1–8.
tures for the Internet of Things,” IEEE Software,
vol. 33, no. 1, pp. 112–116, Jan. 2016.
Biographies
[4] J. Yick, B. Mukherjee, and D. Ghosal, “Wireless Long Sun, is currently pursuing the Ph.D. degree in
Sensor Network Survey,” Comput. Netw., vol. 52, software engineering at College of Computer Sci-
no. 12, pp. 2292–2330, Aug. 2008. ence, Sichuan University, Chengdu, China. received
[5] M. Caporuscio, P.-G. Raverdy, and V. Issarny, the B.S. degree in 1996 from Southwest University,
“ubiSOAP: A Service-Oriented Middleware for Chongqing, China, and M.S. Degree in 2008 from
Ubiquitous Networking,” IEEE Trans. Serv. Com- University of Electronic Science and Technology,
put., vol. 5, no. 1, pp. 86–98, Jan. 2012. Chengdu, China. He get Software Architect qualifica-
[6] Q. Xiaofeng, L. Wenmao, G. Teng, H. Xinxin, W. tion issued by The National Qualification Certificate
Xutao, and C. Pengcheng, “WoT/SDN : web of of Computer and Software Technology Proficiency in
things architecture using SDN,” China Commu- 2011, he has served on several Natural Science Fund
nications, vol. 12, no. 11, pp. 1–11, Nov. 2015. project of national and provincial, among which are
[7] E. Avilés-López and J. A. García-Macías, “Ti- the software architecture for the advanced manufac-
nySOA: a service-oriented architecture for wire- turing technology and the trusted computer system
less sensor networks,” Service Oriented Comput- evaluation, statistical natural language processing.
ing and Applications, vol. 3, no. 2, pp. 99–108,
Apr. 2009. Yan Li, graduated with a B.Eng. in Mechanical Engi-
[8] Fok, Chien Liang, G. C. Roman, and C. Lu, “Ser- neering from Sichuan University P. R. China in 1983
villa: A flexible service provisioning middleware and received a M.Sc. degree from the same Universi-
for heterogeneous sensor networks,” Science ty in 1986, and received his PhD from Liverpool John
of Computer Programming, vol. 77, no. 6, pp. Moores University, U.K in 1996. He was a postdoctor-
663–684, Jun. 2012. al research associate in Cardiff University from 1997
[9] Y. Guo, H. Zhu, and L. Yang, “Service-oriented to 1998 and Cambridge University in 1999. In 1988
network virtualization architecture for Internet he was appointed as a lecturer and in 1991 he be-
of Things,” China Communications, vol. 13, no. came an associate professor and in 1999 a professor
9, pp. 163–172, Sep. 2016. in Sichuan University. His research interests include
[10] L. Lan, B. Wang, L. Zhang, R. Shi, and F. Li, “An application of artificial intelligence techniques in in-
Event-driven Service-oriented Architecture for dustry, creative product design technology and com-
Internet of Things Service Execution,” Interna- puter control of manufacturing systems.
tional Journal of Online Engineering, vol. 11, no.
2, pp. 68–73, Feb. 2015. Raheel Ahmed Memon, Currently Mr. Memon is
[11] J. Soldatos et al., “OpenIoT: Open Source Inter- pursuing his PhD in the school of Computer Science
net-of-Things in the Cloud,” in Interoperability & Engineering at UESTC, Chengdu, China, in year
and Open-Source Solutions for the Internet of 2012 he have received his Masters degree in Com-
Things: International Workshop, Springer Inter- puter Engineering from Myongji University South Ko-
national Publishing, 2015, pp. 13–25. rea. He is a also faculty member at Computer Science
[12] D. Namiot and M. Sneps-Sneppe, “On Mi- Department Sukkur Institute of Business Administra-
cro-services Architecture,” International Journal tion in Sindh, Pakistan. His research interest includes:
of Open Information Technologies, vol. 2, no. 9, Internet of Things, Fault tolerant networking, Android
pp. 24–27, Sep. 2014. Mobile computers and NAND Flash Memories
[13] T. Vresk and I. Čavrak, “Architecture of an in-

China Communications • February 2017 162