[Fiware-iot] Necessary updates on IoT Chapter Architecture Description prior to publication

[Tobias Jacobs]

Hi Juanjo, all,

We agree in principle with your proposal, except that we think that the name "IoT Broker GE" describes the functionality of the Observation+Request handler better than "NGSI-IoT bridge" does.

Best
Tobias

From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro
Sent: Mittwoch, 29. Februar 2012 07:24
To: fiware-iot at lists.fi-ware.eu
Subject: Re: [Fiware-iot] Necessary updates on IoT Chapter Architecture Description prior to publication

Hi all,

  Please proceed uploading the contents of the IoT chapter once you incorporate the comments I provided.  If you don't agree with them, please let's discuss.

  I believe that the pending comments regarding interaction between the Observation/Request Handler and the Publish/Subscribe Broker GE are comments we can deal with before the final release by March 6 so we don't need to delay uploading of contents because of them.

  I remind you that we agreed to upload now contents linked to the backend part.   Uploading of contents linked to the gateway part can be planned for March 6.   This will give you enough time to fix whatever needs still to be fixed.

  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

On 28/02/12 17:04, Juanjo Hierro wrote:
Hi all,

  I have carried out a revision of the new text regarding the description of the Exposure GE in the IoT Chapter Description and here you are the comments that I believe we should incorporate prior publication of the IoT Chapter Architecture Description.   Some comments may be labeled as editorial but others are not.   However, I believe (or at least hope :-) there shouldn't be so much controversial ...


1. What we refer as "exposure GE" should be renamed to avoid misinterpretations.

  What is there within the boundaries of the so called "exposure GE" do not comprise the APIs exposed to the final applications.   The FI-WARE NGSI-10 interface that applications will use will be implemented by the Publish/Subscribe Broker GE, while the FI-WARE NGSI-9 interface that applications will use to query or get notified about IoT entities registered in the system (IoT resources or abstract things) will be implemented by the Things/Resource Configuration Management GE.

  It is true that the Observation and Request Handlers will implement the NGSI-10 interface (partly, see comment below) as well as use some operations of the NGSI-9 and NGSI-10 interfaces to interact with the Publish/Subscribe Broker GE and the Things/Resource Configuration Management GE, but this is not because we intend that those interfaces be exposed to applications but because we wish that the interfaces between the GE embracing the Observation and Request Handler and the other two GEs be standard (therefore, the implementation of the three be truly replaceble).

  Regarding what name is therefore more appropriate for this box/GE, I refer to point 3 below.


2. What is a GE within the "exposure GE".

 GEs are by nature "replaceable" and, therefore:

  *   we should put the boundaries of GEs where we intend to make this replacement "feasible"
  *   we should keep withing the box of a GE those functions elements we believe may probably come closely coupled together in a given implementation.

  Given said this, I don't think it's a good idea that people infer that the implementation of the "device-level API" component is coupled with the implementation of the components named as "Thing-level API".   They should be both two separate GEs.

  About the name to give to those GEs, I definitively don't like and I rather believe it is wrong to name a GE as "<whatever> API" ... APIs are what GEs expose but a GE is not an API.   Some people believe this kind of issues are not rather important but I believe that the more rigorous we are, the more professional our work will look like.   While I do not have a good candidate name for the "device-level API" GE ("IoT device handler" ?) I believe that the "Thing-level" API should be renamed as "NGSI-M2M bridge" or "NGSI-IoT bridge" if we want to keep it more generic since its mission is actually to deal with the bridging between the "Pub/Sub Broker" GE and the "IoT device handler" GE (if we call it that way)

3.  Do we really need to give an entity to what has been called as "exposure GE" ?

  Based on 1 and 2, I would rather propose to drop the "exposure GE" as an GE embracing two GEs, the "NGSI-IoT bridge" GE and the "IoT device handler" GE.   It's true that we may use the notion of nested GEs, therefore defining a GE as the grouping of two related GEs ... but then ... why aren't we grouping the Things/Resources Configuration Management GE within the same group ? or grouping the "IoT device handler" and the "Publish/Subscribe Broker" GE together ?

  Note that the "IoT device handler" GE (named as "device-level API" in the current figure) plus the "Publish/Subscribe Broker" GE and the "Things/Resources Configuration Management" GE altogether implement the APIs that are exposed as northbound interfaces to the applications so, if we believe it is important to have a "exposure GE" grouping those GEs implementing exposed APIs, it should be embracing these three, and not the "NGSI-IoT bridge" GE (named as "Thing-level API" in the current figure)

  I would kindly ask you to implement these changes prior to publication.

  There are a couple of further comments regarding the interaction between the Request and Observation Handler components and the Publish/Subscribe Broker GE that I will forward on a separate email.

  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120229/1ba9f203/attachment.html>