How would I create an asynchronous notification sy

Question

I have a Java application which I make available via RESTful web services. I want to create a mechanism so clients can register for notifications of events. The rub is that there is no guarantee that the client programs will be Java programs and hence I won't be able to use JMS for this (i.e. if every client was a Java app then we could allow the clients to subscribe to a JMS topic and listen there for notification messages).

The use case is roughly as follows:

1. A client registers itself with my server application, via a RESTful web service call, indicating that it is interested in getting a notification message anytime a specific object is updated.
2. When the object of interest is updated then my server application needs to put out a notification to all clients who are interested in being notified of this event.

As I mentioned above I know how I would do this if all clients were Java apps -- set up a topic that clients can listen to for notification messages. However I can't use that approach since it's likely that many clients will not be able to listen to a JMS topic for notification messages.

Can anyone here enlighten me as to how this problem is typically solved? What mechanism can I provide using a RESTful API?

Answer 1

If polling is not acceptable I would consider using web-sockets (e.g. see here). Though to be honest I like the idea suggested by user189423 of multipart content-type or chunked transfer-encoding as well.

Answer 2

In the response to the RESTful request, you could supply an individualized RESTful URL that the client can monitor for updates.

That is, you have one URL (/Signup.htm, say), that accepts the client's information (id if appropriate, id of object to monitor) and returns a customized url (/Monitor/XYZPDQ), where XYZPDQ is a UUID created for that particular client. The client can poll that customized URL at some interval, and it will receive a notification if the update occurs.

If you don't care about who the client is (and don't want to create so many UUIDs) you could just have separate RESTful URLs for each object that might want to be monitored, and the "signup" URL would just return the correct one.

As John Saunders says, you can't really do a more straightforward publish/subscribe via HTTP.

Answer 3

We have this problem and need low-latency asynchronous updates to relatively few listeners. Our two alternative solutions have been:

1. Polling: Hammer the list of resources you need with GET requests
2. Streaming event updates: Provide a monitor resource. The server keeps the connection open. As events occur, the server transmits a stream of event descriptions using multipart content-type or chunked transfer-encoding.

Answer 4

I can think of four approaches:

1. A Twitter approach: You register the Client and then it calls back periodically with a GET to retrieve any notifications.

2. The Client describes how it wants to receive the notification when it makes the registration request. That way you could allow JMS for those that can handle it and fall back to email or similar for those that can't.

3. Take a URL during the registration request and POST back to each Client individually when you have a notification. Hardly Pub/Sub but the effect would be similar. Of course you'd be assuming that the Client was listening for these notifications and had implemented their Client according to your specs.

4. Buy IBM WebSphere MQ (MQSeries). Best IBM product ever. Not REST but it's great at multi-platform integration like this.