EDIT: I forgot to include the prime candidate for web applications: JSON over HTTP/REST + Comet. It combines the best features of the others (below)
- Persevere basically bundles everything I need in a server
- The focus for Java and such is definitely on Comet servers, but it can't be too hard to use/write a client.
I'm embarking on an application with a server holding data, and clients executing operations which would affect this data, and thus require some sort of notification across all interested/subscribed clients.
The first client will probably be written in WPF, but we'll probably need to add clients written in other languages, e.g. a Java (Swing?) client, and possibly, a web client.
The actual question(s): What protocol should I use to implement this? How easy would it be to integrate with JS, Java and .NET (precisely, C#) clients?
I could use several interfaces/protocols, but it'd be easier overall to use one that is interoperable. Given that interoperability is important, I have researched a few options:
- JSON-RPC
- lightweight
- supports notifications
- The only .NET lib I could find, Jayrock doesn't support notifications
- works well with JS
- also true of XML-based stuff (and possibly, even binary protocols) BUT this would probably be more efficient, thanks to native support
- Protobuf/Thrift
- IDL makes it easy to spit out model classes in each language
- doesn't seem to support notifications
- Thrift comes with RPC out of the box, but protobufs don't
- not sure about JS
- XML-RPC
- simple enough, but doesn't support notifications
- SOAP: I'm not even sure about this one; I haven't grokked this yet.
- seems rather complex
- Message Queues/PubSub approach: Not strictly a protocol, but might be fitting
- I hardly know anything about them, and got lost amongst the buzzwords`-- JMS? **MQ?
- Perhaps combined with some RPC mechanism above, although that might not be strictly necessary, and possibly, overkill.
Other options are, of course, welcome.