Hi Juanjo, So you agree that pull-style communication is needed for IoT? - This is great, because we have the same opinion. :) And you say that "the architecture becomes much clearer if we just support this pull-style of communication"? - We are more than happy with that. :) Indeed it was the TID architectural proposal had which had introduced the push-style communication. However, the pub/sub GE does not fully support the pull-style interaction, as we have pointed out in our email from yesterday. (I attach the email for your reference.) Once again: This is a restriction of the pub/sub GE. It is not a restriction of NGSI-10. The simplest solution would therefore be to remove the pub/sub broker GE from the IoT backend. Then we only have one Thing-level interface that is exposed towards apps. And we have full support for pull-style communication. What do you think? Best regards Tobias From: fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro Sent: Dienstag, 21. Februar 2012 12:51 To: Martin Bauer Cc: fiware-ngsi at lists.fi-ware.eu Subject: Re: [Fiware-ngsi] [Fiware-iot] Comments on Exposure GE in IoT Chapter Hi Martin, You are putting restriction on usage of NGSI that are over-complicated the overall IoT Architecture. Among other things, forcing to have a cascade of two brokers implementing the NGSI-10 interfaces where you may have just one. The need for support a pull-style of communication between the a Pub/Sub Broker implementing the FI-WARE NGSI API is clear and this is something that seems to be proven not because TI's experience demonstrates this (and I guess this is something worth to consider) but because the design of architectures which may have similar requirements to those in IoT (i.e., need to capture context data from sources that may be pasive rather than active or have to safe power) would require this. Just consider an example of architecture where we may need to get context data elements from mobile devices. I have to confess that the first time I read the NGSI-10 spec I though that not that the fact it didn't support this pull-style of communication was a gap, but thought that we would just need to add such extension if there were a clear requirement to support it (I assumed we would find it sooner or later, but wanted to confirm it in real, rather than speculating) ... and this is what has happened. Sorry, I don't buy your arguments. The IoT Architecture becomes much clearer and cleaner if we just support this pull-style of communication within the FI-WARE NGSI API. As I have said, that would be a feature that would not only be relevant to ease the implementation of the IoT Architecture but would be also a feature that I envision would be rather useful in other scenarios. Added value no matter from what angle you analyze it. Last but not least, I'm afraid that support of this pully-style of communication would also be needed between Pub/Sub Brokers and Consumers. This may be needed to establish federation between the backend and gateways that support a FI-WARE NGSI-10 northbound interface for forwarding of events and may not want to be pushing events but rather react on demand. As for NGSI-9, I will send soon an email elaborating on the mismatch I have found regarding the interpretation about scope and semantics of the NGSI-9 interface. Best regards, -- Juanjo On 20/02/12 15:51, Martin Bauer wrote: Hi Juanjo, One short comment on the NGSI discussion - we are currently preparing an NEC answer to your other comments. - NGSI only defines interfaces, NOT an architecture of the respective enablers. - The NGSI interfaces are to be seen as external (northbound) interfaces of the enablers - the TI architecture for implementing a context enabler is only one possibility - anything is possible as long as the northbound interface implements the NGSI functionality - NGSI can, but does not have to be used to implement (internal) Context Producer components - internally any structures, interfaces and interactions can be used (and TI conceptually uses two different subsets of NGSI-10/9 to implement the respective interfaces with the Context Sources (NGSI-10 update) and Context Providers (subset of NGSI-10 query towards context provider, subset of NGSI-9 register towards Context Broker) - from an NGSI point of view, context providers could implement the full NGSI-10 interface and register their services with a context broker using NGSI-9 - from an NGSI point of view it is also fine to implement Context Sources that use the NGSI-10 update operations to publish information (but as mentioned above this is not the only way to do it and we do not consider this to be suitable for a number of IoT scenarios) 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: fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro Sent: Monday, February 20, 2012 3:33 PM To: Bisztray, Denes (NSN - HU/Budapest) Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu> Subject: Re: [Fiware-ngsi] [Fiware-iot] Comments on Exposure GE in IoT Chapter Hi Denes, The queryContext operation defined in OMA NGSI-10 is to be exported by the Publish/Subscribe Broker (in OMA NGSI referred as "Context Management component". Precisely the problem is that it is nowhere specified in OMA NGSI-10 that Context producers may export the queryContext operation. The current OMA NGSI-10 spec seems to work assuming that Context Brokers gather events because Context producers have invoked the updateContext on them. This means that only a push mode of communication is used between Context producers and Brokers (Context Management components). My understanding was that NEC mentioned this may be a drawback of any OMA-compliant Publish/Subscribe Broker implementation: experience idemonstrate that there are real scenarios where it would be highly desirable that Publish/Subscribe Brokers query Context producers (i.e., support a pull mode of communication) when the Context Producer is linked to a IoT resource running on a device, since this would avoid that such IoT resource were consuming energy pushing events when may not be necessary. It was also my understanding that NEC assumed that TI's implementation of NGSI would not support this pull style of communication between producers and Brokers. Interestingly enough, as I explained, I have found (I didn't know) that TI's implementation support this pull type of communication. I guess because they have faced similar scenarios to the ones described by NEC. TI has published a description of its current asset on From my point of view, this is the typical example of something in the OMA NGSI specs that needs to be changed and we had decided to change in FI-WARE leading to this notion of FI-WARE NGSI specs Cheers, -- Juanjo On 20/02/12 13:36, Bisztray, Denes (NSN - HU/Budapest) wrote: 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> [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<mailto: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 [cid:image001.png at 01CCF09C.69F637D0] 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<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 ________________________________ 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 ________________________________ 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/20120221/95fddc4a/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/20120221/95fddc4a/attachment.png> -------------- next part -------------- An embedded message was scrubbed... From: Tobias Jacobs <Tobias.Jacobs at neclab.eu> Subject: RE: [Fiware-iot] Comments on Exposure GE in IoT Chapter Date: Mon, 20 Feb 2012 16:40:31 +0000 Size: 208673 URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120221/95fddc4a/attachment.mht>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy