Hi all, We at NEC have started to look into the Thing Management Architecture proposal made by Telefonica. Up to now we had assumed (also from the high-level architecture document) that the architecture would be closer to IoT-A/SENSEI. We see a number of open questions and points that we would like to start discussing: - Scope of the proposal and relation to other tasks in the WP We have the impression that the proposal provides a certain functionality in a stand-alone fashion. How does the proposal relate to the other tasks, in particular T5.3 and T5.4? Is it correct to say that the proposal covers significant parts of data handling (T5.3) in that it gets the update events, stores them in the repository and dispatches them further? - NGSI-related questions The idea of the NGSI interfaces is that they define the external interfaces of a "context enabler". They do not define the internal aspects, i.e. the architecture, underlying concepts etc. of such a "context enabler". The NGSI-10 interface is primarily intended for applications that use "context information", whereas NGSI-9 is intended for the interaction of the "context enabler" with peers or external context sources. They may provide context information which can be used by the "context enabler" to answer requests sent via NGSI-10. The peers or external context sources would typically implement NGSI-10 for accessing this context information. We are not sure whether the use of NGS-9 in the proposal is used as intended. You identify missing functionality, but we think that this functionality is related to the internal structure of the system, i.e., IoT Resources are aspects of the internal structure and this concept does not exist in OMA-NGSI and does also not fit the intended use. - General architectural concerns >From our point of view, the proposal can be characterized as a (logically) centralized architecture that is founded on a complete decoupling between applications and IoT resources, i.e. requests from applications cannot have any direct effects on the IoT resources as the latter publish their events independent of any request. The interaction type supported therefore is an asynchronous "push"-style M2M data transfer that does not allow any other interactions. The resolution (unlike in IoT-A) only works from IoT-data to Things, but not the other way round, i.e., the IoT resources are not visible and therefore accessible to applications or IoT components from T5.3 and T5.4. We currently do not see how Thing-based actuation can be supported in this approach as this required a resolution to IoT resources and then a direct interaction with these resources. (We also see use cases where queries should be directly forwarded to Iot Resources.) Finally, the business processes/workflows planned in T5.4 require the Thing-based look-up/discovery of IoT Resources, which should then be directly integrated into the process execution. Best regards, Martin and Tobias ------------------------------------------ Dr. Martin Bauer Senior Researcher NEC Europe Ltd. NEC Laboratories Europe Software & Services Research Division Kurfürsten-Anlage 36 D-69115 Heidelberg Tel: +49/ (0)6221/4342-168 Fax: +49/ (0)6221/4342-155 E-Mail: Martin.Bauer at neclab.eu<mailto:Martin.Bauer at neclab.eu> http://www.nw.neclab.eu<http://www.nw.neclab.eu/> ************************************************************* NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120111/a260aeb9/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy