With Java 2 Enterprise Edition applications becoming more
widespread, companies must start thinking seriously about
monitoring, change management and suppliers' plan.
Applications based on Java 2 Enterprise Edition are continuing to
roll into production, but companies will have to do more to prepare
themselves to offer complete support for these applications.
Operational-level "experts" in J2EE are now beginning to appear, as
opposed to those with broader organisational expertise. These
experts are responsible for ensuring the technology operates
properly, is tuned and is properly changed. In 2004, this role will
become more formal - similar to a database administrator.
J2EE experts will also become involved with development and quality
assurance, using teams responsible for root-cause analysis and
enabling them to be tied into application updates, changes and
expected behaviours.
Overall, the emergence of J2EE applications presents several issues
to confront and new tools to consider, which means users should
watch the J2EE framework suppliers, such as BEA, IBM and Sun, to
see how they address management.
Although the enquiries received by Meta Group illustrate that users
are concerned about J2EE management and are seeking tools, budgets
are not being allocated. Companies are being forced to eke out
funding from anywhere they can, which often means the application
development budget.
J2EE tools are likely to receive operational budget attention by
2006, but that purchasing will remain mostly reactive until then.
Most organisations address the problem of monitoring first, with
about 15% to 20% of J2EE users having invested in some type of
management tool. By the end of 2004, 25% to 30% of companies are
expected to have invested in third-party J2EE monitoring, rising to
50% by 2006.
As the applications become more critical, the root cause is
increasingly important, but few organisations have addressed this
issue. Root cause will be a key driver of reactive J2EE purchases
throughout 2004.
J2EE represents a complex set of technologies. The proper virtual
machine, J2EE connectors, and Java Database Connectivity
interfaces, among other components, must be present. When one part
of the J2EE environment changes, or the application itself is
altered, it may mean an upgrade is necessary or it may present
other incompatibilities, leading to complex changes. Currently,
J2EE change is mostly manual as the applications are relatively
small. By 2006, applications will have expanded to such a level
that change will have to be automated.
A lot of companies are waiting for application server suppliers to
provide management. BEA will release additional operational
monitoring within the next few months, but it is unclear how much
technology will be included or how much will be made available for
sale.
IBM has made it clear that Tivoli is its preferred management brand
company-wide, but it has not yet started pushing Websphere to
users. By 2005, Tivoli is likely to become the IBM-recommended
solution. (Currently, IBM Global Services recommends other tools.)
Other application server companies, such as Sun and Oracle, have
not made their management intentions clear. Organisations should
ensure that third-party suppliers are using well-supported data
sources or have ties to the development groups of the application
server supplier to minimise risk.
Companies are finding evaluating monitoring tools a challenge, not
only because of their relative inexperience with J2EE, but also
because of the many interested parties attempting to influence
purchasing.
From application developers to database administrators to quality
assurance analysts, there are more people interested in J2EE tools
than in most traditional monitoring. This is because of the
ambiguity over operational support, leading to many diverse
audiences owning some level of support and desiring data.
Management tools are still expensive, but prices should begin to
fall as soon as competition takes effect.
The management of J2EE environments is maturing. The tools are
available, but if organisations are to avoid a poorly supported
environment, their priority must be to clarify internal ownership
of J2EE operational support.
Corey Ferengul is vice-president at Meta
Groupwww.metagroup.comEvaluating third-party toolsDoes it work?
Some of the J2EE management tools are so immature that Meta Group
cannot find a good reference. Before investing time in evaluating a
supplier, look for public references and ensure there are real
users.
How is monitoring performed?
Tools either perform external observation, collecting data from
numerous sources external to the J2EE environment, or they embed
collection - code is embedded directly into the application or
wrapper containers to collect monitoring data.
Both are valuable in different situations, with the embedded type
tending to be more detailed, but requiring more effort and overhead
(although the overhead issue is minimal). Users should seek
suppliers that offer both collection methods. By 2005, they will
all offer multiple collection options.
Where does a tool obtain its data?
Java Management Extensions (JMX) is the most common data source,
although the Websphere JMX is not as mature as the Weblogic JMX.
However, collecting JMX is not sufficient and additional sources
exist for suppliers to explore. JMS and JVM data are necessary for
most users.
What is J2EE capable of?
Companies should begin making strategic J2EE management
investments. As the application becomes more critical and complex,
users should not be evaluating tools - they must be actively
managing. In making strategic choices, users should understand the
breadth of a supplier's offering, beyond simply monitoring. Quality
assurance, testing, debugging, root cause and change management
should also be offered.
Ability to map relationships
There are many complex object relationships within a J2EE
environment, but it is possible to access those relationships and
map them. This map will prove valuable in root cause and impact
analysis.