What are worth to look at libraries for reverse ajax in Java web app?
Atmopshere is still in 0.6 version, ICEpush still in alpha version, and websockets in Firefox 4.0 wont be available too.
Try out Comet with Tomcat. Also, Tomcat 7 might be useful to you since it implements the Servlet 3.0 spec, which I believe has some niceties for Reverse Ajax thanks to the Async support. Here is an example.
Try DWR
You can also use APE(Ajax Push Engine). Here is the link APE
The good thing about atmosphere is that it delegates to the best underlying mechanism available, and these mechanisms are mostly stable (each container provides its own ways). I think it's more or less a standard solution, so don't be bothered by the version. (Note: I haven't used it)
The blog post Introduction to Comet and Reverse AJAX by Krishna Srinivasan says:
AJAX push with ICEfaces
It is an open source AJAX based framework for developing Rich Internet Applications using Java. AJAX push is an exciting feature of ICEfaces which enable us to develop Comet web application with simple Java API without worrying about the low-level details of the push-mechanism. ICEfaces uses “long polling” to communicate from server to client. This involves holding an open connection from client to server with a blocking request, and then sends the response only when some state change in the application.
Related
I would like to get some input on some ways to handle long computational tasks within a java web framework and how to callback to a browser client.
I have come accross JBoss remoting, and Spring remoting.
Want to be able to have the client send a request for processing. Processing can take X time, and once complete responds to the client.
Any pros and cons and suggestions welcome.
Thanks.
There are several ways this might be accomplished:
Utilize Servlet 3.0 with an AsyncTask.
Incorporate a Comet implementation with either long-polling by your UI, or server push.
Build your UI with HTML5, and utilize WebSockets (least portable solution).
Both JBoss and Spring Remoting might also be viable solutions, but they really were built for different purposes.
Executing a long computational task and server push for web applications are two separate things, really.
As mentioned, web applications using comet will allow the server push (which is a term for when a Web Server can push updates to a browser without the browser initiating a request). There are frameworks which build on top of this. ICEfaces, Primefaces and ZK are three web application frameworks which support this. Flex has its own support for pushing data from the service layer as well.
The async executions could be anything as simple as a thread spawned off that runs and has enough information to start the server push process back to the client. You could also use message-based solutions to handle the async execution of the long process.
There are a lot of options out there, and it really comes down to what tools/frameworks you're currently using and find a good fit.
You could use GWT, it handles asynchronous calls quite well. I have huge data loads done in the background of a lot of my applications. All while the user can interact with various views etc.... It's quite seamlessly integrated into GWT, with their home-cooked rpc mechanism. Also, you can use JBoss Errai to do pushing if you need that as well, (within gwt of course). It's worth a look.
I have to use Icefaces for some legacy projects and it is so difficult to do this same thing. GWT just makes it easy. Icefaces you need to use JS unless you bind your async calls to a component such as a button and make sure the requests are not queued. It's messy.
Just my two cents I guess.
In my web-app, i need to push specific messages to my clients in real time. Web-sockets would be a good idea, but they don't work in IE, which should be supported as well.
Until recently we have been using StreamHub, but it's license has expired and the project itself seems to be dead. We also considered jWebSockets, but they seem a bit of overkill.
Again, all we need to do is to send messages from the server to specific clients as events happen on the server.
Could you recomend a lightweight, free and opensource solution for that?
Here's an opensource Java implementation of Socket.IO. It allows you to use Ajax mulitpart streaming to simulate WebSockets when your client doesn't support them. I've used it on projects in the past. It's horribly out of date with the most recent implementation of the WebSocket protocol, so if you plan on using WebSocket capable browsers in addition to IE, you'll have to update the source code to comply with the latest protocol. At one point I was researching a maintained replacement for Java Socket.IO and jWebSockets sounded like the way to go.
Take a look at the Atmosphere WebSocket/Comet library. I believe it can use long polling when WebSockets aren't supported.
Reading RESTful documentation, it does not seem like it is possible to implement an asynchronous instance, but someone may know better on SO.
What I mean here is I would like to execute service requests asynchronously:
#Path("/helloworld", asyncSupported=true)
public class MyHelloWorldService {
...
}
I know asyncSupported is not defined in #Path, but I am looking for something similar to #WebServlet. Then, I would like to use AsyncContext instances (or anything equivalent).
Is this possible?
RestEasy has some support1 for it - using a custom annotation called #Suspend.
See here:
http://docs.jboss.org/resteasy/docs/2.2.1.GA/userguide/html/Asynchronous_HTTP_Request_Processing.html
There is also a framework/library on top of Jersey called Atmosphere however that might be overkill for your usecase as its focus appears to be on long-polling client/server web applications ( e.g. chats - https://github.com/Atmosphere/atmosphere )
[1] The CDI scope for your request will be lost in in the thread that actually executes the logic. See the RESTEasy-682 issue for more information. This is a problem that hasn't been solved by any REST frameworks that I know of at this moment[March 2014].
It's apparently possible with CXF and Jetty Continuations but that only appears to be possible with Jetty 6; they've been changed in Jetty 7 to something that's in the Servlet 3.0 spec and I don't know if that's supported by CXF. Moreover, Jetty Continuations seem to be a bit of a messy API, with a lot of manual stuff so I don't know how easy it is to convert the code.
Still, somewhat possible it seems. With a following breeze and when God wills it.
Restful spesification is still at early ages of its life. But this problem should be considered as 2 part. Client and Server.
Client:
For the client side recent changes at last year became mature enough. And recently a non blocking client from based on Jeanfrancois Arcand was implemented and pushed to repository. There is an explanation here.
Server:
For the server side, it is still immature. The adoption of the new servlet specification is quite slow and as a developer I am expecting JSR 339 to address these issues as well. And this is also addressed at the JSR spec clearly with these sentences.
JAX-RS 1.1 defines a synchronous request response model on the server
side. This JSR will specify a simple asynchronous request processing
model such that a response can be returned asynchronous to the
request. Servlet 3.0 can be leveraged to enable such support but
implementations may choose to use other container-specific APIs
instead.
However there are other alternatives too. Projects such as Jetty are addressing such kind of problems elegant as in this example. I can only suggest you to consider other alternatives as the community is growing.
Now you can make Asynchoronous RESTful calls using JAX-RS 2.0 API which is part of the recently released Java EE 7.0
http://www.slideshare.net/reza_rahman/jaxrs2?ref=
Check out Pubsubhubbub found here for an example of a REST-based asynchronous protocol. It is based on the Atom Syndication format and is a lot simplier than WS-* pub/sub mechanisms.
You may also want to try Spring Webflux which is async and reactive at the same time. However, this is not a JAX-RS implementation from Java EE.
I'm writing my first client/server android app, and need an advice regarding server architecture.
My app is not a browser based app, but a stand alone client.
On server side i use hibernate/JPA and would like to transfer objects to client side.
What should I use:
Implement MVC- meaning writing servlets that will handle http requests (via Apache for example).
Write my own stand alone primitive server, meaning using simple sockets connection(in java for example), and handle each client in a different thread.
if you can think on a better way, you're more than welcome to share..
HTTP is definitly your choice since many carrier will block other protocols, since application servers/containers will take care of handling the multiple connexions and since it will also be a base if you decide to have a browser-based version some day ...
REST + JSON based webservices are well suited for android, given its simplicity, lightness and readability, but SOAP is also available via kSOAP2.
In my opinion. writing your own socket server is only warranted if you are required to implement your own wire protocol.
Most likely it's not a case for you.
So stick with http since it's widely adopted and has excellent client support in Android.
As for specific server side technology, you need to enumerate your requirements and do some research.
Don't start with Apache if plan to use Java, though. Pick Tomcat or Jetty. For framework, my personal choice would be Spring MVC.
Well, I have some experience in this very sphere and we used apache + php "covered" with nginx. I believe it's better to use standard approach, such Apache + PHP or Tomcat + servlets, cause it's easy to scale if needed and support... Of course it interesting to write your own application, but you might have some troubles with when traffic grows or server is down etc.
I want to implement a Java HTTP server locally, I mean the server computer would be in my control. I'm expecting not more than 20 clients to send requests to it.
I was wondering how to go about it:
Should I use a J2EE servlet container, like Apache Tomcat?
Could I use J2SE classes and just build it using them?
Are there any existing alternatives?
What does your experience suggest?
There's a simple HTTP server embedded in the Sun 1.6 JRE. It's not JavaEE or servlet-compliant, it's very lightweight, but it might be good enough for your requirements. No need to download any 3rd party stuff if this is all you need.
The javadocs, rather bizarrely, are out on their own, here.
Embed Jetty in your application. Aside from performing quite well, it is delightfully easy to use and configure
You've got many options, not the least of which are Jetty, Grizzly, and TTiny.
I would strongly urge against writing your own web server, unless you've got time to kill and want to spend it writing things that are already available to you for free.
Seriously, reuse an existing solution. Why the hell are you even thinking rolling your own?
Now, 1. I don't understand your question as being about embedding a container. 2. You mentioned long polling several time. So I'd suggest to use GlassFish v3 / Grizzly (because there are many samples, e.g. have a look at the Dead Simple Comet Example on Glassfish v3 / Grizzly).
If you don't want to rely on the way a container implemented Comet support, use atmosphere and any of the container mentioned on the web site:
Atmosphere is a POJO based framework using Inversion of Control (IoC) to bring push/Comet to the masses! Finally a framework which can run on any Java based Web Server, including Google App Engine, Tomcat, Jetty, GlassFish, Weblogic, Grizzly, JBossWeb and JBoss, Resin, etc. without having to wait for Servlet 3.0 Async support or without the needs to learn how Comet support has been differently implemented by all those Containers.
If this is not a concern, just stick with the suggested option (GlassFish v3 / Grizzly).
For a concrete and recent comparison between Comet server implementation, checkout this awesome Comet Maturity comparison grid view (source: Comet Gazing: Maturity). It might help you to make your final choice... or not :)
I guess the biggest question is: why do you want to build this?
If it is for the purpose of personal development, I'd stick to whatever standard libraries come with your JDK and build it on top of that.
If on the other hand you have a particular application that needs a dedicated HTTP server I would try to take one of the open source servlet containers, like Jetty or Tomcat and build on those.
Perhaps look at the list of 26 open source web servers at http://java-source.net/open-source/web-servers.
http://java.sun.com/developer/technicalArticles/Networking/Webserver/WebServercode.html is actual code in a single file implementing a multi threaded webserver. For your requirements, such as they are, this should suffice.
http://java.sun.com/developer/technicalArticles/Networking/Webserver/ is an analysis of the code.
If you will write your own HttpServer you will have to implement all the methods of the HTTP protocol. Tomcat can be easily used locally.
Is it for practice, fun, to implement special requirements or why don't you just embed an existing solution?
Do you really want to build a HTTP server that deals with the protocol directly, or do you just want to write web apps? If all you care about is writing the web apps, then just use Tomcat, or Jetty, or Glassfish, or another server -- it will save you a ton of work.
If you really are interested in writing your own server from scratch, then the best way would be to just use Java SE, and not use any existing server technology.
Ad your 3) option: Try JBoss Netty.
http://fisheye.jboss.org/browse/Netty/trunk/src/main/java/org/jboss/netty/example/http/websocket