1. Architectural Principles for Services Group Name: WG2- ARC Source: Tim Carey, ALU, timothy.carey@alcatel-lucent.com Meeting Date: 2013-10-04 Agenda Item: TP#7 ARC

2. © 2013 oneM2M Partners oneM2M-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

3. © 2013 oneM2M Partners oneM2M-ARC-2013-0402-Architectural_Principles_for_Services 3 oneM2M – Common Service Functions (CSF) 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.

4. © 2013 oneM2M Partners oneM2M-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.

5. © 2013 oneM2M Partners oneM2M-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)

6. © 2013 oneM2M Partners oneM2M-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- 0041oneM2M-SEC-2013- 0041

7. © 2013 oneM2M Partners oneM2M-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 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 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.