Don wants to know how Indigo can avoid EJB’s fate

Don recently asked,

I’d love to hear from the EJB alternative camp what they’d like to see from us in Indigo to keep them from reinventing the wheel over here in .NET land.

which was in response to his earlier comments of

I’ve spent some time thinking about whether we’ve taken adequate steps in Indigo to stem the need for dozens of alternative "containers."

Based on what I’m seeing, I think we’re on a good path. Here’re a few things that make me believe that:

  • We don’t mandate a process/appdomain host, so you can host Indigo services in any AppDomain or process you chose.
  • Our dispatch and instancing pipeline is fully pluggable (and replacable) and is wired up to our metadata/contract engine.
  • Most important data structures are extensible without resorting to subtyping.

 

Philosophically, we’ve done a good job at building simple and reliable mechanisms and not imposing a lot of policy on top. This is similar to the approach taken by .NET Remoting (albeit in a somewhat different domain) and quite the opposite of the approach taken by MTS, COM+, and EJB.

So I thought I’d take a stab.

 

One of the critical flaws of the EJB Specification as it stands, and the principal benefit behind the lightweight containers (until they start to get too heavyweight, anyway) is that of composability, the ability to "pick and choose" which parts of the container you want to apply to your particular project. For example, under the current regime, if all you wanted was the ability to start a transaction and kick off some processing each time a message comes in, you either have to write the host yourself, complete with JTA code (which means bringing in some kind of open JTA framework), or else you install EJB and write Message-Driven Beans. There’s no "middle ground" until you start to consider the lightweight frameworks, but even there, there’s a growing tendency to want to be all things to all people. I want a container that gives me the very basics of container-managed inversion-of-control and then gets the rest of the way out of my hair. No automagic pooling (unless I ask for it), no automagic resource management (unless I ask for it), no automagic transaction management (unless I ask for it), and so on.

Proponents of the current crop of lightweight containers will be very quick to pipe up and say "but that’s exactly what we do!", but there’s a difference–in several of the formerly-lightweight containers, they started out this way but have grown to encompass almost all of what an EJB container does, with similar complexity involved. Give me a very basic container-managed relationship, and a raft of services that I can pick-and-choose from, but let the traditional C++ mantra: "Don’t pay for it if you don’t use it" be the guiding principle here. Sometimes all I really want is a simple container in which to put a remote object, and sometimes I want the full nine yards of a middleware container (a la COM+ or EJB). Build a simple container with a ton of hook points, then give me things built on top of those hookpoints that I can take or leave as I wish–not stuff already built in that I can choose to use or not (but still have to pay for in terms of code loaded, processing steps taken and so on), but things that don’t ever get referenced or used unless I explicitly call or configure for them.

That’s the pipe dream, anyway. 🙂