I've been reading/learning more about Spring lately, and how one would use Spring in combination with other open-source tools like Tomcat and Hibernate. I'm evaluating whether or not Spring MVC could be a possible replacement technology for the project I work on, which uses WebLogic and a LOT of custom-rolled Java EE code. The thing is, I've always suspected that our solution is over-engineered and WAY more complex than it needs to be. Amazingly, it's 2009, and yet, we're writing our own transaction-handling and thread-pooling classes. And it's not like we're Amazon, eBay, or Google, if you know what I mean. Thus, I'm investigating a "simpler is better" option.
So here's my question: I'd like to hear opinions on how you make the decision that a full-blown Java EE application server is necessary, or not. How do you "measure" the size/load/demand on a Java EE app? Number of concurrent users? Total daily transactions? How "heavy" does an app need to get before you throw up your hands in surrender and say, "OK, Tomcat just isn't cutting it, we need JBoss/WebLogic/WebSphere"?
I don't think that the decision to use a full-fledged Java EE server or not should be based on number of users or transactions. Rather it should be based on whether you need the functionality.
In my current project we're actually moving away from JBoss to vanilla Tomcat because we realized we weren't using any of the Java EE functionality beyond basic servlets anyway. We are, however, using Spring. Between Spring's basic object management, transaction handling and JDBC capabilities, we aren't seeing a compelling need for EJB. We currently use Struts 2 rather than Spring's MVC, but I've heard great things about that. At any rate, Spring integrates well with a number of Java web frameworks.
Spring does not attempt to replace certain advanced parts of the JavaEE spec, such as JMS and JTA. Instead, it builds on those, making them consistent with the "Spring way", and generally making them easier to use.
If your application requires the power of the likes of JMS and JTA, then you can easily use them via Spring. Not a problem with that.
Google open sources a lot of their code. If you're writing low-level things yourself, instead of implementing code that's already written, you're often overthinking the problem.
Back to the actual question, Walmart.com, etrade.com, The Weather Channel and quite a few others just use Tomcat. Marketing and sales guys from IBM would have you believe different, perhaps, but there's no upper limit on Tomcat.
Except for EJB, I'm not sure what Tomcat is missing, and I'm not a fan of EJB.
What tomcat does not offer apart from the more exotic elements of Java EE is session beans (aka EJBs). Session beans allow you to isolate your processing efficiently. So you could have one box for the front end, another for the session beans (business logic) and another for the database.
You would want to do this for at least 2 reasons:
Performance; You're finding that one box to handle everything is loading the box too much. Separating the different layers onto different boxes would allow you to scale out. Session beans are also able to load balance at a more fine grained level. Tomcat and other web services of that ilk don't have clustering out of the box.
Flexibility; Now that you've moved your business logic into its own environment you could develop an alternate front end which used the same layer, but say, was a thick client front end for example. Or maybe other contexts would like to make use of the session beans.
Though I should probably point out that if you use web services to communicate with that middle tier, it could also be on tomcat!
The only reason to use a full blown Java EE server is if you need distributed XA transactions, if you don't need XA transactions then you can use Spring + JPA + Tomcat + Bean Validation + JSTL + EL + JSP + Java Mail.
Also a Java EE server is supposed to implement JMS but it does not make sense to run the JMS server in the same VM as the rest of the app server so if you need JMS you should have a separate JMS server.
I strongly disagree with all answers given here.
Everything can be added to Tomcat, including EJB, CDI, JTA, Bean Validation, JAX-RS, etc.
The question is: do you want this? Do you want to assemble all those dependencies in the right versions and test that it all works together, when others have already done this?
Let's be clear: nobody uses only Tomcat! Everyone always adds a web framework, an ioc container, an orm, a transaction manager, web services, etc etc
Lightweight Java EE servers like TomEE already include all of that and makes the full stack experience of having all those things integrated so much better.
Maybe this can be of interest:
http://onjava.com/onjava/2006/02/08/j2ee-without-application-server.html
HTH
Related
We have been building two suites of applications for the last 10 years using Spring as our dependency injection. We also use spring-batch and spring-amqp. We are now looking to move to OSGI so that our monolithic applications can be separated into bundles so that we can be more agile. The two suites are web applications and are deployed as two separate war files. We are looking to use Apache Karaf as our OSGI runtime.
Spring-DM is dead and it appears that we are going to have to convert EVERYTHING to use Blueprint for our dependency injection.
My question is how do we do this incrementally? It will be close to impossible to convert all of this over at once. It seems like one bundle should still be able to use Spring DI and have it's own application context as long as we take the responsibility to expose any services that we want to the service registry in the bundle activator, but I'm not sure if there is some kind of magic that we would lose like transaction management.
Any guidance on this would be really appreciated.
You might want to consider to make the problem appear even larger and switch to DS instead of Blueprint ... To take truly advantage of the OSGi model, DS is far superior to Blueprint in all aspects. In reality, after the first hurdle, you'll make much more progress and your gains will be higher. Though Blueprint made Spring available on OSGi, it never 'got' OSGi.
For strategy, keep your Spring app alive as a single bundle and move things out gradually. I.e. the elephant approach.
The biggest gain that OSGi provides can be summarized as follows:
Make sure modules have service APIs that ONLY handle collaboration. I.e. each service API should be a story/scenario how the actors work together, not how they come into existence and are configured.
Let Configuration Admin to the configuration work. I.e. never expose configuration APIs. In OSGi, you register instances, not things that still need to be configured.
Make sure you really understand the OSGi model with services. You might want to take a look at OSGi enRoute that leverages OSGi to the hilt.
I propose you take a look at the blueprint-maven-plugin. It allows to use a subset of CDI and JEE annoations to define injections as well as transactions and persistence. The plugin creates blueprint xml at build time which can then be executed by karaf. The big advantage is that these annotations are also supported by spring. So you can transition and in parallel release to production using spring.
I have a complete example here Annotation based blueprint and JPA.
Using this plugin I migrated a medium sized project while it was developed and released in parallel. If you need further advice while using the plugin I can surely help.
When people mention that Spring is a lightweight containter compared to other frameworks, do they mean? That it occupies less memory in the system or it does not have the operations like start stop that we have for EJB containers and it doesn't use a special container?
What makes Spring a lightweight container?
Whether it is "lightweight" or "heavyweight", it is all about comparison. We consider Spring to be lightweight when we are comparing to normal J2EE container. It is lightweight in the sense of extra memory footprint for the facilities provided (e.g. Transaction Control, Life Cycle, Component dependency management)
However, there are sometimes other criteria to compare for the "weight" of a container, e.g. intrusiveness in design and implementation; facilities provided etc.
Ironically, Spring is sometimes treated as heavy weight container when compared to other POJO-based container, like Guice and Plexus.
Spring calls itself 'lightweight' because you don't need all of Spring to use part of it. For example, you can use Spring JDBC without Spring MVC.
Spring provides various modules for different purposes; you can just inject dependencies according to your required module. That is, you don't need to download or inject all dependencies or all JARs to use a particular module.
If you want to run a Java EE application, you can't just create a small application that will run on its own. You will need a Java EE application server to run your application, such as Glassfish, WebLogic or WebSphere. Most application servers are big and complex pieces of software, that are not trivial to install or configure.
You don't need such a thing with Spring. You can use Spring dependency injection, for example, in any small, standalone program.
I think "lightweight" is mostly a buzz-word. It's meaning is highly subjective and based on context. It can mean "low memory footprint", it can be low execution overhead, low start-up overhead. People also use it to differentiate between some perceived level of complexity and/or learning-curve. In any case, it's assuredly relative as there is no defined point on any scale where "light" becomes "heavy" in terms of "weight".
I personally think it's a dangerous word since it has no real, quantifiable meaning. It's something people throw into architecture proposals to beef up the "pro" section of a certain framework they want to use anyway. If you see or hear it being used in any such situation, it's a perfect opportunity to ask "what does that mean?". If you get an angry or frustrated response (combined with rolling of eyes and shaking of head), it means that the person has decided on a certain architecture, but hasn't managed to formulate coherent or objective reasons for it.
EDIT: not sure I would categorize spring as a "container" either, but that's a similar apples and oranges discussion. I'd call it a framework.
Spring is light weight becouse other J2ee container especially EJB2.1 require more configuration, It can have lot of do nothing code to ,it have complex directory structure for packing applications, overall it took extra memory;on other hand spring minimizes all this things.so it light weight.
I think one can also say that spring is light weight because it uses POJO(Plain old java object) .POJO class does not require to implement,extends technologies specific API(Interfaces,Classes) or it is not bounded to any technology specific API
I am currently working on an enterprise application that is deployed to GlassFish. I am attempting to figure out the right way to communicate to a cassandra backend from within an EJB that has been deployed to GlassFish 3.1. I would prefere to use Pelops to talk to Cassandra.
Disclaimer: I am new to Java EE and the concepts behind enterprise app servers and EJBs; one of the purposes of this project is to learn these topics. This is out of scope of this question as I am really just looking to be pointed in the right direction for best practices or where I should go to find best practices; so far google has not been very helpful/consistent on this topic.
More specifically, should I be thinking about writing a JCA connector for cassandra? Using a singleton EJB that talks to cassandra via Pelops? Just use pelops directly in my EJBs? (though I thought your not supposed to create socket connections in ejbs) Something else entirely?
The EJB spec prohibits EJBs from opening server sockets, but not sockets. However, it does also prohibit EJBs from creating threads. Does Pelops (or Hector) create threads to handle its pooling?
The letter of the law aside, since both those libraries do pooling, they definitely feel like something that belongs in the resource adapter layer to me. I would be nervous about EJBs, whose lifecycle is controlled by the container, and is potentially quite short, hanging on to a resource like a connection pool whose lifecycle is somewhat independent, and should be longer.
That said, most implementations of EJB are quite forgiving, so whether the use of Pelops/Hector directly from EJBs is architecturally right or not, it is very likely that it will work.
If i had all the time in the world, i would write a resource adapter wrapping one or the other of those libraries. However, that would be a considerable investment of resources in pursuit of a negligible practical return.
we are developing a similar application where I work now, even if we do not implement EJB, we deploy a backend to Glassfish 3.1 and internally we have created a small library that talks to Cassandra.
Right now the most used library for connecting and working with Cassandra is Hector:
https://github.com/rantav/hector
It is very actively developed. I have never seen it in use inside an EJB, but I used it and it is very solid. Do not how Pelops is developed though.
What we have developed here is a very custom application tailored to our needs, that is why we didn't use Hector in the first place.
As long as you use client sockets in EJB, you should be safe, the restriction on EJB is for server socket that should be handled by the app server. But if you have other needs, you should write your JCA.
I'm learning Java EE 6. I've seen how much progress it has achieved in this release of the umbrella specification. EJBs 3.1 are far easier and more lightweight than previous versions, and CDI is amazing.
I'm not familiar with Spring, but I often read that it offered some neat features that the Java EE stack didn't. Yet I also read now that Java EE has caught up, and can now fully compete with Spring.
I know that choosing from both depends on many factors, but if we only focus on features, say the latest trends etc. Which one has the leading edge? Can Spring 3 offer some assets The Java EE 6 stack can't?
Also, what about Seam framework? From what I read it's like Java EE 6 but with some additions?
Over time, JavaEE indeed caught up in terms of features.
But one factor, that I've stumbled upon many times, is the main reason I've been preferring spring for a long time - JavaEE servers and implementations are buggy and developer-unfriendly. This may sound like a rant, but even the best of JavaEE 6 - CDI (Weld impl) has cryptic exception messages and is giving developers a hard time (see here). Not to mention application servers - full of really ugly bugs (I managed to find around 5 bugs for 3 hours working with JBoss 5)
Another thing that makes spring more attractive for me is that features can be added in small timeframes. As I noted in my comment, unified cache abstraction, and conversation handling will be added in the next release of spring, which is a couple of months after the previous version. In JavaEE you'd have to wait a lot of time (for a standard solution at least)
But it's not that black with JavaEE. Many of the problems have workarounds or get fixed in a timely manner. And ultimately, it's a matter of personal preference.
By the way, spring's portfolio was filled with side-projects in the meantime, which add a lot of specific features/features sets. Note that many of them can be used with JavaEE as well, but are designed to fit perfectly with spring:
spring security - declarative security
spring roo - a tool for quick bootstrapping projects
spring web flow - framework ontop of MVC to handle wizard-likes journeyes
spring data - still new, aimed at unifying access to NoSQL stores
spring mobile - bringing spring to mobile platforms
spring social - a set of tools for interacting with social networks
This is just extras, and JavaEE also has extras, but they are more general-purpose (as far as I see the picture), apart from Seam, which is specifically targeted at providing what CDI misses.
One very important note to conclude with. Comparing spring to JavaEE is incorrect. I'd prefer to compare Spring to CDI+EJB+Application server. The rest of JavaEE can be used together with spring, and it often is. JAX-WS, JAXB, even JSF fit nicely with spring and are often used.
What are the advantages/disadvantages of Seam over Spring? Why would I use Seam in lieu of Spring?
Is there anything that can be done in Seam that can't be done in Spring? Anything in Spring that can't be done in Seam?
What about stateful/stateless architecture? I am a Spring user, so I am biased, naturally.
Why Spring?
Cleaner code
Streamlined application configuration
Nice integration with popular open source products
First class AOP support
Enterprise-scale security: Acegi
Highly flexible MVC
Abstracted data access (JDBC is OK)
Enterprise Java without EJB
Testing is easy
Why Seam?
Merge Java EE 5 standards (EJB 3.0, JPA, JSF, Annotation) seamlessly
Stateful by design
Bijection
Integrated Ajax (ICEfaces and Ajax4JSF)
Business process integration (jBPM)
Business rules integration (Drools)
Workspace management
Deliver complete stack (from JBoss & RedHat)
Seam Text and EL enhancements
Probably will be a standard (JSR-299: Web Beans)
From Framework Deathmatch: Spring vs Seam. Thomas Wiradikusuma (Spring). Joshua Jackson (Seam). Java User Group Indonesia. JaMU 07.03. March 17, 2007 power point presentation here
although seam does have many advantages over spring, there is a magic word that really is worth paying attention to and this is PERFORMANCE!!! if you are not worried about performance issues I would go with seam. From the other hand if you want your application to be as fast as possible and your hardware is limited I would use spring. I am not saying that you can not develop fast applications with seam, but in order to do this you really need to know what you are doing. I have used both of them (i am not a guru in any of them) and what I found out is that although spring needs more effort to build what you want, at the end the result is more flexible and is performing better. I do not think that there is something that can be done in one framework that it can not be done in the other, saying that, remember that I am not an expert to any of those.
Seam will give you a pretty, ah, seamless, integration between the components that make up the seam stack. All very nice as long you keep within that stack, and within the seam model and foing things. It all starts to look a little less convincing as soon as you start doing something unusual, though.
If it's not too much of a generalisation, Seam is very "microsofty" in that regard. This isn't a bad thing, it's just a stylistic thing. Spring is more open-ended and takes more effort to get going, but it's ultimately more flexible, and a lot more open.
You can use Spring and Seam together - Spring for backend components, Seam for enhancement of web layer (JSF/GWT/Wicket) and other stuff. Seam offers a lot of Spring functionality (i.e. IoC container, transaction managment) - in your project you can decide - witch implementation to use.
More details on integrating Seam with Spring - "Seam in Action - free bonus chapter"
Let's compare the two.
What is common?
Both are open source, follow MVC architecture and has a servlet based front controller.
Advantages of Spring MVC
Extension of Struts.
View can be developed using JSP and HTML. You can also plugin other's like PHP or velocity.
Has large number of controllers predefined.
Integrated out of the box with Spring framework.
Advantages of Seam
Extension of JSF
View can be developed using JSF component library. There are large number of vendors to choose from.
Integrates JPA entities with Web layer
Annotation based validation
Integrates with EJB 3.0
Out the box jBPM support which provides process flow definitions.
Integrates with Drools where you can define web layer business rules.
Good community support.
Conclusion
Since Seam is built on JSF, it has large number of UI Component libraries to pick from. It reuses Java EE stack better. It has lot of interesting modules integrated beforehand.
Spring MVC is built on top of Struts and Spring, so it will reuse Spring framework stack far better than others. But the view is built using JSP, so we have to rely on JSP tag library vendors to build rich components.
Seam framework would be a better choice as Spring framework is anyway extensible enough to be leveraged by Seam.