Project center in tiruchendur - EDOT
This section presents a brief overview of the existing
services description languages and matchmaking approaches
and highlights their limitations for describing and discovering
context services.
During the last two decades, a large body of research has
been conducted on definition and composition of semantic
service, especially in the domain of Semantic Web Service
(SWS). These efforts led to the development of several web
service description languages, such as Semantic Markup for
Web Services (OWL-S) [3], Web Service Modelling Ontology
(WSMO) [4], and Semantic Annotation for WSDL and XML
Schema (SAWSDL)[5].
Most of the above-mentioned languages to some extent
allow specifying services in terms of their signature (i.e., inputs
and outputs of the service), behavioral specification (i.e.,
preconditions and effects) and the non-functional properties
(NFPs). However, all of these languages suffer from the same
limitation, lack of support for describing the contextual
characteristics of a service, that makes them insufficient to
describe context services. To overcome these shortcomings, a
number of different approaches have been proposed [6], [7].
However, they do not fully support different types and aspects
of context and lack an expressive language to represent them.
In this regard, existing semantic service matchmaking
techniques [8]–[10] also suffer from a similar drawback, i.e., a
lack of a mechanism for discovering services based on
contextual characteristics and their associated entities.
In this section, we present the Context Service Description
Language (CSDL). CSDL is a JSON-LD-based language that
enables developers of context services to describe their services
in terms of semantic signature and contextual behavioral
specification. Further, CSDL allows developers to describe
their services using a standard language (underpinned by
semantic computing). CSDL enables the fast development of
IoT applications that can discover and consume context
services owned and operated by different individuals, and
organizations. For describing the semantics of context services,
we adopt Web Ontology Language for Services (OWL-S) [3]
which is a W3C recommendation, as the basis of CSDL. OWLS is an ontology language which is developed based on the Web
Ontology Language (OWL) to enable automatic discovery,
invocation, and composition of web services. However, as
OWL-S was originally designed for describing web services
and does not support the semantic description of context, we
extended the OWL-S by adding the context description of the
entities associated with context services.
Similar to OWL-S, CSDL consists of three main
components: (i) Service Profile, (ii) Service Grounding, and
(iii) Service Model. Service Model gives a detailed description
of service signature, namely its input and output, and identifies
the semantic vocabularies which are supported by the given
service. Service Grounding provides details on how to interact
with a service. https://edottechnologies.in/ This component identifies which type of
communication needs to be used to call the service (e.g., HTTP
get, XMPP, Google Cloud Messaging). Further, based on the
type of the communication, it will provide other required
information to make the service invocation possible (e.g., URI
in the case of HTTP get). Lastly, Service Profile is used to make
service advertising and discovery possible. This component
indicates the type of the entity that a service interacts with.
Further, it defines the context-aware behavior of the service.
COAAS ARCHITECTURE AND IMPLEMENTATION
Communication
Manager is responsible for handling all the incoming and
outgoing messages, i.e. context requests, service description
updates, and service responses. CQE has two main
responsibilities: parsing the incoming service queries
represented in CDQL [2] language, and producing the final
query result. This component will receive the incoming queries,
break them into several context requests, and determine the
query’s execution plan. Furthermore, it is also responsible for
aggregating the context request’s responses to produce the final
query answer. CSDS is in charge of finding the most
appropriate services for an incoming request. CSR is designed
to register new context services in the context service
repository. This module accepts the incoming context service
descriptions represented in CSDL, and register them in the
system after validating its syntax and semantics. Lastly, CSI is
responsible for invoking the context services from the
corresponding service providers to retrieve the required
information. Based on the presented architecture, we
implemented a prototype of CoaaS framework. This prototype
has a scalable, fault-tolerant micro-services based design,
making it ideal for cloud deployment. In this regard, each of the
components described in this section is implemented as a
microservice using Java EE technologies.
SMART CARPARK RECOMMENDER USE CASE
One of the most common IoT applications in smart cities is
car park service recommendation [14]. Developing an IoT
application that utilizes IoT-services to suggest the best
available parking is a challenging task. First of all, it is essential
to have access to live-data, coming from context services, about
availability of different parking facilities. The fact that these
services owned by different providers (e.g., city administrators,
building owners, and organizations) makes the process of
service retrieval even more complex. Further, to be able to
provide personalized suggestions to users, it is important to
obtain additional factors, such as user preferences, car
specifications, and weather conditions that might need
reasoning and inference before it can be used. The query can
become even more complex if the user wants to avoid places
where snow cleaning, waste collection [15] is happening or
other road problems [16] are reported.
The CoaaS framework enables retrieving all the abovementioned information using a single query. To demonstrate a
practical implementation of the use case, we have developed an
Android mobile application which automatically provides suggestions about available parking spaces to drivers using
real-time data obtained from context services. To achieve this
goal, we composed a parameterized context query, using the
CDQL [2] language, that will be triggered when the consumer
car is getting close to the user’s destination. This query takes
different contextual attributes such as weather conditions,
walking distance, required parking facilities, and cost into
account. Further, this application provides an interface for users
to enter their parking-related preferences in the application.
Moreover, the application is connected via Bluetooth to an
OBD II device which reads the sensory data (e.g., VIN, speed,
and fuel level) coming from the car’s CAN bus. The application
collects this information, includes it in the query, and makes an
HTTP POST request to CoaaS.
We registered four different context services in CoaaS
based on the requirements of the scenario under consideration,
namely Monash Parking API, VIN checker API, Google
Location API, and Weather API. We used CSDL to describe
these services. We registered the Monash Parking API in CoaaS
as the main parking context service. Monash University has 10
different parking areas in Clayton campus which are equipped
with occupancy sensors. Further, Monash University has a
private web API that offers the real-time vacancy information
of its parking facilities. Further, to retrieve the specifications of
the consumer car, we registered a context service that accepts a
Vehicle Identity Number (VIN) as input and provides the make
and model of the car as output. Moreover, it provides car
specifications such as height and width. Another service that is
used in this scenario is Google Location API. This API has been
used for reverse geocoding purposes to convert the address to
coordinates. Lastly, to fetch information about the weather
conditions, we registered a weather service that accepts location
coordinates as input and provides the weather conditions as
output.
| https://twitter.com/edottechno1 |
No comments:
Post a Comment