Software service architecture to access weather data

8/11/2019 Software service architecture to access weather data

1/7

Software Service Architecture to Access Weather

Data Using RESTful Web Services

Ramakrishnan RamanathanDepartment of Electrical Engineering and Computer Science

Ostwestfalen-Lippe

University of Applied Sciences,

32657 Lemgo, Germany

[email protected]

Prof. Dr.-Ing. Thomas KorteDepartment of Electrical Engineering and Computer Science

Ostwestfalen-Lippe

University of Applied Sciences,

32657 Lemgo, Germany

[email protected]

AbstractThe field of application where sensors are used isexpanding extensively fast. The ease of using these sensors isincreasing as much as their variety. Generally, sensors provideinformation about various aspects of the real world. Sensorsare used for gathering environmental information such aschanges in temperature, air pressure and water quality. They

are also used widely in diagnosing automobiles, traffic patterns,health care and disaster management. The important task is toanalyze the large amount of multidimensional data generated bydiverse sensors and to provide interoperability among varioussystems which handles such complex data. These sensors aredistributed geographically and these sensor networks do nottake context information into account due to which they provideheterogeneous interfaces to access the data. To handle theseissues we need to pay greater attention to the interoperability ofthe data acquired from heterogeneous and distributed networksof sensors. In this paper, we are going to propose a web servicearchitecture for online environmental data acquisition. Ourarchitecture will also take the user location into account inorder to deliver weather data from the nearest available sensors.We are going to use RESTful web services as they are simple,reliable and easily scalable. We are also going to use a documentoriented NoSQL database. This paper also provides a detailedanalysis and comparison between RESTful web services andWSDL/SOAP based web services.

Index TermsSOA, Webservices, SOAP, REST, NoSQL,JSON, Service Oriented Architecture, GeoSpatial Application,Sensor Network, Environmental data.

.

I. INTRODUCTION

Based on the combined effects of earths motions and

the energy exchanges that continuously occur between the

atmosphere and the earths surface and also between the

atmosphere and space, our planets formless and invisibleenvelope of air reacts by producing an infinite variety of

weather patterns [16]. Weather data comes in a variety of

forms from a number of sources. This weather data is crucial

in making day to day decisions like travel, daily routine, and

business decisions. Weather information has to be considered

as an important aspect in decision making for industries such

as public utility companies, transportation services, maritime,

aviation and disaster management.

Nowadays, a vast majority of such data is gathered using

sensors which sense the earths atmospheric variables like air

pressure, vapor, temperature, relative humidity, wind direction

and speed, etc. These sensors are distributed geographically

and each sensor system is meant for some application. The

sensors generate data in various formats and different inter-

faces are used to access it. This leads to heterogeneity of dataand reduces the interoperability among related applications.

The issues related to sensors are interoperability of several

monitoring systems, heterogeneous data, as well as identifica-

tion and location of relevant sensors. These sensors have to

be integrated in a platform independent manner. These sensors

can be discovered and the user can access the sensor data

for various applications ranging from a smart phone to an

industrial PC. We are going to use RESTful web services to

expose the service to consumers. Each service is designated

by a RESTful API. Different physical sensors would have

a separate RESTful API, which can be consumed with a

Uniform Resource Identifier (URI). This study mainly focus on

finding how the Representation State Transfer (REST) couldbe integrated with the proposed model to access, analyze

and visualize the sensor data produced by distributed sensors.

The structure of the paper is organized as follows, section

II provides information about related works, in section III

SOA concepts are discussed in detail and the basics of web

services are discussed in section IV. The reasons behind using

REST in our implementation is mentioned in section V and

the proposed architecture and its implementation is discussed

in detail in Section VI. The conclusion is drawn in section

VII.

I I . RELATEDW OR K

1 As the sensors produce data in a very large amount andalso, due of the multidimensionality of the data, it is vital

to analyze this data with technical help. Diane J. Cook

[18]. examined some common tools for understanding

and analyzing the sensor data. She also explains the

importance of sensor data and how to visualize them.

2 Tomasz Kobialka. et al. [19] proposed a middleware for

sensor web with stateful services for heterogeneous sen-

sor networks. The aim of the project is to introduce Web

Service Resource Framework (WSRF) mechanisms into


2/7

Fig. 1. Service Oriented Architecture.

the core services implementation of the NICTA Open

Sensor Web Architecture (NOSA). NOSA is a suite

of middleware services for sensor network applicationswhich are built upon the OpenGIS Consortiums Sensor

Web Enablement standard.

3 Pouria Amirian. et al. [20] proposed a architecture

for implementing geospatial web services using SOA

and NoSQL solutions. The project assesses geospatial

services through a so called OGC services framework.

and propose an architecture for implementing geospatial

web services.

4 Jian Meng. et al. [21] proposed a solution for distributed

data integration using RESTful web services. In the

paper they make an in-depth analysis about traditional

Web Services and RESTful Web Services and design

a testing scheme to test and analyze the performance

of RESTful Web Services to demonstrate that RESTful

Web Services are more suitable for Internet-scale dis-

tributed data integration.

III. SERVICEO RIENTEDA RCHITECTURE

The Service-Oriented Architecture (SOA) is a software

architecture that defines the use of services to support software

user requirements [1]. Sun defined SOA in the late 1990s to

describe jini, which is an environment for dynamic discovery

and use of services over a network [2]. In 2000, Alan W.

Brown defined service-oriented solutions as applications which

must be developed as independent sets of interacting ser-vices offering well-defined interfaces to their potential users.

Similarly, supporting technology must be available to allow

application developers to browse collections of services, select

those of interest, and assemble them to create the desired

functionality [3]. Service Oriented Architecture (SOA) is pri-

marily used for designing and developing distributed systems

since SOA is flexible enough to handle different tasks and

provide services, where these services are reusable business

components and they are loosely coupled. SOA is a way

of designing a software system to provide services to either

end-user applications or other services through published and

discoverable interfaces [4]. A Service Oriented Architecturealso allows many clients to discover services and consume

the same. A service is defined as a software component which

performs a specific function, which is exposed by a service

provider and available for users or systems. The basic overview

of Service Oriented Architecture is shown in figure 1. SOA has

three components (i) service discovery, (ii) service provider,

(iii) service consumer. The service discovery is a directory of

services, where the providers publish information about the

services that they offer. Discovery also allows the consumer

to browse the list of available services and also provide the

information as how to access them. A service consumer sends

a request to the provider which returns a response to the

consumer containing the expected results. A service provider

can also be a service consumer and use the service provided

by another service provider.

Even though there are a lot of reports and research articles

about SOA and web services, still there is confusion about

the two terms among the developers. SOA is an architec-

ture paradigm and web service is a technology that is most

commonly used in SOA implementations. Initially SOA was

build using Distributed Component Object Model (DCOM), an

extended version of Component Object Model (COM) which

works largely with the windows operating system. Another

technology which was widely used in the SOA implementation

was Object Request Broker (ORB) based on Common ObjectRequest Broker Architecture (CORBA) specification. SOA

with web services are at the present gaining momentum and

recently with web services there is a fundamental improvement

in SOA based application development [17]. This is mainly

due to the fact that web services will help us to overcome the

major challenges in building SOA applications.


3/7

Fig. 2. SOAP Messages.

IV. WEB S ERVICES

CORBA and DCOM increased the awareness for Service

Oriented Architectures. For the last two decades, many com-

panies were trying SOA using CORBA and DCOM. However,

they had little success and SOA has not gained momentum.

These early efforts in building SOA are not so success-

ful due to platform incompatibility, complexity and mainly

applications build using these technologies are not loosely

coupled. They are tightly integrated objects and components.

SOA gained much traction after 2001, when web services

technology has been widely adapted and web services gave

SOA the foundation it needed to get widely accepted [5].

Currently, web services have become the de-facto standard for

SOA implementation. Many associate SOA exclusively with

SOAP and WSDL. Web services are initially implemented

using SOAP and WSDL. WSDL is a standard for interfaces to

access applications and SOAP is a standard protocol to connect

applications. However, in the last several years, an alternativeapproach using REpresentational State Transfer (REST) has

been widely used for Internet-scale applications.

A. Simple Object Access Protocol (SOAP)

Simple Object Access Protocol (SOAP) is a XML based

protocol used for information exchange between applications.

SOAP was initially developed by Microsoft, to replace the

traditional methods like DCOM and CORBA. The major

advantage of SOAP is, it allows information exchange between

applications running on different platforms written in different

programming languages. This interoperability factor gives a

greater level of flexibility in developing applications using

web services. Another major advantage of SOAP is that itallows rich message exchange patterns ranging from tradi-

tional request-and-response to broadcasting and sophisticated

message correlations [1]. SOAP is most commonly used with

HTTP protocol. SOAP can also be used with TCP, FTP, SMTP

and BEEP, SOAP is not binded to any particular protocol [6].

SOAP has two types of messaging styles namely SOAP Re-

mote Procedure Call (RPC) and document style. SOAP RPC is

more or less similar to other distributed architecture. RPC style

SOAP web service is tightly coupled and any changes made

to the RPC interface would break the agreement between the

client and the service. In RPC messaging style the interaction

between a client and RPC-style web service centers around a

service-specific interface [1]. Clients requests are expressed as

a method call with a set of arguments, which returns a response

containing a return value. The client sends request and waitsfor a response. In document style messaging, both the request

and response are passed as a XML document in the body of

SOAP message instead of parameters. Since the request and

response are self-contained XML files, document style means

asynchronous processing, the document can be processed

in the queue and the message queue offers a guaranteed

delivery mechanism. Document style SOAP messaging is more

reliable, scalable and improves the performance. Due to these

drawbacks, SOAP RPC messaging style is not recommended

in SOA implementations.

SOAP messages are viewed as envelopes in which the

application encloses the data that has to be sent. The envelope

element contains a header element which is optional and abody element which is mandatory. The contents of the header

and body elements are application specific and not a part

of the SOAP specifications. The SOAP headers consist of

information as how the message has to be processed and also

the information related to SOAP engine. The body element

consists of the main end to end information of SOAP messages

in the form of a XML document. In case of a RPC request the

SOAP body element will contain structured data or arguments.

Since SOAP is independent of HTTP, SOAP has an additional

attachment element with which we can also send attachments

along with SOAP messages. The attachment element is often

considered best for web services dealing with attachments. A

simple SOAP request and response is shown in figure 2.

B. REpresentational State Transfer (REST)

REST is an architectural style [7] which consists of a

number of resources and a set of constraints acting upon these

resources. Each resource in REST is identified by an URI

(Uniform Resource Identifier) and service providers in REST

are resources, but consumers may or may not be resources.

The basic idea of REST is to use HTTP mechanisms, to

connect applications rather than using a complex mecha-


4/7

nism like CORBA, RPC and SOAP. REST focuses mainly

on resource interaction and changing their state, instead of

focusing on sending and receiving messages like SOAP based

web services. REST offers a simpler implementation of web

services, any one who is familiar with HTTP will find it easy

to understand the principles of REST and build REST web

services. REST principle includes the following

1 Identification of resources via URI: A RESTful webservice provides a number of resources that identify the

goals of the interaction with their clients. Resources

are identified by URIs which can accommodate an

addressing space for resource and service discovery.

2 Uniformity in resources: Each resource in REST is

manipulated via a set of four operations: GET, PUT,

POST and DELETE to read, create, update and delete

the resource respectively. The PUT operation is respon-

sible to create a resource which can be deleted using

DELETE. The POST operation transfers an existing

resource from one state to another state.

3 Message with self-description: Resources in RESTful

are categorized by the way they are represented, so thatthey can be accessed in various formats such as HTML,

PDF, XML, JSON, JPEG, plain text and others. Meta

data about the resources is available and can be used,

for caching control, detection of transmission errors, ne-

gotiation of representation format and for authentication

or access control.

4 Use of hyperlinks for stateful interaction: All the in-

teraction to resources are stateless, that is the request

message is self-comprehended. Stateful interactions are

one where the state transfers are explicit. There already

exists a number of ways to exchange state such as re-

writing URIs, cookies or hidden form field. State can

also be embedded in the response messages, so that theycan be used for future references.

The major reason why REST is becoming more popular is

due to its simplicity, where the request is a HTTP operation

and the response is a plain XML, JSON or RDF message.

The only drawback for REST is the lack of standards and

this is often seen as a disadvantage in SOA implementations.

However, the simplicity factor is making REST the preferred

choice for SOA implementations. A simple REST request and

response using JSON is shown in the figure 3.

C. SOAP Vs REST

SOAP is a protocol and REST is an architecture paradigm

and both are most widely used in building web services. BothSOAP and REST differ in their perspective and usage; Each

of it having its own pros and cons. Some researchers say

comparison between the both is not appropriate, however, a lot

of blogs and research articles which offer a neutral assessment

of both and compare the same. There is still a lot of debate and

heated discussion going in academic and research communities

in which each side defended their position well. We have

done some detailed research and based on our experiences,

we have listed some of the key differences between SOAP

Fig. 3. REST Request and Response.

and REST. We believe that this will be helpful for developers

and architects, who want to use these methodologies in their

applications.

SOAP

1 The SOAP based web service stack consists of different

standards like WSDL, WS-Transaction, WS-Security

and so on. SOAP is used in complex implementations.

For implementing SOAP based web services, it is nec-

essary to have at least a basic understanding of these

standard which is quite time consuming. It should also

be noted that the acronym SOAP no longer stands for

Simple Object Access Protocol [8],[9].

2 SOAP used HTTP as the Transport layer protocol similar

to TCP [10]. This can be considered as advantage in

some cases, however, due to the fact, we can say SOAP

uses the web but stays outside the web, SOAP is also

misusing the HTTP verb POST to send request messagesand receive response messages. HTTP POST is non-

idempotent, hence caching is not possible.

3 SOAP is tightly coupled when compared to REST.

4 SOAP messages contain additional overhead for each

message, the actual payload is included in the body

of the envelope. SOAP also uses XML which is also

verbose due to these facts SOAP is heavy weight when

compared to REST.

5 Since SOAP messages contain additional overhead, it

consumes a lot of bandwidth and causes network la-

tency [11]. Encoding and decoding of SOAP messages

requires additional processing time which results in high

response time and low throughput[12]. In addition, manymobile platforms do not include necessary libraries for

SOAP-based services, encoding and decoding SOAP

messages also consumes resources (i.e., battery, proces-

sor speed, and memory)[11].

6 SOAP is more secured when compared to REST,

most banking implementations are done using SOAP.

It also supports SSL like REST and SOAP also

has WS-Security, WS-AtomicTransaction, WS-

ReliableMessaging which makes it more secured.


5/7

REST

1 REST is build on HTTP principles and a service is

nothing but a resource which can be exposed using URI

and it is very simple to understand and use. Anyone who

can understand HTTP can easily understand REST.

2 In REST, HTTP is the application protocol[10] as it

transfers representations and REST used the HTTP verb

GET which is idempotent, hence caching is possible.3 REST is loosely coupled.

4 In REST, the entire message is the actual payload

without any additional headers and REST relies on the

principles of HTTP, which makes it light weight and we

can also use the message format in JSON.

5 Since the response in REST is light weight, it consumes

less bandwidth and the response time is less and REST

does not need any additional libraries like SOAP.

6 REST uses HTTP principles so security mechanisms that

are available in REST are HTTPS and SSL.

Both SOAP and REST has their own pros and cons, and

both can be used to get our work done. The decision of

whether to use SOAP or REST depends on application design,implementation and usage. While designing a complex enter-

prise application or applications which have to be secured like

banking applications, SOAP is the preferred choice whereas

REST is the preferred choice for applications based on the web

as well as mobile applications due to its lightweight nature and

the request/response message is not tied to XML.

V. WHY REST

There is still a lot of confusion whether REST is SOA

and its still a million-dollar question in the SOA community

whether REST can be used to implement SOA. Well the

answer for this question largely depends on the business goals

and needs that has to be achieved. Based on our research we

provide some of the important aspects as why we prefer REST

in our implementation.

I One of the basic property of SOA is loose coupling and

REST is lightly coupled when compared with SOAP and

WSDL.

II REST is light weight.

III REST is gaining popularity due to its simplicity, scala-

bility, and architectural dependence on the World Wide

Web[12].

IV The message type is also a reason to be considered, as

this flexibility improves the performance.

V Our application has to be used in mobile devices likesmart phones and tablets and REST offer better perfor-

mance when compared to SOAP in mobile platforms

[11],[12],[13].

Major companies started using REST, initially REST was used

by Yahoo and eBay to design their web services. Recently

the trend has changed and REST is dominating the web and

major companies like Amazon, Google, flickr, twitter etc.,

started using REST to design their web services. Amazons

web services have both SOAP and REST interfaces and 85

% of usage is on the REST interface, compared with other

styles of web services[14]. Two prominent companies have

already implemented their SOA using REST, Google Ad-sense

network is based on REST and the Amazon affiliate network

is the first major SOA implementation based on REST[15].

VI . PROPOSED A RCHITECTURE

The target of architecture is to provide localization based

weather information and the weather data coming from the

sensors can be consumed as a service. We are going to use a

RESTful web service to expose the service to consumers. Each

service is designated by a RESTful API. Different physical

sensors would have a separate RESTful API, which can

be consumed with a Uniform Resource Identifier (URI).The

proposed architecture is shown in the figure 4.

Fig. 4. Architecture of our system.

The proposed system makes use of JSON messages. There

will be three major components residing on different tiers,

which communicate with each other and to external servicesusing JSON messages to realize the complete system. The

first step on implementation would be developing a sensor

application which is responsible to establish a connection

between a sensor and a web service. The sensor application

enables sensors to incorporate sensed values into the database.

The sensor application is programmed using Java. The next

step is to develop a client application, which can be accessed

via a URL. It is a user intractable application and responds

to the users request by fetching data from the RESTful web

service. When the user accesses the client application using

the URL, the users location is gathered implicitly and our

system fetches data that is proximate to that particular location.

In order to achieve this functionality, we need to performgeospatial queries to fetch the data from the database, we

should use a database which can handle geospatial queries

efficiently. We are going to use NoSQL MongoDB as our

database which supports queries to handle geospatial informa-

tion. The user can access the weather data which is designated

by a RESTful API. Different physical sensors would have

a separate RESTful API, which can be consumed with a

Uniform Resource Identification (URI). The final step is to

develop a sensor web service, which is the core of our system.


6/7

It is responsible to process, coordinate and manage sensor

data among sensor devices and the client application. It will

exchange JSON messages to realize the data communication

between the sensor application and client application.

In order to access the weather data, a service request is sent

to the RESTful web service and requests are executed using

HTTP principles and the parameters for the request execution

is sent using URL. We are using the HTTP verb GET to fetchthe data and the same has been displayed to the end user in

JSON format. A simple request and response are shown below

Service Request-:

Service Response-:

{

"Physicalentity": "Pressure",

"Sensor": "Tinkerforge",

"Unit": "Lux",

"_id": "5352cb1e11f644f05a76aa2a",

"date": "19.04.2014",

"loc": {"lon": 8.9043,"lat": 52.0277},

"time": "21.14.38",

"value": "Air Pressure: 1003.318 mbar"

}

We have developed this application giving greater importance

to open source technologies. We have used JavaScript through-

out the stack due to the fact that it is simple, easy to learn

and to troubleshoot and also has quick response time. We used

Backbone.js a JavaScript framework based on MVP design for

the client and node.js as a server side scripting language for

server side programming and express.js for the web application

framework and MongoDB for the database. The example of

URI request and response is shown below. In order to access

the list of weather collections available the user can select the

weather sources from the menu bar which will add /list to the

base URI as shown in figure 5. The user will get a list of

weather collections as a response.The user can select the required weather data from the

collections listed. When the user selects a particular collection,

then the user location is gathered explicitly using the javascript

geolocation API and the same has been parsed using the URL

to the server. The server does geospatial queries and fetch

the values of the sensors which is near to the user location

for example, if the user selects the temperature from the

collections then the data from the temperature collection is

displayed as shown in figure 6.

Fig. 5. List of weather collections.

A. JSON as data interchange format

We have written the web service using Java script and also

due to the complex structuring of XML, we used JSON asthe message format. There are also other reasons why we

considered JSON, (i) JSON is a data exchange format, whereas

XML is document exchange format. (ii) JSON is easy to read

and write; processing is simple due to its structure. (iii) JSON

is lightweight, easy to handle and to parse when compared

with XML.

B. NoSQL DATABASE

The reason why we prefer a NoSQL database is that

the data exchange format is based on JSON and a huge

amount of geospatial data is handled efficiently. A JSON style

database called MongoDB is used in this work. MongoDB is a

document-oriented, NoSQL database management system andMongoDB also provide support for geospatial queries. Instead

of storing data in the tables, as done in SQL, MongoDB stores

data in JSON format documents, therefore, making integration

of data with the web server is much easier and simpler. In

MongoDB terminology, an element of data is represented as a

document and a bunch of documents make a collection. This

concept of the collection is well suited for the work, as it

enables segregation of different sensor types into different

collection. For example, a temperature sensor can have a


7/7

Software service architecture to access weather data

Documents

Transcript of Software service architecture to access weather data