Java Reference
In-Depth Information
vendor's product, is often a recipe for disaster. Support is
critical and if your vendor doesn't directly support a particular
technology, you should carefully consider if you should use
it. People tend to focus too much on easing the development
process and neglect to consider the long term consequences of
depending on large amounts of code developed outside your
organization which is not supported by a vendor. Many
project teams are enamored with new technology (for
example, the latest open source framework) and quickly
become dependent upon it without considering the very real
costs to the business. Frankly, the decision to use any
technology beyond what you've bought from your vendors
should be carefully reviewed by corporate architecture,
business, and legal teams (or their equivalent in your
environment); just as normal product purchasing decisions are
evaluated. After all, with rare exceptions, most of us are in the
business
of
solving
business
problems,
not
advancing
technology for the sheer fun of it.
Plan for Java EE security proactively
Turn on Application Server security. Lock down all your
EJBs and URLs to at least all authenticated users.
It's a continual source of astonishment to us how few
customers we work with originally plan to turn on
WebSphere Application Server's Java EE security. Only
around 50% of the customers we see initially plan to use this
feature. We have even worked with several major financial
institutions that did not plan on turning security on; luckily
this
situation
was
usually
addressed
in
review
prior
to
deployment.
