When I first started programming, it was with a small company. Life was
simple. I understood all the requirements, and knew all the aspects of the
application and how to pull everything together. If I was working with a
team of programmers, the projects were small enough that the team knew each
other's code thoroughly. Mi code es su code. Software engineering was easy
to follow; code and design walkthroughs involved everyone, and, given time,
any person could pretty much handle the whole project on his or her own.
I moved on in my career and, in the last decade, as technology started
to grow at a phenomenal rate, the process of "pulling it all together"
became far more complex and had a lot more nuances than a single person or
team could handle. Distributed computing, by its very definition, requires
distributed components to work together as an integrated application. This
introduces the need to independently test and deploy the components, to
provide an appropriate level of abstraction, and then to test the
application as a whole.
The J2EE platform's purpose in life is to facilitate the development and
integration of distributed components. Sun provides the APIs and the
framework. However, the actual tools for testing and deploying an
application are provided by IDE tools vendors. Fortunately, J2EE IDEs have
come a long way in offering features that support the design and testing as
well as deployment of J2EE-based applications.
As distributed programming platforms have evolved over the last decade,
so too have the design methodologies. About four years ago, you got the J2EE
APIs (which were not yet "J2EE") from Sun, the J2EE implementation and
container for distributed components from your app server vendor of choice,
and the development environment from your favorite IDE. To coordinate
between development, testing, and deployment, you had to manually make these
different environments work together.
Over the past few years, several things have happened to make the
development of J2EE applications both easier and harder. It's harder because
the complexity of APIs has grown to an extent that the developers can
concentrate on only a part of the big picture. The architect who designs the
solution has the big picture in mind, but had to leave the details of
subsystem design, testing, and deployment to the individual subsystem
designers. Development of J2EE-based applications has become easier because
the tools have become more integrated and alternative, less heavyweight
methodologies have become very popular.
eXtreme programming has gained a lot of popularity in the J2EE universe
overall because it offers a practical and efficient way to manage large or
small projects without getting bogged down in an overly complex design and
an unmaintainable development cycle. And XP has become very popular in the
Java environment because it addresses the needs of distributed J2EE
application development in a palatable way. IDE and app server vendors have
added support for J2EE tools using XP as well as support that enables teams
to develop software based on XP principles. The leading app server and IDE
vendors typically include support for tools, such as Ant for building and
deploying software and JUnit for testing, and editing support for
refactoring. The XP principles apply well to a distributed development
environment by reinforcing simple design and continuous integration,
refactoring coding standards, and code sharing through pair programming.
While these principles apply well to all projects, the supporting Java tools
make the application of these principles pragmatic.
It would be nice to have a tool that enforces pair programming. Maybe
that's coming soon. Speaking of eXtreme J2EE, there are a couple of good
books I'd like to recommend on this subject: Java Tools for eXtreme
Programming by Richard High-tower and Nicholas Lesiecki (Wiley), and Java Development with Ant by Erik Hatcher and Steve Loughran (Manning Publications).
Ajit Sagar is the J2EE editor of JDJ and the founding editor of XML-Journal. He is the director of engineering at Controlling Factor,
a leading B2B software solutions firm based in Dallas, and is well versed in
Java, Web, and XML technologies.