EJB 3.0, Really?

EJB 3.0 has been out for a long while and I must say that I feel the same way about it now as I did when it first came out – I really couldn’t care less. It took me a long time to even take a look at EJB 3.0 to see what was new. Surely this is due in part to Sun’s refusal to drop the EJB moniker. A move I would consider an abysmal marketing mistake given the reputation of EJB 1 & 2. I’m sure there are plenty of people who eagerly adopted Sun’s new EJB offering the instant it was released. These are the people that like to blindly gobble up everything Sun has to offer and proclaim said offerings as de facto standard. However, I’m guessing there are a lot of people out there that feel the same way I do. We remember spending countless hours thinking there must be a better way while working with Sun’s first two attempts at EJB. At some point during this painful experience we cautiously looked around and found out we weren’t the only ones who noticed that the emperor had no clothes. We realized it was ok to move on to using other solutions for things like remoting, ORM, transaction control and object security and we never looked back. Sure, I’ll admit that there’s a small part of me that would like to have all of my tools come in one nice little package from the same vendor. This is the same part of me that wants all of my stereo components to be the same brand. Unfortunately for that part of me, I think EJB 3.0 is to Hibernate what JDK logging is to Log4J - too little, too late.

It’s not that I dislike Sun as a company. I really like them. Java is cool, so is the servlet specification; Sun has done some great things. EJB is just not one of those things, at least not the first couple of tries. Granted, EJB 3.0 is a huge departure from and drastic improvement over the previous approach. It's not bad technology. However, I really don’t think it offers any huge advantages over similar options provided by frameworks such as Spring and Hibernate. If Sun really wanted to make a run at bringing EJB back from the dead it should have offered a significant improvement over the other industry standard tools that solve the same problems. Basically the Java community had found alternatives to a technology that was over sold and EJB 3.0 is Sun’s response to those products. Not that I disagree with that approach from a business standpoint; by all means, if you’re not getting something right, copy the guys who are. However, given the widespread adoption of EJB alternatives couldn’t Sun just let EJB die? If all Sun was going to offer was a “me too” product, the development community would probably have been better served if they did. I suppose an argument can be made for having multiple options but I really don't see that much value in yet another ORM or remoting technology.

I know there are plenty of projects out there using EJB 3.0. Given this rant, I’m sure I won’t be spared the irony of being dropped on one in the near future. However, I haven’t had the, ah, pleasure of using EJB 3.0 on a large project yet. I’ll be the first to admit that my perception derived from reading docs and playing with tutorials could be way off base. So, if anyone has been on a wildly successful EJB 3.0 project that convinced them to swear off using anything other than EJB, I would love to hear about the features and functionality that made you an EJB convert.

Text Trickery

If you've ever worked with text extensively you know that it presents some deceptively complex problems. Specifically, things like getting really good looking, print quality text on screen or translating screen text to high quality print are much more complicated than they might appear at first glance.

Dealing with text is a fairly common task so it seems like it’s probably a worth while cause to make this task simpler. Adobe has a new text layout framework available that goes a long way in doing exactly that. The framework leverages the capabilities of the new text engine in Flash 10/AIR 1.5, which boasts some pretty powerful features for handling some notorious text issues. There are some great layout features like vertical text, multi-column text, linked text fields and inline graphics. It also provides some fine-grained control over text display with support for things like kerning and ligatures. There's a video tour of the framework on Adobe's site and Mihai Corlan has posted a good article on getting started.

The API is very new and changing at a rapid pace so I wouldn't dive in if you don't like it when the online docs don't always match the API. However, if you don't mind a few headaches and doing some digging it's some pretty interesting technology.

Tools of the Trade

In the spirit of choosing weapons carefully I’ve decided to start a weekly post about a technology that is currently at the top of my list of solutions for a particular problem. I like to evolve my technology stack slowly and what better way to do that than to get some feedback on the solutions I’m using and possible alternatives to them. I’m hoping that this will create an exchange about tools of the trade that will be of value not only to me, but others evaluating similar technology.

First up is Direct Web Remoting (DWR). DWR is currently my Java Ajax framework of choice. I figure this is a good first topic since JavaScript is all the rage right now and there are a plethora of tools available in this space. DWR makes exposing server side Java via JavaScript simple and clean. Essentially you just register a DWR servlet that generates JavaScript to match your server side objects and make an XML configuration file that lists which Java objects should be exposed. You can literally be making remote calls to your existing server side objects in about 5 minutes. The latest version also supports annotations, eliminating the need for a configuration file.

In general, when I’m evaluating technologies there are a few important factors I always consider. First and foremost I look for something that provides the features needed for me to solve the problem at hand in the simplest manner possible. DWR does a good job of this. I think it’s a great example of a relatively simple solution for a complex problem. It is very easy to use yet it has the functionality I expect from such a framework.

Another thing I like to look at is a tool’s ability to integrate with the other technologies I’m using. DWR has support for integration with several common frameworks including Spring, Struts and Hibernate to name a few. I’ve personally used the Spring integration and was really pleased with it.

Good documentation is a critical factor for me when I’m choosing technologies. There is inherent risk when adopting new technology. This is one of the main reasons I feel the choice to use a new technology should be made carefully. New tools come with new problems and you need good documentation to help you tackle those problems. I wouldn’t say that DWR gets an A+ in the documentation department, but it’s pretty good. The getting started section is a nice way to get up and running in minutes and there are several tutorials to help get you started with common tasks.

Finally, I feel that mainstream adoption is an important consideration. I don’t like to put a project at risk by adopting a technology that no one is getting behind. There are a lot of factors that contribute to the success or failure of a technology; I won’t begin to pretend that I know which unproven technologies are going to make it. DWR passes the test in this area too. Several large companies including TIBCO, Wal-Mart and American Airlines are using it.

Of the tools I’ve used for Ajax functionality, DWR is the hands-down winner. If you haven’t used it, I highly recommend checking it out. If you have used it, I’d be very interested in hearing if it is indeed your weapon of choice when it comes to Ajax or if you've got something else to recommend.

97 Things

Yesterday marked the release date of the book 97 Things Every Software Architect Should Know: Collective Wisdom From The Experts. In what I would consider a truly unique effort, the minds of over 40 architects from around the world were tapped to create a collection of software architecture principles they’ve developed while in the trenches. The idea for the book was the brainchild of Richard Monson-Haefel, esteemed author of Enterprise Java Beans (O’Reilly 2004) and J2EE Web Services (Addison-Wesley 2003). I first discovered the 97 Things project when I stumbled across a wiki where Richard was encouraging architects to submit axioms, the best of which would be selected for the book. All of the contributions are under the Creative Commons Attribution 3 license which is essentially open source for writing. I thought it was a cool idea for a book and submitted a few of my own ramblings. I really think the final result of the project turned out great. All of the contributions are still available on the wiki. There is some excellent advice that’s definitely worth checking out.

Choose your weapons carefully, relinquish them reluctantly

I had a link in my last post to an article I wrote about selecting tools carefully, entitled “Choose your weapons carefully, relinquish them reluctantly”. Apparently that link now brings you to a page where you must sign in to the wiki where it’s posted before you can read it. I didn’t realize that when I tested the link because I was indeed logged into the wiki on another browser tab. I apologize to anyone who clicked the link and thought I was trying to lure them into joining yet another online community, I hate that kind of thing just as much as anyone else. Here’s the write-up that the link was supposed to point to.

As a seasoned veteran of software design and implementation, every architect is armed with an array of weapons they’ve used with repeated success. For one reason or another, these technologies have found favor and bubbled to the top of our list of preferred solutions. Most likely they’ve earned their rightful place in your arsenal by defeating fierce competition. Despite this, a barrage of new technologies constantly threatens their position. We are often compelled to lay down our weapons of choice for these new alternatives but don’t be too quick to dismiss your trusty armaments. To cast them aside for alternatives that haven’t been proven through similar trials is a risky proposition.

This doesn’t mean that once established on our list of favorites a technology is granted infinite tenure and it certainly doesn’t mean that you can bury your head in the sand and ignore advancements in software development. For each technology the time will come when it needs to be replaced. Technology moves quickly and superior solutions are on the way. As architects we need to stay abreast of industry trends, we just don’t need to be the first to embrace fledgling technology. There’s usually no huge advantage to being the first to adopt new technology but there can be several drawbacks.

To justify the risk involved with selecting new technology its benefits should be a quantum leap forward. Many new technologies claim such advancement but few deliver it. It’s easy to look at new technology and see technical advantages but those benefits are often difficult to sell to stakeholders. Before you decide to blaze a trail with new technology, ask yourself how the business will benefit from this decision. If the best outcome from a business perspective is that no one will notice, rethink your decision.

Another important thing to acknowledge is cost associated to the shortcomings of new technology. These costs can be high and are difficult to calculate. When you’re working with familiar technology you’re aware of its idiosyncrasies. It’s naïve to think that a new technology won’t come with its own collection of pitfalls. Adding problems that you haven’t solved before will destroy your estimates. You’re far more aware of the costs involved when implementing solutions using familiar technology.

One last thing to consider is future relevance. It would be nice if we could simply identify and select superior technologies but things aren’t quite that simple. Great technologies don’t always win. Trying to predict the winners early is a gamble that doesn’t yield a large payoff. Wait for the hype to die down and see if the technology settles into a space of usefulness. You’ll find many just go away. Don’t jeopardize your project for a technology that doesn’t have a future.

Selecting the technologies we use to attack problems with is a large part of the software architect’s job. Choose your weapons carefully and relinquish them reluctantly. Let your past success help to ensure future success and evolve your technology stack cautiously.

Stop Inventing Frameworks

Why is it, that with every project I work on, I seem to run into yet another homegrown framework? Some mad scientist has decided he’s got a better way to process http requests than the fine folks who wrote Spring MVC or Struts. I’m not talking about servlet based frameworks that print HTML and were written ten years ago. Sure, it sucks to be on a project like that but you can’t really be that angry about it – those are the tools that were available back then so that’s just how people did stuff. I’m talking about the projects that started a year ago, yet still have some guy’s pet project MVC or data access framework.

I’m not sure why this seems to be such a common occurrence. Perhaps the culprits are those who’ve just finished reading their first patterns book and really feel the need to put together a nifty framework using all those patterns. While implementing a framework may be a useful academic exercise to become familiar with patterns, using such a framework in lieu of a proven solution that solves the same problem is probably not a great idea. Many of the patterns required for a web application have already been implemented in existing frameworks. In fact, identifying patterns in a framework such as Spring is also a good academic exercise.

While it’s very possible that you’ll need to extend an existing framework or write something that is domain specific, it’s not very realistic to think you’re going to single handedly write something like a data access framework that’s on par with an industry standard solution like Ibatis or Hibernate. Don’t get me wrong, it’s not like I think I’m going to be using the same set of standard tools five years from now. However as I've mentioned before, once a tool has made my list of preferred solutions it takes a quantum leap forward for me to trade it in for something new. In all fairness, maybe you’ve created a solution that is indeed a large enough advancement to justify replacing an industry standard technology. If you truly believe that to be the case, ask yourself how you’d feel about releasing your framework to the open source community. Chances are, your gut reaction will be that you don’t necessarily want engineers from around the world scrutinizing your code just yet. It’s easy to push your solution on a captive audience of co-workers. Things tend to change when the people evaluating your solution are a group of completely objective strangers.

It’s easy to become enamored with your masterpiece and convince yourself that it makes sense for your company. The reality is that teams of talented engineers have created the tools you’re trying to replace. An endeavor of that magnitude is a large project in its own right and would require your full attention. Most likely you’re not able to make that type of time commitment. Even if you were able to replicate their results you’d be creating a proprietary solution for a problem that’s already been solved using technology that’s familiar to developers everywhere. It’s very hard for me to envision a situation where the cost incurred to develop, maintain and document that proprietary solution would be worthwhile. Do yourself and the people who inherit your project a favor and take advantage the technology that’s available.

Simple Minded Software

“There’s got to be a better way”. I’m not sure how many times I’ve uttered that phrase, but it’s certainly more times than I’ve said “this is too easy to understand”. One thing is for sure; many of the solutions and explanations we encounter are more convoluted than they need to be. In a world where obfuscation often shrouds solutions in an apparently necessary cloud of cryptic ones and zeros, I’m constantly in search of what I consider to be true software design elegance - simple solutions for complex problems. Sadly, as I’ve said before, it seems much easier to stumble across software utilizing overly elaborate solutions for simple problems. While it may not be immediately obvious, most of the time when I find myself thinking there must be a better way, there is. I’m not saying that all problems can be resolved with equally simple solutions. Transaction control and remoting solutions are probably always going to be a little more difficult to understand than input validation; that’s just the way it is. However, I don’t think I’m the only one that found myself saying “there’s got to be a better way” when I was writing EJBs in 2001. Like most software professionals who’ve been at it for a while, I’ve got my fair share of rants. Overly complex solutions seem to be a recurring theme that is often at the crux of those rants. The evolving quest for simpler software design and development solutions has brought more principles, ideals and opinions to my attention than any other topic. Hence, this is Simple Minded Software, the place where I vent all the things those closest to me are tired of hearing about on a daily basis.

image source: The European Patent Office website