Search code examples
architectureserverexternalcometd

CometD: publish from external server


I am trying to understand the use cases / architecture of typical users of CometD to see if I am on the right track. Here is a diagram describing our intended use.

CometD with web services

We would like to have the CometD server be more of an event pub/sub for our web services, NO CONTENT will pass through CometD, only event data. The web services can publish events to the clients based on an action they process or it can happen from a long running process / scheduled process.

My questions are based on the Java client:

  • Is this an appropriate use of CometD Java client? From the documentation it seems like the Java client is used for short term life applications like desktop apps.
  • Given the Java client for CometD, should we have a single instance or a pool of clients to handle sending events to CometD from a web service instance?
  • The client code seems elaborate enough to handle batching messages and multiple threads calling it and it seems like establishing a client is expensive to just do it on the fly when needed to publish one message, is that correct?

Thank you for your time!


Solution

  • Yes, this is an appropriate use of the CometD Java client.

    You can have a single instance of the CometD Java client, it is safe for multi-threaded usage, or you can have one CometD Java client for each Web Service, probably the recommended approach (as you can identify in the CometD server which Web Service sent what).

    Note that the CometD Java client is asynchronous.

    If you need a reply or a confirmation that the message you sent was processed by the CometD server, you need to be able to suspend the Web Service request (via HttpServletRequest.startAsync() or similar), invoke the CometD Java client, and when you get back the message confirmation arrange to complete the Web Service response to the client.

    You can get confirmations using callbacks in the CometD Java client APIs, see the CometD Java client API documentation.

    For completeness, if you use a broadcast channel to publish a message from the Web Service, the message will be immediately re-broadcast to the remote clients by the CometD server.

    On the other hand, if you use a service channel to publish a message from the Web Service, you will be able to process the message on the CometD server (and perhaps enrich it or drop it following some business logic) before having the opportunity to re-broadcast it or send it to a specific client.