Search code examples
javaweb-servicesclient-serverapache-axisrmi

Broadcasting message to clients

Design

A Server Agent keeps on polling DB (SQL Server 2012) to find if there is any change in schedule and/or configuration required for Client agent. Client agent runs on all machines on network and needs to get updated scan schedule and configuration from server agent and update its job scheduler. Both server Agent and Client agent are built in Java.

Problem Statement

Server to send data to n number of client agents once DB is updated.

Solution1

Create webservices on server and client agents and consume each other. Whenever there is change in scan schedule/configuration in DB, server will call client agent's method and update the configuration files.

Disadvantage Solution1

In runnable JAR, deploy Axis2/Jetty/Similar webserrver on all client agents. Considering this is deployment of webservers on all client agents where the number can go upto 150000, is it advisable? Also if there are webservers on all client machines, can the application clear security certification?

Solution2

Use RMI to communicate between server and client. In this scenario, client will keep polling server as RMI communication is one-directional. Use of bi-directional calls should be avoided as it again involves have server sockets on each client machine.

Disadvantage Solution2

Whenever DB is updated, it cant directly send message to all client machines. It has to wait for client machine to poll it. In case when immediate scan is required, all client agents will need to poll master agent frequently. is this advisable considering the number of client agent can be huge? Another disadvantage informed by Java architect is that RMI is slower than webservice. is that correct?

I have to go either of these 2 solutions OR if there is any third solution which you guys can give me. One person also suggested JMS as broadcasting way.

Solution

  • Your solution 1 has another problem - everyone knows the server, but server would not know all the clients. Ofcourse you can do a client registration workflow on server, but it makes the server heavy to publish the messages

    I am not even considering solution 2 here. RMI to me is as good as dead, we have much better architectures in place right now.

    1. Bring up a messaging queue in a subscription model. Whenever there is an update push messages to the Queue Manager and let the queue manager worry about broadcasting to all the available clients. You can use any reliable queues here such as RabbitMQ, MQTT etc.

    Main advantage is messaging reliability. There are options to ensure that every subscriber gets the message, which is good. You can do a push/pull later if you want. You can also cluster the messaging queues which will create a load balanced solution if the number of clients go higher, at a later point of time.

    1. You can also use a websocket, if speed of transmission is required. But this is not as good as option 1, because of its resource usage. But if you are not worried about it, websockets are a super cool way of full duplex communications.