architectural principles for services group name: wg2- arc source: tim carey, alu,...
TRANSCRIPT
Architectural Principles for Services
Group Name: WG2- ARCSource: Tim Carey, ALU, [email protected] Date: 2013-10-04Agenda Item: TP#7 ARC
© 2013 oneM2M PartnersoneM2M-ARC-2013-0402-Architectural_Principles_for_Services
2
Background
• The current oneM2M Architecture is based on a:– Resource Oriented Architectural Style– Non-coupled descriptions of Common Service Functions derived from
high level requirements
• What we haven’t considered well enough in the existing architecture are– Capability to extend the Architecture with new Services– Ability to extend capabilities using vendor-specific options– Componentization of CSE that allows Services to be expressed– Capabilities to fully utilize the protocols and Architectural Styles of
existing M2M solutions
© 2013 oneM2M PartnersoneM2M-ARC-2013-0402-Architectural_Principles_for_Services
3
oneM2M – Common Service Functions (CSF)
X Reference Point
Z Reference Point
Application Entity (AE)
Underlying Network Service Entity (NSE)
Common Services Entity (CSE)
Y Reference Point
Addressing and Identification
Data Management & Repository
Location
Security
Communication Management/
Delivery Handling
Registration
Session Management
Device Management
Subscription Notification
Service Charging & Accounting
Discovery
Network Service Exposure/Service
Ex+Triggering
Group Management
• The architecture is broken into functional components known as CSFs that logically group describe functions and sub-functions
• The architecture does not specify how these CSFs inter-operate
• The CSFs cannot be considered Service Components as they do not have Interfaces• Instead the Architecture defines a
set of Resources and Message Flows that describe its interfaces.
© 2013 oneM2M PartnersoneM2M-ARC-2013-0402-Architectural_Principles_for_Services
4
oneM2M Architecture – General Communication Scheme
• The architecture is a request and response communication style where Information Elements are exchanged as Resources in a RESTful manner.
• This is different than many existing M2M communication schemes where Information Elements are exchanged as messages either in a RPC or Publish and Subscribe communication style.
Originator Receiver
Request
Response
Resource Storage
© 2013 oneM2M PartnersoneM2M-ARC-2013-0402-Architectural_Principles_for_Services
5
Missing Architectural Principles
• The architecture must be pluggable (functionality must be added and removed without necessarily interfering with other functions)– For example architecture must allow communication to software
components without regard to a specific protocol (MQTT, XMPP, HTTP)
• The architecture must allow for functionality that has not been specified by oneM2M to be plugged into the architecture
• The architecture should be oriented to the majority traffic pattern (Data is passed as asynchronous messages – Typically Device to Application)
© 2013 oneM2M PartnersoneM2M-ARC-2013-0402-Architectural_Principles_for_Services
6
oneM2M Architecture – A Way Forward
• Redefine the Common Service Functions into Core and M2M Service Components
• Further describe the Core and Service Component into further functions, reference points and pluggable (extendible) capabilities)– See the Security CSF description oneM2M-SEC-2013-0041
CSE
Security CSF
SE n
Sensitive Data Handling
Security Service & Administration APIs
Se
cure
S
tora
ge
Se
curit
y A
sso
cia
tion
E
sta
blis
hm
ent
Application Entity
X
Se
nsiti
ve
Fun
ctio
n 1
...
Se
nsiti
ve
Fun
ctio
n n
NSE plug-in
Z
SE 1 plug-in ...
CSE
Y, Y’
SE n plug-in
Iden
tity
Pro
tect
ion
Ap
plic
atio
n La
yer
Se
rvic
e La
yer
Se
curit
y T
rans
por
t La
yer
Se
curit
y A
dmin
istr
atio
n
CSF
tbd
SE ...Secure Environment 1
Access Rules
Secure Storage Sensitive Funct.
Sensitive Data
Se
curity CS
F - C
SF
Interface
tbd
SE capability
A
cces
s
Man
agem
ent
Acc
ess
Con
tro
l
Au
tho
rizat
ion
Au
the
ntic
atio
n
Security Transport
© 2013 oneM2M PartnersoneM2M-ARC-2013-0402-Architectural_Principles_for_Services
7
oneM2M Architecture – A Way Forward
• Decide if Resources should really be used to express Information Elements instead of Services messages. If so; we need to also express Information elements (Resources) as messages in the context of a Service Component
< From Security CSF contribution oneM2M-SEC-2013-0041 >Editor’s note: RESTful approach may only be suitable for a subset of the Security
CSF functionality. Functions that are put into an enabler function (highlighted in blue in above figure) need to be considered. Alternatively, a new resource type <Function> may be needed. Security Transport not classified as resource and therefore not included in the tree.
• If we still stay with expressing Information Elements as Resources, then we will need to ensure that we have a WS interface developed for services in Protocols; since a significant number of existing M2M applications utilize a WS interface with the Device to Application traffic pattern.