As the Java 2 Enterprise Edition (J2EE) platform continues to grow and gain ground in corporations and the battle between Java and Microsoft .NET intensifies, more and more companies are looking for help in building their J2EE applications.

With the large number of standard technologies available, all being exposed at the programming interface or metadata level, making sense of what, when, and how to use these technologies is becoming harder.

This problem opens the door for J2EE frameworks ­ tools and applications that manage much of the complexities of the underlying J2EE data, code, and deployment and allow the user to work in a much more efficient and coherent manner. A framework centralizes different common design-time and runtime resources, allowing developers to concentrate on the unique business logic of the application, and avoid having to build the underlying infrastructure to support the applications.

This can lead to bigger productivity gains for developers, as well as more flexibility for corporations as many of the frameworks don't require in-depth knowledge of a particular programming language or technology, thus creating more opportunities for a diverse group of developers to contribute to building the application. The catch is that frameworks must be able to do this without locking the users into proprietary tools and data, which isn't easy.

Current Frameworks
Frameworks aren't new. Different types of frameworks have been in existence for over a decade. They're designed to help an organization build and deploy an application more quickly and efficiently. Some come with a packaged application for use in customizing that application, while others are more generic in nature, allowing users to build custom applications.

One of the problems with traditional frameworks is the lock-in. With every proprietary framework comes tool, data, and vendor lock-in to that framework. Committing to using one of these frameworks means committing to the framework vendor and its data format for the life of the application. With the lack of industry standards and ever-growing time-to-market pressures, many corporations have bought into these frameworks to help build their applications. These frameworks help most companies build their applications quicker. PowerBuilder and Forte are good examples of these types of proprietary frameworks.

Problems don't surface until a change in the industry, technology, or application requirements forces the company to make changes in their application, and often in the technology stack supporting the application. The Internet was one of the biggest catapults to this crossroad. To reach more users and eliminate costly software distribution and upgrades, developers began fleeing client/server architectures and heading for the Web, with simpler, browser-based user interfaces for their applications.

At this point, the company is at the mercy of the framework provider and the technology and direction they're promoting. If the framework can't support the new requirements or the framework provider chooses not to support these requirements, the company is stuck with an application that requires a massive port or migration to continue evolving, or in more extreme cases, a complete rewrite onto a new technology stack.

This dilemma is not unique to users of proprietary frameworks. Companies that choose to build the underlying application infrastructure themselves can run into similar problems. The lack of industry standards in building applications lends itself to this inevitable predicament.

J2EE
J2EE is designed to solve this problem. With the support of every major software vendor in the market except one, J2EE has quickly become a robust, scalable solution for building enterprise applications. With over 30 vendors shipping J2EE-compliant runtimes and thousands of customers building and deploying J2EE applications on those runtimes, J2EE has proven itself as the industry-standard technology for building enterprise applications.

To prevent the technology dead end that was mentioned earlier, J2EE remains a living thing. More than 300 members of the Java Community Process (JCP) are continuously working to grow and improve the standard. While no one company can come up with all the answers, the JCP ensures that a multitude of diverse knowledge and experience goes into building the Java 2 standards. As the industry grows and changes, so do the J2EE and associated standards. Each addition to the specifications is an extension to the architecture, thus allowing customers building applications on J2EE to evolve them as technology evolves, as opposed to migrating, integrating, or rewriting them.

One of the major benefits of J2EE is how the architecture separates the different components and functionality of the application. The design promotes the separation of functionality, such as keeping the business data, the business logic, and the presentation layers separate from each other. This allows organizations to build more flexible applications that are able to change as the market and industry change, as well as much easier to maintain and support. The downside to this approach is that this architecture becomes more complicated to manage. The application is broken up into different pieces, and developers and businesspeople working on it need to be aware of those different pieces and how they all work together. It's a trade-off between a flexible, scalable architecture and development complexity.

This puts the pressure on the tools and development environments to hide these complexities and allow developers to focus on the task of building the application and not be bogged down by all the details of the underlying architecture. Java Integrated Development Environments (IDEs) have made significant progress over the last year in providing a toolset that greatly reduces some of the complexities of Java, J2EE, and Web services development and deployment.

While in the past the Java community has been criticized for not having tools with the depth or integration of Microsoft's tools, that gap has been greatly reduced over the past 12 months. Although a large number of developers gladly welcome the new generation of IDEs and are receiving immediate benefits from them, others still find them either too heavy or still too technical for their needs.

This brings up the question: Can one tool solve the problems of all the developers in a company? The answer is "No." This answer is something that software providers have avoided admitting for years. A single tool or product that can appeal to every developer, businessperson, and analyst in your company does not exist, and never will. The good news is that the J2EE architecture provides the platform, infrastructure, and process that are able to solve this problem. The industry just needs to realize it and work together to accomplish it.

J2EE Frameworks
Frameworks can be a powerful mechanism to abstract the complexities of the infrastructure away from the logic of the application. This can lead to larger productivity gains and a more maintainable application. Another advantage is that users don't have to completely understand the underlying technology in order to contribute to the building of the application. The level of abstraction will vary between frameworks depending on the target audience and intended usage.

Currently, several products on the market claim to be J2EE frameworks. They accomplish this by providing a proprietary framework that eventually either generates code that runs on a J2EE application server, or generates metadata that's processed by components running on a J2EE application server. In either case, users are stuck with proprietary metadata describing their application. J2EE is not about standardizing implementations, but rather standardizing to the implementations in the form of the code and metadata consumed by the implementations. Having your data in a proprietary format that requires a proprietary tool to manipulate does not give you the portability or freedom of choice promised by the J2EE architecture.

These frameworks behave this way because it's easier. It's easier to work with concise, complete, and proprietary data than with the complex and modular data of the J2EE architecture. It's easier to invent things yourself than to work with the JCP to make them part of the standards. It's easier to claim the standards are incomplete than it is to work to extend them to meet your needs. It's easier to regenerate code from metadata than to build up metadata from code. The result of these choices, however, is a lot of proprietary data formats that lock companies into a vendor and toolset, and, ironically, have them end up with the opposite result of what they were trying to accomplish: to build their application on open standards.

Alternatively, the definition of a J2EE framework should be a set of design-time tools and, optionally, runtime components that ease the development, management, and deployment of J2EE applications by directly manipulating J2EE code and metadata. The features of a J2EE framework are not as important as the data that it manipulates. There will be multiple frameworks that target different types of users, performing different tasks with different skill sets. By this definition, a Java IDE can be considered a framework. Current Java IDEs can help in the creation, management, and deployment of J2EE applications, all while editing standard Java code and J2EE XML metadata. A user can then take that code and metadata and manipulate it with any other Java IDE, regardless of the vendor.

If J2EE frameworks work off a standard set of code and metadata, companies can mix-and-match the types of tools and frameworks that they use throughout the development organization and process. Each framework can have a particular set of features targeted at different types of users and still manipulate the same underlying data as all the rest of the frameworks. This would include frameworks from different vendors as well.

For example, there's a J2EE framework that allows the user to pick a database table and create an object so he or she can use that table information in the program. Behind the scenes, the framework might be creating an entity EJB with its multiple Java files and XML deployment files. Then another user, who does not use the same framework as the first user, is able to work on the same EJB using a favorite IDE or even a text editor. The first user may know nothing about Java or EJBs and the second user might know everything about Java and EJBs, but they can work together on the same project and the same code base. This is almost impossible with the frameworks on the market today.

Extend and Submit
Accomplishing the task of standardizing the code and metadata across all tools and frameworks becomes more difficult as the level of abstraction in the framework increases. The more the framework removes the user from the code and metadata and incorporates process, the more mapping the framework vendors must do to store their information in the standard formats. Because the J2EE standards are written at the code and implementation level, the data formats are not always designed to store the abstract information that would be needed by many of the frameworks. This could lead to vendors using a mix of some standard data as well as some proprietary data where the standards, didn't support a particular notation or abstraction. Although this is better than a totally proprietary solution, without the right commitment to the standards, this still lends itself to a certain level of vendor, tool, and data lock-in.

The resolution to this is to extend and submit. When framework vendors come across a situation in which the current standards do not provide adequate means to store some metadata that's needed to support their framework, they should extend the current specification, and then submit those changes back to the standards community.

The Java Community Process has been very good at turning around requests to extend the Java 2 standard in a fairly short time. (These requests are called Java Specification Requests or JSRs.) The JCP is also good at providing lots of information on these JSRs to the public during the standard-making process.

There is a chance that the requirement the framework vendor is looking for is already covered in an existing JSR that's still in process and has not yet become part of the Java 2 standards. In this case, vendors should align themselves with the JSR and ensure that what they produce will be compliant with the technology once it becomes part of the standard. In other situations, vendors' requirements may not be covered in an existing specification or JSR. In this case, vendors should submit a JSR to the JCP with their request while developing their framework. This path requires more discipline on the part of the framework vendors because they'll be producing a technology that the JCP will be debating and changing as it becomes part of the standard.

Throughout the JSR process, vendors' specific requirements may turn into the industry's broader requirements, causing vendors to revisit their implementation to align with the new standards. This will result in vendors spending more time implementing their solution, which in turn will ensure that their solution is part of the standard.

A good example of this is the EJB support in J2EE. With versions 1.0 and 1.1 of the EJB specification, application server vendors needed to store more information than the specification allowed; their runtimes were more advanced than the specifications. The result was that vendors extended the EJB specification in their own proprietary manner. Then with version 2.0 of the EJB specification, those vendors were able to collaborate and extend the EJB standard to include additional information. The EJB specification was extended, and then submitted back for inclusion in the standards. The alternative to this is for vendors to continue producing proprietary metadata for their frameworks, which will lead to the fragmentation of the standards.

Industry Effort
To help stop the fragmentation of the J2EE standard, Sun Microsystems supplies a J2EE Compatibility Test Suite (CTS) to any vendor wishing to license the J2EE technology. Vendors must pass these tests in order to claim they are J2EE-compliant. As mentioned earlier, J2EE is primarily focused on runtime implementation, not design time. Therefore, all these compatibility tests are focused on runtime, not design-time, compatibility. This means that as long as vendors produce something that complies with the J2EE runtime standards, they're considered J2EE compliant, regardless of how they store the metadata that is used to create the compliant runtime code. Currently, no test can validate that the metadata a tool is producing is J2EE compliant, just the data that it deploys.

This means the framework vendors must remain disciplined when building their frameworks and adhere to using standard code and metadata. This makes the job of building these frameworks harder, especially when competing with Microsoft .NET. Microsoft has the luxury of controlling the runtime, the data, and the tools ­ one of the advantages of a totally proprietary solution. Therefore it's up to the J2EE vendors to continue to prove that you don't have to give up a robust, scalable, and open architecture just to get a productive set of tools. Users will be able to benefit from all the advantages J2EE has over Microsoft .NET, without sacrificing efficiency, flexibility, or ease of use.

Framework Architecture
Just as having one tool cannot satisfy the needs of everyone, having several different tools, even if they're sharing the same underlying data, can also be a headache. Multiple tools can lead to more maintenance and management problems, overlapping technologies, and questions about what to use when and why. To get around this, J2EE frameworks should not be standalone technologies, but rather standalone functionality plugged into a common architecture.

Some of the Java IDE vendors have extendible architectures. This is different from an add-in API to an IDE because with extension architecture, you can build tools that have nothing to do with IDEs. The architecture provides you with common resources such as project management, navigation, file I/O, and data sharing, and lets the different extensions define the functionality. Each extension is treated as a first-class entity and can share the data and the processes of the application with the other extensions.

By building J2EE frameworks on top of a common architecture, the frameworks can take advantage of the resources already provided by other extensions, such as compiling, code generation, parsing, debugging, etc. There's no need for the framework to build this duplicate technology when it can share it with the rest of the products.

Another advantage to using a common architecture has to do with the problem of trying to make everyone happy. For example, a user using a framework wants to cut out and edit some code directly. If the framework is a different product than the user's Java IDE, he or she needs to save all the work and then bring up the IDE, load the data, and begin working. When done, he or she needs to perform the opposite tasks to get the framework up to date with the code changes. With a common architecture, however, all the functionality is in the same product. The user would just switch to the code editor and make changes. When the user switches back to the framework (tab, panel, window, etc.), the framework is automatically notified by the architecture of the changes and updates. In this environment, the user is not bound by any one framework, but can use functionalities of different ones when needed. Since all the frameworks work off the same data, everything is kept synchronized.

Summary
Building enterprise applications can be complicated. J2EE provides a proven, scalable, and robust platform for accomplishing this task. As the technology continues to grow and companies are looking for more ways to utilize the J2EE infrastructure, J2EE frameworks will play a key role in coordinating and optimizing the resources and efforts across organizations. To ensure that this next phase of productivity tools and frameworks is successful, the J2EE community must remain disciplined and focused on preserving and growing the Java 2 standards by committing to maintaining a common, standard set of code and metadata.

Just as J2EE application vendors will continue to compete on who has the best implementation of the runtime standards, J2EE framework vendors will compete on who has the best set of features and processes to build applications using the standard metadata. With all the different types of users and requirements, the market to provide J2EE frameworks could be big. Vendors will be able to compete in this market by the features that their frameworks provide and not their proprietary data.