adopting EE6 and CDI in a corporate enterprise

[asookazian]

I have been elected to the architecture/standards committee here at Intuit.  We are currently using a variety of EE5 app servers (e.g. Glassfish, JBoss, Websphere) and Spring 2.x and Seam 2.x in our development stack.  There is supposedly a movement to standardize towards Spring 2.x or perhaps 3.  Being a devoted follower of JBoss and Seam, I would like to see us standardize with CDI and the rest of the EE6 web profile rather than Spring 2.x or 3.

Is there a list of items that would be useful (technical or non-technical) in proving the merits of adopting EE6 over Spring?

It seems to me that Spring 3 has hand-picked the handful of EE6 JSRs that it finds useful in their application stack, namely Bean Validation, JPA 2.0 and JSF 2.0.  There are a lot of similarities in the EE6 web profile and Spring.

One main advantage that Spring has is that it can run in J2EE 1.4 or JEE 5 servers (or even servlet containers like Tomcat).  With EE6 platform, the enterprise must literally upgrade their EE5 servers, which is a hindrance to adoption (i.e. barrier to entry) IMO for various reasons.

Well, Spring is usually deployed as part of the application, e.g. in WEB-INF/lib. Updating Spring is just a matter of updating an isolated application's libraries, without affecting other applications running on the same server, and without affecting the server itself.

So for example, Spring 3.0 can be deployed on existing WebSphere 6.1/7.0 installations today. Upgrading the server would be a huge and costly affair there - and it's in control of the data center ops team, not in the application development team's hands - whereas upgrading the application's Spring version often doesn't even require a permission by the ops team to begin with (since it by definition only affects that very application anyway, hidden inside its deployment unit black box).

That aside, for WebSphere concretely, there is of course no Java EE 6 version available and won't be any time soon. I think it's fair to say that WebSphere-based data centers won't see Java EE 6 in production before 2012. But not to beat WebSphere here: JBoss 6.0 is at M1 only, and Java EE 6 in the WebLogic world isn't around the corner either. I think it's a pretty big deal that Spring 3.0 can bring such features to the enterprise world today, in production, on existing servers.

http://www.infoq.com/news/2009/12/spring30#view_51491

Also, if EE6 offered a 100% incremental hot deployment solution for any and all components (e.g., EJB 3.1 components as well), then EE6 would have an advantage in terms of dev/test productivity.  I know, it's supposedly a JVM limitation but it would be very nice...

[agori]

One main advantage that Spring has is that it can run in J2EE 1.4 or JEE 5 servers (or even servlet containers like Tomcat).  With EE6 platform, the enterprise must literally upgrade their EE5 servers, which is a hindrance to adoption (i.e. barrier to entry) IMO for various reasons.

I think that Seam3 without EJB, or CDI plus many good extensions could be used in every J2EE AS (Java5 VM) like Spring.
Am I wrong?

[meetoblivion]

I've purposely avoided naming my employer on forums like these (not sure if anyone knows who I work for, I've walked the line a couple of times).  When I joined ~15 months back, I came the realization shortly that no one ever standardized their software platforms.  As a result, I was told that the only Java platform I could deploy on was Tomcat 5.0 (not even Tomcat 5.5) (this was by an admin mind you).  I told my boss it was unacceptable and spent about 4 hours over the next couple of days explaining to him the differences between servlet container and app server, everything you can do with JEE5.  He agreed that upgrading was the way to go.  Before this, we had an ecommerce platform running on Weblogic 6.1 (this has since been upgraded under my leadership to a newer version, the newest that the vendor, now defunct, could support on new hardware, as the old hardware was made while I was in middle school).  We run a portal platform on OC4J 10G R1, this cannot be changed.

Since then, I've secured 6x the hardware for my group, though I am considered by many to be the only java programmer in the organization (we have someone else on the team who's become a java programmer).  I've gotten people to move away from the idea that scripts running the background is the best way to ensure something works correctly and to ensure that making sure that something is clean, easy to use is a good approach.  The typical web application in the organization (before I came in) involves a perl or java servlet running that invokes a C executable, generates a file, and then spits that file out into the browser.  I have surprised some with how clean the UI is on some applications (usually not differing much from the default JSF template that is generated).  Heck, I've gotten approval to start working on deploying an embedded app server on an instore server at each of our locations to provide some apps that have to be up even if corporate is down; we've gotten web apps to run using JSF in a browser on motorola 9090s (our typical handheld app is a telnet application).  I already have commitment for 2 up coming projects to try glassfish v3 and java ee 6 in production.  One thing we have instilled in the business is that they have to take some kind of pain point if they want new features in the software they need to have a bit of downtime.  We've been able to alleviate the donwtime to being very minimal by deploying in dual node environments always, using a load balancer in front (divert traffic from the node that's being upgraded for a while).

As far as a dev/test productivity, I'm not sure how tightly controlled your environment is, but SOX kills us from testing too quickly.  We end up doing a full release (including RPM package and deploy) before QA sees our executables.  In dev, most of our machines aren't fast enough to run an IDE and app server simulataneously, even if it's just tomcat.  Mind you, we still have some environments that haven't been upgraded and are going to be difficult to upgrade (since we have some necessary dependencies on C libraries for certain software) and we're still going to end up with a lot perl and php running, simply because it takes a long time to rewrite certain code bases; especially when they don't require it.  We're still looking for solutions for situations like that.  The moral of the story though; if you never upgrade, you'll still be running tomcat 6 in 8 years from now, and you're going to end up letting your business down.

[gavin.king]

Alberto Gori wrote on Dec 29, 2009 10:40:

One main advantage that Spring has is that it can run in J2EE 1.4 or JEE 5 servers (or even servlet containers like Tomcat).  With EE6 platform, the enterprise must literally upgrade their EE5 servers, which is a hindrance to adoption (i.e. barrier to entry) IMO for various reasons.

I think that Seam3 without EJB, or CDI plus many good extensions could be used in every J2EE AS (Java5 VM) like Spring.
Am I wrong?

We've actually done some good work to get CDI working nicely on Tomcat and Jetty. CDI (and eventually Seam3) on Tomcat might be a nice sweet-spot for some users. Or it might be a nice migration path, especially once we get the Spring/CDI integration PE done.

[asookazian]

Ok so I know in EE6 I can package EJB JARs directly in a WAR, correct?  So what happens if I deploy that into a servlet container like Tomcat, deployment errors most likely b/c there is no EJB container in Tomcat, correct?

Ok, so you're suggesting JavaBeans strictly in a Seam3 app on Tomcat in a WAR?

What happens if I have a Seam 2.x app that has only JavaBeans with Facelets, etc. (i.e. no EJBs) in a WAR.  How will I be able to upgrade that app to a Seam3 app?  I'm assuming all the Seam 2.x annotations like @In will be supported in a Seam3 container?

Btw, when I discussed EE6 in an email, one of our architects commented that JEE6 doesn’t support everything that Spring does and pointed to this article by Adam Bien.

I don't necessarily agree with his statement for a variety of reasons (e.g. does the Spring container support PEs?)

It's just like GKing says, ppl make comments about technology stacks without reading the specs (like me!) or doing some prototyping!

I think Spring3 and EE6 web profile are very similar for the most part...

Anyways, here is my unofficial list thus far:

JEE6 web profile vs. Spring 3
1.     -Spring: not standards-based; introduces vendor lock-in
2.     -Spring: AOP overkill; higher learning curve compared to JEE interceptors
3.     -Spring: excessive XML configs (although this is not as relevant anymore)
4.     Spring: selective adoption of EE6 specs such as Bean Validation, JSF 2.0, JPA 2.0
5.     +EE6: standards-based; no vendor lock-in; multiple implementations of JSRs
6.     +Spring: don’t need to upgrade to EE6 server (JSE5 is required)
7.     Hot incremental deployment for development envmts (e.g. Tapestry 5 and Seam 2.x)?
8.     Lightweight vs. heavyweight (considering the EE6 web profile)
9.     +EE6: Portable extensions in CDI
10.     +Spring: easier to find developers with Spring experience vs. developers with EE6 experience
11.     -Spring: using OSIV, for handling LIEs whereas Seam has a more elegant solution
via SMPC and Hibernate manual flush
12.     -Spring: conversation support via Spring Web Flow but there's also JSF and Spring MVC to confuse you more?
13.     +EE6: profile concept with full and web thus far
14.     ++Spring: don't need to upgrade to EE6 server to use Spring3

Feel free to fix/add and try to be objective....

[asookazian]

John Ament wrote on Dec 29, 2009 11:51:


When I joined ~15 months back, I came the realization shortly that no one ever standardized their software platforms. 

I've seen it happen in a few large shops where it's very difficult to completely standardize, even in one language like Java, due to acquisitions of smaller companies that may be using different platforms/technologies.

So when they decide to standardize, say on EE6 for example, then it's typically moving forward on new projects and possibly refactor older/smaller projects in .NET to JEE, for example.  That's what happened at Cox and I started using Seam there...

But honestly, if you tell management that they will need to upgrade app servers, that's a total disaster as there are support contracts, maintenance issues, purchasing new licenses in some cases, etc.

With Spring3, apparently you can write Spring3 apps that must run on JDK5 (new requirement and thus the impetus for the version 3 apparently) but you can still run them on Tomcat6 or JBoss4.x, for example.  So no app server upgrade is necessarily required unless you're running JDK1.4 or older.  You definitely don't need JBoss6 or Glassfish v3 to run a Spring3 app AFAIK, which is a major advantage in terms of adoption...

[asookazian]

So now I'm wondering if Spring3 uses Servlet 3.0 spec?

In terms of system requirements, Spring 3.0 covers a broad range of environments. For two key characteristics, Spring 3.0 supports Java SE 5 and above and Servlet 2.4 and above, e.g. Tomcat 5.x and 6.x, also retaining compatibility with common enterprise servers such as WebSphere 6.1 and WebLogic 9.2 (which are formally still based on J2EE 1.4). At the same time, we support GlassFish v3 already – adapting to Java EE 6 API level in Spring as well.

http://blog.springsource.com/2009/12/16/spring-framework-3-0-goes-ga/

so it's officially Servlet 2.4 and above?

Because if Servlet 3.0 was required, then wouldn't that force existing Spring 2.x users to upgrade their servlet containers??

Apache Tomcat version 6.0 implements the Servlet 2.5 and JavaServer Pages 2.1 specifications from the Java Community Process, and includes many additional features that make it a useful platform for developing and deploying web applications and web services.

http://tomcat.apache.org/tomcat-6.0-doc/index.html

So apparently, JSR 315 was strategically not included in Spring3 as was JSR 299...

So what is the plan going forward with Spring, will they adopt/include 315 and 299???

[asookazian]

And what about EE7?  Will it be architected more like Spring such that a major app server upgrade is not required in order to use the web profile, for example?

For example, how can I use CDI on its own outside of a EE6 server?  Can I use it in Tomcat 5.5/6?  Apparently, yes.  Are there any known disadvantages (other than not having access to EJB container's services) to running a JSF2/CDI/JPA2 app in a servlet container like Tomcat?