Dear All, Under the following link http://www.openmobilealliance.org/Technical/release_program/NGSI_v1_0.aspx you may find and download publicly available documents regarding the Next Generation Service Interface Enabler defined within OMA. Context management is represented there by NGSI-9/10 specifications. Among the documents you might be interested in the following documents: - OMA-RD-NGSI-V1_0-20100803-C.pdf<http://www.openmobilealliance.org/Technical/release_program/docs/CopyrightClick.aspx?pck=NGSI&file=V1_0-20101207-C/OMA-RD-NGSI-V1_0-20100803-C.pdf> - requirements considered for this Enabler; - OMA-AD-NGSI-V1_0-20100803-C.pdf<http://www.openmobilealliance.org/Technical/release_program/docs/CopyrightClick.aspx?pck=NGSI&file=V1_0-20101207-C/OMA-AD-NGSI-V1_0-20100803-C.pdf> - reference architecture of the Enabler; - OMA-TS-NGSI_Context_Management-V1_0-20100803-C.pdf<http://www.openmobilealliance.org/Technical/release_program/docs/CopyrightClick.aspx?pck=NGSI&file=V1_0-20101207-C/OMA-TS-NGSI_Context_Management-V1_0-20100803-C.pdf> - context management interface description (NGSI-9 and NGSI-10). Moreover I recommend to take a look at the presentation http://www.ict-ccast.eu/workshops/2nd/13%20-%20OMA%20-%20Kovacs%20-%20OMA_ServiceAPI_Standardisation.pdf, which describes the Enabler at high-level. I preferred to give you the links to external documents on their respective web-sites instead of putting into our FI-WARE server or even worse sending via email. However if we need I may upload them to the server. Best Regards, Boris From: fiware-data-bounces at lists.fi-ware.eu [mailto:fiware-data-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro Sent: Sunday, June 05, 2011 9:37 AM To: fiware-data at lists.fi-ware.eu Subject: [Fiware-data] Notes and thoughts on Publish/Subscribe GE and Query Access GE Dear colleagues, I have uploaded on the following link: http://forge.fi-ware.eu/docman/view.php/9/108/Notes+and+Thoughts+on+Pub-Sub+Broker+and+Query+Access+GEs.doc a short document with notes and derived thoughts from our previous calls on the Publish/Subscribe GE and Query Access GE. I hope you all can endorse them so that we can make progress. I plan to use this document as basis for a post in our blog. It might be a reference of the kind of posts we may publish on progress of our activities in our blog (serving as an example for other WPs). Don't hesitate to make any comment. For your convenience, I have also attached its contents in plain text below. This may be helpful in any discussion. Best regards, -- Juanjo ======= 1. Motivation This document intends to summarize some notes and thoughts that may help to progress on the discussion about features that the Notification (Publish/Subscribe) Broker and the Query Access GE should support. They should be taken into consideration when writing the sections describing both GEs in the FI-WARE High-level Description document. Contents of this document will be considered as baseline for a post to publish in our Data/Context Management blog in www.fi-ware.eu<http://www.fi-ware.eu> (http://data.fi-ware.eu) 2. About the Notification (Publish/Subscribe) Broker Enabler There are essentially two products on the table regarding this GE that may be considered as baseline for our work: * One from Telecom Italia, see [1] * Another one from Orange, see, see [2] and [3] The very basic concepts and operations in both proposals are similar, so probably it's not difficult to reach a consensus on entities/interfaces and operations. Actually, we may define the Notification (Publish/Subscribe) GE based on the following interfaces and operations (additional operations may be added): * The Notification Consumer interface, which would map to the Context Consumer interface in both the Telecom Italia's and Orange's proposal. This interface would support the notify operation (which may take the form of a post operation if the interface is implemented as a RESTful interface). It may also support a subscription_ended operation. * The Notification Broker interface, which would map to the Context Broker interface in Telecom Italia's proposal or to the Context Source interface in Orange's proposal. This interface would support the subscribe/unsubscribe operations. Querying of new data following a pull style of communication would be supported through a get operation exported by the Query Access GE as explained in section 4 of this report. * The Notification Broker Finder, which would map to the Context Broker interface in Orange's proposal. Note that this interface doesn't exist in Telecom Italia's proposal but this doesn't imply any conflict. This interface would support the discoverNB operation enabling to locate a Notification Broker Finder based on criteria (see discussion below). * The Notification Supplier interface, which would map to the Context Provider in Telecom Italia's proposal. This interface doesn't exist in Orange's proposal because sources of notifications directly export operations enabling multiple Consumers to subscribe. In other words, both the role of Notification Supplier and Notification Consumer are played by entities exporting the Context Source interface in Orange's proposal. This interface would support a get operation in order to support retrieval of new data complying with a given query, thus supporting a pull style of communication. This operation should follow the same signature as the get operation supported by the Query Access GE. A first conclusion and action point would be that we can describe the Notification (Publish/Subscribe) GE elaborating on this common set of entities/interfaces (i.e., product vision) and the operations they support. We would include a disclaimer at the beginning of the section explaining that the final set and signature of operations may change during final specification of the GE but it will be along the lines of what is described here. Given said the above, a fundamental difference of the two proposals has to do with the format of data being handled and notified (Telecom Italia supports a XML-based ContextML language while Orange supports RDFs). There are at least two aspects that strongly depend on the selected format for obvious reasons: * The kind of repository where data is stored (no matter whether it is located in a memory cache or in disk, the notion of repository is there) * The query language used to define subscriptions 3. Is a Universal Query language feasible? The conclusion of the team is that probably not. Even if it were feasible, it would imply to define "yet another query language" which certainly would impose severe barriers of adoption by the developers community. Something that would be feasible is to support multiple query languages and ask the programmer to declare what particular query language he/she wishes to use. This will determine the format/structure used to store data in the repository and the repository itself. Thus, a programmer may declare he/she wishes to use SPARQL while another may declare he/she wishes to use MPQF, CQL, Mongo DB's document-based query language or any other Query Language as long it is supported by the platform. Selection of the query language is a first step we may require the programmer to perform prior getting access to a particular Notification Broker, as illustrated in Figure 1. The complete list of steps to be followed by a Notification Consumer for subscribing to messages that comply with a given Query Language may be the following: 1. The Notification Consumer (NC) sends a request to the Notification Broker Finder (NBF) looking for a Notification Broker (NB) that supports a given Query Language specified as parameter in the request. 2. The NBF returns a reference to a NB supporting the specified Query Language 3. The NC subscribes to reception of data complying with a particular query by issuing a request to the NB. Note that in this model, the Notification Broker Finder plays a similar role to the Context Broker in Orange's Publish/Subscribe service. [cid:image001.gif at 01CC23D7.E4557B90] Figure 1. Steps in connecting to a Publish/Subscribe Broker 4. Relationship between the Publish/Subscribe Broker GE and the Query Access GE The Context Broker component proposed by Telecom Italia, similarly to the Context Source component proposed by Orange, exported operations that would allow Consumers to query for context data. On the other hand, we have identified the need for a Query Access GE that allows to access to data stored in the FI-WARE Data/Context Management Platform. How should both means for quering data be related? After some discussion, we came to the conclusion that the Notification Broker interface to be defined in the Publish/Subscribe Broker GE should just export an operation that would return the access point to the interface offered by the Query Access GE. This interface should offer a get operation that enables to retrieve data that complies with a given query statement and has been stored in the platform after the last call to the same operation made by the same entity. This way, we would avoid duplicated interfaces. Note that a particular product may be providing the implementation of components implementing the Notification Broker interface and the Query Access interface for a particular query language (i.e., format for representing/storing data). This is illustrated in Figure 2. [cid:image002.gif at 01CC23D7.E4557B90] Figure 2. Two products implementing the Publish/Subscribe Broker and Query Access interface for two different query languages 5. Abstract Query Language Families Two given query languages may have some common constructions/components and this may allow that a given query, formulated based on common constructions, can be executed by the corresponding Query Engines. Therefore, we may consider supporting the concept of "abstract query languages" in FI-WARE, each defined based on minimum common denominators of existing query languages. A question mark is what to do when abstract query languages are declared at the connection to the Publish/Subscribe Broker or the Query Access GEs. How are then queries executed? It seems like the solution may consist in performing a parallel execution of the query in compatible repositories (the query may be transferred to the query engines linked to each repository and then results gathered together in the response sent back to the application). However, there are still some open questions like, for example, what would be the actual format in which data results would be returned to the applications. We need to find out a solution or position on the matter. 6. Availability of data in different repositories Finally, there is still a big question mark regarding the following issue: what to do when some particular data is of interest to many applications but the query language each application uses to access data is different. Let's illustrate this scenario with an example. One data that may be of interest to several applications may be the ambient temperature measured in a given street. However, while a given application may wish to use Query Language "A" to subscribe for receiving such data through the Publish/Subscribe Broker GE, another application may wish to use Query Language "B". This would typically imply that the underlying engine is linked to a different Repository based on a different storage format. Then ... are both applications going to receive the data? Is the data going to be replicated in both repositories We need to find out a solution or position on the matter. 7. References [1] - http://forge.fi-ware.eu/docman/view.php/9/99/FI-WARE_ContextQuery-CQL_v3.pdf [2] - http://forge.fi-ware.eu/frs/download.php/3/2011-05-31OLPubSubPrez.pdf [3] - http://forge.fi-ware.eu/frs/download.php/4/WISHWellIE11midasFinal.pdf ________________________________ 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non è necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110605/7370edf7/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 9036 bytes Desc: image001.gif URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110605/7370edf7/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 24189 bytes Desc: image002.gif URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110605/7370edf7/attachment-0001.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110605/7370edf7/attachment.jpg>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy