I spent the last three days at a training about the EJB3 standard. It was very interesting but, while it's way beyond the troublesome tech that was EJB2, I still have my reservations about it.
Here's my problem: you have a layer of entity beans, which are persistent versions of your business objects. Then you have a layer of session beans which provide services to the outside world which allow you to manipulate the entity beans according to your business processes. For that outside world the safest strategy is to treat the objects as pure data; as structs rather than objects. The overall effect is that you're really programming in a procedural way. In Java. Yeah.
Now you may point your finger in the direction of the JEE standard. But actually I put the problem with the embedding in Java (or any OO language). That's because I think that a procedural approach with a separation of data and services is a much better fit in enterprise settings. Service oriented architectures really are a smart way of setting up such environments.
So, assuming you're in agreement with me (which I won't take as a given), you might come to the following question: wouldn't it be smarter to define an enterprise platform on a language which is a better fit to the services+data architecture, rather than trying to fit it into an OO language and then having to deal with the mismatch ?
Might this be another reason why Cobol was (and still is) such a success ? That it was designed for a business environment, and actually fit very well ? I quite understand why companies might want to stay with Cobol (and I know that some still do), but Cobol no longer fits the current enterprise reality: web applications with high availability, integration with relational databases, distributed systems, clustering, load balancing, and integration in heterogeneous environments.
So let's say we wanted to start with the right language (and it's not Cobol), what would it need to be ? What should it have ? Well, here is my list:
- No objects but structs. That is, your data is just that: data. Easy mapping to and from a relational database is essential.
- A procedural language for manipulating the data. I'm wondering if we could even go with a purely functional language, which would be ideal in a distributed environment. I think this should be possible and, if so, would be preferential.
- Dispatching on argument types (multi-methods), because polymorphism is a very good idea. Let's stay away from if-elsif-elsif-elsif-etc hell. This means that our data should be typed, and that we need some sort of type system.
- A module system for grouping functionality in logical units. Not to be mixed with objects/classes! We want reuse of components and services, not just of their code.
- A meta-programming system. Because a lot of interesting and important stuff becomes much easier that way: logging, security, transactions, etc. This stuff should get generated as much as possible from meta-code.
- Lambda's, closures and higher order functions ? These are nice in event systems and for callbacks. Not sure how essential this is...
- No support for the presentation tier. Because that's where OO and other paradigms actually are a natural fit.
Given the above I'm pretty sure you could define a superior enterprise platform. So anyone know a language which fits ? Or perhaps has some observations on the wish-list ? Let me know.