I am planing to develop a messaging module where with in the organization (also across the firewall), employees will be able to send messages to each other. These messages will be stored in the DB and the user will be notified with the message that 'new message is arrived'.
To achive this server will need to make the callback to the client.
I was planning to use the JMS which will asynchronously log the messages in the DB and will notify the respective user(s).
Problem I am facing is with notifying the client which can be a browser instance across the firewall on web.
Following are few alternatives which I looked into:
1.Applets: I have read that applet does not help across the firewalls.
2.Polling: This will cause unneccasry network traffic.
3. Holding the client connection: This can become scalability issue.
Is there any clean way to achieve this.
Any help will be apreciated
Thanks in advance
My suggestion is to forget about making a call to a browser from your server. :-)
What you could do instead is to set some kind of flag on the user's session (either on HttpSession or an SFSB) indicating that there are new messages. This will be set by your MDB. Whenever a new page is being rendered, check for this flag & based on whether it is set or not, show a link saying "New Messages Found". The user can then click on this link and be presented with all the new messages.
About the options you had mentioned:
> 1.Applets: I have read that applet does not help across the firewalls.
If the applet is "pulling" information from the server, you should not have any issue - just keep all traffic as http(s). But this is essentially the same as #2 - polling.
> 2.Polling: This will cause unneccasry network traffic.
Yes. This should be avoided. Depending on how many users are logged in, it would affect performance.
> 3. Holding the client connection: This can become scalability issue.
Yes. Avoid this as well.