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.
Related
Is there any documentation / articles identifying best practices / rules for when should one use JPA in an ejb container vs. when is it appropriate to use JPA in a web container?
At a high level - couple of things that I can think about is if we have JPA in WAR then the transactional code will need to be managed by the developer in UserTransactions and it cannot be reused by other modules or even the EJB in the same application.
I typically use JPA for either Java SE applications or in a Container. The SE application is really only playing around or doing database loads or setup. I have setup JPA in Tomcat, but I wasn't really pleased with the end result and felt there was some issues that couldn't really be resolved.
EDIT: That said, consider Spring/Hibernate runs in a servlet container under your HTTP server of choice, and seems to be a pretty popular and mature platform, but also quite vendor specific. It will do just about anything I can think of that a Java EE certified container will do and perhaps more.
I think your considerations come down to what kind of application you're building which, in turn, provides a lot of input about what database to use.
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 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.
I've recently been given a project to work on that involves writing a web application. I've never done Java EE before. A lot of resources on the web are dated and I'm having trouble figuring out what the current differences are between the various standards and Java technologies.
Originally I thought I really needed EJB 3.1 due to dependency injection, JPA, session management, and web services. I started experimenting with Glassfish but was told that we had to write the thing in Tomcat. So I've been trying to figure out what I need as well as what and how to put into Tomcat to get there. I've begun to question whether I even need EJB at all.
I want to use JFS, I think, for the MVC architecture. In learning about that I've run into both ManagedBeans and CDI, which according to some renders the former obsolete and also seems to provide all the dependency injection stuff I want to enable unit testing. I've also come to realize that I can get JPA outside of EJB in the form of Hibernate and maybe a few others. Additionally it seems that web services, which I don't know that I need anyway, come in the form of another standard I can't think of the name right now and this also can be installed independently.
My major issue here is session management and state. It seems to me that all which remains for EJB to do is provide #Stateless/#Stateful and #Local/#Remote. However, as I understand it, some of this is already exists in the form of session management in the servlet container...but I don't know how much or what the major differences are that I need to account for in order to decide if I need these things at all.
So my question is, what are the basic, essential differences that I need to know in order to decide if EJB is worth looking at or if I have enough in the form of other libraries and technologies? I've been all over google and Usenet and have not been able to find this information anywhere.
Just thought of another bit. As I understand it, the #Stateful bean annotation provides me thread-safe state saving. I'm probably not going to directly use threads, but I know Java does so behind the scenes a lot and suspect EE especially so. When I need to keep state I don't want to be dealing with threads if this already provides it.
ManagedBean
Java EE 6 has three different ways of defining beans that are managed in one way or another:
#javax.faces.bean.ManagedBean
JSF 2.0 introduced this annotation declaring managed beans in faces-config.xml. This annotation is used to access a bean from the Expression Language.
#javax.inject.Named
In an EE 6 container CDI this annotation is a built-in qualifier types to provide a name to a bean, making it accessible through EL.
#javax.annotation.ManagedBean
This annotation attempts to generalize JSF managed beans for use elsewhere in Java EE.
If you deploy in an EE 6 container (If you use Tomcat or another servlet container, you can also get CDI by adding the Weld jar to your web app), then there is really no reason to use #javax.faces.bean.ManagedBean. Just use #javax.inject.Namedand start taking advantage of CDI sevices.
CDI
One of the objectives of CDI specification is to bring together the Web tier and the transactional services, making easy for developers to use EJB along with JSF in web applications of the Java EE platform.
With CDI you have the following services among others : well-defined lifecycle contexts(influenced by seam 2 and conversation scope), Dependency injection, loose coupling facilities like interceptors, decorators and events and portable extensions, which allows third-party frameworks to integrate in the Java EE 6 environment like SEAM 3 extensions
Managed beans and EJB Services
First of all CDI applies to any managed bean. Some managed beans are EJBs. When we need to use the EJB services in a managed bean, we just add a #Stateless, #Stateful or #Singleton annotation. IMO they act as complementary technologies allowing you to have a flexible and gradual development just only adding some annotations.
So, when should we use a session bean instead of a plain managed bean?
When you need some EJB features that CDI is missing : declarative transactions, concurrency management, pooling, remote or web service invocation ,timers and asynchronous method invokation.
Of course you could also get all aspects using third party libraries - but this would introduce additional complexity to your project. In terms of functionality IMHO EJB are the place to implement :
Business logic, allowing you to have a cleaning separation of busniness logic and web tier logic (implemented by "JSF backing beans" which are CDI managed beans but no EJB)
Functionality which makes most sense for components which are entrypoints to the application (endpoints for remote invocations delivered via RMI or HTTP)
Finally if you need EJB services then you need an Aplication Server (eg. GlassFish or Jboss AS) if you only need CDI services you need a Servlet Container(e.g Tomcat) plus CDI libraries.
Do you need the features provided by EJBs, i.e. security and transaction management? If the answer is yes, EJBs might be a good option.
If the answer is no, and you only need dependency injection, CDI could then be a good option.
You can also get similar capabilities with other 3rd party products, like Spring (dependency injection, Spring security, etc), but deciding whether you use one (EJB) or the other (e.g. Spring) is in many of the cases a matter of previous skillset.
In my opinion, if there are no previous constraints, going Java spec compliant is a good investment.
I would suggest you to start with the CDI and proceed to the EJB's (which is really adding one annotation on top of your POJO) if the requirements needs them (just as it was told - transactionality, web services, JMX, timers, EJB asynchronous invocations).
It's quite reasonable to develop an application in which your entry point is an EJB which encompasses your call in the transaction and allows you to define multiple entry points. The EJB then invokes the CDI beans with the business logic in them.
It's also worth noticing that the TomEE is a certified Java EE 6 Web Profile developed on top of the Apache Tomcat.
For example, Play-framework supports RESTful services like this: RESTful on Play! framework
How does this compare to something like Jax-RS Jersey implementation? Does a framework like Play run circles around Jersey because of all it's cool bells and whistles, and it does REST too?
Developer productivity is important, but so is a proper implementation. Perhaps using an MVC framework for REST only services is 'wrong'?
Note, only RESTful services, no UI components at all.
Even though it's not "wrong" to use an MVC framework for RESTful services, there are some pros and cons versus using a JAX-RS implementation.
(Disclaimer: I have only used Jersey and Play! for fun, and not on production-grade systems, so I have tailored my comments more generally to MVC vs. JAX-RS. Keep in mind that these are broad generalizations.)
MVC frameworks--at least the ones that are considered developer friendly and "slick"--typically save you from having to build a persistence layer (the model part). Most also simplify "routing" requests using either scaffolding via convention or some form of configuration. The downsides are that you have to conform to some conventions for your controllers and usually have to write a view for each resource (or build layers of abstractions to avoid rewriting the same code).
JAX-RS excels at defining the routing (using Java annotations) as well as eliminating any restrictions on the service class. In my experience, that has greatly reduced the amount of boilerplate code and developer overhead. Jersey and Apache CXF also handle the XML or JSON serialization using JAXB annotations, which eliminates the need to figure out the view in an MVC context. The downside here is that you have to figure out your own ORM or persistence layer, which could be good or bad depending on whether you're building on top of existing data or creating a greenfield system (or using something other than an JPA/RDBMS e.g. NoSQL data store).
My own personal comment: Play! is a really cool framework, but I'd choose CXF (or Jersey) over an MVC framework any day for building out a RESTful service. In my experience, this frees up the developer to focus on the logic needed for the service, and opens up options for different database approaches. Right tool for the right job.
As a rule of thumb: For Scala, use Play. For Java, use Jersey.
You can use Jersey/Scala and Play/Java; I've done both. It works. It isn't bad. But unless you have a particular reason to do that, I wouldn't mix ecosystems. Java and Scala are interoperable but they have different ecosystems, I would avoid adding Java-isms if you are using Scala or Scala-isms and dependencies if you are running straight Java.
Jersey and Play are generally close for REST services. Neither really has any killer features over the other.
Jersey defines URL mappings in annotations, Play defines them in a service wide route file. And they bundle or have varying quality of integration with different libraries for things like XML, JSON, database, testing, mocking, dependency injection libraries and app server deployment.
The Java world has JMS, Spring, JUnit, jdbi/hibernate/jpa, Jetty/Grizzly. The Scala world has Akka, specs2/ScalaTest, Anorm/slick. Jersey is a better fit for the first world, Scala for the second. You can definitely cross that, but it will be a little less elegant and might require more glue coding.
JAX-RS is a standard and implementations can be created by different vendors. Jersey is one such implementation. The other frameworks may make use of JAX-RS but are not standards. So it is not a one-to-one comparison.
I have never heard of Play before but it does look interesting, more akin to Rails and Django than Jersey. What I like about Jersey is that it can be integrated into existing Java web applications by simply adding the JARs and declaring some things in the web.xml. What I find confusing about Jersey and JAX-RS is the routing.
Play seems to make routing easier, however, correct me if I'm wrong, seems like it is an all-or-nothing framework and cannot be used alongside other servlets in the same web application.