I want to use EJB in my GWT Application, but I coulnd't find a current Tutorial. I am new to the topic of EJB's and with GWt I have worked the last months. At the moment I have got some RPC Calls in my GWT Application and this works. Is it's possible in GWT to use EJB and if yes would it be difficult to install?
GWT is a client-side framework. It can connect with the server-side i.e. using RPC calls, REST web services or SOAP web services. An EJB on the other hand is a server-side technology which can define several entry-points for its clients.
I would consider creating a proper business logic and create a boundary for it - in form of i.e. RESTful Web Services. This functionality can be tested in well-controlled environment or even in real-life application server.
If this is done, than you just need to create a regular GWT application which 'talks' with EJBs through REST-WS.
Sorry, but I'm not aware of any tutorials about GWT + EJB. There is an example of EJB RESTful implementation at Adam Bien's weblog, but if you're really interested in EJB technology and don't know a bit about it, I would recommend to take some decent book first, like Enterprise Java Beans 3.1.
Related
I have a question, I was developing a desktop web application based on a REST API in Java using Servlets and JSP, but my boss said that it's not the best way to create a web application, because servlets and JSP are working as fat/thick clients( a request to the server make the application to download all content of data not a part like GWT does) and he suggested to go with GWT because it is working as a thin client.
As I was looking on the Internet I didn't see that servlets are working as fat clients, so my question is why is better GWT than servlets?
GWT solves a different problem than servlets. GWT is a tool to make clients, and servlets/JSP are tools for telling servers what to send to clients.
For example, my server uses a JSP to serve a GWT client, and servlets to connect the client to my database. I use all at once! You could use just one.
You can make your GWT client arbitrarily thick or thin. You can even run a GWT application with no server at all.
Use GWT if you want a nice tool for making complex, cross-browser web apps in Java. The decision to use JSP or servlets should be made separately.
I'm trying to build a REST web service (server side) that will allow a partner system to connect/POST order information in JSON format. Should I use JAX RS (for example from JBOSS RESTEasy) or Spring MVC to build such a service? They both seem capable enough to accomplish the same thing as far as building a REST service is concerned.
Thank you!
Depends if you want to learn something new or go with what you already know.
If you already have experience with Spring MVC and want to get the work done quickly, then I'd suggest staying with Spring MVC. There are some neat enhancements to the REST features in Spring 3.1, including the ability to generate "end point documentation".
If, on the other hand, you are looking to expand your CV and/or enjoy learning new technologies, then give JAX RS a go. I haven't used it but it is a dedicated WS framework that would likely have any feature you'd require.
Of course, if you have experience with JAX RS but not Spring MVC, then the opposite applies :-)
If you are developing an EE 5 project then I would recommend using JAX-RS with Spring. The RI for JAX-RS, Jersey, has a Spring JAX-RS dispatcher servlet. This makes it much easier to manage dependency injection with JAX-RS and gives you all of the Spring MVC features like form binding and validation, but you are also able to use the Java standard approach for REST - and in my opinion, a better and easier to manage approach than Spring REST.
If it is an EE 6 app, then you may want to think about ditching Spring as JAX-RS is part of the EE 6 specs and you can use EE CDI within your JAX-RS classes.
Notice that Jersey has a bug that affects its integration with Spring:
https://java.net/jira/browse/JERSEY-2301
In summary if you need Spring AOP in your JAX-RS resources it will not work. Dependency injection works well.
REST is more of an architecture style of developing web services which are very easy to understand without even documentation for a developer. Normal tech savy people can easily understand the URL patterns also the response types of JSON and XML support makes it easy for integrating with new javascript modularization standards such as backbone or angular.js.
On the other hand SpringMVC is more concentrating on model-view-controller architecture style of developing applications.
I am asking this question because, I see that Roo include SPRING MVC and GWT...but
- GWT (on its website) shows an example of a MVP pattern but I think it is not comparable with the SPRING MVC framework (indeed Spring MVC has more features. I have never used it...but I read that it helps a lot to do website, and easily lets have a REST architecture (how to do as easily a REST architecture with GWT and a MVP plateform ?)...
Can you help me to choose between these technologies (taking care that I want to develop my app on GAE, and I will also want Mobile phone version) ?
I suggest you not to use GWT with Roo, its GWT support extremely buggy at the moment. (Saying this as a big fan of Roo)
Also, REST is architectural style which embraces HTTP as an application protocol, not only as a transport protocol, meanwhile GWT is a framework, or rather a toolset for creating rich web application which use JavaScript as a frontend, one has basically nothing to do with the other. You can however use Spring MVC to build RESTful applications:
http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
http://static.springsource.org/spring/docs/3.0.0.M3/spring-framework-reference/html/ch18s02.html
http://www.oudmaijer.com/2010/01/16/spring-3-0-rest-services-with-spring-mvc/
Is there a way to implement RESTful WebService using Spring 3 (or not) that does not use any web container?
Thank you !
I assume that the RESTful request will arrive over HTTP? So something needs to listen on the appropriate port and dispatch requests off to the service code. Obviously you can write such code, but you are likely to end up with something not very different from a Web Server.
If your objective is to embed this capability in some context then a lighweight container such as Jetty (as proposed by skaffman) seems like an answer - I'd be reluctant to write my own code instead
Using a framework such as JAX-RS makes writing REST services very easy, so if the actual objective is develop RESTful services quickly then I'd be prepared to live with a container that does the work for me.
In theory, yes - the various Spring-WS components are decoupled from the Servlet API. So you could, in theory, use the webserver built in to the Sun Java6 JRE.
In practice, this would be a lot of extra work. You'd have to bridge the Sun Web Server API to the Spring-WS API.
As an alternative to traditional Servlet containers, I can highly recommend Embedded Jetty, where your app can start up a lightweight servlet container within itself, and serve Spring-WS from that.
I'd like to create a simple Google Web Toolkit application which makes uses RPCs. For persistence, I'd like to use something like the Java Persistence API.
Does this mean I have to use an application server like Glassfish? or can I stick with a simple web container?
In terms of concrete libraries, how should I proceed? TopLink? Hibernate? ...
I believe the GWT RPC stuff is implemented as simple servlets. Assuming that, you totally can use JPA in a web container like Tomcat and don't need a full blown J2EE app server.
To do that, you will need to do a bit of manual setup to make access to the PersistenceContext simpler. Hibernate suggests using ThreadLocal, and I have an entry on my blog that details how I did that for Tomcat here
I would personally recommend Glassfish, as being more stable, better implemented and generally higher quality that Tomcat. I don't want to start a flame war (by saying that putting J2EE into Tomcat is like putting lipstick on a pig), but I will tell you how we deploy all of our applications:
We use Glassfish as the web container, TopLink as the persistence provider, generally connected to a MySQL 5 database. We use the JPA POJOs all the way from the EJB layer, through the web tier, and the GWT layer as well, via RPC. We also use Stripes and JSPs for all the presentation logic that doesn't require AJAX functionality. We've never had any problems with this approach, and have so far done at least 10 large-scale projects this way. It's the best architecture that we've had to date, and we've had a lot (tomcat, jboss, hibernate, struts, spring, etc, etc, etc).
You can user any container you like, i mean servlet and jpa containers.
The key point is that GWT doesn't suport jpa, so you have to use DTO design parten.
This will keep everything organized and you will not have problems with lazy loading.