The Design and Implementation of Service Composition in Widgets by Shirley Wang

www.seipub.org/ijc

International Journal on Communications (IJC) Volume 3, 2014

The Design and Implementation of Service Composition in Widgets Lin Yao1, Zhang Yang2 The State Key Lab of Networking and Switching, Beijing University of Posts and Telecommunications No.10 Xitucheng Road, Haidian District, Beijing, China ee08b168@outlook.com; 2yangzhang@bupt.edu.cn

Abstract In recent years, the flourishing Internet of things has permeated into many fields. With innumerable tiny devices working and interacting together to produce real-time information, the supervision and configuration process has become more and more significant. Though there exist various ways to supervise and control the devices in IoT, they lack the flexibility and efficiency in the interoperation among devices. Hence, in this paper, we propose a widget service composition to enhance the device interoperation. For flexibility, we represent services using widgets and build a platform for these widgets so as to support flexible and portable devices interoperation. Furthermore, we utilize resource modelling in semantic technology to parse and process widget interactions to provide efficient device configuration. Keywords Service Composition; Widgets; Resource Model; Internet of Things

Introduction Along with the rapid development of the Internet of things, multifarious devices have increased and aroused many problems in supervising and controlling them. It is well known that devices in IoT are characterized by their instability, heterogeneity and diversity. How to monitor all the devices without installing a full set of supervisory and configuration software? And, how to control the devices in a more efficient way? Considering the problems mentioned above, we design and implement a widget service composition system that comprises three layers. It publishes portable and user-friendly widgets, which represent services and display real-time data. Whatâ&#x20AC;&#x2122;s more, these widgets can interact with each other for the users to control the exact devices. The rest of this paper is organized as follows. Section 2 introduces some related work. Section 3 describes the whole architecture of the system. And the detailed implementation of the system is presented in Section 4.

The evaluation and comparison of the system is given in section 5. Section 6 draws a conclusion to the whole paper. Related Work So far, a variety of work has been done on service composition and widget. Some of them have already been used in the supervisory of devices in IoT, but still need to be improved. Service composition in graphical user interface has been fully developed in some domain-specific graph configuration softwares[1]. It provides flexible composition between UI components and services by using SCA and DTS models, which decouples business from user interface and models user interface in different aspects. However, this kind of UI composition has been built on C/S architecture, in most cases, users need to install a full set of the softwares although they only want to use a small fraction of functionality in the whole software. Another research on widget orchestration has provided a UI composition in B/S architecture[2]. It encapsulates service into widgets so that they can work everywhere as long as the users have a web browser. This approach, nevertheless, suffers from the problem that their sematic reasoning is built upon common ontology, which is unable to clearly describe the complex relations in some domain-specific environment in the Internet of things. Regarding the previous work and our domain-specific requirements, we introduce a design and implementation of widget service composition system based on resource model, which offers professional and comprehensive modelling in different areas. Architecture of Widget Service Composition System The widget service composition system presents a

International Journal on Communications (IJC) Volume 3, 2014

user-friendly platform for users to manipulate the widgets. We have built several widgets to represent different services that are processed by our powerful ontology reasoning of resource models. An overall illustration of the whole system is shown in Fig. 1.

www.seipub.org/ijc

supervisory and configuration system in boiler room, which fully utilizes the widget service composition system to supervise and control devices in a boiler room company. Implementation of Widget Service Composition System Presentation Layer 1) Widgets

Widget A

Widget B

Widget C

Presentation Layer Frontend Features

Composition Layer

Widget API

Wookie API

Wave API

REST API

Primary Interoperation

Resource Model

Linked Data

Ontology Reasoning

Data Source Layer

Databases Resource Model Files

FIG. 1: ARCHITECTURE OF WIDGET SERVICE COMPOSITION SYSTEM

The system is divided into three layers. The presentation layer displays services in terms of widgets. These widgets can be either embedded into other web applications or accessed from our platform, which improves the interoperation of widgets with extra features. The composition layer is responsible for the processing of the widget interoperation generated from the presentation layer. This layer is made up of two parts: one to deal with the primary interoperation of widgets and the other to handle more complex tasks using ontology reasoning. The data source layer supplies the upper layer with necessary data, including diverse databases and resource model files. In order to thoroughly depict all the characteristics of this system, we describe it using the example of a

Services are revealed using widgets that follow the W3C Widgets specification[3]. This specification makes basic definitions of widget in terms of packaging format, the configuration document, reserved files and the processing of a widget package. According to their different authentications, users may access and control widget, widget instances and participants through the REST API supported by this system. Once a widget is published, it can be independently presented in different environments. It can be embedded into other web applications, offering the basic functionality built inside, like, displaying shared information and communicate with other widgets. Moreover, it is able to interact with other widgets on our widget platform using its frontend features. 2) Frontend Features Defined as JavaScript functions, frontend features are built in our widget platform, aiming to enhance graphical widget interactions and user experience. In our system, there are two frontend features: the shared features and widget-specific features. Shared features provide some most commonly used functions that every widget can use so as to interact with others, such as snapping when two widgets with certain relations are dragged close to each other. Widget-specific features are functions to boost certain types of widgets. In terms of interactions, the widgets described in this system falls into two categories: graph widgets and control widgets. ď Ź

Graph Widgets The main purpose of graph widgets is to display supervisory graph, which reveals the real-time data and status of devices. There are two graph widgets: tree widget and map

www.seipub.org/ijc

widget, as shown in Fig. 2. Tree widget displays the folders containing the graphs in tree structures where the users can click the leaf node to open the graph. Map widget presents the graph as a location point on the map, so users can search a graph according to its location. Besides, graph has two formats, one is 2-Dimension svg file, and the other is a 3-Dimension obj file along with its material information in a mtl file(see Fig. 3).

International Journal on Communications (IJC) Volume 3, 2014

fully developed to extract and process widgets. 

Widget API This API is the Java implementation of w3c widget API. It is an enhancement to the JavaScrpit parts and offers functions like getting the preference and metadata, which are persistent in database.



Wookie API Wookie API is an extension to the w3c widget API, supplying the widgets with extra serverside functions like locking and unlocking, showing and hiding, etc.



Wave API is the implementation of Google Wave Gadgets API[5], which produces a live, multi-user environment, called Wave, for widgets. The widgets in Wave are able to set and respond to different states that are maps containing key value pairs to record and deliver information. Apart from that, management of hosts, participants and viewers is also supported by Wave API.

FIG. 2: TREE WIDGET AND MAP WIDGET



Control Widgets

Control widgets itself only display limited information, it is used to interact with graph widgets.

After going through the primary interoperation, an interaction request is half-processed, leaving the intricate relations to ontology reasoning. In this part, we extra and process complicated relations from the request, with the help of semantic web technology.

This paper takes the example of a stopping widget. When a graph widget is showing the data of a boiler room, if the user drops a stopping control widget on it, all the devices in this graph should stop working. Other control widgets involve setting widget, which sets the value of a certain device, and blocking widget, which blocks the value from changing. Composition Layer 1)

Primary Interoperation

When an interaction between widgets is triggered from the previous layer, primary interoperation processes the basic parts of the interaction. This section is built upon Apache Wookie[4], which is

REST API For the purpose of better controlling widgets, a set of REST API is published to get, create, update and delete the widget instances, widgets, participants and properties.

FIG. 3: 2D AND 3D GRAPH



Wave API



Ontology Reasoning

Resource model During the process, we use resource model, rather than ordinary ontology, to define and model domain information, in which the upcoming interaction request will look up and find the resulting response. Although ontology is capable of modelling real-life information and defining semantic relations, it is not sufficiently helpful when it comes to professional domain with complicated interoperations. Based on ordinary ontology, resource model is built to model the domain-

International Journal on Communications (IJC) Volume 3, 2014

www.seipub.org/ijc

specific resources in the Internet of things. It not only clearly divides different concepts into categories and defines their relations, but also enable information binding and reusing.

In terms of data bases, we set up a Mysql for the data process in composition layer. Additionally, a H2 database is running for real-time refreshing data in graph widgets.

In run-time, the resource model is instantiated into Model object using Jena[6], an open source framework to serialise and search ontology models.

When it comes to resource model files, we download and store the most frequently used files in local cache, which keeps updating from the resource modelling tools.

Follow the example that a stopping control widget is dropped on a graph widget representing a heat exchange station. This interaction is being searched in the run-time model that is built from the resource model like that in Fig. 4. Consequently, this interaction will stop all kinds of sensors that are defined in this heat exchange station.

Experiments

<owl:Class rdf:about="http://www.test.org/Class/concept/entity/heatExchangeStation"> <rdfs:subClassOf rdf:resource="http://www.test.org/Class/concept/entity"/> </owl:Class>  <owl:DatatypeProperty rdf:about= "http://www.test.org/heatExchangeStation/SenseProperty/waterSupplyHumidity1"> <rdfs:domain rdf:resource="http://www.test.org/Class/concept/BindCls"/> <rdfs:domain rdf:resource="http://www.test.org/Class/concept/entity/heatExchangeStation"/> <rdfs:range> <rdfs:Datatype> <owl:unionOf rdf:parseType="Collection"> <rdf:Description rdf:about= " http://www.test.org/Class/concept/resource/humiditySensor"/> </owl:unionOf> </rdfs:Datatype> </rdfs:range> </owl:DatatypeProperty>  <owl:Class rdf:about="http://www.test.org/Class/concept/resource/humiditySensor"> <rdfs:subClassOf rdf:resource="http://www.test.org/Class/concept/resource"/> </owl:Class>

We have utilized the widget service composition system in the supervisory and configuration of a boiler room with millions of devices. During the practical applications, we have found that the distinguished advantage of our system over other systems is the processing efficiency in parsing hierarchy and composition relations such as looking up all the devices in a selected boiler room. The main reason is that we store all the predefined hierarchy and composition relations in resource model, in which we can search efficiently. Without resource model, a commonly used method to deal with these relations is to look up the devices from the displaying graph such as the svg file. On one hand, this is error-prone, because the graph referring to a certain boiler room may not depict all the devices in that room. On the other hand, when the number of devices is large, searching in a graph file is time-consuming. The comparison of the efficiency between searching in a resource model and graph is shown in Fig. 5.

<owl:DatatypeProperty rdf:about="http://www.test.org/humiditySensor/BasicProperty/humidityStand"> <rdfs:domain rdf:resource="http://www.test.org/Class/concept/resource/humiditySensor"/> <rdfs:range> <rdfs:Datatype> <owl:unionOf rdf:parseType="Collection"> <rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#double"/> </owl:unionOf> </rdfs:Datatype> </rdfs:range> </owl:DatatypeProperty>

FIG. 4: RESOURCE MODEL SNIPPETS

ď Ź

Linked Data Some of the interaction request may come with structured documents, where we plant semantic information using RDFa[7]. In order to deal with the RDFa mixed in html, we utilized Semargl[8] to parse it and produce the formal ontology information that can be used to search in the run-time model.

Data Source Layer Data source layer contains varieties of data source to support the data consumption from upper layers.

FIG. 5: COMPARISON BETWEEN SEARCHING IN RESOURCE MODEL AND GRAPH

The goal of this comparison is to find out the difference in time consuming when the number of devices to be searched is different. The green line depict the time cost in searching using the resource model, and the red one depict the time cost in searching in graph file. This comparison reveals that searching in resource model is more efficient than searching in graph, especially when the number of devices is large.

www.seipub.org/ijc

International Journal on Communications (IJC) Volume 3, 2014

Conclusions

REFERENCES

This paper introduces a widget service composition system that can be used in the supervisory and management of devices in the Internet of things. Exploiting the W3C Widgets specification and semantic technology, this system offers a flexible and user-friendly way to create, manage and interoperate widgets that indicate different services. Currently, widget interactions are triggered in the granularity of the whole widget, future work may be achieved to reduce the granularity, resulting in the interactions among certain values in widgets.

Ahmet Soylu, Fridolin Wild. ”Mashups and Widget Orchestration”

Proceedings

Conference

Management

of of

the

International

Emergent

Digital

EcoSystems, Nov. 2011. Apache Jena. Webpage. [Online]. Available: https://jena.apache.org/ Apache Wookie. Webpage. [Online]. Available: http://wookie.apache.org/ Google Wave Gadgets API. Webpage. [Online]. Available: http://www.waveprotocol.org/wave-apis/google-wave-

ACKNOWLEDGEMENT

The work presented in this research is supported by the National Grand Fundamental Research 973 Program of China under Grant No. 2011CB302506, 2012CB315802; National Key Technology Research and Development Program of China (Grant No. 2012BAH 94F02); National High-tech R&D Program of China (863 Program) under Grant No. 2013AA102301; National Natural Science Foundation of China under Grant No. 61132001, 61372115); Program for New Century Excellent Talents in University (Grant No. NCET-11-0592); Project of New Generation Broad band Wireless Network under Grant No. 2014ZX03006003, 2011ZX03002-002-01, 2012ZX03005008-001; The technology development and experiment of innovative network architecture (CNGI-12-03-007).

gadgets-api Linked Data in HTML. Webpage. [Online]. Available: http://rdfa.info/ Marcos

Cáceres,

“Packaged

Web

Apps

(Widgets)

Packaging and XML Configuration (Second Edition).” W3C Recommendation 27 November 2012. Accessed September 15, 2014. http://www.w3.org/TR/widgets/ Semargl: better linked data processing. Webpage. [Online]. Available: http://semarglproject.org/ Youyu Chen. “A Graph Configuration Method Base on UI Service

Composition.”

2011

Seventh

International

Conference on Mobile Ad-hoc and Sensor Networks, 2011 , Page(s): 339 – 340.