Java EE 6 and enterprise applications — why we bet on standards

When our company was founded three years ago, we faced a fundamental decision: which technology platform to build on. We considered .NET, PHP frameworks and the then-popular Ruby on Rails. We ultimately chose Java EE — and today, after dozens of successful projects, we know it was the right decision. Here’s why.

Why Java EE and not Spring?¶

This is probably the question we get most often from colleagues in the industry. Spring Framework is an excellent tool and certainly has its place. But for our clients — mostly large companies with requirements for long-term maintenance and certifications — a standardized platform is simply a safer bet.

Java EE 6 brought a fundamental change compared to previous versions. Remember those enormous XML descriptors in J2EE 1.4? Entity beans that nobody wanted to use? That’s gone. Today’s Java EE is surprisingly simple — annotations instead of XML, CDI for dependency injection, JPA 2.0 for persistence.

EJB 3.1 — finally usable¶

Enterprise JavaBeans had a bad reputation for a long time. Justifiably — in the J2EE era it was an over-engineered mess. But EJB 3.1 is a completely different story. A simple POJO with a few annotations, automatic transaction management, timer service, asynchronous processing. And most importantly — No-Interface View, so you don’t even need to write an interface if you don’t need one.

On our last project for a Czech bank (I can’t name them, NDA), we built an entire transaction system on EJB 3.1. It processes thousands of transactions per minute, runs on a cluster of two GlassFish servers and over the past year we haven’t had a single outage. Try that with PHP.

JPA 2.0 and Oracle Database¶

Our typical stack is JPA 2.0 (EclipseLink implementation) over Oracle Database 11g. I know what you’re thinking — Oracle is expensive. And you’re right. But when your client has an Oracle license and a DBA team that has been managing it for twenty years, there’s no point pushing PostgreSQL at them just because it’s free.

JPA 2.0 gives us a beautiful abstraction over the database. The Criteria API is more verbose than JPQL, but type-safe queries are worth the extra code. And with Oracle-specific optimizations (partitioning, materialized views) we achieve performance that would cost us much more effort with an ORM framework over MySQL.

Application servers — GlassFish vs. JBoss¶

At the moment we mostly use GlassFish 3.1, the reference implementation of Java EE 6. It’s the logical choice — Oracle stands behind it, documentation is excellent, and if you hit a bug you can be sure it’s a specification issue, not an implementation problem.

JBoss AS 7 is an interesting alternative though. We tried it on an internal project and it starts orders of magnitude faster than GlassFish. For clients who prefer the Red Hat stack (and have an RHEL subscription), it’s the obvious choice. Migration between servers is relatively painless thanks to the standards — usually just adjusting the datasource configuration and a few vendor-specific things.

SOA — buzzword or reality?¶

Service-Oriented Architecture is a term that has been thrown around in enterprise IT for the last ten years. And honestly — many projects merely reference SOA but in reality have a monolithic architecture with a few SOAP web services bolted on top.

We try to do SOA properly. That means clearly defined services with a WSDL contract, an ESB (we use Oracle Service Bus) as the mediation layer and a governance process for managing services. It’s more work upfront, but a client with 50+ systems needs order in their integrations.

SOAP web services remain the standard in the enterprise world. I know that in the startup community people talk about RESTful APIs and JSON — and yes, for simple scenarios REST is simpler. But try defining a transactional contract with WS-Security and WS-ReliableMessaging in REST. SOAP still has its place in enterprise.

Deployment and operations¶

Our stack here is straightforward: RHEL on servers, Oracle DB, GlassFish (or JBoss), Apache HTTP as a reverse proxy. Monitoring via Nagios, deployment via script over SSH. No magic, proven practice.

Continuous Integration we currently handle via Hudson (yes, I know it’s called Jenkins now). Every commit triggers a build, unit tests and deployment to a test server. It’s nothing bleeding edge, but it works reliably and our clients — who typically have monthly release cycles — don’t need more.

What’s ahead¶

Java EE 7 is in preparation and looks promising. WebSocket support, JSON processing API, Batch API — these are things we currently lack and are solving with proprietary libraries. We’re most looking forward to JPA 2.1 with stored procedure support and Criteria API improvements.

Cloud computing is a topic we are monitoring, but we don’t yet see it as a realistic option for our clients. Regulation in the banking sector, data residency requirements and security audits — all of this still argues for on-premise solutions. But the situation will certainly evolve.

Conclusion¶

Java EE 6 is a mature, standardized platform for enterprise development. It’s not the sexiest technology — you won’t get upvotes on Hacker News for it. But if you’re building a system that needs to run for five years in a bank or insurance company, it’s the platform you can rely on. And that’s exactly what our clients need.