Consider, several users are using my Java Application.
I am using Http Common Apache to GET/POST from a Http Server to get various user data.
There is a module in this client Application which triggers current Page no. of the Document (user1 opened). I want other Users(User2, User3,....UserN) to know the Page no. User1 opened.
Should all users listen/query the HTTP server in a time interval always ? I think it is not a good idea.
How can I implement this so that Load on server is minimized.
Long Polling:
Clients open a connection with your server and the server sends response only when user1 has changed the page (Considering your example). This will work great if the number of clients for your applications are not huge.
User Query:
If dynamic update of page number on your application is not a hard requirement, querying the page number will be a good idea by providing a link would be a good option. This will improve the server performance.
You need to use Comet (long-polling) in your server application to avoid periodic polling. J2EE 6 will support it. Developing with Comet and Java describes how to make it in J2EE 5.
Some other server-side platforms are not well suited for Comet (for example PHP).
Related
This question might sound a bit abstract,answered (but did my search didn't stumble on a convenient answer) or not specific at all ,but I will try to provide as much information as I can.
I am building a mobile application which will gather and send sensory data to a remote server. The remote server will collect all these data in a mySQL database and make computations (not the mysql database ,another process/program) . What I wanna know is :
After some updates in the database , is it doable to send a response from a RESTful Server to a certain client (the one who like did the last update probably) ,using something like "a background thread"? Or this should be done via socket connection through server-client response?
Some remarks:
I am using javaEE, Spring MVC with hibernate and tomcat (cause I am familiar with the environment though in a more asynchronous manner).
I thought this would be a convenient way because the SQL schema is not much complicated and security and authentication issues are not needed (it's a prototype).
Also there is a front-end webpage that will have to visualize these data, so such a back-end system would look like a good option for getting the job done fast.
Lastly I saw this solution :
Is there a way to 'listen' for a database event and update a page in real time?
My issue is that besides the page I wanna update the client's side with messages from the RESTful server.
If all these above are unecessary and a more simple client-server application will prove better and less complex please be welcome to inform me.
Thank you in advance.
Generally you should upload your data to a resource on the server (e.g. POST /widgets and the server should immediately return with a 201 Created or (if creation is too slow and needs to happen later) 202 Accepted status. There are several approaches after that happens, each has their merits:
Polling - The server's response includes a location field which the client can then proceed to poll until a change happens (e.g. check for an update every second). This is the easiest approach and quite efficient if you use HTTP caching effectively and the average number of checks is relatively low.
Push notification - Server sends a push notification when the change happens, report's generated, etc. Obviously this requires you to store the client's details and their notification requirements. This is probably the cleanest approach and also easy to scale. In the case of Android (also iOS) you have free push notifications available via Google Cloud Messaging.
Set up a persistent connection between client and server, e.g. using a Websocket or low-level TCP connection. This should yield the fastest response times, but will probably be a drain on phone battery, harder to scale on the server, and more complex to code.
I want to develop a Java server that is able to send messages asynchronously to a client in form of a website with JavaScript. I know that one possibility is using WebSockets, but these are not supported in IE 9.
For transmitting messages from client to server I can use AJAX calls with maybe a RESTful Interface on the server side.
Does anyone have a solution for this?
This is not how webservers work, most of the time. HTTP Webservers are inherently a request-response architecture:
HTTP functions as a request-response protocol in the client-server computing model. A web browser, for example, may be the client and an application running on a computer hosting a web site may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client.
That said, there are technologies that you can use to do this. Read here about Comet and Reverse AJAX:
Is there some way to PUSH data from web server to browser?
You better implement your Java server to act as a Websocket server when it's supported by the end user. For the users who does not support Websocket it should fall back to long-polling.
This behaviour will avoid unnecessary overheads due to long-polling communications whenever possible.
The good thing is you don't have to implement all these behavious from the scratch. You can readily embed and use a reliable implementation available open source.
One such implementation is CometD project. The CometD project was available for more than a decade and it has evolved to solve most of the issues.
If you are looking for commercial products, there are many available. One such would be lightstreamer (http://www.lightstreamer.com).
You need to use a design pattern like long polling since WebSockets is not available. Rather than build it yourself you could use a library like SignalR. SignalR is an ASP.NET library but there is a client for Java (https://github.com/SignalR/java-client)
For anyone who comes across this question more recently, the modern answer (as of early 2021) supported across all browsers (except IE, which even Microsoft has given up on in favour of Chromium-powered Edge) are server-sent events. A most elegant and standardised solution to providing a pub/sub model to web clients.
Hello
I have a cache server (written with Java+Lucene Framework) which keeps large amount of data and provides them according to request query.
It basically works like this:
On the startup, it connects DB and stores all tables to the RAM.
It listens for requests and provides the proper data as array lists (about 1000 - 20000 rows)
When a user visits to the web page, it connects to the cache server, requests, and show the server response.
I planned to run web and cache applications in different instances because of memory issues. Cache Server is as service and web is on Tomcat.
What is your suggestion about how the communication should be built between web side and cache server ?
I need to pass large amount of data with array lists from one instance to another. Should I think web services (xml communication), nio socket communication (maybe Apache MINA) or the solutions like CORBA ?
Thanks.
It really depends very much on considerations you have not specified.
What are the clients? for example, if your clients are javascript running AJAX, obviously something over HTTP is more useful than a proprietary UDP solution.
What network is it working on? Local networks behave differently than internet, and mobile internet is quite different than both.
How elaborate use can you make of caching? If you use HTTP you can have a rather good control (through HTTP headers) of both client cache and network caches, and a plethora of existing software that can make use of both.
There are many other considerations to be taken into account, and there are many existing implementations of systems matching the more-common needs. From your (not very detailed) description you gave, I would recommend having a look at Redis.
I'm looking for some advice on the simplest way to create some product registration communication. I have a Java desktop application that needs to be re-newed every year. When a user downloads and install this app (through JNLP) they get a limited demo-version. There is code in place on the client to "register" the product and unlock all of the features.
My next step is to build the server-side components. There will be a database with customer ID numbers and other information about the customer. When the user clicks register, some contact information will be sent to the server as well as some product registration ID. The server will check this against the database and then either give the client the o.k. to unlock the features or the user will be informed that the registration id was not valid. This seems like a very standard thing. So what is the standard way to do it?
I have my own VPS and I'm running Tomcat, so I'm really free to implement this any way I choose. I was planning on building some web service, but I have never used REST before.
Use REST; REST is nothing more than using plain HTTP 'better'. Since you are already using HTTP, somehow you are already doing REST like calls and moving these calls to full fledged REST will be easy.
Implementing REST calls is easy. You have two approaches:
Low end: using URLConnection objects on the client, servlets on the server and following some REST conventions on using HTTP methods and 'clean' URLs (see here). Advantage is that you need no 3rd party library and minimize the footprint. Maintenance and evolutions are harder though.
High-end: a framework and specifications like JAX-RS. Using Restlet you can be up in running with a REST server in a couple of hours without having to deploy a servlet container.
Don't use SOAP. The only reason you would want to use SOAP is that you want to contractualise using a WSDL what you are exposing (you can do the same with REST btw, see the Amazon documentation for instance). Trust me, SOAP is way too heavy and confusing for what you are trying to do.
I need to create web application which must have two separate web browser windows to comfort usage. And events on each of them must cause action on another. The app will be on html5, perhaps with websockets on client side and Java with glassfish on server side. Is there any way to cross browser window communication or some another solution for this problem?
The best way to solve this problem is to store the information on the server side and have the web application communicate with the server (with JavaScript I expect).
You can have the web page "poll" the server every set period (eg 5 seconds) to see if there is an event or message to handle.
I used postMessage before - but not very heavily, worth a shot.
See post and demo at: http://robertnyman.com/2010/03/18/postmessage-in-html5-to-send-messages-between-windows-and-iframes/
Also see http://benalman.com/projects/jquery-postmessage-plugin/ for jQuery postMessage
Yes, I described a lot of ways here:
How is it possible to share single js resource between browser tabs?
If the browser support is not so important for you, then you can use shared webworkers. The next option to use storage event to exchange data, one implementation is intercom.js for that. The most supported way to use cookies BNC Connector does that.