Hi all, Please find my comments to the IoT chapter. I have found some major issues to resolve prior going public. And they are not just "formal". * We have to fix the issues I have already mentioned regarding the "Exposure GE" * There is a missmatch on interpretation about the meaning of the NGSI-9 interface in different parts of the Architecture. I will elaborate on this matter in a separate email I will send to the NGSI mailing list. We have to fix it. * It is unclear to me why we should have a common "Service Execution Layer" wrapping access to southbound APIs (see detailed comments below). Below, the detailed comments: ==== (note: whenever I use the term "FI-WARE NGSI" I refer to the spec based on OMA NGSI we are going to support in FI-WARE which may differ from the OMA spec for good documented reasons. We will intend to fast-track the adoption of changes into OMA to generate an update of those specs that finally aligns with FI-WARE NGSI specs. "OMA NGSI" will be used to refer to the NGSI interface as currently specified in OMA. Whenever I use the term NGSI, without qualifying it, it is because it is in a statement that would apply both to OMA NGSI and FI-WARE NGSI. Note that a clarification like this should be introduced in the Architecture Description.) 1. Major comments 1.1 Chapter overall description * In the FI-WARE Product Vision we introduced the term "IoT resource" an used it with preference to "device" which could mean many things and may lead to misinterpretation ... Why aren't we here consistent with that and use "IoT resource" rather than "device" ? * Saying "It has two northbound APIs: a device level and a thing-level" when talking about the IoT Backend is not accurate. The FI-WARE NGSI interfaces will allow to get events (as context element data structures) generated from IoT resources (i.e., device-level). Note that both things and "IoT resources" will be represented as entities in NGSI. I would say something like "it supports access at both device and thing-level" (or "it supports access at both IoT resource and thing-level" if we consider the previous comment). 1.2 Exposure GE architecture Please check mail on "Comments on Exposure GE in IoT Chapter" for the most relevant comments, content-wise, for this section. These comments should be tackled in the first place. The Main Interaction section doesn't strictly follow the reference example provided in the guidelines. Reference to name of interfaces and operations in the descriptions are missing. UML sequence diagrams would be helpful as well. Change OMA NGSI to FI-WARE NGSI where appropriate. 1.3 Things/Resource Configuration Management GE Again, as described above, we should use the term "IoT resource" to be consistent with the terms and definitions we introduced in the FI-WARE Product Vision (otherwise, review it). Sometimes the text may lead to misinterpretation. Entities, as defined in FI-WARE NGSI may represent either Things or IoT resources. Sometimes the text is clear about that, but sometimes it is not. As an example, it is said "using the NGSI-9 interface exported by the "Things/Resource Configuration Management" component, applications are able to register and discover Things in the system" ... when the fact is that using the NGSI-9 interface they would be able to register IoT resources too. Please review it. The repository of events does not need to be a part of this GE. I believe it should be assumed that storage of events would be handled by the Publish/Subscribe Broker GE. Some of the descriptions of Main Interactions should be revised. English writing should be polished. We should refer to names of operations in the NGSI-9 interface whenever possible while describing Main Interactions (for example, interaction regarding registering of Things, IoT resources and associations. Regarding interaction with GEs related to Data Handling, the described interaction is only in push mode (the Observation Handler receives an event from lower layers) while we should also cover the pull mode (the Request Handler receives a query request from the Publish/Subscribe Broker GE and handles it issuing a request to the lower layers, see comments on Exposure GE). Change OMA NGSI to FI-WARE NGSI where appropriate. 1.4 Device FrontEnd GE Probably some of the contents need to reviewed at the light of comments to the Exposure GE. Again, I would recommend using "IoT resource" rather than "Resource" ... There is a missmatch about the interpretation about semantics of NGSI-9 interfaces here and in the Things/Resource Configuration Management GE. This should be fixed prior to publication. Description of main interactions do not follow the reference example provided in the guidelines. 1.5 Service Control GE We should at least provide a high-level description (one paragraph) of this GE. We currently just say that it won't be supported in the first release of FI-WARE ... 1.5 Connectivity Management GE The relationship with the ETSI M2M APIs or the southbound NGSI APIs is not clear ... Are the operations listed in "Main interaction" just wrappers of ETSI M2M operations which support "cache" of requests/responses data in case of lack of connectivity ? If so, ... how does connectivity management work together with NGSI interfaces when used southbound ? The section on "Main Interactions" do not follow the reference example provided in the guidelines. Actually, it would be rather helpful to elaborate on interactions describing how this Connectivity Management GE would intermediate messages exchanged with lower layers either through the ETSI M2M interface or through NGSI interfaces (I assume, based on the high-level picture provided for the whole chapter, that interaction between backend and gateway may be based on any of the two interfaces). Illustrating the description with some UML sequence diagrams would definitively help. 1.6 Device Front-End GE (Backend side) It's not clear what is the role of the "Service Execution Layer" component ... Is it intending to be some sort of common wrapper for both NGSI and ETSI M2M APIs ? If so, I would think it twice prior defining it as part of the architecture ... I would be much more in favor of describing that the "Observation Handler" or "Request Handler", for instance, would make usage of southbound ETSI M2M APIs or NGSI APIs ... 1.7 Local Storage GE (gateway) GEs are, by nature, replaceble ... Do we intend to make this element replaceble ? One thing is that the Publish/Subscribe Broker GE running on a gateway, for example, obviously needs to rely on a local storage repository and another thing is that such component would be replaceble ? I would go for dropping it and mention local storage capacities when required. 1.8 Data Access Policy GE The Architecture Description for this GE is too short. It is not described how it would interact with other GEs or the description lacks of the necessary details ... Why isn't this GE also present in the Backend ? 2. Minor comments (some editorial): 2.1 Chapter overall description * I would not use the term "component" when referring to the full backend, IoT gateway Device parts of the Architecture ... "Layers" ? (not sure this one is best) * "Devices can further be categorized into IoT compliant" ... I would say "Devices can further be categorized into ETSI M2M compliant" ... stating that "IoT complaint" equeals to "supporting the ETSI M2M model and APIs" is way too much * For the same reason when (at Backend description) we say: "The backend can be connected southbound to IoT compliant devices" we should say "... to ETSI M2M compliant devices" * When talking about Gateways we state: "taking into consideration the local constraints of devices" ... to avoid confusion with the devices the IoT gateway is interfacing to I would say "taking into consideration the local constraints of gateway devices" * In Exposure GE Architecture Description: I would suggest renaming "Northbound interfaces" in "Main Interactions" as "Northbound Interactions", in line with the other section within "Main Interactions" ==== Best regards, -- Juanjo Hierro ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es<http://www.tid.es> email: jhierro at tid.es<mailto:jhierro at tid.es> twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Chief Architect You can follow FI-WARE at: website: http://www.fi-ware.eu facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 twitter: http://twitter.com/FIware linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ________________________________ 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/20120220/a19ffe15/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy