Hi Richard, A Message Broker is a general construct in pub-sub environments, acting as mediator for publishers and subscribers, matching interests and announcements, and enforcing access policies. I'd think of it as an essential part of the pub-sub middleware, not necessarily as a central server or a bottleneck.
I agree the document is rather general: bear in mind it is a first statement addressed to a WG like I2RS, with very broad goals and in its initial stages. My intention was precisely to provide it as an initial reference for the ALTO crowd to consider and discuss on use cases. The one you mention is the one I had in mind. More complicated ones could include hierarchical aggregation, composition of information from different servers, or data filtering driven by policies. I guess this could be applicable in inter-domain scenarios. Be goode and have an Extremely Goode New Year, On 31 Dec 2013, at 03:05 , Y. Richard Yang wrote: Hi Diego, Thanks a lot for posting the link. I read the document and it was a well-written document. If the document provides more text to review the two pub-sub models and how they may apply to I2RS, it will be more self-contained. A key proposal from the document, I see, is the introduction of a Message Broker. A main motivation appears to be scalability, i.e., to avoid the P * S problem, where P is the number of publishers and S the number of subscribers. One problem of the document is that it appears to be quite broad, where either applications or routers can publish and subscribe (not sure if routers will subscribe though), and many types (e.g., router/device status changes, app info changes? policy changes) are mentioned. This may imply that the schema of the pub-sub system can be quite complex or very generic. We know generic, well-used systems such as Google Chabby (Zookeeper), and hence I will wait to see the details of any specific proposals, on whether they will apply to ALTO. A concrete issue that I will look for is on how to encode updates of a large data set, e.g., a Network/Cost Map. As a simple, related use case of their scheme, an ALTO Server can be a publisher to push any incremental updates to the Media Broker, who can then handle a large number of subscribers. More complicated use cases or ALTO should develop its own sub-pub mechanism? Happy New Year! Richard On Fri, Dec 27, 2013 at 10:58 AM, Diego R. Lopez <di...@tid.es<mailto:di...@tid.es>> wrote: Hi, Some time ago we discussed about the pros and cons of using Websockets for implementing server-to-client notifications and I mentioned the possibility of using a pub-sub schema for creating a general notification framework. While reviewing some messages during my end-of-year tidying I came through this draft: http://tools.ietf.org/html/draft-camwinget-i2rs-pubsub-sec-00 contributed to I2RS, that discusses the application of the model in the access to a programmatic interface to the routing system. I think it provides a good overview of the model, and that many of the considerations are applicable to ALTO notifications, and even more to a generalized topology service. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: di...@tid.es<mailto:di...@tid.es> Tel: +34 913 129 041<tel:%2B34%20913%20129%20041> Mobile: +34 682 051 091<tel:%2B34%20682%20051%20091> ----------------------------------------- ________________________________ 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 _______________________________________________ alto mailing list alto@ietf.org<mailto:alto@ietf.org> https://www.ietf.org/mailman/listinfo/alto -- -- ===================================== | Y. Richard Yang <y...@cs.yale.edu<mailto:y...@cs.yale.edu>> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | ===================================== -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: di...@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ 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
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
