Microsoft's approach integrates a full set of enterprise services into the Windows Server 2003 operating system. The company's product manager for the .Net developer platform, Dino Chiesa, doesn't believe Sun Microsystems Inc.'s new tools-centered strategy will bring J2EE up to par with Microsoft's fully integrated approach. He spoke with InfoWorld's Tom Yager and Tom Sullivan.
Q: How is the combination of .Net and Windows Server 2003 more powerful than the combination of J2EE and Solaris?
You have to align the right stuff next to each other. J2EE is a set of specs, not a product. Windows Server has a set of implementation characteristics. So you might want to compare IBM WebSphere to Windows Server 2003, or BEA WebLogic to Windows Server 2003. There are some philosophical differences between the two. In the J2EE world, you're seeing the evolution of the middleware mind set, which basically says, "sell a thin operating system, layer middleware on top, and that's the surface to program to." Microsoft sells a total solution. It doesn't need that middleware. It has a kernel and a set of services that is very rich. It allows us to build tools that make developers a lot more productive. Customers who looked at J2EE tell us that .Net allowed them to get projects out a lot faster.
Q: Microsoft often brings up the subject of J2EE's complexity. Certainly, if I stack up all of the manuals for .Net and the Windows API, I have a stack at least as large as the reference materials for J2EE. Are most of the productivity improvements derived from the use of Visual Studio .Net?
Tools are definitely a contributor. Our competitors have tried to build tools that are as productive as Visual Studio. When you want to build a secure Web application, it takes one line of code because it's attribute-based programming. That pulls in Kerberos and Active Directory. If you try to do the same thing with Sun's app server, you'll find there's a lot more code required just to build a secure site. Microsoft popularized this approach in COM+ in 1995. We took it to the next level with the .Net framework. And when you stack up just the reference manuals for EJB (Enterprise JavaBeans), they're as thick as all of the manuals for .Net. EJB has so many ways of doing related things, sometimes developers get hung up on "what's the right container model." It's so bad that developers skip using EJB and go with simpler technologies like Java Server Pages.
Q: Some of J2EE's complexity is hidden by development tools from companies like IBM, Oracle and Borland. None of these measures up to Visual Studio .Net, but then Microsoft has massive resources devoted just to tools. Could the J2EE programming experience be improved significantly by the introduction of better tools?
I think that's not possible. Better tools do not solve the problems that many adopters of J2EE have encountered. It stems from the lack of integration of the layers. They're separate from the operating systems. There are issues that come up in all stages of the software lifecycle. For example, it's impossible to reconcile all of the logs from the OS and the various J2EE pieces. At deployment time, J2EE rollouts take much longer just because there are so many knobs you have to tweak, and the application server is not integrated with the operating system, and those pieces are not integrated with the databases. All of the pieces are not designed to get along together. We have our Windows Server team working with our database team and our .Net team. We iron those issues out before the customers have to deal with them. None of those knobs needs to be exposed to an operator or administrator. No matter how far you take things with J2EE development tools, that larger lack of integration problem is not addressed.