An article from an O'Reilly columnist talking about The Death of EJB As We Know It? Personally I don't think things are that bad.

The principles for building distributed systems, for transaction handling, etc. have been understood for longer than EJB has been around. And they've been difficult for longer than EJB has been around. Some things are just conceptually hard, and it's not possible to make them easy. On the other hand the fact that something that is conceptually hard does not also require that it is difficult to implement. Choosing the correct transaction boundaries for your transactions so as to get the best performance with the fewest deadlocks bearing in mind the business requirements for consistency is difficult. But it shouldn't require procedural code to implement, you should be able to declare what you want. J2EE get's this right. The deployment descriptors make a lot of this stuff declarative, but you still need to know what you're doing, and you probably always will.

I think in many places we're all still programming at too low a level though. I shouldn't have to use procedural code to define the persistent fields for an object, or set up the mapping to and from a persistent data store. I know that there are IDEs out there that do this visually. OptimalJ from Compuware is one of these. You define the model, the patterns to use, etc. and the code is generated for you. My issue with these systems is the vendor lock in and the cost of the tools. I might as well use .NET if I'm going to be tied to one vendor.

I'd like a more open system. Something along the lines of multiple layers of domain specific languages, each generating a more detailed description of the system in the next more detailed language, perhaps in combination with other descriptions of other aspects, till you get to executable code. At each level it would be possible to override the generated code giving you the opportunity to customize at the appropriate level of abstraction. The "compilers" converting the system expressed in one language to a more detailed expression in the next language would also be modifiable, perhaps through templating. I prefer this to the idea of adding annotations to the simple model to express the more complex concepts as I'd like to keep the levels of abstraction separated as far as possible.

Of course ideas are cheap compared to implementations, and as this idea doesn't have an implementation it's not worth a lot at the moment. Also, it rambles too much. Need to tidy up and try to express better what the idea is.