Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Publishing based on the properties of a subscriber

IP.com Disclosure Number: IPCOM000202705D
Publication Date: 2010-Dec-23
Document File: 2 page(s) / 49K

Publishing Venue

The IP.com Prior Art Database

Abstract

Traditional pub/sub systems rely on the subscriber knowing the topics that publishers will be using to broadcast information. In certain cases, the publishers know which subscribers need to receive information but the subscribers are unware which topics provide relevant data. In such cases, modifications to the pub/sub engine architecture which allow the publisher to specify the type of subscribers can facilitate much simpler and more efficient flow of information.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 01 of 2

Publishing based on the properties of a subscriber

One example where traditional publish/subscriber (pub/sub) systems are not ideally suited is the rise of push notifications systems

(http://en.wikipedia.org/wiki/Push

_

    Often the publisher will know what type of subscribers (e.g. phones in a certain location or phones with a firmware < 3.0.123) they want to push messages to (e.g. a firmware update) but the subscriber has not necessarily subscribed to the correct topic so a pub/sub network is not a perfect match for the use-case.

    At the moment, subscribers in various messaging engines have ways of filtering messages they receive on a topic (e.g. selection strings) but it is based on the subscriber knowing what information is out there and what they want to receive. Some form of "pushed" information fit very badly into this model. For example, location based broadcasts (e.g. service outages or adverts): should the subscriber subscribe to a topic string based on the street, town, city, county, state or country?

    Messaging engines already store a lot of information about subscribers (for instance, for a subscriber, most servers will store at /least/ the version of the protocol they are speaking, the ip address they are on, the topics they are subscribed to and the "client id" that uniquely identifies the client).

    This information would be stored in a queryable datastore/database. In addition the protocol would be extended so that the client could provide extra information in the form of key/value pairs (e.g. hardware and software types and versions, current gps latitude and longitude and the home postcode of the owner of the device). Connections could be policed by the server so that some pieces of information are mandatory. The server would add some (or all) of these key/value pairs for the client to the queryable datastore.

    Instead of publish to a topic, the publisher would provide (in addition to the message and meta-data) a query fragment (e.g. in an SQL-like syntax). For example, the publisher might want to publish to
firmware > 3.3 and STATE

_FROM

    The messaging engine then queries the datastore and sends a copy of the message to each matching subscriber. For this kind of use-case this is much more flexible than a topic based model of pub/sub where (for the example query listed above) the publisher and subscriber would have had to agree a very complex topic string in advance.

The steps in the basic system are:
1) On registration to the messaging engine some information is stored in a queryable datastore about the application registering (for some classes of application, the messaging engine may well make some types of information mandatory for a successful registration)
2) Publishers supply selection criteria instead of (or in addition to - see extension B) a topic string for a publication.
3) Subscribers whose metadata (according to the datastore) matches the supplied selection criteria are sent a copy of the message.
4) (Optional) S...