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.
Related
Spring seems to be deprecating its RMI:
As of Spring Framework 5.3, support for several remoting technologies is now deprecated for security reasons and broader industry support. Supporting infrastructure will be removed from Spring Framework for its next major release.
But I can't find any easy equivalent alternative to it. REST would sound like the best choice for simple stuff, but it does not cover solutions where the task is long running and/or a continuous flow of results is needed. So the implementation would be very absurdly painful with REST. Some consider submitting the tasks via REST to queues and then possibly querying for the results separately - but this sounds like an overkill and blows the amount of work needed to sky-high for something really simple that used to be available.
Is there a good alternative or some framework that uses the non-deprecated technologies and is officially available that deals with the above mentioned problems? When something is deprecated it usually indicates that something better is available that would be the better solution, so can somebody help me on educating me what it is?
Based on the spring documentation:
https://docs.spring.io/spring-framework/docs/current/reference/html/integration.html#remoting-web-services
I can say, that probably these alternatives remain in future versions, but I did not try them:
Jax-WS
Spring Web Services
AMQP
I feel, that Spring Web Services is Spring's favorite.
We will see when the 6.0 documentation is finished.
I have come across the same problem using Hessian. I think you still can make your own implementation. Spring only deprecates their own integrations to RMI technologies.
I think there are plenty of other technologies, but the message is clear. Spring will not make any own integrations.
I can think of these alternatives:
Hessian: still usable, but implement your own integration
gRPC
messaging (rabbit, pulsar, kafka, ...)
SOAP
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.
I've been looking into JAX-RS lately because I really like the Java platform and a RESTful style of web development. I've read a lot about using JAX-RS for creating RESTful Web Services, but is it possible to use JAX-RS to create RESTful web sites? I guess more specifically, is it possible to use JAX-RS as a controller (to retrieve required data from the server) and then forward control to a view engine to render the appropriate HTML?
I've been googling around but haven't found any resources that show you how to do this.
Thanks for any insight/help.
I think you are having difficulty with your google searches because not many people are doing this. JAX-RS was designed for web services, so developers don't think of using it as a controller for web applications. However, there is no reason it wouldn't work.
Check out this blog post: JAX-RS as the one Java web framework to rule them all?
I think it's exactly the kind of thing you are looking for.
If you truly want to rely just only JAX-RS for your web framework, Jersey might be your best bet. Keep in mind the features you get from it are going to be bare minimum and you are obviously not going to get all the bells and whistles like what's provided by JSF, Wicket, etc.
If you know your web application is going to rely on Spring, perhaps you should consider using Spring MVC 3.0. It provides restful web services-alike and it gives you better features so that you don't need to implement most of them yourself. Granted, Spring MVC 3.0 is not an implementation of JAX-RS and based on what the Spring developer said, it seems like they will never make Spring MVC as an implementation of JAX-RS since they are already quite a few stable implementations out there. However, the syntax is pretty similar in my opinion, or at least I was able to understand them rather quickly even though I have been using Jersey for quite awhile.
dbyrne is right that almost no one is doing this. It's more conventional to use JAX-RS to dump information to JSON or XML. Then you fancy up the web browser with an RIA framework (e.g. Ext JS), which handles manipulating the DOM and injecting data as its fetched in JSON/XML form. This approach is powerful. You can write multiple, possibly non-browser clients for the service, all parsing the same JSON/XML. You can write "one-page" webapps, where all information exchange happens through AJAX after the initial pageload. I urge you to investigate and consider its strengths and weaknesses in the context of your particular problem.
Returning to your question: the answer is "sort of". This functionality is not directly provided by the JAX-RS spec (as of 1.1). However, it is in the JAX-RS reference implementation, Jersey, through the Viewable response object. See this blog post if you want to investigate further: http://blogs.oracle.com/sandoz/entry/mvcj. I want to point out that I have no experience with this side of Jersey. It has been pleasant to write XML/JSON-returning web services with Jersey, but I can't speak to this server-side HTML templating business.
Edit: dbyrne's edited his answer to include a blog post which points to the one mentioned above. I think we've both converged on approximately the same answer.
Is AXIS or CXF necessary for Java web services? Can it be all done via the JDK (1.6)?
Is AXIS or CXF necessary for Java web services?
No. Although Axis2 is the most popular framework to work with Web Services is not the only way to do them.
Can it be all done via the JDK (1.6)?
Yes, but it is way much harder. You will benefit tremendously from using a framework used by others apps and from the bug fixes the development team provide. Doing all by hand is like reinventing the wheel.
If you want to have full control of what's happening underneath, probably you could go with: JAX-WS
or if the application is very simple, directly with socket.
But again, Axis2 is the canonical way to do WS ( but not the only one )
The following is based on an all to true and personal story:
So you want to consume a web service in your Java web application, and you don't want to add 10MiB of JARs to your lean 1.3 MiB .war file, and besides you are great at parsing XML (you can hand code XPath Queries, and XSLT files), you totally understand HTTP, and the client you are interfacing with has great documentation. You download the WSDL look at your endpoints and your methods and start creating a Java class that maps to the features you are going to need. You feel great already.
They you start reading up on how to send a SOAP request and you think well this looks a little verbose but what they hey it's all just a string, so you start building a utility that takes your Java request object and converts it to a SOAP request. You send your clear SOAP request to the server but it gets denied (missing a signature).
So now you start adding encryption JARs to your project and you start looking at how to calculate a signature of part of an XML document and include both it and the document in the request. This takes you a while but with enough hacking you get a message that you can send to your soap service and you are now dealing with the SOAP response. Now you are feeling great...
Until the admin at your client changes their security requirements, issues new public keys, and updates the soap interface with some custom types, and your next client who is running a similar service (but on a Windows Server) wants you to implement with them as well.
At this point I gave up trying to implement this in a pure Java way and just started using standard libraries. They deal with stuff like encryption, marshaling, deviations form the standards and they let you focus on stuff that is closer to your problem domain. I hope you can save yourself the lost month it took me to learn this lesson.
An update on the landscape of web services in 2013.
Web services used to be SOAP and XML-based. Web services were standardized into JAX-WS. Some of the more popular frameworks are (were):
Axis 1.x
Axis 2
Apache CXF - CXF also includes other protocols. It is a much broader framework
Metro Web Services which includes the JAX-WS Reference Implementation.
Java 6 and Java 7 include the JAX-WS RI by default. It means that frameworks are no longer needed except to generate client and service stubs / skeletons
There are other implementations not listed here that are vendor-specific e.g. IBM Websphere's WS implementation and Weblogic's WS implementation.
Generally though, to create web services, I would recommend Metro and the JAX-WS RI.
Note that there are many WS-* standards e.g. WS-Security which may not be part of all WS implementations.
Since web services have been around for a while, other alternatives have come up both in terms of architectural style, protocol, and encoding.
For instance, XML used to be the de-facto encoding. JSON is now more prevalent. It is worth looking into Jackson, a JSON parser, or Google GSON. The main arguments in favor of JSON are that it is easy to use, lightweight, and developer-friendly.
Along with JSON came REST. REST is an architectural style. With REST, you can still implement "web services" in the sense of remote services that can be easily consumed over a network. REST has also been standardized in the Java family of standards as JAX-RS. Some of the popular JAX-RS implementations include CXF, Jersey, and RESTLet.
Finally, there are some new kids on the block that use binary encodings. Those are Google Protocol Buffers and Apache Thrift. Their main goal is performance as well as broader support for other languages (Java, C#, Erland, Perl...).
When developing a web service today, the question should be:
- do I care about performance?
- do I want to access the service from many different languages?
- do I want mobile-friendly?
These should help you guide your choice. Also, I prefer to keep my dependencies to a minimum. This means I would rather take something that is native to the JRE or JDK e.g. the JAX-WS or JAX-RS reference implementation.
As an alternative to Axis, you can use the Spring WebServices framework to run your webservices application within a J2EE container like Tomcat or anything similar. I've found it very easy to use and setup, and if you want to integrate your webservices into another web application later, it's quite easy to do (I've done so myself on two separate occasions).
You can use the http streams provided by the webserver as you whish, but using a framework and some jars (which are proven to work) will save you a lot of headaches and a lot of time in the long run.
Normally you will want to use a programming framework for web services.
Something like AXIS, CXF, or the Java EE (GlassFish) download from Sun.
I'm looking for a light version of REST for a Java web application I'm developing.
I've looked at RESTlet (www.restlet.org) and the REST plugin for Struts 2, but I haven't made up my mind. I'm leaning towards RESTlet, as it seems to be lighter.
Has anyone implemented a RESTful layer without any of the the frameworks or with the frameworks?
Any performance issues that you've seen because of the new web layer?
Did the introduction of REST added unmanageable or unreasonable complexity to your project? (Some complexity is understandable, but what I mean is just plain overkilling your design just to add REST)
I'm a huge fan of JAX-RS - I think they've done a great job with that specification. I use it on a number of projects and its been a joy to work with.
JAX-RS lets you create REST resources using POJOs with simple annotations dealing with the URI mappings, HTTP methods and content negotiation all integrated nicely with dependency injection. There's no complex APIs to learn; just the core REST concepts (URIs, headers/response codes and content negotiation) are required. FWIW JAX-RS is quite Rails-ish from the controller point of view
There are a number of JAX-RS implementations out there - see this thread for a discussion.
My personal recommendation is to use Jersey as its got the biggest, most active community behind it, has the best features at the time of writing (WADL support, implicit views, spring integration, nice REST client API); though if you are using JBoss/SEAM you might find RESTeasy integrates a little better.
I'm a big fan of Restlet, but I usually use it to implement apps whose primary role is to be a RESTful web service. It sounds like you're looking to add a RESTful API to an existing application. If that's the case, JAX-RS's (or Enunciate's) annotation-based approach might be a better fit for your project.
As for Restlet, I can tell you that I've been very impressed with the developers and the community; they're very active, engaged, responsive, and committed to a stable, efficient, reliable, and effective framework. My single favorite aspect of the framework is that it is a ground-up implementation of the REST paradigm; therefore there is no impedance-mismatch between a Restlet app's external API and internal implementation. I also really like how flexible it is - it can run inside a Java application container/server such as JBoss, Tomcat, Jetty, etc, or standalone, with an embedded HTTP server library.
Well, I've used Enunciate quite a bit. It uses simple annotations to provide either REST and/or SOAP endpoints.
http://enunciate.codehaus.org
Plus, Ryan Heaton has always provided top-notch support for things, too.
You know there is a new JCP API for Accessing RESTful Services, also:
JAX-RS JCP311
https://jsr311.dev.java.net/
The open source version is called Project Jersey
I am working on a REST API for gliffy.com and we ended up rolling our own. We didn't want to have to bring in Struts 2, Spring, or any other framework. I looked at RESTLet and found it incredibly confusing and over complicated.
Apache has an implementation of the JAX-RS spec, but it is not finalized and also has some oddities to it. We're tentatively planning to open source our solution, but that's not for a few months.
Rolling your own is easy, though. The Servlet Specification gives you everything you need, and you can easily connect to a database via Hibernate (see http://www.naildrivin5.com/daveblog5000/?p=39 for how to set up JPA without using EJB3).
I found restlet to be a really elegant architecture. I'm working in the .net world so it was not an option for me, but I was able to build my own framework following the same basic principles of restlet.
I have found the conversion of our WCF contract-based SOA application to REST based one has significantly simplified the application,