Service-Oriented Computing - CSC 450 and CSC 750 · XMPP: Extensible Messaging and Presence...

Challenges

Discovery

Physicalobjects

Dealingwith places

Dataservices

Powersource?

Distri-bution

Delaytolerance

Asynchrony

Unreliablemessaging

Security

Integrity

Privacy

Owner’sOthers’

Trust

Provenance

Gover-nance

Autonomy

Decen-tralization

Sharingthings

Usability

Identifying

Visualizing

Manip-ulating

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 126

http://courses.ncsu.edu/csc750/lec/601/

ResearchApproach

Require-ments

Datastreams

Loggingdata

Decen-tralization

Governance

Explicitmodeling

Causality

Integrity

Privacy

Account-ability

Enactment

Autonomyrespecting Asyn-

chronous

Decoupled

Supportstracing

Gover-nance

Sharingthings

Normativebasis

Vividmodeling



Contract Net Protocol: 1Announce

Sensor Sensor Sensor

Sensor Manager Sensor


advertise advertise advertise

advertise advertise

advertise advertise advertise



Contract Net Protocol: 2Bid




bid

bid

bid bid



Contract Net Protocol: 3Award




award



Contract Net Protocol Evaluated

I Generic protocolI Can apply recursively

I Supports important propertiesI Robustness against sensor failureI Robustness against connectivity failureI Incorporating economic features

I Not well specifiedI Confuses interaction and internal reasoningI Limited to two-party interactions



Main Architectural Elements

Things Middleware Applications Users

DiscoverySelection

Sensors StorageUser

Interface yActuators Monitoring Reasoner x

Control

IoT emphasizes ownership



Decentralization Calls for a Multiagent ArchitectureEach agent represents an autonomous party, contains a reasoner; interact within Org

Org

UserInterface

UserInterface

KnowledgeBase

Agent AgentKnowledge

Base

StreamProcessing

StreamProcessing

Adapter& Thing

Adapter& Thing



Emerging Standards Support Decentralization in Principle

Application

AuthenticationBootstrapping

ServiceCapability

Gateway

Device


Based on ETSI draft TS 102 690, May 2014, 〈http://docbox.etsi.org/smartM2M/Open/Latest_Drafts/〉


http://docbox.etsi.org/smartM2M/Open/Latest_Drafts/

Comparing Traditional Web and IoT ProtocolsFrom ReST to Constrained RESTful Environments (CoRE)

HTTP Application layerMQTTCoAP

TCP Transport layer UDP

IPv4IPv6

Network layer6LoWPAN

Zigbee

EthernetWiFi

Data link layer IEEE 802.15.4

InformationResource

Thing



Protocol: MQTTNee Message Queue Telemetry Transport

I OASIS standard as of November 2014, v3.1.1

I Focused on machine-to-machine communications

I Asynchronous

I Data parsimoniousI Small set of primitives, including

I PublishI SubscribeI Create and cancel subscriptionsI Configure “last will and testament” (LWT) notifications

I Detect disconnections without a disconnect messageI Send configured LWT notifications

I Three QoS levels (separately specified by sender and receiver)0 At most once; message: publish; no message ID needed1 At least once; resend with dup bit until puback received2 Exactly once; server stores, then forwards to receivers



CoAP: Constrained Application Protocol

I IETF RFC 7252, June 2014

I Asynchronous

I Data parsimonious

I Supports URIs

I Supports resource discovery from server

I HTTP-like verbs: get, put, post, delete

I Small set of request and response typesI Communication patterns

I CachingI Block transfer of large content

I QoS support (message types)I Confirmable con: require acknowledgmentI Nonconfirmable non: do not require acknowledgmentI Duplicates to be ignored by receiver



CoAP Tooling: Copper Plugin for FirefoxDisco

very

Commands

Headers

Payload


Credit: Matthias Kovatsch, 〈http://people.inf.ethz.ch/~mkovatsc/copper.php〉


http://people.inf.ethz.ch/~mkovatsc/copper.php

AMQP: Advanced Message Queuing Protocol

I OASIS standard as of October 2012, v1.0

I Protocol—distinguish from an API such as JMS

I Decouples communications from destination address

I Long-lived conversationsI Variety of communication patterns

I InterceptI DelegateI Multiplex and demultiplex

I Upcoming improvementsI Traffic flow and QoSI Decentralized deployment and governanceI Multiple underlying protocols



AMQP Exchange Space Abstraction

Sensor Broker Broker Consumer

Local AreaExchange

Wide AreaExchange

Local AreaExchange


Based on work with Ocean Observatories Initiative, UCSD Scripps


XMPP: Extensible Messaging and Presence ProtocolOriginally meant for collaboration and content sharing

I Adapted and enhanced for IoT via XMPP Extension Protocols

I XEP-0323: Internet of Things – Sensor Data, v0.4, March 2015I Describes protocols and data formats for variety of needs

I Request sensor reading and responses theretoI Requests with multiple responsesI Requests to multiple thingsI Discovery: what features (including services) a thing supports

I Different from discovery of a thing

I Specification of quality of data value (termed QoS), e.g.,I Missing, estimated, manually read, delayed, invoiced, . . .



XMPP: Extensible Messaging and Presence Protocol

I XEP-0347: Internet of Things – Discovery, v0.3, November 2014I Uses JID or Jabber ID or an XMPP address for various resources

I RegistriesI Provisioning serversI Things

I Specifies protocols and data formats forI Finding a registryI Registering a thing: a thing registers itself

I Specifies secret data for registrationI May provide the same data via a sticker (QR-code) on a physical thingI Public things remain searchable after being claimed

I Owner claiming a thing (by supplying the secrets)I Only claimed, currently owned, things can be searched

I Removing a thing from a registryI Disowning or relinquishing a thing



Cloud StorageEliminate need to set up complex storage services from scratch

I On demand

I Variety of dataservices

I NoSQL (andNewSQL) databases

I Alternative toACID databases

I Tradeoff strongconsistency forlow latency

Cloud Storage

Database

File system

ReplicationLoad

balancing

Contentdelivery

networking

Memorycache

Sensors

Data



Cloud ServicesQuerying and transforming data

I Structured Query Language (SQL)

I Rule engines

I Complex event processing (CEP)I Streaming SQL

I Continuous queriesI SQL-interface for event processing

I MapReduce programming

I Hosting and executing custom programs



ETSI’s Service Capability LayerOn top of connectivity: holdall for functional, security, and governance aspects

I CommunicationI Semisynchronous: quick ack followed by full answerI AsynchronousI Works on top of another protocol, e.g., HTTP and CoAP

I Service capabilitiesI RegistrationI Access controlI AuthenticationI Data transferI Subscribe and notifyI Handling groups



Fog ComputingCisco’s term for decentralized or “ground-level” variant of cloud computing

I Intermediary between things and the cloud (data centers)

I Place computing, storage, services near the edgeI Process data closer to where it originates

I Many devices talk to one anotherI Improve latency and throughput

I Improves treatment of autonomy with gains inI Local governanceI Security



Event-Driven ArchitectureConsume and produce event streams

I Event attributes: ID, timestamp, and content values

Sensor 0

Sensor 1 Rule A Rule B

Sensor 2

(Alerts) (Threats)



Linked Data Highlights

I Web-based identity and networkI URIs identify resourcesI Deferencing a URI produces a resource descriptionI Resources link to other resources

I Web-based semanticsI Encoded in a Semantic Web language, such as the Resource

Description Framework, RDF

I Exploit underlying architecture, e.g., Domain Name System and Webservers, to locate resources



Linked Data for IoTSensor data is worthless unless linked to something else!

I Describe thingsI Link thing descriptions to one anotherI Enable thing discovery

I Describe the information produced by things

I Describe how to configure thingsI Enable things to exchange semantic information

I Facilitate reasoningI Promote interoperability

I Supported by standards that incorporate URIsI CoAP, ETSI’s Service Capability Layer



Realizing IoT

Asyn-chrony

Publish-subscribe

Topics

Streams

Selection Registering

Discovering

Descrip-tion

QoS spec-ification

Enactment



SelectionCriteria

Device

Sensedattribute

Perfor-mance

Latency

Through-put

Quality

Precision

Powerprofile

Datavolume

Envi-ronment

Location

Nearbydevices

Mobility

Contextawareness

Vehicles

Approach

Semanticquery

Similarity

EconomicSocialOwner oroperator

Reputation

Price



SemanticDescriptions

Ontologies

Content

Qualityof service

Social re-lationships

Semanticservice de-scriptions

InputsOutputs

Precon-ditions

ResultsInteractiondescrip-

tions

Data types

Protocols

Normativeexpec-tations



History-BasedSelection

Reputation

Sharing

Main-taining

Trust

Engen-dering

Estimating

CredibilityProvenance



Sensor WebEnablementStandards

Services

Registry

Obser-vation

Alert sub-scription

Planning

Notificationdialogue

Infor-mationmodels

SWEcommon

data model

SensorML v2.0,Feb 2014

Obser-vations

and mea-surements

AssociatedtopicsLocation,

v1.2,Sep 2008

Indoorgeospatialmarkup,

Dec 2014


Credit: OGC Network, 〈http://www.ogcnetwork.net/〉


http://www.ogcnetwork.net/

Safety: Approved Access UnsafeRemoved local conflict between accept and reject

Approved Access Unsafe {role Reques te r , C o n t r o l l e r , Sourceparameter out ID key , out item , out outcomeprivate token , v a l u e //REMOVED: r e s p o n d e d

R e q u e s t e r 7→ C o n t r o l l e r : r e q u e s t [ out ID , out i tem ]C o n t r o l l e r 7→ R e q u e s t e r : a c c e p t [ in ID , in

item , out token ] // , out r e s p o n d e dC o n t r o l l e r 7→ R e q u e s t e r : r e j e c t [ in ID , in item , out outcome ]

// , out r e s p o n d e dC o n t r o l l e r 7→ Source : ask [ in ID , in item , in token ]Source 7→ R e q u e s t e r : p r o v i d e [ in ID , in item , in token , out

v a l u e , out outcome ]}

I controller can send both accept and reject

I Thus outcome can be bound twice in the same enactment



Liveness: Approved Access Minus AskOmitted the ask message

Approved Access Minus Ask {role Reques te r , C o n t r o l l e r , Sourceparameter out ID key , out item , out outcomeprivate token , responded , v a l u e

R e q u e s t e r 7→ C o n t r o l l e r : r e q u e s t [ out ID , out i tem ]C o n t r o l l e r 7→ R e q u e s t e r : a c c e p t [ in ID , in item , out token , out

r e s p o n d e d ]C o n t r o l l e r 7→ R e q u e s t e r : r e j e c t [ in ID , in item , out outcome ,

out r e s p o n d e d ]// C o n t r o l l e r 7→ Source : ask [ in ID , in item , in token ]Source 7→ R e q u e s t e r : p r o v i d e [ in ID , in item , in token , out

v a l u e , out outcome ]}

I If controller sends reject, the enactment completes

I If controller sends accept, the enactment deadlocks



Safety and Liveness Violations

R C S

Approved Access Unsafe

Safety Violation

request

accept

ask

reject

provide

R C S

Approved Access Minus Ask

Liveness Violation

request

accept

provide

Cannot occur



IoT Hourglass: Few Platforms for Many ApplicationsBenefit from the upper layers; excitement from the lower layer

Consumers Providers

Applications

Platforms

Infrastructure

Devices



Service-Oriented Computing - CSC 450 and CSC 750 · XMPP: Extensible Messaging and Presence...

Documents

Transcript of Service-Oriented Computing - CSC 450 and CSC 750 · XMPP: Extensible Messaging and Presence...