By the time you read this, the J2EE revolution will be gaining significant momentum. Most large companies will have some type of new development around it; many more existing and new e-businesses that leverage this technology will have emerged. Many platform providers will have delivered core J2EE functionality, committed resources to transition to this technology, or made plans to build J2EE-based interfaces to their systems. All systems go.... "J2EE is ready for the masses" will be the theme for the near term.

To give this notion of a J2EE revolution a little more perspective, we should look at it in terms of the technology adoption curve well articulated by Geoffrey Moore in his book Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers (Harperbusiness; 1999). As with any new technology, there will be an industry adoption curve that starts with the innovators and early adopters, individuals and companies that will accept a new technology at any price and level of pain. They do this for a variety of reasons, but it's typically driven by the innovative functionality offered by the technology or a passion to help reach the long-term vision.

If all goes well in this early stage and the technology gets enough momentum behind it, it'll jump into the majority stage of adoption. Many individuals would argue, me included, that J2EE has already made this jump and is headed up this portion of the adoption curve. The individuals and companies at this stage will have seen enough success delivered by the early adopters that they're ready to engage the technology as well. At this point the technology has probably evolved to where it's more stable and has a certain level of required functionality to appeal to the broader market. We've seen evidence of this transition in the level of J2EE activity and support being generated in the industry. From this early-adopter stage the technology transitions to the late majority where it's mature and stable. Finally, in Moore's model, there will also be a group of companies and individuals, called laggards or skeptics, who will never adopt the technology.

Why have I spent a paragraph reviewing the technology adoption curve in an article about framework development? Because any talk about framework development, regardless of the underlying technology used, must encompass some sacrifice of short-term deliverables to meet long-term goals. This becomes an investment decision, which entails an understanding of both the risk and reward.

Understanding where an underlying technology is relative to its adoption in the market is required for such a critical decision-making process. This jump of the J2EE technology is forcing individuals and companies to decide whether to move full stride, take small steps, or adopt a "wait and see" approach. Regardless of the decision, there's a cost associated with the level of transition taken. Those who enter with full stride may invest more heavily, take on a bit more risk, but ultimately reap greater rewards. Those who take smaller steps may be trying to minimize cost and risk but still be ready to take advantage of the technology shift. Those following the "wait and see" approach may still be able to capture some of the residual value if the technology succeeds, but will probably have a significant opportunity cost associated with not making the transition and being left behind. As such, any individual or company must determine how best to progress into the new technology in terms of assessing hype versus reality, hiring and training the appropriate individuals to make the transition, understanding what base infrastructure is available, and determining what the next steps should be.

Application Frameworks and Components
Assuming that there's more reality than hype and that J2EE has crossed over into the early majority stage, one of the best ways to jump directly in and capture the momentum is for individuals and companies to figure out how to rapidly implement high-quality, repeatable J2EE solutions. Those that do will be successful to a point in this early majority phase, but also in the late majority. One mechanism to reach this goal is to start new developments with the mindset toward building enterprise-level components and the application frameworks to host them.

The adoption of J2EE has already started to fundamentally shift the application market, as individuals and companies are now seeking prebuilt or jumpstart components rather than end-to-end platform solutions to meet their requirements. The traditional system development model has been to pick a full-featured platform and try to configure it to meet the needs of the project. In many cases the platform may meet only 20-30% of the functionality requirements, and extra time and money must be spent to fill in the gaps. The cost of this extra work is often many times greater than the initial investment in the platform.

If this model is flawed, why has it been in place for so long? It grew over time out of necessity because of the lack of lower-level standards to drive baseline infrastructure. In essence, a customer buying a platform product was buying the underlying horizontal infrastructure as well as the higher-level vertical functionality. This horizontal infrastructure, with the advent of J2EE, can now be built using a robust, standardized, distributed object model. With a baseline infrastructure in place, individuals and companies can shift time and energy from the nonvalue-added parts of the application to the parts that do provide value, such as the niche functionality that may be their core line of business or competitive advantage. With component-based development, this can be accomplished in a manner that allows implementation of only the needed functionality in an ˆ la carte fashion.

What is a Framework?
If J2EE is good, what exactly do I mean by framework? You could argue that J2EE is already a framework and that nothing new is needed. While this is a defensible argument, I tend to think of J2EE as more of the foundation and raw materials necessary to build something much bigger. J2EE is a means to an end, not the end itself. This model is analogous to going to your favorite do-it-yourself home center, buying the necessary raw materials, tools, and instructions, and building something for your home. You may choose to go to one home center over another, perhaps because of convenience, quality of service, or the variety of products offered. In the end, though, the basic materials, tools, and instructions remain the same regardless of where you shop.

As any do-it-yourselfer knows, it takes a long time to build something from scratch, especially if you're just learning how to drive a nail with a hammer and have just read the how-to books and pamphlets for the first time. If we then start to think about building a house using prefabricated components, such as roof trusses and walls, we begin to see some advantages. These trusses and walls are built by specialists using proven techniques and processes. You could argue that in this approach we give up quality and flexibility, but we can point to prefabricated homes in Sweden that rival some of the best custom homes in the United States when judged along these same quality and flexibility attributes.

Where Do Frameworks Come From?
Turning attention back to J2EE, as more projects are developed and more code is written, patterns start to emerge, indicating an opportunity for componentization, or prefabrication, using the terminology from the home building example. This componentization can simply be in the form of the development of helper classes, but it can also take the form of reusable, configurable components such as EJBs and Java-Beans. These components can be used to support functionality such as database interaction and transaction management, command and response brokering, system authentication, mail processing, queue working, system reporting, application integration, and so forth. A significant part of their behavior can be driven by configuration information stored in property or XML files rather than in lines of code.

We can then begin to think of these various components as configurable engines or brokers within a much larger system. Once our engines and brokers become cognizant of one another and begin working together within the larger system, we have the start of a framework. Over time, these engines can be assembled in a loosely coupled fashion to form more commonly used vertical functionality, such as user, catalog, sales processing, content, or project management. Either by plan or by chance, a framework is born.

Why Do I Care About a Framework on J2EE?
While frameworks can be built on top of just about any distributed component technology, such as CORBA, COM+, or J2EE, the case for the latter is quite compelling. Perhaps the strongest argument mentioned in the introduction to this article is that J2EE is based on Java, and the technology has jumped into the early majority phase, while the other technologies are well into their late majority of adoption. What does that mean to you, the person responsible for implementing a new application on J2EE?

Java and the J2EE specification have matured to the point where the goal of writing once and running anywhere is a reality. Certain "100% Java" J2EE containers have made it possible to have a single code base run across just about any Java- compliant operating system and hardware platform. For example, you can perform J2EE-based development on a laptop computer running NT. You can check the code into a shared Linux environment at the office for testing, then push to a Solaris production environment at the data center. All this can be done using the exact same code base.

Another advantage afforded by this flexibility is that you can start your production environment small and scale it to meet your growth. For example, you may be a start-up with grand aspirations but need to minimize your cash outflow while you hone your business model. In this scenario, for example, you can start your production environment on nonclustered Linux running on dual processor Intel-based servers. Once your business starts to grow, you can easily progress to clustered Linux running on quad processor Intel-based servers. If your business model really takes off, you can progress into eight-way Intel-based servers, or make the decision to switch to various sizes of Sun servers running Solaris. Again, we can do this progression with the same code base. If you're a company with an existing infrastructure of Windows NT or Sun or Alpha, you can utilize this hardware to take advantage of the J2EE technology. There's a high degree of value in this flexibility.

Another advantage of J2EE is that it brings about competition, which is good for you, the consumer of this J2EE infrastructure. At last count there were something like 14 EJB containers available on the market with as many servlet containers. Likewise, there's JDBC support for every popular database server vendor. This means that if properly constructed, a single code base can be shared across both open-source and commercial infrastructure providers. In the open-source camp are the Resin and Tomcat servlet engines, the Enhydra and Sun Reference EJB containers, and Postgress and Interbase database servers. In the commercial camps you can use products such as iPlanet, BEA Weblogic, ATG Dynamo, Allaire JRun, IBM Websphere, GemStone, and BlueStone as your J2EE containers. Similarly, you can choose among Oracle, Sybase, Informix, and others for your database server. In short, there are ample choices to meet a particular project's requirements.

You may think that a J2EE framework isn't for you. Surprisingly, just about any software development effort can benefit from a framework approach. If you're a systems integrator, J2EE allows you to support a much larger customer base that may already have established hardware and operating system preferences. Adding a framework philosophy to J2EE allows you to build reusable core components that can be used across proj- ects. Rather than building from scratch at the outset, you can begin leveraging work performed in the past. This continual reuse allows an ongoing improvement (or "hardening") of the core code base while letting you focus on the more complex functionality that the client really needs you to be working on. Additionally, as the company brings on more developers and a consistency in components and frameworks is fostered, a certain level of operating efficiency and leverage is created.

In a start-up business there are two absolute truths:

• Cash is king: We've already talked about how J2EE allows better control over cash flow without building a code base that will have to be ported or thrown away at some later stage.
• Get there fast: and be flexible enough to change once you're there. In many cases the work to get there fast will make it difficult to be flexible when you arrive. Again, the value of flexibility is high. A good framework is often worth the investment in time and money.

For a large corporation that may have a heterogeneous hardware and operating system environment, J2EE can help protect those investments. Many large corporations have departmental pockets of development activity that are most likely building applications using similar components - they're just hooking them together a little differently and adding a couple of niche components that define their department. Likewise, there may be multiple departments writing similar interfaces to get similar data from the same ERP system. Considering even the broader scope, many companies have had to deal with the issues of platform or ERP lock-in over the years. this can force a company to adhere to preconceived business processes enabled by these applications, leaving little room for the company to engage in business-process improvement activities that could generate competitive advantage. A component-based J2EE framework mentality can help even large companies leverage current hardware investments and work across multiple departments, reducing its dependence on lock-in.

How Do I Get One?
By now you may be asking yourself how to bring a J2EE-based application framework into your development efforts. Fortunately, you have several options:

• Take a look at something available in the open-source community, such as the iCommerce platform by GemStone. You may choose to use such an existing framework to get an idea of what's involved, and perhaps as a starting point to one you might build on your own.
• Look at purchasing a jump-start platform, such as the Commerce and Personalization Server from BEA.
• Start converting your existing development efforts to more of a component-based, framework-oriented process.

A Quick Intro to J2EE
Regardless of the route taken, the horizontal aspects of a J2EE framework should be fairly similar. Most distributed implementations will start with what's known as a multilayered architecture that, at a minimum, partitions out presentation, application, and data functionality into discrete logical and physical components. Some frameworks further refine the application layer to break out domain and interaction services.

Figure 1 shows this basic layering and how it maps to the J2EE technologies. In general terms, the presentation layer provides the presentational and navigational aspects of the application. The application layer is often considered the heart of the system because it defines not only the problem domain in terms of simple entities tracked by the system, but also the behavioral aspects of those entities and how they interact with one another. The data layer is responsible for managing the long-term state within the system, typically in the form of RDBMS storage.

As an example, a user may interact with an HTML page (presentation layer) that's submitted back to the web server. The web server may respond immediately based on navigational programming, or it may need to interact with the application server (application layer) to gain access to data or behavioral aspects of the system. If the application server needs to manage the state of some domain object to complete its task (say, a database retrieval), it will have to contact the database server (data layer) to do so. Once the application server has satisfied the data and behavior requests, the results are passed back to the web server for final navigational and presentational work before sending a response back to the user.

Layering is important because it allows the distribution of processing across multiple logical processes, whether they're physically on one machine or spread across multiple machines. This layering approach also sets the initial foundation and boundaries for the components that will make up the framework. Such modularity provided by a component-based framework has several benefits:

• Various development tasks can be split between multiple developers according to the components and partitions.
• Long-term maintenance of the application becomes more manageable as well-designed components can be easily replaced over time as improvements are made.
• Test harnesses can be built rather easily to exercise the functionality by one or more components within the framework.

Conclusion
With a business-oriented overview of a J2EE-based application framework complete, I'd like to turn technical and focus on a real-world example. Part 2 of this article will provide a more detailed dive into such a J2EE framework used on one of our recent projects (www.bid4real.com). Not only will we cover the framework aspects of the system, but we'll go into detail on the hardware and operating system selection process, the clustering solution implemented, design decisions made along the way, and some of the components that were leveraged.

• The Case for a Cloud Computing Trade Association
• The Case for Single-Purpose Services
• The Case For 3rd Party Software
• CloudNet & The Case for Enterprise-Ready Virtual Private Clouds
• Rebuilding Public Trust: The Case for Compliant Financial Data
• Making the Case for Green IT

• Figure 1