![](bg5.png)
third party (3
rd
-party) with respect to the user-to-
cloud relationship of storing users’ device data. Users
must be able to grant fine-grained access for their de-
vices. This can be device data (e.g., single key-values)
and/or control abilities.
Methods to grant or retrieve access based on user
credentials (UC) with login and password, or access
token-based concepts like Oauth 2.0
12
(OA2). Nowa-
days, OA2 is the state of the art for granting 3
rd
-party
access to own resources. It avoids exposing credenti-
als while combining authentication and access control
into a single operation.
User to User (u2u) access is another possible 3
rd
-
party scenario. Imagine a neighborhood where people
on vacation want to give other neighbors temporary
access to devices (e.g., door lock or CCTV). Hence,
we investigated if clouds allow sharing device resour-
ces across users. We distinguish no (e.g., forbidden),
full (across all users in the cloud), and partial sharing
(e.g., tenant or account based).
2.6 Cloud-federation Support
Some of the reviewed clouds’ API support cloud fe-
deration (Fed.). Because our intention is to build a
P2P-Intercloud, we were interested in the aspirations
of cloud providers to interconnect with other clouds.
It confirms our assumption of a general need for this
idea. The main difference to our approach is that 3
rd
-
party cloud providers have integrated their solution in
each of those ecosystems.
2.7 Discussion of the Results
The Microsoft Azure IoT Suite
13
is more like a PaaS
Framework than a ready solution. It provides building
blocks with different implementations to compose a
solution. There are neither reasonable constraints nor
a complete data model nor defined interfaces. Thus,
most of our evaluation criteria are not applicable (n/a).
We included it for sake of completeness.
The Pull API only shows minor differences
among all clouds. To the best of our knowledge, only
the Digi/Etherios
14
cloud is not capable to deliver a
full device state in the result list, while only utilizing
the Pull API. For the request parameters (Pj, Pg, H, S),
adaptation strategies have to be found for each cloud,
if they support a certain parameter only partially, or
not at all. E.g., the Nest cloud would need a solution
12
https://tools.ietf.org/html/rfc6749
13
https://docs.microsoft.com/en-gb/azure/iot-suite/iot-
suite-what-is-azure-iot
14
http://www.digi.com/resources/documentation/
digidocs/90002008/default.htm
for history parameters. As only the last state is sup-
ported, a possible strategy could be, to only deliver
this last state, if the requested time interval includes
the present time, otherwise nothing. Clouds missing
projection capabilities could respond the full device
projection, while their results need to be processed
either in the adapter of the IB or at service client side.
The same applies to parameters (PU, RA) of
the Push API. Here, the IB may add missing logic
for aggregation of periodic updates and also introduce
addresses instead of handler objects, which the most
clouds only support. This can be achieved by utili-
zing CEP and IoT messaging protocols. For the No-
tification phase of the Push-based communication, all
clouds provide communication on base of full-duplex
protocols. Notably, with MQTT the Eurotech Every-
ware cloud already has in use a protocol designed for
IoT Publish-Subscribe scenarios.
The most important differences of the clouds on
both, Pull and Push API, are related to the filters and
the device model. As they work together, a unified po-
werful solution needs to be selected for the IB, cove-
ring all vendor-dependent scopes. The proceed model
for filtering are equal for Path and TB, rsp. KVS and
CB. The firsts needs a structure to apply key-value fil-
ters (table/object, topic) on, while seconds work on
all contents (stream, NoSQL DB).
The Kiwigrid Cloud is able to filter key-values
with the same filter engine for Pull and Push. The Eu-
rotech Everyware cloud uses a CEP Engine for Push
data. Others’ filters are limited to a predefined set of
query operations rsp. filter on predefined topics. Be-
cause filtering with key-values is more flexible, our
API should support it. The adaptation for Pull-based
requests between NoSQL and relational databases is
possible. Following the Entity-Attribute-Value (EAV)
model, key-value queries can be mapped on schema-
based databases. Mainly, with a well-defined EAV
temporary DB, the required property mapping and re-
lationship mapping are feasible. The reversal is also
possible. Mapping between topic to content-based fil-
ters can be achieved by connecting to all topics, and
then filtering the result with a CEP engine.
Interoperability of device models is of special im-
portance since some of the communication aspects di-
rectly depend on a uniform/compatible interpretation
of device data. In particular, the complex filters pas-
sed to the Pull or Push API and the Control API base
on the device model. The heterogeneity of device mo-
dels makes it fairly impossible to simply link APIs of
different cloud providers. Complex mapping based
on ontologies and data adapters would be necessary
to establish a common base. In future, development
can be facilitated, if a common high-level standard for
CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science
680