Hi, I attach some slides that hopefully shed some more light on the discussion about interaction patterns. The first one is a decoupled pub-/sub- architecture and corresponds to how we understand the Telefonica proposal, which is supported by the Telecom Italia Publish-/Subscribe-Broker. We then argue why this is not suitable for some IoT scenarios and show the interaction style supported by the SENSEI architecture and ISIS. (Tobias or Ernö will present these slides in the WP5 meeting.) Below some comments to Juanjo's comments. 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 ... My point was not that FI-Ware has to directly take the IoT-A or SENSEI architecture, but 1) IoT-A and SENSEI before have already done a lot of architecture work, so it should not just be ignored. There should be good reasons why different decisions are taken. 2) Telefonica had earlier stated that it would like to see an alignment between the projects - I was just pointing out that apparently this position has changed. Regarding OMA NGSI, I would like to point out that Ernö and me were directly involved in the OMA NGSI standardization process. In fact, a significant share of the contributions towards the Context Interfaces came from us. Maybe that should be taken into consideration in the discussion about OMA NGSI-9/10. Looking at OMA NGSI-9, the interface is used for registering and discovering sources of context information, i.e., external applications (external context providers or "peer" context enablers) that can provide this information through an NGSI-10 interface. The idea is that the "context enabler" would query or subscribe to their context information through this interface. If the applications simply uses "update" to push information into the "context enabler", I don't think it would have to register. (This seems to be the case for the Pub-/Sub-Broker from Telecom Italia and they therefore do not implement NGSI-9). So, looking at OMA NGSI-9 again, of course it can be used in all cases where the "IoT Resource" provides an NGSI-10 interface for interaction. The URI that is registered should point to that NGSI-10 interface. Now, we should discuss whether this is realistic, or whether the "IoT Resources" rather implement ETSI M2M or OGC interfaces. In these cases, we might still use NGSI-9, but we have to make clear that the URI may point to a different interface and we need to provide the information what type of interface that is elsewhere. 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). In my opinion the relations between entities is content information that should rather be stored in and provided by IoT Resources, i.e., there is a property/attribute of a Thing that would point to the IoT Resource that can provide this information. This association would be stored in the Thing management, same as associations that refer to IoT Resources providing sensor data. This IoT Resource can be a large data storage and could implement an OMA NGSI-10 interface for access. 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. For me an IoT Resource is a functional component with an interface that can be accessed, i.e., that IoT resource would implement subscribe and query functionality. If you use OMA NGSI-9, the registered URI should point to this interface. What you are saying is that an IoT resource could also be modeled as a Thing - sure it can, but this is not the underlying functional component, which needs to be discovered. In certain scenarios, it is not sufficient to get the value that a resource has previously delivered to the system, but to actually contact the IoT Rresource itself. For enabling this, you cannot have a completely decoupled system (see attached slides). 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. No this is not true, see statement just above. 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) I'm not talking about the NGSI-10 interface, indeed you can use both pull- or push-style communication there. I am talking about the internal communication within the WP5 IoT Enablers (see attached slides). Best regards, Martin ------------------------------------------ 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 From: Juanjo Hierro [mailto:jhierro at tid.es] Sent: Montag, 23. Januar 2012 07:22 To: Martin Bauer Cc: fiware-iot at lists.fi-ware.eu; jhierro >> "Juan J. Hierro" Subject: Re: [Fiware-iot] Feedback Thing Management Architecture 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/ae834990/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: FI-WARE IoT - Interaction Patterns.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 110356 bytes Desc: FI-WARE IoT - Interaction Patterns.pptx URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120123/ae834990/attachment.pptx>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy