Hi, Sorry that I didn't jump on this discussion earlier, but I was on holidays from Jan 12 until Jan 17, then I had to attend the FI-PPP Architecture Board on Jan 18 and 19, and I haven't been able to catchup until now. I wish to provide an answer to Martin's, Denes' and Tobias' mails (I will start with that from Martin's and I hope I will be able to answer the rest along today). My answer will just complement what Ricardo has said, maybe going a bit further. I hope they are useful. I plan to join the architectural discussions during the IoT WP meetings and be able to contribute to a fruitful discussion. On 11/01/12 09:33, Martin Bauer wrote: 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. Well ... I understand that IoT-A/SENSEI are relevant and important inputs to the definition of a Reference Architecture but do not dictate us the solution. On the other hand, I also believe that our work could translate into valuable input for IoT-A, which as far as I know is relatively early in its developments. Nevertheless, I believe looking at your questions that there is no big issue on compatibility between the proposed solution and the principles in IoT-A. Let's elaborate on those open questions ... 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? The proposal describes how everything can work together. So, yes, it explain how data that is sensored can be handled and exported by the Things Management Layer through a NGSI-10 -like interface. In our Architecture Specifications, we have to explain how the different GEs can integrate together. I don't believe this is an issue but the kind of things we should do. - 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”. OMA NGSI interfaces are defined in a way that the may be adapted to different usages. We are just explaining what components in a IoT Architecture would implement them and how these components would relate each other. We are not elaborating on rather detailed internal aspects. 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. According to OMA, NGSI-9 interface enables to: * register and unregister entities, * update information about entities and properties (e.g., what properties are linked to a specific entity, but not values of properties defined for an entity which is something that is obtained through NGSI-10) * dynamically discover registration/unregistration as well as updates on properties. And that is the intended use in the Architecture. Given the fact that we have gone for adoption of NGSI as the basis for our work, I would find contradictory to say that we support NGSI-10 for basic exchange of data, but then we don't support NGSI-9 for the functions above. It gives me the impression that your vision on NGSI-9 is a bit limited. However, the above listed functions are not the only ones that the components handling access to the repository of entities and the information model have to provide through well-defined APIs. That's why we envision that we should define some sort of extension to NGSI-9 to deal with, for instance, the ability to register relationships among entities, and navigate through these relationships (apply discovery on relationships). My vision is that most of these extensions should be fast-tracked as optional interfaces in OMA (because not all Context Management systems, for example, may need to support the concept fo relationships between entities). I don't understand what you are trying to say when you state "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" ... As it was already mentioned in the slides, IoT resources may be treated just as any other entity from a NGSI perspective (this was something that was an open point for discussion, but based on your comments below, I would assume the right approach is that they should be treated as such). So there would not be any contradiction with OMA-NGSI. - 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. Wrong. Regarding "decoupling between application and IoT resources", I want to say that entities, as treated through the NGSI interfaces, can be translated to whatever we want in the IoT space, as long as we don't break any of the principles in the OMA conceptual model. Therefore, both Things and IoT resources can be treated as OMA entities, with the obvious relationships between one another. Neither OMA NGSI-9 nor NGSI-10 include operations that enable to manage relationships between entities, because that would not be a mandatory characteristic of a Context Management system, but there is nothing that prevents such relationships to exist and be manageable through a well-defined set of APIs that complement NGSI-9 and NGSI-10. If we allow IoT resources to be treated as OMA entities, we then achieve the direct access to IoT resources from applications you were requesting for. That simple. That elegant on the other hand. Issue solved. Regarding your comment that "the proposal can be characterized as a (logically) centralized architecture", I don't see why it cannot be adapted to run on IoT gateways, for example. We would just need to elaborate what components may not be there in such scenario or make some adjustments regarding description of how some of the interactions would be implemented. The interaction type supported therefore is an asynchronous “push”-style M2M data transfer that does not allow any other interactions. I don't see the point you are trying to make. Using NGSI-10, applications will be able to consume events from entities (i.e., Things or IoT resources) both in a pull or push style of communication. That is what the Pub/Sub Broker GE will support. Whether integration with lower levels through southbound APIs is a push or pull style will depend very much on the characteristics of the southbound API (i.e., ETSI M2M or even OGC-like) 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.) Wrong assumption. These resolution functions (from Things to IoT resources) would be also accessible to applications through APIs as well as to the end users through the portal. Such functions would be accessible through a well-defined set of APIs which would work as an extension of NGSI-9. 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. The proposed slides just elaborated how everything would work together with data handling, but of course, could be easily extended to cope with actuation on IoT resources. Hope it helps, -- Juanjo 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 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120123/79456b29/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy