Impossible to create products in JEE

It is impossible to create products in JEE.

First, JEE is not about creating off the shelf products, but about delivering integration solutions (hence the "Enterprise" in its name).

Second, JEE is not portable across vendors. If you build it for WebLogic, you can't deploy in WebSphere and viceversa.

Third, with all the mergers and aquisitions, there will always be plenty of room for JEE developers, since all those disparate propietary systems will need integration. And even in the case of the JEE vendors integration is not something to take for granted, but it is usually harder because of all the APIs and the descriptors needed.

Spring is like fresh air to this respect. It is far easier to integrate Spring services than to integrate JEE vendors. Spring and Hibernate are so simple that the JEE 5 (incuding EJB 3) was modelled after them.

Fourth, web services are a mess. There are many standards and they do not interoperate. They introduce more trouble than they solve, but that is good. Companies and developers will move away from web services and therefore only the developers that really understand the technology will remain using it, until it becomes simpler for other people to use. usually this means they will find and embrace the right abstractions, and then coding monkeys will be able to leverage from there.

There is a very strong need in the market for an abstraction layer that will permit different application servers to work together. But the right abstraction must first be found. It is not like developers are not trying to find it (granted: 80% of the developers are simply drones and couldn't possibly think of creating abstractions themselves, although they are using abstractions all the time), nor it is that they can't come up with a good abstraction because they lack a brain. Maybe they lack the ability to decide what a good abstraction is, or in other words, the criteria for deciding if an abstraction is ok or not. The real problem, as in the case of most software development efforts, is finding the correct requirements.

Usually developers settle for the wrong abstraction and for the incorrect requirements. It is as if they knew they had a hammer and everything looked like a nail. This problem with this reasoning is that it conduces to wasted time and money. And wasted money is no problem, because if you loose some money you can always recover it, but if you loose time, you can't get it back.

The Right Requirements for a JEE abstraction layer

In order to understand how to create an abstraction layer for X, you first need to understand X. No secrets here. But you don't need to understand X mechanisms, but how X relates with its environment. In other words, you need to model interactions of X with its surrounding environment.

Most frameworks already have an abstraction that they present to you. Like it or not, the present an abstraction. Sometimes they try to force an abstraction on you, the programmer. Other times they try not to enforce an abstraction, but a completely transparent code where you can modify everything underneath and have direct access to the internals.

Most of the time the abstraction is lacking, other times the abstraction is there simply is no abstractions and you can modify everything.

And sometimes, as with TCP/IP, the abstraction is great and you can do wonders with it. Even if you don't like TCP because it is too high level, you can use UDP which is IP and very thin layer on top.

In other words, you don't need to worry that you are going to obscure the underlying mechanisms, because they can always go back to UDP mode, but guess what?... TCP is 99% of the time good enough as an abstraction layer.