11.1 Technology
By now, you probably understand
that I believe technology is only a small
part of any given problem. Java is not the best programming language
that's ever existed, although it's
easily among the most successful. The tools are not nearly as
important as the hands that wield them. That said, technology does
lead any discussion about the future of a dominant platform.
11.1.1 Less Is More
By far the biggest challenge Java developers face is the issue of
complexity. I'm starting to see more advanced
customers scale down by strategically stepping back from traditional
J2EE application models such as EJB with CMP to simpler models such
as simple POJO deployed on Tomcat. It's difficult to
estimate how well lightweight containers are doing, but the early
buzz and adoption rates are promising. The trend toward simplicity is
likely to pick up momentum in other places. Hibernate is wildly
successful not because it's more powerful than
TopLink or EJB CMP, but because it's simpler. JUnit
has been more successful than any other testing framework, by far.The success of these types of frameworks must trouble larger vendors.
The top web application server vendors, BEA, Sun, Oracle, and IBM,
must take notice of the simplicity trend. They've
got no choice, because their customers are struggling with J2EE. You
can already see those vendors start to embrace simpler, lighter
frameworks:Most vendors are not selling EJB solutions as strongly as they once
were. Vendors are especially backing off of EJB CMP for persistence
solutions.Many vendors are quietly developing alternative persistence
strategies. Oracle has acquired TopLink, Sun and JBoss have included
JDO solutions with their application servers, and IBM is now
co-marketing another persistence solution.Vendors are working to build better, simplified tools for their
communities. IBM has worked with the Eclipse project to simplify and
replace their massive VisualAge product suite, and BEA is increasing
their investments in Work Bench, which simplifies development of web
services applications.
Still, there's a long way to go. The current web
services specification is spinning out of control and closing in on
permanent bloat-ware status. XML is getting so complicated and
awkward that some researchers are already seeking an alternative.
11.1.2 Open Source
I'm not convinced that the future
direction of the Java platform could or even
should come from the major J2EE vendors. You can see the results of
committee-driven big-enterprise design:EJB
Vendors and customers alike spend too much time building on this
dead-end technology.
Generics
The implementation of generics in Java 1.5 is a solution without a
problem. The current implementation forces an interface and increases
the burden of the programmer, for very little benefit.
Web services
Early versions of web services were light and simple. Later versions
have patched a few holes and also dramatically increased the
complexity.
Logging
Log4j is a fantastic open source solution, but Sun decided to go it
alone, creating a competing and many say inferior implementation.
As I said in Chapter 1, the pressure for larger
companies to build bloated software is sometimes too difficult to
resist. Some of the juggernauts are starting to understand this. IBM,
for example, is showing interest in open source software. They know
that embracing open source software makes good business sense and can
bring innovations to light that may not have surfaced in other ways.The open source community fills an important niche in the Java
community. It allows software to evolve and improve based on usage
patterns of its customers. Many of the revolutionary ideas in the
Java community have come from open source projects:MVC template technologies such as Struts changed the way we integrate
user interfaces.JUnit changed the way we integrate and test software.Ant changed the way we build softwareEclipse and Tomcat changed the way big vendors approach open source
software.Hibernate changed the way we think about reflection and transparent
persistence.
The next generation of open source software is already making waves.
You've seen Spring, one of the lightweight
containers that dramatically improves integration and assembly.
Lucene is a clean text search engine opening up applications to
searches that go beyond the database. Velocity, WebWorks, and Tea are
user-interface technologies that are challenging the state of the
art. These projects have the potential to change the way we code in
dramatic ways. Beyond individual projects, open source software has
another affect on the industry. True, open source software is not
right for every customer, but Linux and the Apache web server both
have the market share and industry backing to be long-term players.
Figure 11-1 shows the typical components and
services of an enterprise application. Corporate shops are
conservative with their adoption of open source solutions. Still,
penetration of open source software, shown in darker colors in Figure 11-1, is increasing. Already, conservative
customers, including banks and insurance companies, are deploying
open source operating systems and web servers in increasing numbers.
In the past five years, Tomcat and JBoss have also made inroads.
It's only natural that the line between
what's acceptable open source and
what's proprietary is always moving further up. I
believe that it will continue to do so. In particular, databases and
persistence are services ripe for open source deployment.
Figure 11-1. Open source penetration is increasing
server. While working at IBM, I never read one line of open source
code, but that situation is changing quickly. For IBM, Eclipse is
only the beginning. They are beginning to exert pressure on Sun to
open up major pieces of the Java platform. They may not succeed, but
it's hard to argue against the increasing roles that
open source software can play. Oracle and BEA test their software for
compatibility with key open source projects like Tomcat, and also
generate Struts-compliant code.
11.1.3 Aspect-Oriented Programming (AOP)
Many a programmer has tried to design
programming
paradigms that make enterprise development easier. Object-oriented
programming helps: you can make models with business rules that look
and act much more like the real world. But OOP can only get you part
of the way there.Certain services called crosscutting concerns
are difficult
to add to
an enterprise application because you need to apply them broadly,
based on a changing policy. For example, many different objects might
need to be persistent. You may want to add all methods to an audit
log. You might also want a certain kind of method to participate in a
transaction. You don't want to add this kind of
service code to all of the classes in an application.You've seen that object-oriented programmers tried
to solve this problem with inheritance, interfaces, or programming
models like containers. I've made a case that the
best service implementation techniques preserve transparency with
respect to the service.AOP software is an attempt to make it easier to produce and consume
far-reaching services (crosscutting concerns) while maintaining
transparent models. Here's how it works:Break out core tasks, called concerns, from your requirements. The
core concern is the business purpose of your application, such as
making reservations in a reservation system. Other concerns
(crosscutting concerns) should be separated from the requirements.Code individual aspects individually. This is where
you'll notice the biggest productivity boost. You
are free to think of each problem independently, allowing for better
focus and better reuse.Configure the policy for each concern. Here, you specify how to
identify the methods of your core concern and how to apply your
concern.Your framework weaves the concerns together based on the
configuration and implementation of each concern using a tool called
a weaver.
That's the premise of AOP. Like most powerful ideas,
it's remarkably simple. The details, though, can get
tedious to implement Although some researchers and leading-edge
developers are already using AOP, it's my belief
that it will take a full-blown, successful aspect-oriented language
to make the language thrive in the mainstream. We saw the same
phenomenon with object technology in the early 1990s. It just takes
time for the industry to move when it comes to major paradigms.I do think that you'll start to see some
aspect-oriented ideas quickly move into the mainstream well before
AOP fully matures. In Chapter 8, you saw
several AOP ideas in action in Spring's transaction
management:Spring provides method interceptors to attach functionality to an
existing method without changing the method.Spring provides a pointcut model to describe the methods that require
a given concern, such as a transaction.
Other frameworks, such as JBoss, use core AOP ideas like method
interceptors, and that's likely to continue. When
enough developers use AOP ideas, it will be much easier for an
aspect-oriented language to establish itself when the market
conditions are right. Although you don't yet see AOP
ideas in the mainstream, you do see several frameworks with an AOP
flavor. The most common one is persistence.
11.1.4 Persistence
If you look closely at JDO, you can
see several AOP ideas. Persistence is a
crosscutting concern. JDO addresses it by implementing the concern
independently of the core concern (your application). JDO then uses
byte code enhancement to effectively intercept a Java thread of
execution and inject calls to the JDO librariesor, more
generally, the persistence aspect. It's an effective
solution. I've been impressed with the Kodo JDO
product produced by SolarMetric. The performance, flexibility, and
power of the framework is impressive, and big customers are starting
to take notice. It warms my heart, because transparent persistence is
important.Nearly all enterprise applications have some persistence element. In
some ways, the EJB CMP implementation has done us a disservice
because it's made many gun-shy. The states of
technology in persistence frameworks, RDBMS technology, and hardware
have come far enough to make transparent persistence possible. While
not all applications need persistence frameworks, many do.
It's critically important for the Java community to
establish an effective standard for transparent persistence. It looks
like JDO 2.0 might be just what we need.
11.1.5 Containers
Most applications do not
need EJB.
It's just easier to build it all from scratch,
adding in the occasional useful J2EE service as needed.
I'll go even further: for the occasional application
with true heavyweight enterprise requirements,
there's a better way.After reading Chapter 1 and Chapter 8, you know that I believe
we're late in the era of the heavyweight J2EE
container. They'll either wane or Java will die.
They won't be killed by a technology so much as by
an idea: that the idea of dependency injection has power. Right now,
I've only coded minor applications in Spring, but
after using Spring in the place of my J2EE container, I wondered what
was missing.Sooner or later, customers will notice that they're
spending a lot of money without a lot of benefit. When that happens,
vendors will respond. Whether they write their own or embrace open
source containers doesn't make any difference. The
idea of the lightweight container is what's
important. The cat is out of the bag, and it will be tough to get it
back in.