Dear Juanjo, dear all, In order to reach a conclusion in our discussion about the role of the Thing-Level interface, we propose a slightly modified architecture picture, see appendix. The changes are - The component responsible for translating NGSI requests into resource requests and performing those requests on behalf of the application is now called "request handler". It resides in the "Thing-Level API". - The Observation Handler now resides in the Thing-Level API as well. This is because its functionality is complementary to the request handler and therefore should reside in the same GE. Another reason for moving the Observation Handler is that it deals both with data and with resources and therefore does fit into task 5.4 better than into 5.2. - The Publish/Subscribe Broker now resides on top of the whole backend. Its single point of contact to the IoT Backend is the Observation Handler, which publishes events into it. We hope that we can come to a final agreement in tomorrow's phone conference. Best regards Martin and Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120214/5f29bac5/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: IoT-Complete_tj_2011-02-14.graphml Type: application/octet-stream Size: 232023 bytes Desc: IoT-Complete_tj_2011-02-14.graphml URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120214/5f29bac5/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: IoT-Complete_tj_2011-02-14.pdf Type: application/pdf Size: 1230069 bytes Desc: IoT-Complete_tj_2011-02-14.pdf URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120214/5f29bac5/attachment.pdf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy