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 couldnt have felt that rush or satisfaction. And then I started to get this great metaphor and promptly crashed. Spectacular crash; soft landing; cant complain.
Back to the metaphor. A good trail sits in the background, and if its doing its job, you know its there, but will never appreciate it as much as you should. And until the last year, Id been noticing my middleware way too much lately. In a response to my first blog, I told you that Id have the most boring blog on java.net. Id have a single-minded vision of simplicity and productivity. I hope that Ive remained true to that promise. Lately, Ive been pretty vocal about EJB, lightweight containers and persistence frameworks. Theres 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, Ive been working primarily in the court of public opinion. After all, we, the Java consumers, will ultimately have the final vote.
In fact, thats the reason that Justin and I wrote Better, Faster, Lighter Java. Id 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 havent got a clue about lightweight development if their vendor isnt telling them about it. Thats my intended audience. To this end, Id like to step back and talk about the principles that I believe are important for good middleware.
- Good middleware is simple. One of the big reasons for the success of web-based programming is the simplicity of the model. Youre seeing a comeback of ORM technologies because theyre getting easier to use. And youre 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.
- Good middleware allows more transparency. By this, I mean that good middleware lets you hide services. Its 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.
- 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. Thats why you see added emphasis on things like reflection, class loading and configuration. Its hard to be extensible without those tools. Standards and popularity play a huge role here. Thats often ironic, because popular frameworks and developers often resist standardization.
- 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 cant automate your testing, its not going to get done. You simply cant afford frameworks that get in the way of your testing effort.
- Good middleware makes you more productive. Great tools give you leverage. Theres no other good reason to use middleware. Otherwise, wed all write our own.
- Good middleware is safe. If you cant depend on it for the long haul, its not good middleware. Theres no substitute for good management at the top of an organization. Thats 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. Ive got tremendous confidence that a good management can fix significant flaws in a product (like IBM and WebSphere), just as Ive 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 youre agreeing with everything in this blog, its 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 youre 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, Youre still a good trail. This accidents on me.