Reputation: 2796
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.
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:
Thank you for your time!
Upvotes: 0
Views: 290
Reputation: 18637
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.
Upvotes: 1