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
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
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 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
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
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.
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
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
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.
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
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
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.
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.
Ted Farrell is architect and director of strategy for application
development tools at Oracle Corporation. He's responsible for the technical
and strategic direction of Oracle's development tools products, including Oracle9i JDeveloper, Oracle's Java and XML Integrated Development Environment (IDE) for J2EE application and Web services development.