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 Group
Evaluating third-party tools
Does 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.