If you asked me what the theme for this month's WLDJ is, I'd have to say "performance and scalability." I was once asked, "What is the most scalable way to build a J2EE application?" "Let's just find the holy grail while we're at it!" I thought. The question is quite common among J2EE developers but not an easy one to answer, even with a stack of ECPerfs up your sleeve. So I did what every good football coach does when it's fourth and long. I punted. Actually, I answered with a few questions, "By scalable, do you mean an application that can increase its users without a significant degradation in performance? Or do you mean, 'How many developers can you throw at this thing to get it done more quickly?'" My associate wanted to know the former, but I sparked enough interest to discuss the latter as well.

I use WebLogic because it's scalable and performs well, but that's not the only reason. I use it because it's easy to develop with and easy to administer once development is finished. It scales well to a large development group for several reasons. First, the install is simple and easy to duplicate across development machines, which allows each developer to have the same environment.

WebLogic is (and always has been) configured through files, whether they are Java properties files or XML files. This feature allows easy customization of server environments with or without tools (I'm thinking Notepad here). Also, files are easily stored under source-code control and can be customized per developer and in an automated fashion. On the other hand, WebSphere utilizes a DB2 database for configuration information and is a bear to configure, with or without its administration console. I know what you're thinking, and yes, I've worked with WebSphere on more than one occasion. Each experience was a reaffirmation that its technology is ages behind WebLogic's.

WebLogic has also improved its administration features tremendously from the 5.1 to the current 7.0 release. It is by far the most highly supported application server by third-party vendors in the application monitoring space. Its management and monitoring backbone is based on JMX (Java Management Extension). This is the key to allowing WebLogic to scale beyond a product to a platform that integrates seamlessly with add-on tools and products from other vendors as well as BEA.

I've mentioned numerous ways to think about WebLogic's scalability from the perspective of development and administration. It's food for thought; however, this issue also has articles from experts on WebLogic performance and scalability of the kind you are most familiar with - raw speed! Peter Zadrozny, chief technologist for BEA Systems, Europe, joins us this month with a modified excerpt from his book, J2EE Performance Testing. In it, he focuses on the performance results his team gathered during their study of WebLogic Server's JMS implementation. Philip Aston looks at "The Grinder: Load Testing for Everyone," an open-source performance testing tool. Also, we have an article on WebLogic performance tuning from Srikant Subramaniam and Arunabh Hazarika that covers many of the knobs and buttons you can twist and turn to make WebLogic hum, whether the knob is on an EJB deployment descriptor, the Web container, or a JVM argument. This month's WLDJ will show you how to make WebLogic scale to meet the masses, whether in development or production.

I'd also like to introduce a new WLDJ column, "In the Admin Corner," which features information that will make life easier for system administrators of WebLogic applications. As more applications are put into production, this is becoming a hot topic.