How to make an interoperable "push" based web service?

We've come across a problem where we have some data, lets say a stock price for example sake, and we want to provide a service that notifies clients when the price changes by a significant amount.

We need this service to be interoperable with as many clients as possible, across platform boundaries. Standards-based therefore seems a good way to go.

Asking clients to poll our service seems crazy, and a recipe for quickly overwhelming our server.

开发者_StackOverflow中文版Is there a standards-based way to do pub-sub or some event based way of notifying clients of interesting events?

There is WS-Eventing, by it feels like there isn't wide framework support for it.

Check out Comet, Ajax push, etc: http://en.wikipedia.org/wiki/Comet_(programming))

That's specific to JavaScript but can work well with any type of asynchronous client. The client "polls" the server. The server then holds on to the connection until there is data. The process then repeats itself. You do have to take into account client timeouts, however.

Without having the client implement its own service, this is about the closest you'll come to a push mechanism. I'm not sure if it's more costly to keep all these open connections or for the client to do true polling. In general I would say the longer the period between each poll, the better traditional polling will perform. Though if your servers can handle the extra connections, you'll have much less notification latency.

For the benefit of others, I'd like to put out there the idea of using XMPP to achieve this. XMPP (formerly Jabber) is an IETF standard which works somewhat like email to achieve push based instant messaging using an extensible XML based protocol. It also offer TLS for channel encryption and SASL for authentication. XMPP is also the basis of Google Talk. It is possible to run an XMPP server using open source software such as Jabber, and at a pinch its probably possible to use Google's Talk infrastructure to relay messages.

There are XMPP libraries to simplify client and server development.

We could reverse the typical roles of service host and client. We would supply clients with a WSDL contract, and they would need to host a Basic Profile Web Service conforming to that contract. There would be a simple web services method that we, in the role of client, but provider of the service, would invoke to notify the customer of an interesting event.