logo

Clouds and JEE, or why nothing changed

The more and more I see this idea of paralleling work on multiple nodes.

As obviously, this is nothing new: first they were clusters, then simple distributed applications containers with a load balancer on top of them, and now clouds: distributed servers with a load balancer on top of them. Seen like, that the jump from a distributed JEE container to a cloud is almost non-existent; yes, I get that infrastructure is changed, but this is only on the surface - you still get the same controller/load balancer on top of the actual machines/application servers.

This is why the newest generation of JEE servers are `cloud ready`, whatever that means, and the JEE7 is going to target specifically clouds.

But what it truly means, is that we as developers need to change our programming model, and go back to the basics: no more session storage, and as less as possible processing on the server.

That means that JSF (in whatever incarnation 1 or 2) needs to slowly fade. Replace it by either JS, or GWT (Dart?).

SOAP? I don't think so, you probably meant REST. EJBs? I would think twice if they're not at least EJB 3.1 (read JBoss's CDI or Apache's OpenEJB). Even then I would probably go with Guice. Spring? It's the worst of the trio, but has really good backwards compatibilty - a bet not so safe with EJBs. Simpler is always better, because it allows instant integration and scalability. Do you need an Android native client? REST connectivity is a breeze to add. SOAP or EJB? Not so much.

Being stateless alows you to scale far better, and the deployment of your application - a load balancer with some application containers behind it, or the real-deal cloud - becomes a non-issue.

comments powered by Disqus
Hot Projects

Germanium

The one to rule them all. The browsers that is.

SharpKnight

SharpKnight is an Android chess game.

MagicGroup

MagicGroup is an eclipse plugin.