5.1 Golden Hammers
In my first and second Java
I addressed antipatterns, patterns of solutions
that break in systemic ways. By far the most common antipattern is
the golden hammer. As a weekend builder, I know
the metaphor well. Most carpenters have a tool in the box
that''s so beautiful that they want to use it for
every task. I''m the poster boy.
I''ve literally used a circular saw with a carbide
blade to cut wire. Java developers are no different. All of us have
developed favorites. In this section, I''ll lay out a
beautiful set of golden hammers for your inspection. Chances are good
that you''ve used one to hammer the occasional screw.
5.1.1 The Allure
An antipattern is a bitter
seems sweet at the time. A golden hammer attracts a Java programmer
like a box of Krispy Kremes and a bottle of Jolt. The power of bad
frameworks over otherwise intelligent developers has sometimes
bewildered me, but I guess it''s good for business.
Sometimes, programmers do the damage to themselves. Past success can
cloud your judgment. I learned XML while working on a very successful
project and afterwards, I wanted to use it everywhere, from writing
simple, four-line configuration files to building an alternative
programming language. Others have had the same experiences with
CORBA, persistence frameworks, web services, and even Java itself.
188.8.131.52 The sales process
Other times, aggressive marketing
sales can do you in. Understand that the stakes are high, and this
industry spends millions of dollars at the drop of a hat to get you
to like and use something. If you''re making a major
buying decision with the help of a sales staff, be very careful. If
you don''t know how the process works, you
can''t make the most informed decision. Since
I''ve worked in sales, I can tell you how that
process works from the inside. Figure 5-1 shows a
combined version of all of the technical sales processes that I have
seen from the inside.
Figure 5-1. Knowing the typical J2EE sales process helps you buy smarter
Here''s a little more detail about each step:
The best salespeople make hundreds of phone calls and mine their
customers for leads. The goal is to establish an interest in their
product. Once the salesperson has established interest,
she''ll try to get to the decision maker.
That''s called getting to power. The final step is to
establish that the customer has the budget to buy the product. If
you''re a serous buyer, don''t share
your overall budget with your vendor! They''ll use
that information against you.
Sales reps know that sales involving an inside sponsor (usually
called a power sponsor) are
more successful because there''s no trust barrier to
overcome. It''s often a good relationship for both
parties. If you''ve already decided on a technical
solution and you''re trying to sell a technical
solution to your management, you can use your role as a power sponsor
to get your vendor to do a lot of your legwork for you. Chances are
good that they have much more information.
Getting agreement (pre-close)
The sales rep comes in, buys lunch, and slings around some nice
coffee mugs and cool pens. In the relationship stage, the salesperson
wants to build up a level of trust. In the relationship building
stage, the sales rep tries to get a list of objections. Their goal is
to get you to agree to buy the software once they overcome all of
Execute (technical sales)
Armed with a set of objections, the vendor passes control of the sale
from the rep to the technical sales team. The sales team can take a
number of different approaches, all designed to overcome your
objections and make the sale. They may include one or more of these
Technical presentations. Use these to your
advantage. Let your vendor answer critical questions about their
product. Be careful, though: the vendor is not the best source of
information about their competition. (In fact, while I was at IBM, I
found that certain vendors were notoriously bad.)
Proof-of-concepts (POC). This is the sales job
that I did at IBM. POC engagements are expensive. A vendor may do a
POC if you say you''ll buy if it''s
successful, if they believe that it will improve their odds of
closing the deal (usually, based on some competitive advantage), or
if they believe that you won''t buy without one. Once
you''ve come to a tentative decision about a vendor,
get proof that the product works. Pay if you must.
References. Reference selling is increasingly
taking the place of proof-of-concepts. Be cautious here, too. Hearing
a name at a vendor meeting is not the same as talking to the
customer. You''ll also want to know if the customer
received any special consideration in exchange for the reference, and
if they got any special support to make a project go smoothly. Unless
you also agree to be a reference, you may not get the same support,
so take references with a huge grain of salt. Further,
don''t buy without a reference that you trust.
Once you''re at the end of the process, the vendor
closes you. If you''ve got special negotiators at
your company, it''s best to take advantage of them.
If you don''t, then it may pay you to take advantage
of a negotiating class. Your sales rep probably has.
That''s what you''re up against. You
can use the sales process as a source of information to make a
knowledgeable decision. You should use them to help you fully
understand a particular product and areas in which the vendor
believes it has an advantage. Just don''t use the
sales process as your only source of
information. And above all, don''t make buying
decisions based on friendships with sales reps! If you do either of
these things, you''ll find a toolbox full of shiny,
expensive golden hammers.
5.1.2 Some Examples
Project teams across the nation have shown me many examples of golden
hammers. Few of them knew that they were making bad decisions at the
time. My favorite early examples include C++ for a team of COBOL
retreads, Visual Basic for an inventory and control system, and Lotus
Notes for a transactional airline reservation system. With Java,
we''ve got a whole new collection of potential golden
Java is one of the biggest golden
hammers that you''re likely to wield. You should have
many other tools to choose from, including scripting languages and
competing languages. Yet choosing alternatives often carries a stigma
that it doesn''t deserve.
Some industry dynamics are hard for me to understand. Microsoft
technologies build richer interfaces with much less effort than their
Java counterparts, and many enterprises support nothing but Microsoft
clients. Yet even in this restricted environment, most developers
would rather wade through the neck-deep quagmire that Swing has
become rather than inject any Microsoft development where it makes
sense. On the other side of the fence, Microsoft bigots would prefer
to tune up that rusting clunker that Microsoft calls their message
server and tie it together with 10-year-old transaction code in an
unmanaged environment, duct tape, and bailing wire rather than use a
better middle-tier technology like one of dozens of Java application
Most applications don''t
J2EE. Sun has effectively carried the J2EE brand into the mainstream.
It''s hard to find a simple, standard-edition
application server and few customers consider deploying that way. If
you''ve ever been tasked with getting a J2EE server
off of the ground, you know: it''s a tedious,
demanding process under the best of circumstances. On the other hand,
if you''ve been fortunate enough to lay out a lot of
money to buy a whole fleet of these things, you may have had your
vendor install it for you. When you lay out a ton of cash, they work
hard to keep you happy.
But J2EE is not the lowest common denominator! Many applications
should deploy with nothing more than a servlet container, a web
server, and a database connection. Some of the finest and fastest
commercial web sites use nothing more than Tomcat on Apache.
When you''re reading about
solutions, you probably see all kinds of potential clustering
strategies in the name of scalability. Customers with larger
applications often settle on deploying a cluster of presentation
servers, a cluster of business servers, and resource servers.
It''s a tried-and-true formula that scales well for
large loads, but it''s not the
Increasingly, experts are thinking about how to consolidate these
systems to save complexity and communications costs. Often, you can
get away with one middle tier cluster. The motivation is simple: when
you begin to add distributed nodes, you''re inviting
complexity and overhead into your door. You frequently invent the
need to connect to named services, manage distributed transactions,
and create synchronous and asynchronous messages. I have seen any
number of middle tier applications designed with arcane multiobject
hierarchies wrapping a single, local database
transaction. It pays to occasionally look at every
distributed tier with fresh skepticism. You can frequently
consolidate individual tiers with potentially significant gains.
Figure 5-2 shows two alternatives for consolidating
a typical architecture. One alternative is to deploy static content
and the MVC framework with the business tier, eliminating the need
for a distributed façade. Another alternative is to deploy
the CPU-intensive business tiers with a RDBMS, which often
underutilizes CPU cycles.
Figure 5-2. Sometimes consolidation of tiers reduces overhead and complexity
The image in the center of Figure 5-2 represents
many typical deployments. However, by deploying the façade
layer next to your MVC framework, you can eliminate the need for a
distributed façade. One client of mine did so and at the
same time eliminated the need for a J2EE server by eliminating the
need for stateless session beans.
Another strategy (the right-hand side of Figure 5-2) shows the
business-tier logic with the RDBMS. This deployment solves three
Typical well-tuned RDBMS servers rarely use more than a small
percentage of CPU cycles. Deploying a CPU-intensive business tier can
take advantage of those extra cycles for intensive data marshalling.
The communication costs between a database tier and a business domain
model can be among the most expensive in an entire application.
Deploying them together alleviates this concern.
Security is harder to manage across a wire than locally between
Think about it like this: it takes a great deal of energy to confine
your business domain model to the middle tier. Some of the logic
inevitably wants to fight its way to higher or lower tiers.
Presentation logic needs frequent access to validation; a persistent
domain model has a tight affinity with the database;
façade layers are much simpler to code and deploy as local
interfaces. If your situation seems to require a deviation from the
norm, don''t fight it.
EJB is not so much of a golden hammer
a glass hammer. The idea may be pretty to look at, but
it''s much less impressive in practice. Perhaps no
other Java API has been as hyped or oversold as EJB.
I''ve written a whole book on the topic; I
won''t rehash it here. As the years go by, I spend
less time talking about EJB pitfalls and more time talking about when
EJB should be used at all. This book is about moving away from EJB in
its entirety. Still, certain elements of that framework have a
limited value. If you''re going to use EJB, use it
appropriately in situations like these:
If you have a distributed, transactional
that needs to be highly scalable, consider EJB. In fact, in its
original incarnation EJB supported only stateless session beans, with
plans to quickly add message-driven beans. The EJB framework was to
provide scalable pools of stateless resources, to control access to
scarce resources on higher tiers.
Don''t put too much of your logic
inside of the EJB itself. Use the EJB
as a façade or a thin wrapper around POJO objects that do
the actual work. This design is much more testable and easier to
Use EJB only for transactional, distributed
problems. If you find that your
façade layer no longer needs to be distributed,
don''t use session beans for it.
They''re overkill for a local call. Similarly,
don''t use EJB when you only need one token service.
Whenever possible, adopt a simpler solution.
Avoid entity beans and CMP altogether. Entity
are unwieldy albatrosses that take tremendous energy to understand,
code, tune, and maintain. Better solutions are out there; find them.
No stateful session beans
Avoid stateful session beans.
better off using HTTP sessions or
databases, depending on your solution. Those solutions are more
broadly adopted and won''t tie you to EJB for the
Consider EJB only when you''ve got enough experience
and skill to deal with the inevitable issues. Don''t
kid yourself. EJB requires a lot of knowledge and finesse to pull
off. If you don''t have it on your team, get it or
use another framework.
These are just a few guidelines for using EJB appropriately. But just
to reiterate, I strongly believe that the best way to win the EJB
game is not to play.
Few will argue that XML has changed
face of Java programming forever, but not all of the changes are for
the better. XML does solve some problems very well, but it also has
XML is hard. If you''re a great programmer, you
probably think that "hard" is
overstating it. You might prefer
you''re new at programming, you may wish that
I''d chosen a stronger word: the syntax is awkward,
and the many versions often collide. If you''ve ever
needed a different version of your XML DOM classes than your JDK
provides, you know exactly what I''m taking about.
XML does seem to be getting more difficult. As it becomes more
sophisticated to solve the demanding problems of the few,
it''s rapidly succumbing to the bloat. XML can also
be slow. Depending on what you''re doing, it can take
a whole lot of time to move those bytes around. Since
it''s so verbose, XML takes longer to marshal than
other, more limited message formats.
XML sometimes forces you to define your data structures too early and
too definitively. DTDs and Schema are hard to write and often you end
up writing them once, too early in the process, and bound to them for
the rest of time. This is one of those coupling-by-decoupling
paradoxes: XML Schema is supposed to free us from long-term coupling
to a data definition, but in practice, it usually ends up just as
restrictive as all other data definition mechanisms.
Still, XML has its place. If you value decoupled software and think
that messaging models are undervalued and underused,
you''ll recognize the incredible benefits XML
delivers. It''s flexible, self-describing, and
broadly adopted. There''s nothing out there that
comes close to it. (Can you see the gold on that hammer beginning to
gleam?) These advantages drive XML everywhere, including some
inappropriate places. You don''t have to drop that
tool like it''s heated up to 400 degrees. Just be
XML is just the input, or output, for an interface. To use it
appropriately, consider the nature of the interface. XML works well
to reduce coupling by providing a standard, self-describing payload
for some type of interface. It provides power and flexibility at the
cost of complexity and performance. To decide whether to use it, ask
What will a tighter coupling cost?
If you''re building a very specialized interface with
high performance requirements, it''s perfectly valid
to live with tighter coupling in order to reduce complexity.
How complex is your message?
If it''s not complex, something simpler may serve you
well. You wouldn''t consider XML to specify
command-line parametersit''s overkill. You may
only need a simple text string, or a map of name-value pairs. Both of
these message types can be quite flexible and dynamic. On the other
hand, your message may be deeply nested, with rich schema
For messages, do you control both ends of the interface?
If you do, consider a lighter message payload. If not, XML may allow
you to have a message format that''s self-describing,
extensible, and neutral.
Do you need to bridge programming languages, or enterprises?
If you''re working across very different platforms,
XML can provide a convenient intermediate representation to let the
Are your performance requirements relaxed?
XML requires significant data marshalling. Be sure that your
infrastructure and application can afford the increased requirements.
If it''s a borderline situation, do a brief
proof-of-concepts to be sure.
Are you trying to support possible future requirements?
If you are, stop. It''s usually better to adopt a
simple solution and make sure to build a loosely coupled service that
you can adapt to future purposes.
On the topic of XML, I''m not religious.
I''m a pragmatist. XML is a fact of life. Use it when
it makes your life easier; leave it behind when it
doesn''t. If you''re a Java
programmer, you probably need XML within your bag of tricks
somewhere, but you don''t have to reach for it at
184.108.40.206 Persistence frameworks
As the programming craft advances,
developers need to think in
progressively more complex abstractions. Half of everything that you
know will be obsolete in seven years. Your brain is like any other
computer: space is limited. When you push a new piece of data
insuch as aspect-oriented programmingsomething else is
discarded. One of the skills that''s getting
progressively harder to find is good database application
programming. As a result, many developers tend to reach for
persistence frameworks and expect them to hide all of the database
details. In fact, that''s what persistence frameworks
are designed to do. The problem is that reality gets in the way. Real
persistence frameworks eventually create good or bad SQL. Real
applications are either good or bad citizens of the database realm.
It''s hard to build a persistence framework that
solves general problems well for every instance and it takes a
knowledgeable database developer to know the difference.
Persistence frameworks do have a major tangible benefit. They let
Java developers deal with an application in comfortable terms. Java
classes, instances, and idioms replace database tables, indexes, and
records. Persistence frameworks also have a cost: their abstractions
can hide problems, they can be hard to tune, and they may get
inexperienced developers into trouble.
If you have a complex data model and you''re spending
a lot of time wading through endless persistence details, a
persistence framework can save you a whole lot of time if someone on
your team knows what''s going on under the hood. But
don''t use what you don''t
understand. If database access is working and the details
aren''t overly tedious, you probably
don''t need a persistence framework.
220.127.116.11 Web services
The web services standard is
the latest in a long line of
technologies that promise to tie disparate systems together. It was
supposed to be simple, fast, and intuitive. One look at the list of
acronyms for associated technologies tells us something has gone
horribly awry (SOAP, XML-RPC, WSDL, Disco, UDDI, WS-I, WS-Eventing,
and WSA). SOAP originally stood for Simple Object Access Protocol but
tellingly, they''ve dropped that acronym.
Yet you can''t simply ignore web services. With the
potential to tie together Java and Microsoft technologies and the
strong backing of most of the players in both spaces, web services
has a meaningful niche to fill. So far, I''ve had a
difficult time understanding what that niche should be. If you look
at the basic characteristics of the technology, some ideas begin to
Relaxed performance requirements
The web services API is heavyweight and relatively slow.
It''s tough to imagine a credible use for web
services with demanding performance requirements.
Spanning languages or platforms
Java has many better native options. If you''re
trying to wrap a Java service for a Java consumer, it pays to check
one of the excellent native APIs first, such as a lower-level API
like JMS or even RMI, depending on what you''re
trying to do. Web services do have strong supporting tools on many
platforms, most notably Java and .NET, as well as several others.
It''s a strong alternative to link disparate systems,
since it''s relatively simple compared to the
Web services encapsulate a loose-grained client/service model. It
should be used accordingly. Trying to use web services for
fine-grained communications is asking for trouble.
Table 5-1 is a list of the most frequently used
golden hammers. It is by no means complete. If you look closely, you
can see a pattern begin to emerge. A golden hammer can definitely
drive in a screw if you strike it often enough and hard enough. Most
of the golden hammers that I''ve listed can do a
jobjust not efficiently or well.
Not suited for
Rich user interfaces on homogeneous platforms
Distributed transactional programming
Heavyweight enterprise applications
Controlling access to scarce resources
Simple, lightweight applications
EJB (stateless session beans, MDB)
Distributed, transactional façades
Secure, distributed transaction monitor
Applications where transactions are limited to one database
Façades that are not distributed
Sophisticated domain model
Moderate performance requirements
Relational problems (e.g., reporting)
Problems that do not present a domain model
Teams without database experience
Heterogeneous platforms and languages
Moderate performance requirements
Java to Java applications
Demanding performance requirements
Standardized data format
Message format when one team controls both the producer and consumer
High performance requirements
Simple, lightweight applications
The list of golden hammers is not complete. They do have a few things
in common, though:
Integrated frameworks and platforms claim much, but
don''t always deliver. Attempts to solve more than
one problem can break down if a framework is not easy to extend or
adapt. It''s just too hard to predict in advance
exactly how a multifaceted framework will be used in every instance.
EJB, web services, and CORBA were collaboratively designed
frameworks. They were also released before anyone had any real
practical experience with them. Frameworks designed by committee are
especially prone to problems. The open source model works because
visionaries prove their designs under the strain of real-world
problems. Most people don''t understand that most
open source projects fail. This is natural and healthy.
In the early stages, even sound frameworks can become bloated and
lose their value. While XML has unquestionably added some useful
capabilities, its practical utility is diminishing because
it''s getting too hard for the everyday programmer to
use. Web services seem to be taking this path as well.
There''s a time and place for complexity and
you''ve got to balance a healthy tension between
power and complexity. As a rule, watch out for increasing complexity.
It isn''t always true that where
there''s smoke there''s fire. In
fact, you can come up with counter-examples for each of these warning
signs. My point is that frameworks and platforms, like code, can also
smell bad. Develop your instincts, hone them with data beyond the
latest marketing hype, and develop sources that you trust.
I''ve given you a few examples of golden hammers and
other frameworks that I don''t like. While these
warning signs might steer you away from bad decisions, they
can''t help you make good ones. In the remainder of
this chapter, I''ll tell you some techniques
I''ve used to help my customers choose a good