I'm developing java enterprise web application using EJB 3.1 and I wonder which technology to use on which MVC layer. I have ear, ejb(jar) and war projects.
Is it possible to use something other as persistence layer then JPA implementations (e.g. myBatis) and how? I would like to manage some more difficult queries on my own.
What framework to use in web project (war) except JSF or plain servlets?
I'm familiar with Spring, would it be possible to use Spring in web (war) projects and benefit from its controllers?
Can you explain which technologies are used to develop enterprise web applications?
Thanks.
The best combination would be to use what's already there. JSF 2.0 is already one of the best MVC frameworks, so it would often be a first choice anyway.
When using EJB 3.1, this is almost always in combination with a Java EE implementation, so in that case JSF is already there and simply using it is a no-brainer.
The different technologies in the Java EE stack are made to work with each other, so a typical stack consisting of JSF + CDI + EJB + JPA is the most ideal combination and you'll find the most support for this.
I personally don't think there's any place for Spring in an EJB/CDI stack. Those two technologies are direct competitors that solve the same problem in (slightly) different ways. Combining them will most likely only complicate your code.
For a starter like you, stick with what comes out of the box with Java EE 5/6. So in your case JSF+Facelets, EJB 3.1 and JPA.
I suggest you to read the below books and in the order given
Beginning Java™ EE 6 Platform with GlassFish™ 3
Real World Java EE Patterns Rethinking Best Practices
Related
Suppose I have to create a shopping cart website, it should accept lot of requests and process their request without any performance issue. Which method I can use EJB Enterprise application or Spring MVC framework..?
I don't think the two are mutually exclusive. Here is a good discussion on coderanch that really helped me.
http://www.coderanch.com/t/317507/EJB-JEE/java/EJB-MVC-pattern
Hope this helps.
The well asked question IMHO would be Spring MVC vs JSF as the view part of the Java EE stack is currently JSF.
IMHO both are server centric (pages are built on server side) and quite obsolete now, I would personally go on a server part exposing a rest API consumed by a html5/javascript client.
Both Spring and Java EE stacks are well suited for building rest services (Using Jax-RS for Java EE or one of theses approaches for Spring).
I would personally go with the Java EE stack as I prefer by far CDI to spring DI anyway just keep in mind that Java EE is the standard way but spring probably evolve faster.
Have a look to this before choosing.
This came as an interview question.
The interviewer asked me if you can use spring for all the purposes and get away without using any of the Java EE framework .
I said yes, but he asked me how about if the application is distributed and what is the point of application servers.
I am not sure about the answer.
Does Spring do everything that the Java EE framework does?
Well, Spring is wide. So you can review point by point. I'm not specialist in Java EE but I'm sure Spring can cover a lot (if not all) of Java EE concerns. And I'm pretty sure Spring can handle most of layers/concerns in an application.
First of all, Spring IOC. You can configure an object graph with Spring IOC. It helps at any layer configuring all the components you need to implement a layer.
Spring-MVC-Web: you can configure an MVC web component in order to handle and serve all web application requests. I think you can make something cool with it. Configure web responses and its necesary configuration with other business elements (including IPC - Inter Process Comunication).
Spring Security is heritage from Acegi. It's a web framework for defining role-defined access to web resources.
I'm not sure if Hessian is Spring's too. Anyway it's lightweight and it helps comunicating with components in other processes à la RMI.
Well... I'm not sure about persistence, but I thing Spring has templates for JDBC, Hibernate, and all, so it can help anyway (as suggestions indicate: JmsTemplate and RestTemplate are available for communication with other business components!).
The core thinking here is: you can make an app from scratch, so in all cases, Spring can provide a framework to ease the difficult/repetitive tasks on every layer. Does Spring does it? Yes.
Please check other features to see if Spring has something for it. I'd bet it.
Deep down, Java EE is a set of specifications (some of which have been contributed by Spring team!)
Spring's mission statement is to 'Simplify Java Development'
It does so using the following techniques:
POJO -> facilitates easy testing
DI -> promotes loose coupling
AOP -> promotes separation of concerns, maintainability etc
Templates -> provides a standard programming model which does the heavy lifting for you
Spring and Java EE do not have a "Vs" relationship.
Using the above techniques, the Spring Framework lets you build (Java EE) standards-based applications more efficiently.
>Does spring do everything that the Java EE framework does ?
Based on what I've said above, the question might be rephrased as 'Does Spring have support/implementations for all the technologies that comprise the Java EE specification?' -
Nope, but it does do what it set out to do and that is simplify development on most Java EE technologies.
That said, the trade-off for this simplification of Java development is that you need to now have significant amount of knowledge (of the Spring Framework) at your fingertips... (comes with practice and google :) )
>Can't we use Spring for distributed java applications?
Sure you can. Spring has a whole lot of Exporters/FactoryBeans and Clients(Templates) for most conceivable use cases.
Yes Spring can be used in a distributed application without Java EE. We have used it to send messages to MQ and update a database both within one XA transactions.
According to this article, Spring can definitely be used on its own in a distributed application.
http://www.wrox.com/WileyCDA/Section/Why-Use-the-Spring-Framework-.id-130098.html
http://www.artima.com/forums/flat.jsp?forum=276&thread=204508
Historically, (5 years ago?) Spring was weak in the distributed applications area, in particular database clustering. That is no longer a concern. I would say that Spring is going even further for distributed computing these days as they are vigorously pursuing cloud technologies which Java EE hasn't approached yet.
In my view the main benefit of Spring was that it did away with some of the more heavyweight components of the Java EE framework (Entity Beans, session beans) and replacing them with a lightweight alternative.
On of the main benefits of Spring as I see it, is that it decouples a lot of components and then uses XML or Annotations of wiring them together. That makes it easy to write Unit Tests (by injecting mock components instead of real ones), which wasn't something easily done when using heavyweight Java EE components (couldn't easily unit test EJB 2.1 Entity Beans).
A lot of Spring concepts have since gone into the Java EE standards, so I would argue that Java EE is no longer a heavyweight option, and Spring works will with Java EE components such as application server managed connection pools (via JNDI), transaction managers, queue managers that can very easily be managed using an application server which can provide additional functionality such as clustering, failover, load-balancing, serving web resources...
Having said that, the people behind Spring (VMWare) have their own application server (tcServer) which is based on Apache Tomcat and provides a lot of the glue used by spring, but is not considered as "heavy" as some of the traditional Application servers (Websphere, Weblogic).
I don't think so. Basically Spring is about integration between Java EE frameworks.
Use spring inegration framwork for this .
Use can uss Akka framwork for managing distributed applications with spring integration .
Akka uses the Actor Model together with Software Transactional Memory to raise the abstraction level and provide a better platform to build correct concurrent and scalable applications.
Take a look at the step by step tutorial that gives more information about how to build a distributed application using Akka framework.
In general, distributed applications are built in Java using Java-RMI that internally uses Java's inbuilt serialization to pass the objects between the nodes.
I heard that the core product of Java EE is EJB 3.x? Is that true ?
The Java EE specification was intended to specify how vendors would support transactional, distributed components that were called Enterprise Java Beans. The "Enterprise" distinguished them from POJOs, because they were intended to run in a separate application server that would handle all the issues around life cycle, threading, and services.
There are a lot of pieces in the Java EE toolkit: servlets, JSPs, Enterprise Java Beans, services such as messaging, naming, pooling, etc., relational database access, connectors to resources such as mainframes, and more.
Picking something as "core" would be like picking a "favorite" child. Better to consider them as a whole.
UPDATE: If you don't use entity EJBs, you don't need persistence or JDBC. You can write stateless session beans and be perfectly happy.
If you don't use an HTTP client, you don't need servlets or JSPs.
You don't use what you don't need.
The core product of J2EE is their containers.
Sorry, when I look at the Java EE 6 specifications page, I see dozens of technologies. EJB 3.x is one of them, but there are many others:
What are the primary reasons for using the Java EE (EJBs) over just a simple Servlet implementation?
I am working on developing a new project that will primarily be a web service that must be very fast and scalable.
Sorry for any confusion, Although I am experienced in Java, I am very new to the Java Web world, and may not be asking this question well.
Servlets are HTTP request listeners; they can't respond to anything else.
If you embed a great deal of logic in servlets it won't be available to any other clients.
Write your app in POJOs. Get it thoroughly tested without an app server involved. Then worry about how you'd like to package and deploy it. Servlet? EJB? Web service? Something else? No problem - those are just packaging and deployment issues. Get the behavior that you want working properly in POJOs first.
Spring can give you a lot of options here. I'd recommend it.
EJB's specification 1.x and 2.x added complexity that for most webapps was not needed.
Due this complexities the new frameworks appeared to simplify the development and the runtime architecture ( Hibernate / Spring / other microcontainers / others ORM frameworks ) .
EJB's 3.x matches this changes ( through JDO and JPA ) and now, using Servlets with these enhanced frameworks or Java EE with EJB 3 + would give you basically the same results.
Using a Java EE Application Server would add you a number of administrative advantages ( GUI to manage pools, logs, monitoring, transactions etc. ) With out them you may have the same result but you would have to do it all by hand ( editing configuration files that is ) Which may not seem too problematic, but if you plan to have an administrator for your webapp It would be better to use the admin tools that come out of the box with this servers.
Is the web service stateless? If so, I don't see any real advantage in using a full blown Java EE server over something lightweight like Tomcat or Jetty. You can deploy a jax-ws implementation with either of those, and do what you need pretty easily. If there's some kind of state involved, and you end up wanting to share that across multiple machines, that is where having Java EE can come in handy.
With that said, I don't think Java EE would decrease performance any at all. The app servers generally take longer to boot, and take more effort to manage, but once they are up and running the performance should be similar.
If your web services are likely to need any degree of "enterprise" features such as per-method security or transactions use EJBs.
With EJB 3 this is not actually very hard at all, a couple of annotations and you're done.
Otherwise simple POJOs behind a servlet are enough.
What’s the equivalent of S#arp architecture(.net) in the java world.
A one stop package that encompasses all the best practices and well identified packages to start a web application project.
If you're looking for a one-stop package that handles ORMs, web framework, presentation etc., then several options exist in the Java world. Two widely used, but very different ones are:
Spring MVC + Hibernate
Grails
You'll find other frameworks such as Tapestry or Struts which are geared towards web applications. I can't advise on these other than to say they (again) are widely used and you probably need to perform more investigation.
All the above will ultimately rest atop the base-level Java Servlet framework, which is probably too low-level for your needs (but worth knowing about).