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.
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.
I was wondering if Spring MVC can be used to implement MVC pattern in Java Swing Applications. I've done some study and found Spring MVC to be used for web development.
Is there any way Spring MVC to be used with Swing Applications?
Not really. As you say, Spring MVC (or Spring Web MVC) is primary targeted for web server development and thus have little to do with client side or standalone GUI applications.
That said, nothing prevents you from using ordinary Spring technologies for dependency injection, as a backend in your model, etc. Spring provides abstractions for persistence, remote network communication, transactions, security and so on that might come in handy in many projects.
Additionally, there is the Spring Rich Client Project that was released some years ago, but I do not know its current status.
No, but you may want to take a look at Griffon, which offers a Swing MVC framework base on Spring libraries and the Groovy language, which should be really easy for any Java programmer to pick up.
I've used it quite successfully to build rather large desktop applications for corporate clients.
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.
I am embarking on a new RIA project with Java on the backend. I'm the only developer, and the app is a line-of-business application. My current stack looks like this:
MySQL || Spring(JdbcTemplate for data access) || BlazeDS (remoting) || Flex(Cairngorm)
My question is: what changes can I make to improve productivity? Manually coding SQL, server-side entity objects, client-side value objects and all the Cairngorm stuff is obviously a drag, but I'm not sure what higher-level frameworks to introduce.
What Flex/Java stack has served you well?
Manually coding SQL
Hibernate is an option to cut this out.
One thing that may be of interest is Grails with the available Flex Plugin. It's built on Spring, Hibernate and BlazeDS, so it's all there for you. It was unbelieveably easy to get it remoting stored objects and responding to AMF calls. I was using this and then moved over to a RESTful E4X implementation as I found it a lot easier to debug and tweak as I could inspect the server output in a browser and have tighter control over exactly what I returned to my Flex app (lazy loading problems in collections using BlazeDS were a headache at times).
Here is a quick tutorial showing how easy the whole Grails + Flex Plugin stack is: BlazeDS in Grails
I would seriously reconsider using Cairngorm. In my opinion it's a pretty bloated framework that introduces a lot of abstraction you'll never use. Check out:
http://code.google.com/p/swizframework
http://www.spicefactory.org
Both introduce the concept of dependency-injection into your Flex app.
Also +1 for Hibernate. I would use the standard JPA annotations on a Java class and extend that with Hibernate Annotations as you find you need additional functionality.
Check out springsource.org's new Spring BlazeDS Integration Project
Spring BlazeDS Integration is a new
addition to the Spring portfolio, and
a component of the complete Spring Web
stack. This project's purpose is to
make it easier to build Spring-powered
Rich Internet Applications using Adobe
Flex as the front-end client. It aims
to achieve this purpose by providing
first-class support for using the open
source Adobe BlazeDS project and its
powerful remoting and messaging
facilities in combination with the
familiar Spring programming model.
As alternative to hand-coding sql, aside from hibernate, you might wanna consider JPA/Toplink. And since you are already from a Spring camp, check out Spring ActionScript (formerly known as Prana), it's an IOC framework for Flex. It solves many inherent problems in Cairngorm. Also a good IDE that supports Flex/Actionscript like IntelliJ IDEA 8.
Whats missing between Flex and BlazeDS is, it doesnt have any sort of landing page where you have a listing of all the available services by just typing a url on the browser (similar to webservice endpoint).
You can try GraniteDS. It's an alternative to BlazeDS, with an actionScript generator, Spring integration (an Spring security), and if you use an JPA implementation, help you with the Lazy Initialization (in a transparent way).