Hi Juajo, I just wanted to make a quick comment: the OMA NGSI-10 does have a queryContext operation that queries the value of a contextInformation supplied by the ContextProducer. Although we have not seen neither the specs nor the implementation of the TI NGSI-10, I wonder what is the novelty? Can you please be more specific what is missing from the OMA NGSI-10 operation? Best, Dénes From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of ext Juanjo Hierro Sent: Monday, February 20, 2012 8:46 AM To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Comments on Exposure GE in IoT Chapter Hi all, Please find below my comments on the Exposure GE. === (note 1: 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.) (note 2: 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 ... However, the current IoT Service Enablement Chapter Architecture uses the term "device" prominently ... Below, I use the term "IoT resource" rather than "device".) There is no need to define two cascade layers of the FI-WARE NGSI-10 interface, one exported by the "Thing-level API" part of the "exposure GE" and another one exported by the "Publish/Subscribe Broker GE" (no matter whether the reference implementation of this last GE is provided by Telecom Italia or not), making both "cascading layers" visible to applications. As far as I understand, NEC argued that such "cascading" would be necessary mostly because the OMA specifications didn't consider the possibility that the (Publish/Subscribe) broker exporting a OMA NGSI-10 interface implements the "query" operation so that it can, in turn, invoque a query, on a context producer. NEC pointed out this might be an issue in scenarios where it is more sensible to query IoT resources at device level instead of letting them be constantly notifying observations. However, the fact that such operation is not considered in OMA NGSI-10 specs may be consider a major usability gap of OMA specs and we don't need to feel constrained (trying to find an artificial workaround) whenever we face a gap in the specs as we have mentioned several times. We may simply decide that the FI-WARE NGSI-10 specification will include a "query" operation that a Publish/Subscribe Broker can invoke on Context Producers, provided such Context Producers have registered as exporting such operation. Interestingly enough, I have found out that Telecom Italia's implementation of NGSI includes this extension, probably because real-life applications have proven to request this (I guess for scenarios similar to those described by NEC when it raised the issue). On the other hand, as already explained a couple of times, there is no need to wrap access to the Things/Resource Configuration Management GE in order to provide the FI-WARE NGSI-9 interface. It can expose this directly to applications. This would be because entities handled at FI-WARE NGSI level may be either Things or IoT resources (at device-level). You may discover the existence of an entity that refers to an IoT resource and then deal directly with the interface exported by that IoT resource using the ETSI M2M API. Is anything wrong there ? Based on the comments above, a figure that may describe a target reference architecture for the backend may look as shown below. I have renamed the "Exposure GE" as "ETSI M2M Handler" because it wouldn't deal with exposing the NGSI APIs but indeed it would act as a bridge between the NGSI and M2M worlds (besides supporting Process Handling which probably would require further discussion). Indeed, I would be in favour of splitting the GE into two, so that the "Observation Handler", "Request Handler", "Process Handler" and "Semantic Handler" components are on one side, being part of the "ETSI M2M Handler GE", and the "Device-level API" component goes apart so that, together with the "Service Control GE" and the "Device Control GE", become a GE dealing with implementation of the ETSI M2M API. Note that the channel in red represents the "query" request that is missing in the OMA NGSI-10 spec and we should include in FI-WARE NGSI-10 specs Besides the above, I believe that a component dealing with self-registration of IoT resources may be required (I'm not sure if the ETSI M2M model supports that). Such component would deal with reception of messages from lower layers (IoT gateway or IoT resources at device-level) using ETSI M2M APIs linked to registration of IoT resources. ==== Best regards, -- Juanjo On 17/02/12 14:26, Juanjo Hierro wrote: Hi all, I just want to anticipate to you that I see several issues in the description of the Exposure GE. I will sent you a detailed analysis later this evening or tomorrow. Unfortunately, I cannot do it earlier. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: 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/fiware-ngsi/attachments/20120220/55d2b3f8/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 133941 bytes Desc: image001.png URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120220/55d2b3f8/attachment.png>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy