Good middleware

Today, I hopped onto my mountain bike and had a great ride. Even though it was hot, the play of the trail over the hills was beautiful to behold. It had just enough down to let me recharge my legs for the next technical climb. It had sections that stretched me technically and scared me just enough, and sections that let me turn my brain off and just cruise. I got to thinking that it was all about me. I was in a zone. But without a good trail, I couldn’t have felt that rush or satisfaction. And then I started to get this great metaphor…and promptly crashed. Spectacular crash; soft landing; can’t complain.

Back to the metaphor. A good trail sits in the background, and if it’s doing its job, you know it’s there, but will never appreciate it as much as you should. And until the last year, I’d been noticing my middleware way too much lately. In a response to my first blog, I told you that I’d have the most boring blog on java.net. I’d have a single-minded vision of simplicity and productivity. I hope that I’ve remained true to that promise. Lately, I’ve been pretty vocal about EJB, lightweight containers and persistence frameworks. There’s a good reason for this. If I work hard to help establish standards that I believe make sense, it will eventually make my life easier, and my trail will fade into the background. Instead of working within the JCP, I’ve been working primarily in the court of public opinion. After all, we, the Java consumers, will ultimately have the final vote.

In fact, that’s the reason that Justin and I wrote Better, Faster, Lighter Java. I’d considered writing a book about Spring or Hibernate or even lightweight containers, but I sensed that it may be time instead to make a statement about lightweight development. Most of the people that read java.net on a daily basis already know about lightweight containers and AOP, and many like and use agile methods. But most Java developers haven’t got a clue about lightweight development if their vendor isn’t telling them about it. That’s my intended audience. To this end, I’d like to step back and talk about the principles that I believe are important for good middleware.

1. Good middleware is simple. One of the big reasons for the success of web-based programming is the simplicity of the model. You’re seeing a comeback of ORM technologies because they’re getting easier to use. And you’re seeing the community at large reject technologies that are not simple. Beauty, utility, and simplicity are all closely related. Effectively layered simplicity is the secret to good design.
2. Good middleware allows more transparency. By this, I mean that good middleware lets you hide services. It’s very important to be able to write a transparent model, without being concerned about persistence or transactions or security. This is why you see so much written about AOP, JDO, Hibernate, declarative transactions, and containers in general. They lay the burden of services at the feet of the middleware. Transparent code is far easier to understand.
3. Good middleware is easy to change and extend. Investments in middleware are inherently risky. Those who lead the market today may not be in two years. You need to be able to configure a variety of extensions. You also need to be able to swap out your services with minimal pain. That’s why you see added emphasis on things like reflection, class loading and configuration. It’s hard to be extensible without those tools. Standards and popularity play a huge role here. That’s often ironic, because popular frameworks and developers often resist standardization.
4. Good middleware is testable. Our leadership is reading the same books, and talking to the same consultants. The day of the large testing organization is over. That burden is increasingly falling on the every-day developer. Further, outsourcing is putting greater productivity requirements on each of us. If you can’t automate your testing, it’s not going to get done. You simply can’t afford frameworks that get in the way of your testing effort.
5. Good middleware makes you more productive. Great tools give you leverage. There’s no other good reason to use middleware. Otherwise, we’d all write our own.
6. Good middleware is safe. If you can’t depend on it for the long haul, it’s not good middleware. There’s no substitute for good management at the top of an organization. That’s why I tend to place such a high premium on the relationships with the people at the top levels of products and projects that I support. I’ve got tremendous confidence that a good management can fix significant flaws in a product (like IBM and WebSphere), just as I’ve got every confidence that poor management can torpedo any temporary competitive advantage.

If you want to ramp up on the lightweight movement, you might check out my book, but if you’re agreeing with everything in this blog, it’s probably beneath you. If you want to read authors that understand good middleware, start with Martin Fowler, Ted Neward, Stuart Halloway, and Rod Johnson. They know good middleware. If you want to see good middleware in action, start with products like Spring, Pico, Hibernate, Kodo, and Coherence. If you’re looking for good architectures and services that can move you in the right direction, look into inversion of control (or dependency injection), aspect oriented programming, transparent persistence, and declarative transactions.

As I picked up my bike and dusted myself off, I jumped back on the bike, and thought, “You’re still a good trail. This accident’s on me.”