Publish/Subscribe

I want to go back to the middleware diagram.

There's an agreement implied between the application and the middleware in the messages exchanged between them. The application has to describe enough information in its proper format so that the middleware, the location service and the routing protocol, can do their job. Being that the diagram doesn't lay any requirements for that out, you might deduce that my proposal will be equally ambiguous. In reality, this is part of what I intend to examine in my work.

To start, though, we've noticed that the interaction of the patients and their healthcare professionals fit nicely with what is known as a Publish/Subscribe Architecture.

The idea of Pub/Sub is that some entity produces a stream of data packets (publishes) to some publication, and other entities subscribe to that publication. The architecture then moves all the data packets from the publisher to the subscribers. It's easiest to think of this in terms of a blog (like this one), where each new blog entry is ultimately sent to the RSS readers of those people subscribed to the blog's RSS feed. The only thing that publishers and subscribers need to communicate is the name of the publication.

A more complicated implementation is called Content-based Publish/Subscribe. Here the publishers, instead of attaching just a name to each message, attach a series of values, like patientID = 1234, signal = ECG, situation = 'heart attack', etc. An interested party can then subscribe by declaring a filter that says something like, "send me all messages where the 'situation' is 'heart attack'."

You might imagine that Content-based Pub/Sub is harder to implement. It might, however, make the entire system easier to operate.

Thus, one of the questions I have to (want to) answer in my work is:

Which Pub/Sub Architecture better serves the application/system?