In my blog Comet Servers for a Single-Dealer Platform (SDP) one of the questions I posed was whether a Comet server supports bidirectional messaging. The key feature of Comet has always been the ‘server push’ aspect – being able to send data from the server to the client without the client initiating the process. Client to server has always been possible, that is how the web has always worked.
Althought the focus for Comet is on server to client push, most Comet solutions provide an API to allow client to server push within the Comet environment – rather than forcing you to send client to server messages over HTTP directly.
The ‘Web’ way
The problem is many people are still stuck in the ‘web’ way of doing things and they only come to Comet when they need server push.
The problem with this is it leads to a circular architecture. Somewhere on the server side lives some application logic, sending messages and receiving messages, and probably doing something to them in between. Before the web, or if the web isn’t a requirement, people would use communication APIs that allow you to send and receive – from low level socket APIs to higher level messaging – but you send and receive using the same API.
With some web applications, messages are sent to an Application server using standard web technology, this is then passed on to another server process which may feed into the back (or side?) of the Comet server, which sends messages using Comet to clients. The circular architecture.
The Comet way
If you are using a Comet solution, make full use of it. A single API on the client, and a single API on the server.
What benefit do you actually get?
I think I have covered the benefits of using a single API, but there is more. Liberator, and some other Comet servers, provides a security API to control access to the system and granular access to specific data. When using the Comet server for data in both directions this aspect of controlling data access is contained in one place. With a circular architecture, subscribing to data needs to be controlled by the Comet server, but sending data needs to be controlled by the application server. It’s quite clear that this situation is not a good thing.
What about efficiency?
At the moment, most Comet solutions will be using new HTTP requests for each client to server message – so technically it isn’t much different to the circular architecture (as far as the network is concerned). What about the future? I have blogged about WebSocket before, but if/when WebSocket does become more widespread using Comet servers for bidirectional messages will be more efficient, since client to server messages do not have the overhead of HTTP requests.
So take a step into the future, it isn’t all about posting requests to application servers and all the constraints of the request/response stateless nature of the web. Comet gives you a much more natural way to communicate!