I am working on a project where a website needs to exchange complex and confidential (and thus encrypted) data with other systems. The data includes personal information, technical drawings, public documents etc.

We would prefer to avoid the Request-Reply pattern to the dependent systems (and there are a LOT of them), as that would create an awful lot of empty traffic.

On the other hand, I am not sure that a pure Publisher/Subscriber pattern would be appropriate -- mainly because of the complex and bulky nature of the data to be exchanged.

For that reason we have discussed the possibility of a "publish/subscribe/request" solution. The Publish/Subscribe part would be to publish a message to the dependent systems, that something is ready for pickup. The actual content is then picked up by old-school Request-Reply action.

How does this sound to you?

  • What does "publish/subscribe/request" solution save compare to a standard "Request-Reply" pattern? Does the direction of information flow matter? – Dime Apr 2 '12 at 11:39
  • @Dime, It should eliminate all the empty polls. The subscriber is notified when there is something to pick up. – Morten Apr 2 '12 at 11:55
  • Sorry, I still do not get the problem. System1 sends request to System2 only when it has something to send. System2 also sends request to System1 when it has something for it... Why one system has to poll another all the time? – Dime Apr 3 '12 at 9:52
  • @Dime, The situation is that System1 has something for System2. With request-reply, System2 will request news at certain intervals from System1, whether there are any or not, thus the potential for empty polls. With the other pattern System1 will tell System2 -- by pushing a message -- when there is something new to request. This way System2 will only request news from System1, when it has been told, that news are available. – Morten Apr 3 '12 at 10:37
  • Would it make sense to have the website publish a feed that the other systems could read or poll periodically, or when needed - and then only retrieve the files/data in the standard request/reply at that point? It seems like publishing the events may be more scalable, and could easily be re-purposed for different types of data and systems. Or am I misunderstanding the question? – katemats Apr 4 '12 at 3:57

Consider PubSubHubbub

PubSubHubbub works by first offering a general AtomPub feed with links to various hubs. Subscribers register with the hubs using a direct socket feed (typically reverse Ajax using Comet). This allows the hubs to push data out to subscribers on demand without consuming too many resources. Publishers send data to the hubs for dissemination. Hubs can be clustered.

In your situation, you could do the following (subject to your own data protection policies):

  1. A new subscriber is provided with a secret symmetric key along with their login credentials
  2. The subscriber registers with a hub to receive data
  3. The publisher creates the data specific to a subscriber and sends it to the hub encrypted along with their symmetric key
  4. The hub handles the process of sending the data to the subscriber

In the Java world, a combination of Jetty (version 7+), OData4J and Atmosphere would probably achieve most of what you need.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.