Have somebody experience with using REST on GAE? Maybe you can advise some lightweight REST implementation for this.
I found that RESTlet said that they have GAE optimised implementation. RESTlet-GAE
Anybody try this?
I am currently using GAE plus Restlet 2.0M6 for a Goolge Apps Domain specific business project and find it very useful.
Integration with google Accounts and Data Api is easily done for obvious reasons.
However I could not get the XStream lib that is bundled with Restlet to work properly, so I use the very intuitive Simple framework instead for object serialization.
Another disadvantage of Restlet is its lack of JSP integration, which is unfortunate if you do not want to use more heavy-weight templating approaches.
So far I have used XSLTransformations to render browsable html representations, but am not fully satisfied with it yet and always looking for suggestions.
Update
I am now using Saxon to transform xml on the server. This is a good tutorial on how to use it with App Engine. It is in Jython but not too hard to convert.
Update2
When the xslt approach is too heavy, I take a different approach with the helper package from the Lift framework to enable enriched xhtml templating/binding. This method is based on Scala however.
Related
I am trying to create my own REST-based API using Java and Akka. I have created my main algorithmic implementation using Akka already. My confusion is coming in the form of how to implement the REST part of this. Most examples and libraries I have seen are specifically for Scala, which I am at the moment trying to stay away from.
I see Spray is a good way to go, but I see it's supposed to be for Scala. However, I know Scala compiles down to Java Byte Code and Java should be able to call Scala and visa versa. Is it possible to do this with Spray? If so, are there any working examples or tutorials online? I am not having any luck anywhere.
Thanks for your help and time.
I would recommend you to use playframework 2.0. It is already integrated with akka and you can choose to write your code in Java or Scala. Its will be very easy to implement a REST-based API.
Actually, I went down the same exact path: wanted to use Akka for REST-based services implementation and did not want to use Scala.
Akka can be used with Play-mini, which gives you the Sinatra-like REST mapping without any of the ui stuff (you don't need).
You may also want to look at the Spray Framework http://spray.io/.
It might be the lightweight alternative to Play Framework.
Here is a github repo with Jersey 2 Rest Service using Akka actors for processing in a Java project based on Maven.
https://github.com/pofallon/jersey2-akka-java
I think you want to look at this:
https://www.typesafe.com/activator/template/akka-http-microservice
Simple (micro)service which demonstrates how to accomplish tasks typical for REST service using Akka HTTP. Project includes: starting standalone HTTP server, handling simple file-based configuration, logging, routing, deconstructing requests, unmarshalling JSON entities to Scala's case classes, marshaling Scala's case classes to JSON responses, error handling, issuing requests to external services, testing with mocking of external services.
There is an old entry (2010) on akka github for a akka-sample-rest-java example that would be really interesting. However it's removed in following versions, don't know why.
https://github.com/akka/akka-modules/tree/v1.0/akka-samples/akka-sample-rest-java/src/main/java/sample/rest/java
Since it has been unmaintained, most of the classes rely on old versions of akka and does not works with the most recent ones.
at the moment two modern microservices & REST technologies: Vert.x and dropwizard
Akka-HTTP is the defacto Spray 2.0 as this stackoverflow thread shows:
Spray, Akka-http and Play, Which is the best bet for a new HTTP/REST project
So, I would opt for choosing Akka-HTTP if REST based API for Akka was what you were looking for.
I'm developing a web application with multiple frameworks (spring, hibernate, spring-security, ZK for GUI), and using Tomcat as app server. I must say I have absolutely no experience with java web services technologies. Thing is, I will almost certainly have to expose number of services for some external applications in the near future, and I was wondering what would be the way to go (considering the frameworks I'm using)...
I saw and read various tutorials and some questions (link) regarding Axis, Axis2, JAX-WS... Thing that confuses me a little bit is that I don't know what is the common practice (if any) to integrate services within existing web application (mainly in the terms of project organization). As I see it now, these services that I need to implement will rely partially on the existing source code, so I don't know whether I should use completely separate project, or I can put it inside my existing web app folder (which I tried with Axis2, but don't know if it's a good practice).
Thanks.
How to organize the projects?
In general I agree with #ericacm, but there is one thing you should keep in mind... You said you're going to develop a number of services in the near future. You may come to a point at which you want to host the services on a separate server, e.g. for performance, availability or maintainability reasons. This may influence your decision of separating the projects. Furthermore, separation "enforces" loose coupling, but therefore introduces other challenges like session sharing across multiple WARs. It's a case-by-case decision.
If I were in your situation I'd first ask myself whether the service(s) logically belongs to the web application or not.
Implementation
When in comes to WS-* implementations you have to make 2 decisions:
Decide for an API to use; today, I can't see any reason for not going with JAX-WS together with JAXB as API, they work well and they are standardized.
Decide for a Framework; I've experience using Axis2 as well as METRO (keep in mind that JSE 1.6+ provides basic JAX-WS support). Both work well. It's fairly easy to change the frameworks if you use the JAX-WS APIs.
I have good experience with Spring-WS 2+ and manual Castor mapping . Is is easy but powerful combination.
Spring-ws 2:
provides contract-first development (specially good for the web app with number of services).
provides WS annotation
supports XML mapping (Castor, JaxB, etc)
Castor:
mapping based on xml configuration
allows map multiple messages (requests/responses) to one java object (based on xml configuration)
If you are using some Java EE 6 server, consider also JAXB for manual mapping:
mapping based on annotation
should be faster than Castor
allows map multiple messages (requests/response) to one java object (when you use java inheritance)
You can go ahead and put them into the same project. Each web service will be an additional interface and implementation class along with some configuration.
Since you are using Spring CXF is a good choice as a for JAX-WS as it integrates well with Spring. See this page as a starter.
Spring-WS is complex framework for simple web services. If you want to understand web services completely and to know the nuts and bolts of web services, learn Spring-WS. It is extremely flexible and provides lot of options.
Else, if you want simpler alternative use JAX-WS. Spring supports JAX-WS annotations. Refer to the section 17.5.7. Exporting web services using the JAX-WS RI's Spring support.
http://static.springsource.org/spring/docs/2.5.x/reference/remoting.html
Is it possible to create WS Server and WS Client manually (without generators) by JAX-WS? Specially if you are developing a big application you want to re-use objects but generators are generating a lot of classes that can be in 99% the same (for example if your app is WS Client and you have to connect to badly designed external WS Server). Is there some tutorial how co create ws manually?
There is a lot of reasons why I don't like generators and completely agree with http://ogrigas.eu/spring/2010/04/spring-ws-and-jaxb-without-a-code-generator
I am in the process of beginning development of a web-based user interface and am looking for some expert advice on the right direction for my project.
Since our server-side is to be developed using Java, I am planning to use scriptless-JSP and an MVC framework called FrontMan. FrontMan is a lightweight Java-based MVC framework similar to Struts. I have played around with it and like it. The plan is to use scriptless-JSP assisted by JSTL and JSP tag files. I worked out some prototypes using these technologies and I liked what I had.
Now I am in the process of planning out the client-side stuff. My plan is to use JavaScript, jQuery, jQuery UI to build the front end. During my investigation I came across a very nifty JavaScript MVC framework named JavaScriptMVC. I have to say I really like it. It is not just a client-side MVC framework, but also includes tools for testing, documenting and deploying.
The more I engage in figuring out the client-side plan, I realize that I think this is going to be more of a JavaScript (client-side) app. I am leaning towards doing as much of the work in JavaScript rather than on the backend via Java. The backend will exist mostly for communicating with the database and responding to requests from the client (frontend) for manipulating or retrieving data.
I am rather new to RESTful web services, but in the little I have read about them, I think this might be a good direction to take this project.
I am wondering how I can employ both an MVC framework and REST framework together? Do they make sense together?
I am using Jetty as my web server, so I think that lends itself to using Restlets...?
Anyway, I am not sure how much sense I am making in this post, so I will stop it there for now.
As the previous poster mentioned, it makes perfect sence. MVC let's you separate concerns such that you can keep your application logic separate from your presentational logic.
Your REST controller serves the request you need, populates the model, and exposes it in a REST like manner, typically by returning an xml view to the user. This can be aided by a number of libraries such as xstream, jaxb, castor, xmlbeans, which all provides routines to marshall an object into xml.
Exposing a REST API on the server-side will be a perfect fit for your JS front-end. Your resources will have to expose JSON representations. You will even be able to reuse this web API from other clients such as mobile phones.
As the lead for the Restlet Framework, I can only recommend it for this purpose. Integration with Jetty is very stable :)
Cheers,
Jerome
A quite extensive discussion on this can also be found here:
Separate REST JSON API server and client?
For me it was very helpful.
Yes! It makes sense as Johan Sjöberg said! You can use Spring MVC for example. I like it a lot and think it is very simple and easy to learn. You have an example here.
By the away, for the frontend maybe you would like to check this presentation.
Looking to implement a RIA using AJAX with Java on the backend.
I was looking at DWR for an RPC style approach, but the project hasn't been updated since 2008.
I was also looking at DOJO and GWT.
Can anyone recommend a core set of technologies that works best for a Java based back end, that contains a rich set of client side widgets and backend integration with Spring WebFlow/MVC?
thanks
I would recommend Spring 3.0. It's up to date, lightweight, easily configurable, supports dependency injection, annotated classes, and is a great framework.
It supports REST, so it's easy to implement classes that return JSON to your HTML pages. This will help keep your content, behavior, and presentation all separate while still enabling you to build a Rich Internet Application.
Although outside the scope of your question, I'd suggest you use JQuery on the frontend as I've had really good results using it to transfer JSON back and forth from the server.
I would stay away from DWR. They merged with Dojo, which in my opinion is a better choice than DWR. DWR sounded good, but in practice it was buggy and difficult to use. Dojo was much cleaner and more modular. But unless you're using Comet (aka Reverse Ajax) just stick with Spring and JQuery.
Spring 3.0 is also supported on Google App Engine... just worth mentioning as Platform as a Service is in our future.
My recommendation is a RIA framework like SmartClient or ExtJS + a REST-based backend (built on Jersey, for example). I have also found JQuery to be extremely helpful when combined with these frameworks. Together. this allows you to build your GUI right on top of a REST API, which itself could be reusable for programmatic integration.
These kinds of questions are always religious ones, but FWIW I am personally not a massive fan of GWT, for multiple reasons. One of those reasons is because I don't want server side folks constructing GUI-targeted data structures (I'd rather have them stick to pure data and let me GUI folks handle the GUI stuff). So I actually don't appreciate that capability of GWT, but obviously many other people welcome that aspect, so again it's a religious choice.
you can try GWT.That supports Spring well.
http://www.springbyexample.org/examples/simple-gwt-spring-webapp.html
If you use a Spring MVC back end, you can use any AJAX frontend there is.
And if you are going to develop a RIA, I would suggest either Prototype with Script.Aculo.Us (Killer GUI effect library) or MooTools (which is either an extension or a re-write of prototype, that also includes many GUI tools).
The great thing about both ProtoType and Mootools is their Object-Oriented methodology (MooTools Class() docs, Prototype Class.create() docs), but the extension mechanism that gives additional methods and properties to DOM elements (How Prototype extends the DOM, MooTools Element reference). Of course this mechanism is exactly what the JQuery guys loathe about these libraries. But the nice thing is that because of these extensions, you hardly ever have to resort to browser-specific programming, the abstraction handles that for you.
I choose JSF for RIA applications.
It is J2EE 6 standard
it built-in in J2EE application servers (glassfish, jboss),
it has several implementations - if you have problem with one, you can switch to another
I has at least 4 (richfaces, myfaces, icefaces, primefaces) independent, big components libraries.
Spring can work well, but my personal preference is for simplicity, and Spring is bit heavy platform. So I prefer deploying services on JAX-RS containers (like Jersey); Guice for wiring things together, and in case I want to override or change data bindings, Jackson for JSON handling.
Other useful pieces would be jDBI for database access (much simpler than hibernate or other full ORMs), async-httpclient for doing calls to other web services.
Best of all, these all work nicely for many other kinds of uses.
I have a quite extensive Spring 3.0 service architecture (the typical architecture; a bunch of model objects and a bunch of services that do stuff with these objects). I would like expose some of these services as SOAP web services.
We have developed SOAP web services before, but these have always been relatively simple and dedicated, and we have always used Axis 2. I found Axis 2 a bit heavy on the dependency and implementation side, and I'm a bit worried that this will bloat my current project something awful.
I have looked around and apparently using Apache CXF this would seem quite easy. So I'm looking for some advice on this. Does anyone have any practical experience with this? Pros and cons?
We are using spring with CXF for soap services and it goes very smooth. Following the CXF tutorial makes it straightforward to use by simply using the jaxws xml namespace.
I haven't really tested any other webservice frameworks - always been going with CXF and am quite happy with that.
If you're using Netbeans (even if not, it's still useful I'd say), check out this tutorial: http://sites.google.com/site/apachecxfnetbeans/loanproc
Just skip the first few paragraphs (Database integration, testing etc. etc. .. all of which you should already have knowledge about).
The CXF integration in Netbeans is useful for writing fast clients using the built-in netbeans functionalities.
cheers