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.
Related
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'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
I in the process of designing the server side of a web-based user interface that will be very JavaScript intensive.
I originally thought of going with an MVC solution, but now I am thinking I want to use a REST-based solution such as Jersey or Restlets.
Is this often an one or the other type decision or can they be a combined solution?
Thanks,
Mike
MVC is about how the inner side of your app works.
REST is about how your app "talks" with other apps.
You can combine them.
A lot of modern frameworks actually are MVC based and make implementing REST web services easy: Ruby on Rails, Java Spring Framework with SpringMVC , Django, Backbone.js
One of the best Java frameworks I've seen for building MVC webapps with the ability to support REST is SpringMVC. This blog post outlines the REST capabilities in SpringMVC since version 3.0. I've developed REST services using SpringMVC and Jersey, and they are fairly comparable.
They are patterns / solutions to solve different problems.
REST sanitises & simplifies addressing access to features of a web application, for users, client software, etc.
MVC provides a means to organise your application code, making it easier to maintain.
MVC is an architectural design pattern for the layers of your application.
The folder structure:
Models/YourClassModel.php
Views/Home/HomeView.php
Controllers/Controller.php
index.php
The application style REST is the Representational State Transfer of the application.
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.
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,