I'm relatively new to the whole AJAX way of doing things so please excuse me if I'll mix two different things (although I'd appreciate it greatly if you could comment me on that).
My question is this:
I have many web clients (lets say around 1500) whom I want when starting up to "subscribe" to the web server with some sort of Id and then I want the web server (APACHE) to send them a relevant url (build dynamically doesn't really matter for this purpose) to display (sort of redirect).
Now my problem is basically that I've spent the last few days reading a lot of articles and howto's on how this should be done and I think I have too many buzz-words.
I think that in order to solve my problem I need some sort of implementation of COMET with something called "continuations" (to support that many clients). Is that correct?
Am I going down the right path?
Does GWT have any connection with this?
Thank you all very much in advance
EDIT: After reading some more I think that basically the Java Servlet 3.0 Asynchronous support is exactly what I need on the server side (correct me if I'm wrong) and I'm still debating on the client side? Maybe GWT after all?
Thanks
OK, so I indeed was making a bit of a mess earlier and I'm putting it out there so my nonsense doesn't confuse anyone.
What I was looking for was asynchronous request support both on the server side, regarding the thread handling to allow many users and scalability, and on the client side for ease of use of the Comet patter.
I've found that Jetty, Tomcat and Grizzly all offer a solution for this (just search the specific server with Comet and see what they offer) but I've decided to use the Servlets 3.0 spec as supported in Glassfish even though it will only be released with Java EE 6 as to not be tied down to a specific server.
On the client side I will probably go with GWT for many other reasons not related to Comet and because it has sufficient support for Comet.
Thanks
You may want to try StreamHub Push Server and the accompanying GWT Comet Adapter. This will give you a scalable Comet server and a GWT Client-side.
Related
I have been working on a mobile app that sends an ajax call to the server and waits for a response from the server in json format.
I am wondering from the server side, how to respond to an ajax call? Could someone give me an example in code?
I check the server code of my project (written by other members of the team) and could not understand it. I can only see it is written in java and also some keywords such as apache, springframework, etc pop up. I am a total newbie for server side programming and I want to learn more about it. Could someone give me some tips on how to get started with those as well? How does a server work? Is it just like responding to various request? What language could you use to build it and what is Apache? I know this looks like a lot of questions so probably I need to get some basic knowledge first. Any help/tips/suggestions on readings is appreciated.
This is kind of a broad question, as there are a lot of different server-side technologies that can handle server side AJAX requests, but if you want to go the Java route, using Spring Framework makes it very easy.
Spring Framework is a large open-source Enterprise Java framework that has a variety of features which entire books rarely even cover.
(Apache is an open-source project that contains over a hundred different sub-projects, the most popular being a web server.)
Spring does have some specific tools to handle REST calls. Assuming your AJAX is making a REST call (which is what it sounds like), and your project is already using Spring framework, it is fairly straightforward (assuming you already know Java). The Spring framework handles all the hard stuff for you. There are a few different ways to do this using Spring, but check out this link for creating a simple REST service:
https://spring.io/guides/gs/rest-service/
Another route would be to look into PHP, which is a server-side scripting language. With PHP, you can handle AJAX requests without the need for an application server (most basic web servers speak PHP). There are plenty of good resources for this, but one of my favorites is http://www.tutorialspoint.com/php/
BTW - the TutorialsPoint site is great for Java and Spring as well
My first post.
I have experience of basic java servlet and jsp and have got my webpage implemented in tomcat7.
Regarding Websocket, I am finding difficult to build understanding of how to implement it, i want to use tomcat8 implementation of websocket api and uplift my webpage (jsp, java, jquery, tomcat7) to use the websocket features, have not been able to find the the tutorial that can guide me through, something like hello world example. any pointers (sample codes, tutorials)?
have tried to understand tomcat8 examples but not understanding them at all
You need to understand that you don't just "add" WebSocket to an existing web application.. to make it faster, better, cheaper, more scalable, etc. Instead, you have to completely re-architect the web-layer of the application to take advantage of its capabilities.
I suggest that you first read a lot about WebSocket and what the whole idea is before you try to write any code, using Tomcat or any other WebSocket-capable server.
Nick Williams has a forthcoming book that appears to cover everything in the web application world, and as I understand it, will have a great deal of information about WebSocket-based code. You will unfortunately have to wait until March 2013 (at least) to use that particular book.
I'm sure there are similar books available, or even online tutorials to help get you started using WebSocket. Just be aware that switching to WebSocket isn't some simple configuration option: it's a very disruptive change to any existing web application.
Hi I am trying to compare the performance of zk and gwt.
In my comparision I cant write any javascript by myself if the framework itself converts some code into js its ok(like gwt) but I cant write js by myself
On writing code in the above way for almost anything done on browser a request is sent to the server in ZK.
Hence eventually if you compare the no of request sent by zk to server is too high as compared to gwt.
i would like to ask the following.
whose performance is better zk or gwt while ignoring the above.
if we dont ignore the above then is my conclusion that gwts performance is better than zk right ?
I know that there might be other parameters when comparing performance... but if the difference between requests are so high i cant really see zk beating gwt which some people have said on some forums
pls help
thanks
GWT and ZK are very different architecturally. GWT is client-centric so it sends less requests to the server. With GWT you can basically control everything by yourself. This on the otherhand means, the developer is responsible for handling server requests and asynchornouse data transfer between server and client. If you are an experienced web developer then the result could be great. If you are not then it could be pretty challenging and complex as there are some network and security issues you need to take care.
On the other hand, ZK is server-centric, it handles these server-client async communication for you. With ZK developers can focus more on the business logic without taking care of client-server issues. As the framework takes care of client-server talk, there are more requests by default. If you wish to minimize the request, you can probably follow their developer's guide to do some tuning.
IMO ZK and GWT are both matured framework. You can probably think about your project requirements and your experiences in Web development then choose the solution.
The previous posts are basiclly, but there are some features in zk that,I think, must be talked about.
Remember, every request is a zk-event, cos zk is completely event-based.
Client-Side Event-Handling
Zk allows you to implement client-side event-handling just as well as server-side,
which includes preventing zk from firing an event to the server.
You can simple manipulate the client objects in js as you can do it in Java on the
server-side or just do some post processing and and then...
Use Client-Side Event-Firing
Zk got that usefull js method zAu.send(zk.Event,int) that let's you send custom
or standart events to the server.
Deferrable Event-Listeners
Deferrable-events are queued at client-side, so you can minimize the number of
requests.
Stubonly
Stubonly is a way to make a component client-side only. But by now this is only
available for zk EE.
So, you can see, if you like, you can limit the requests to maybe the same amount of requests of GWT.
If it make sense or not depandce on you/your applycation. But I think you can say that zk is more powerfull than GWT.
You maybe interested in iZUML and defer rendering too.
ZK is server side focused, since GWT is all in the browser, so ZK needs much more ajax hits to the server to get js fragments, screen portions, etc. whereas GWT just hit the server at the beginning to download the js app (which will be cached in the client for ever) and whenever the app needs some data from the backend.
Said that, IMHO GWT should perform better since you dont need any sort of view logic being executed in the server (lighter servers), and there are less requests in the wire.
GWT and ZK are kind of different.
I've done some ZK projects and also some GWT projects. I didn't have performance issues in either cases,but I feel I need to write more code when I use GWT.
My experience from real world projects with two teams, one writing using the zk framework and the second using GWT. Identical UI projects having data served from the same data service layer. The zk team completed the project in one third of the time the GWT team consumed. Both projects deployed in production. Users were happy using either app. Finally we kept the zk version in production. Why? Simply because the maintenance of the zk app was so much faster and simple compared to GWT! Sorry GWT... Nice technology backed up by a giant but we will keep going with zk.
In our project our server must know as quickly as possible if a client gets disconnected.
Is there a effective way to implement this? Maybe with the GWTEventService or a powerfull framework?
You have a few options:
You can check out Comet. Comet was designed for this kind of behavior, where you intend to push data to the client without the client explicitly requesting it. Check out Wikipedia's article about Comet for more information. There's a GWT implementation of it here: gwt-comet.
Alternatives: You could use something like Spring Framework to keep tabs on your clients. You could also implement a heartbeat-style approach, where you force the client to hit a given page every X seconds so you know they're still connected.
Honestly, there are countless ways to do what you're looking for here. I'd say Comet would be your best bet if you don't mind implementing a whole framework.
Of course I am aware of Ajax, but the problem with Ajax is that the browser should poll the server frequently to find whether there is new data. This increases server load.
Is there any better method (even using Ajax) other than polling the server frequently?
Yes, what you're looking for is COMET http://en.wikipedia.org/wiki/Comet_(programming). Other good Google terms to search for are AJAX-push and reverse-ajax.
Yes, it's called Reverse Ajax or Comet. Comet is basically an umbrella term for different ways of opening long-lived HTTP requests in order to push data in real-time to a web browser. I'd recommend StreamHub Push Server, they have some cool demos and it's much easier to get started with than any of the other servers. Check out the Getting Started with Comet and StreamHub Tutorial for a quick intro. You can use the Community Edition which is available to download for free but is limited to 20 concurrent users. The commercial version is well worth it for the support alone plus you get SSL and Desktop .NET & Java client adapters. Help is available via the Google Group, there's a good bunch of tutorials on the net and there's a GWT Comet adapter too.
Nowadays you should use WebSockets.
This is 2011 standard that allows to initiate connections with HTTP and then upgrade them to two-directional client-server message-based communication.
You can easily initiate the connection from javascript:
var ws = new WebSocket("ws://your.domain.com/somePathIfYouNeed?args=any");
ws.onmessage = function (evt)
{
var message = evt.data;
//decode message (with JSON or something) and do the needed
};
The sever-side handling depend on your tenchnology stack.
Look into Comet (a spoof on the fact that Ajax is a cleaning agent and so is Comet) which is basically "reverse Ajax." Be aware that this requires a long-lived server connection for each user to receive notifications so be aware of the performance implications when writing your app.
http://en.wikipedia.org/wiki/Comet_(programming)
Comet is definitely what you want. Depending on your language/framework requirements, there are different server libraries available. For example, WebSync is an IIS-integrated comet server for ASP.NET/C#/IIS developers, and there are a bunch of other standalone servers as well if you need tighter integration with other languages.
I would strongly suggest to invest some time on Comet, but I dont know an actual implementation or library you could use.
For an sort of "callcenter control panel" of a web app that involved updating agent and call-queue status for a live Callcenter we developed an in-house solution that works, but is far away from a library you could use.
What we did was to implement a small service on the server that talks to the phone-system, waits for new events and maintains a photograph of the situation. This service provides a small webserver.
Our web-clients connects over HTTP to this webserver and ask for the last photo (coded in XML), displays it and then goes again, asking for the new photo. The webserver at this point can:
Return the new photo, if there is one
Block the client for some seconds (30 in our setup) waiting for some event to ocurr and change the photograph. If no event was generated at that point, it returns the same photo, only to allow the connection to stay alive and not timeout the client.
This way, when clients polls, it get a response in 0 to 30 seconds max. If a new event was already generated it gets it immediately), otherwise it blocks until new event is generated.
It's basically polling, but it somewhat smart polling to not overheat the webserver. If Comet is not your answer, I'm sure this could be implemented using the same idea but using more extensively AJAX or coding in JSON for better results. This was designed pre-AJAX era, so there are lots of room for improvement.
If someone can provide a actual lightweight implementation of this, great!
An interesting alternative to Comet is to use sockets in Flash.
Yet another, standard, way is SSE (Server-Sent Events, also known as EventSource, after the JavaScript object).
Comet was actually coined by Alex Russell from Dojo Toolkit ( http://www.dojotoolkit.org ). Here is a link to more infomration http://cometdproject.dojotoolkit.org/
There are other methods. Not sure if they are "better" in your situation. You could have a Java applet that connects to the server on page load and waits for stuff to be sent by the server. It would be a quite a bit slower on start-up, but would allow the browser to receive data from the server on an infrequent basis, without polling.
You can use a Flash/Flex application on the client with BlazeDS or LiveCycle on the server side. Data can be pushed to the client using an RTMP connection. Be aware that RTMP uses a non standard port. But you can easily fall back to polling if the port is blocked.
It's possible to achive what you're aiming at through the use of persistent http connections.
Check out the Comet article over at wikipedia, that's a good place to start.
You're not providing much info but if you're looking at building some kind of event-driven site (a'la digg spy) or something along the lines of that you'll probably be looking at implementing a hidden IFRAME that connects to a url where the connection never closes and then you'll push script-tags from the server to the client in order to perform the updates.
Might be worth checking out Meteor Server which is a web server designed for COMET. Nice demo and it also is used by twitterfall.
Once a connection is opened to the server it can be kept open and the server can Push content a long while ago I did with using multipart/x-mixed-replace but this didn't work in IE.
I think you can do clever stuff with polling that makes it work more like push by not sending content unchanged headers but leaving the connection open but I've never done this.
You could try out our Comet Component - though it's extremely experimental...!
please check this library https://github.com/SignalR/SignalR to know how to push data to clients dynamically as it becomes available
You can also look into Java Pushlets if you are using jsp pages.
Might want to look at ReverseHTTP also.