In-Depth

J2EE Applications Can Be a High-Maintenance Proposition, Survey Shows

Down time, different maintenance cycles cited as problems.

• By Stephen Swoyer
• 12/02/2003

For some enterprise developers, however, a survey published late last month by Java application management vendor Wily Technology Inc. confirmed what many had long suspected: J2EE applications can be a high-maintenance proposition.

According to Mike Malloy, vice president of marketing with Wily, most organizations only average about 88 percent availability across their J2EE-based solutions. “That’s the equivalent of being down nearly a full day a week,” he points out, adding that 60 percent of users reported that a completed J2EE-based application failed to scale according to expectations. “One thing that we focused on was what level of attainment against your target have you been able to achieve for that application? If you’ve designed or built your application with a target of 1,000 transactions an hour, and you’re only able on your best day to get 800 transactions through, that’s 80 percent of the performance.”

Malloy says that Wily hosted the survey on its Web site and collected 360 valid responses. The survey was quite involved, the company says, and an entry was counted as valid if a respondent answered 80 questions. Respondents were drawn equally from large and small organizations.

While the average J2EE application availability experienced by respondents was 88 percent, Malloy says that at least half of those who took the survey reported 96 percent or less availability for their J2EE applications. While that might seem good enough, Malloy points out that it’s a far cry from the five nines—99.999 percent—of uptime that most organizations aspire to. “That amounts to almost seven hours a week,” he says. At a minimum, organizations reported 81 percent availability for their J2EE applications, which works out to a staggering 4.5 hours of downtime each day.

For this reason, and for a host of others, Kevin Kinney, a mainframe systems programmer with provider of IT solutions for the insurance industry, says he’s never bought into the Java hype. “If Java was so easy, we wouldn't need consultants, would we? But we cannot hire any Java people. We can only rent consultants, and when the going gets tough, as it does in every project, they simply update their resume and wander off,” he says, adding “In six years, we've been through five Java consultants.”

Kinney says his biggest beef with Java is that its “maintenance” cycle differs drastically from what he’s accustomed to with mainframe programming. “On the mainframe, there is a development cycle and a maintenance cycle. The first is expensive and time-intensive. The latter tweaks code to fix problems. Once an app enters the less expensive maintenance mode, it rarely goes back to development mode,” he comments.

In a Java world in which many features and capabilities are pegged to incremental releases of the Java Development Kit, this is rarely the case, Kinney says. “In mainframe terms, Java doesn't have a maintenance cycle. Instead it has a perpetual design cycle, which will always be more expensive than maintenance. Why? Java isn't mature yet, and each new release introduces a whole new suite of functions. Coders are constantly working to incorporate the newest do-dads. They may fix logic problems while they're doing this, but the main reason they're messing with code is to include more bells and whistles.”

It’s All About Complexity

For his part, Wily’s Malloy maintains that the performance and scalability of the J2EE framework itself isn’t necessarily at issue. “These numbers don’t reflect the capabilities of the platform, because frankly you can get much higher availability and performance out of the Java platforms,” he argues.

Instead, Malloy says, because J2EE applications typically cross so many different business processes and lines of business, they’re much more complex to develop, support, and manage than conventional applications. “A typical support team would be five to ten people representing developers, architects, DBAs, and sometimes network administrators and CICS programmers, if you have mainframes,” he comments. “It really takes a team approach, a collaborative approach to manage these applications.”

Over the last 18 months, BEA Systems Inc., IBM Corp., Oracle Corp., and Sun Microsystems Inc.—among other purveyors of J2EE application servers—have enhanced their application server offerings to tackle many common development, support, and management problems.

BEA, for example, has married its market-leading WebLogic 8.1 application server to a full-blown WebLogic platform, which includes an integrated development environment (IDE) and a revamped portal offering, along with BEA’s JRockit, which the company claims is the market’s fastest Java Virtual Machine.

IBM, for its part, shipped version 5.0 of WebSphere last year, has contributed the highly extensible Eclipse IDE to the open source software (OSS) community, and, as a complement to its WebSphere offering, introduced 40 different WebSphere Business Integration adapters that facilitate common integration scenarios in as many as 11 different verticals. “We’ve been putting together pre-packaged solutions that include adapters that are typical in an industry, as well as some pre-built process templates that we provide, and collaborations for the WebSphere Business Integration server or others that get you 50 or 75 percent of the way there [without customizing code],” explains Scott Cosby, manager of WebSphere business process integration.

Michael Hudson, a framework engineer for Blueprint Technologies, a software architecture firm based in McLean, Va., says that BEA, IBM, and others are taking a page from Microsoft Corp. as they attempt to take a lot of the pain out of J2EE application development. “You see a lot of these companies like BEA trying to create enterprise suites that are more than just application servers,” the a WebLogic programmer says. “These suites have started to become complete development environments with the aim of reducing the complexity inherent in J2EE. Their goal is to [Visual Basic]-ize J2EE as much as possible so as to allow businesses the ability to hire more junior developers to crank out code since that would theoretically be cheaper than hiring a team of J2EE gurus.”

Have they succeeded? Hudson says the new J2EE application server platforms are a big help, but believes that J2EE “gurus” will probably remain hot commodities for the foreseeable future. “None of these tools have eliminated the need for J2EE gurus. They’ve only reduced the number of gurus that you need,” he notes. “If a company does decide to go the J2EE route, they do need to understand that they still need a number of J2EE gurus on board, including experienced J2EE architects.”

What, Me Worry?

One of the most vexing problems associated with J2EE application downtime is that few organizations have integrated their J2EE application servers with systems management tools. As a result, Malloy says, they often have no way of knowing when a failure has occurred.

Another big issue is the interconnected nature of most J2EE application environments: If there’s a CICS transaction failure, or if the application server can’t establish a session with a database, he says, the team that monitors the application server typically doesn’t hear about it until after the fact. “We found that application code is the leading [cause of downtime], but it’s only [14 percent of the time] that it turns out to be a code problem,” he explains, noting that IT support personnel often learn that a failure has occurred only after they’ve received an angry phone call from an executive or a customer. “What you want is a team of people who can quickly triage the problem, who can then hand it to the database people if it’s a database problem, or hand it to the mainframe, or they can call the developers and say you need to take a look at what’s going on here.”

Wily’s interest in promoting its survey results isn’t entirely altruistic: Malloy concedes that the company does market a variety of J2EE application testing tools and services, and it’s possible that many respondents were drawn to Wily’s Web site in the first place (and completed the survey as a result) because they were experiencing J2EE application availability problems.

Nevertheless, Blueprint Technologies’ Hudson believes that performance and availability shortcomings are problems in organizations that haven’t done due diligence during the J2EE development process. For starters, Hudson says, IT organizations should consider investing in testing tools to vet the performance of their applications. “The other thing to keep in mind that I don’t think corporations always do … is invest in third-party performance tools and employ effective but lightweight software development processes,” he concludes.

“In terms of software development processes, it preferably should be iterative and test-oriented, risks should be mitigated up front through prototyping, and think through your deployment and scalability plans and test these plans throughout your development process.”