eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
With Symantecs acquisition of Veritas in the summer of 2005, the combined companies took on the challenge of extending Symantecs role as a protector and manager of desktop systems into the enterprise data center. On the eve of this years JavaOne conference, Technology Editor Peter Coffee spoke with Bob Maness, vice president of product operations in Application Performance Management Solutions for Symantec, in Cupertino, Calif., about the mandate to make Java a more manageable platform and the opportunities that Java technologies and standards afford to that end. Also participating in the discussion was Product Marketing Manager Sateesh Narahari.
Whats the connection between Symantecs application-performance management offerings and the issues that are on the agenda at JavaOne?
Maness: During development, the developer is often not so much concerned with performance as with putting the pieces together. Only when the application is put into production does the developer find that the application did not behave as expected. So its all about pushing application performance into the tool suite thats needed to manage the data center to the service levels that IT is being held to. Its helping developers meet expectations throughout the application life cycle.
In Javas early years, its demands for processor and memory resources often eclipsed its strengths. Has 10 years of Moores Law progress overcome those issues and let Javas advantages emerge from that shadow?
Maness: Javas made great strides in the enterprise, and were seeing that in the explosive adoption of Web-based applications that are built on Java in online banking, ERP [enterprise resource planning], all the multitier applications. Javas the fastest-growing tier in that end-to-end application transaction path.
Another thing thats helped Java is the introduction of .Net. Microsoft now talks a lot about doing the same things that Java does, and it makes Java look more mature by comparison. Customers see a role for .Net on the front end of an application, and Java on the back end. What theyre saying is that there are some cool things that .Net can provide, but it introduces some immaturity in manageability and performance, while Java has more mature tools.
Guru Jakob Nielsen offers advice on designing applications for usability.
Click here
to watch the video.
Developer tools have always relied on Javas end-to-end object orientation to allow better insight into code, to tell the developer things about the code with more specificity and more transparency than with other programming environments. Does that carry over to the management side, with Java giving better access to the knobs that control the black box?
Maness: Its more exposed, but, like any exposure, that can create initial difficulties in management. Having more flexibility in building code and more components exposed is not the same as having standard ways of managing those components. If you look at the mainframe world, over time you got very mature ways of managing that environment.
The Symantec i3 tools started out as ways to manage databases. As Web-based applications became more important in enterprises, we saw a need to manage not just the Java tier—the Web application server tier—but also the effects of that tier on the others. IT management is being held accountable for the whole end-user experience. When youre doing a shopping-cart transaction and you get an hourglass and you walk away, the application didnt do its job—even if everything was up and all the code was working fine.
Next Page: “Application problems.”
2
There are classic mistakes in Java programming, things like string manipulations that create huge overheads and that developers learn to avoid at the level of application code. Are there similar types of common errors that you encounter at the level of end-to-end application performance analysis?
Narahari: Developers are sometimes negligent about object creation and the management of object lifetime. They assume that Javas garbage collection will handle everything. We look for leaks and for repeated object creation. Fixing those problems can give a lot of improvement.
The second area we see is interaction between the Java layer and the database layer: Your optimization in [JDBC (Java Database Connectivity)] code can give a lot of performance improvement, and its important to be able to correlate whats happening in J2EE [Java 2 Platform, Enterprise Edition] with whats happening in the database. When you can see that connection, you find yourself saying, I didnt realize that the query would execute like this; let me change my JDBC statement on the J2EE side.”
It sounds as if you have to maintain a perspective on the full stack, so that youre never limiting yourself to solving “Java problems” but always thinking about “application problems.”
Maness: That is exactly the way we built the product. We took a blueprint of the application transaction path. We said, OK, if you really look at performance, you have to have information from each point in the path as well as the network itself. [That lets you] get a real breakdown of what response time means and, if you have a problem, where to find it and troubleshoot it.
Not just each tier, but each component within the tier—in the database, the tables and views; in the Java tier, the methods and strings. These things get complex. At the end of the day, the value is not in managing a silo or a segmented tier but in managing that tier in the context of what the user is doing.
Looking at the arc of complexity of Java, its almost hard to recognize the language that we first saw in the late 1990s—but the last two years of JavaOne conferences have seen growing emphasis on manageability. Are there any key Java technologies that you expect to see highlighted at this years conference to help developers handle enterprise workloads?
Maness: I think there will be a lot of discussion around instrumentation: around understanding complexity without hogging the server CPU so that the instrumentation becomes a problem in itself. Thats central to the way were looking at the world [and working to make it] so that J2EE becomes more manageable.
Narahari: One [Java Specification Request] thats very interesting to us is JSR 168, the portlet specification. Our interest is in the adoption of that standard by the portal vendors, which is very much in the interest of the customers.
Maness: Thats right. And our [i3 version] 7.5 product instruments and manages performance on any JSR 168-compliant server. That really expands the activity that were doing around performance management, and its the JSR were most interested in driving forward and being part of.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.