January 20, 2010

Some thoughts about enterprise platforms

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.


Crimson13 said...

Doesn't Common Lisp qualify for a lot of those points? You have structures, multiple dispatches, lambda functions, closures, macros, etc. Or since you work with the JVM, maybe Clojure?

Kris said...

I'm sure Lisp would fit the bill, or could be made to fit it. That's the strength of Lisp. I'm wondering if there were other choices which are a closer fit.

Also, Lisp scares a lot of people. A somewhat more typical syntax would be a bonus.

PS. I was told by Joram Barrez that jBPM made a switch from an OO-centric structure to a simple services one, and that they and their users were very pleased with the result. So the basic idea behind my post isn't without merit, at least.

Crimson13 said...

Service oriented software is of course one of the hot topics today because of the popularity of the web. Most of the major websites (like Twitter, Amazon, etc) now provide a REST or SOAP interface to their data. Our company is also in the progress of turning our applications into online variants (we, the TWO programmers, are however trying to make them realize what an ENORMOUS task that will be).