Logo
IT Dienstleistungen

Public/Subscribe

Public/Subscribe ist eine Weiterentwicklung der Messagequeues aus der Familie der Message-orientated Architektur

BÄÄÄÄÄÄÄÄÄÄÄÄM

jtom dürfte alles machen was wir brauchen…

Herausforderungen für Spot News

  • Wie ermittelt das Mobilgerät die Topics? Die Topics sind bei uns als Teile einer rasterisierten Oberfläche der Welt gedacht, von dem das Mobilgerät die entsprechenden Topics zu seiner Position anfordert. Dazu müsste diese Rasterung jedoch auf jedem Mobilgerät verfügbar sein, die Datenmenge ist derzeit nicht absehbar. Änderungen an der Rasterung ergeben Synchronisationsprobleme.
  • Eine Authentifizierung der Subscriber ist nur eingeschränkt möglich
  • Rückmeldungen zu entsprechenden Nachrichten sind womöglich über eine andere Verbindungsart oder gegenläufige Topics zu realisieren
  • Die Laufzeit der Nachrichten kann schlecht festgelegt werden, denn Topics können jederzeit ortsabhängige neue Subscriber erhalten.

Vorteile

  • Loosely-coupled: Publishers are loosely coupled to subscribers, and needn't even know of their existence. With the topic being the focus, publishers and subscribers are allowed to remain ignorant of system topology. Each can continue to operate normally regardless of the other. In the traditional tightly-coupled client-server paradigm, the client cannot post messages to the server while the server process is not running, nor can the server receive messages unless the client is running. Many pub/sub systems decouple not only the locations of the publishers and subscribers, but also decouple them temporally. A common strategy with such pub/sub systems is to take down a publisher to allow the subscriber to work through the backlog (a form of bandwidth throttling).
  • Scalable: For relatively small installations, pub/sub provides the opportunity for better scalability than traditional client-server, through parallel operation, message caching, tree-based or network-based routing, etc. However, as systems scale up to become datacenters with thousands of servers sharing the pub/sub infrastructure, this benefit is often lost; in fact, scalability for pub/sub products under high load in large deployments is very much a research challenge.

Nachteile

The most serious problems with pub/sub systems are a side-effect of their main advantage: the decoupling of publisher from subscriber. The problem is that it can be hard to specify stronger properties that the application might need on an end-to-end basis:

  • As a first example, many pub/sub systems will try to deliver messages for a little while, but then give up. If an application actually needs a stronger guarantee (such as: messages will always be delivered or, if delivery cannot be confirmed, the publisher will be informed), the pub/sub system probably won't have a way to provide that property.
  • Another example arises when a publisher „assumes“ that a subscriber is listening. Suppose that we use a pub/sub system to log problems in a factory: any application that senses an error publishes an appropriate message, and the messages are displayed on a console by the logger daemon, which subscribes to the errors „topic“. If the logger happens to crash, publishers won't have any way to see this, and all the error messages will vanish.
  • As noted above, while pub/sub scales very well with small installations, a major difficulty is that the technology often scales poorly in larger ones. These manifest themselves as instabilities in throughput (load surges followed by long silence periods), slowdowns as more and more applications use the system (even if they are communicating on disjoint topics), and so-called IP broadcast storms, which can shut down a local area network by saturating it with overhead messages that choke out all normal traffic, even traffic unrelated to pub/sub.

For pub/sub systems that use brokers (servers), the agreement for a broker to send messages to a subscriber is in-band, and can be subject to security problems. Brokers might be fooled into sending notifications to the wrong client, amplifying denial of service requests against the client. Brokers themselves could be overloaded as they allocate resources to track created subscriptions.

Even with systems that do not rely on brokers, a subscriber might be able to receive data that it is not authorized to receive. An unauthorized publisher may be able to introduce incorrect or damaging messages into the pub/sub system. This is especially true with systems that broadcast or multicast their messages. Encryption (e.g. SSL/TLS) can be the only strong defense against unauthorized access.

Berwertungskriterien

  • Quellcode verfügbar
  • Skalierbarkeit
  • Rückantworten
  • Sicherheit
  • Nachrichtenlaufzeit
  • Loadbalancing

Lösungen

Pub/Sub Middleware

Seiten-Werkzeuge