This issue, in an uncharacteristic attempt to fit in with the Zeitgeist, I propose to depart slightly from my well-trodden path to the transaction manager and take a look at frameworks. I expect you can guess which particular framework I am going to take a pass at, too.

For nearly as long as there have been microprocessors, there have been frameworks. J2EE application servers can be said to be frameworks, as could messaging systems or even operating systems. It is also pretty easily arguable that frameworks are the only elements of software that have succeeded in delivering the holy grail of reuse. While instances of truly reusable business logic remain hard to identify, frameworks abound (especially if you accept my definition of frameworks, which includes application servers and such - what could be seen as more reusable than the code comprising a widely adopted commercial product like BEA WebLogic Server?).

Frameworks are entities that exist in layers, each taking care of some generic issues that exist at their architectural layer, and thereby provide a higher level of abstraction to their consumers sitting in the level above. The application server, for instance, takes care of low-level technical issues such as thread and socket management, thereby leaving the programmer of the components that use it able to put more of their focus on the business functionality he or she is trying to implement.

Despite the raised level of abstraction that the application server so effectively provides, pretty much every application server customer that I am aware of does not simply run projects that result in the production of a set of EJBs and servlets created from the ground up to implement some business function. In almost all cases, the app server customers have written a framework themselves, and their application developers write code that exists within their own bespoke framework. Typically, these frameworks perform such functions as reading data from centralized corporate repositories to configure static reference data and business rules. In many cases the frameworks also constrain the degrees of freedom afforded to the application developers - J2EE provides the ability for its users to make many architectural decisions. Is my logic in a servlet, or an EJB? Is the EJB a session or an entity bean? Is the session bean stateful or stateless ... the choices roll on and on. These choices provide a powerful toolkit for solving a wide range of server-side, logic-style problems, but in the 80% case the problems application server customers are trying to solve are not wide ranging. Many applications follow very common standard usage patterns. These patterns drive a common set of J2EE usage patterns, or at least they should. By giving the powerful tools to the application developers, you have forced them to be capable of making wise decisions as to how best employ their toolkit.

What is the business value of an entire team of experienced J2EE architects? Why do you need to staff up with people capable of making these hard decisions? Moreover, how will you retain them? If they spend their lives solving problems that are all pretty much identical from a technical perspective they will probably look for another job - ("Brain the size of a planet, and here I am parking cars") or maybe spend the vast majority of their time dreaming up and writing a new framework for you that you may or may not want, or benefit from. Even if you are in the situation where you do have a team of experts and they are disciplined enough not to go off on architectural off-road odysseys of this nature, the very fact that you have many talented individuals doing their own thing in the pursuit will inevitably lead to multiple code styles and variations in practice, which will be a future maintenance cost as the next generation of programmers looks to maintain the portfolio of business J2EE applications in production and quietly running the business. In production, regularity and conformity are your friends!

So, frameworks are needed (not simply to keep the gurus happy, either!) to provide consistency to developments and to enable "ordinary mortals" to be productive, not just superheroes. However, most application server customers find hidden peril in their bespoke frameworks. When they recruit new team members, these individuals cannot be immediately productive - the first few weeks of their employment will be spent grappling with the bespoke framework they have to work within. Inevitably, documentation will be scanty or nonexistent, so the new hires, however experienced in J2EE they may be, will spend lots of time badgering the guru in the corner about how they should get going. Not only does this waste their time, but the guru in the corner spends half his or her life answering basic questions, not delivering the high-value code they are paid for. This problem gets worse if you look to outsource some of the development. Developers in another organization, or maybe even on another continent, cannot bother the guru in the corner - he or she is not in their corner - with the obvious impact on productivity and so on. The framework has brought us consistency and an ability to have a multiskill level team, at the expense of the benefit of skill transferability, which was the reason we adopted J2EE in the first place.

So, the net of all this is that while we need a framework to enable productivity, we have identified a set of requirements of any truly useful framework, namely:

• It must be widely adopted and fully documented to maximize developer transferability.
• It must be easy to use to minimize the need of developers to engage in the low-level details of the plumbing of server-side computing. This means it must be toolable.

All three elements use code annotations to drive what is deployed from a runtime perspective - resulting in declarative setting of runtime behavior confining most of the code-level developer interaction to the direct pursuit of implementing the business requirements. Code annotations on the controller allow the pageflow subsystem to handle the minutiae of struts; annotations at the class and method levels allow things close to business objects to be exposed easily as Web services; and annotations allow developers to make declarations about the reusable chunks of functionality that are delivered in controls. The best news of all: although the annotations are collected together with the code they relate to and could be manipulated with the trusty vi editor, they lend themselves to intelligent manipulations via a Beehive-aware IDE (WebLogic Workshop being the first, but other tool vendors - not to mention the Apache Pollinate project - lining up to ensure it's not the only) that allows developers to easily interact, not only with the Beehive development model, but with custom controls in custom ways - for example, take a look at today's database control - creating one in the IDE prompts you to find a datasource from your running server, and can even go and look at what tables are in the schema. This intelligent, context-sensitive prompting is clearly going to get developers up the learning curve fast, and unlike a wizard-based, code generator approach, the novice user will never be left with hundreds of lines of code and other artifacts that he or she didn't write, doesn't understand, and now has to maintain (anybody remember the 4GL COBOL generator tools?!).

Of course, BEA's existing customers benefit from this approach to development today, as documented in studies by Gartner and Crossvale among others, but Captain Paranoia on their shoulder is whispering the dreaded "proprietary" word, and muttering about vendor lock-in So for these people, Beehive represents the possibility of benefiting from BEA's innovation without needing to commit to a lifetime of BEA infrastructure (although why that would scare anyone is beyond me!)

For the rest of the world, Beehive is not only providing an open, proven, toolable development framework supported by a major vendor to the world at large, but it is bringing ease of development to server-side Java, all in a way that is sympathetic to the current vogue for services-oriented architecture.

The final bastion of resistance to the tooled framework approach often comes from the J2EE developers themselves. They see their ability to chant the arcane incantations of JNDI lookup on demand as their value - "if tools and abstraction make things so simple, then we will be out of a job!" I believe this is misguided for two reason. First, all the code that does the lookups and so on is invariably cut-and-pasted from samples, or "one I prepared earlier." In my days as a Tuxedo consultant, I lost count of the number of production systems whose comments claimed they put a string into upper case (even the comments were cut and pasted from the "simpapp" sample application). It is the same in the J2EE world - any J2EE developer who thinks his superior ability to cut and paste lines of code will guarantee him job security is, well, misguided must be the polite term. Moreover, frameworks don't mean projects can get by with no J2EE developers - an architect or two will always be required on every development. With a framework, there is now a clear distinction between J2EE architects and business developers. Far from devaluing expertise, the framework actually provides some sort of career path for the developers - highlighting the true value of experience. Finally, if Java (and hence the market value of associated skills) is to survive in the enterprise for the long term, it is imperative that the experts target their expertise wisely, and that the masses can mass produce productively.

So come one, come all... wake up and smell the honey! Beehive has arrived!

References