Scott Dietzen, the chief technology officer of BEA Systems, is well-known in the Java community for his role in helping launch the server-side Java standards that became Java 2 Enterprise Edition (J2EE), and as a key contributor in the formation of the Java Community Process. In this exclusive interview, CIN talks with Dr. Dietzen about how the Java and .Net worlds co-exist — and compete.
Is there room in the enterprise for both Java and .Net?
Yes. Java and .Net are going to compete and co-exist. There are tens of thousands of production applications in Java around the world today, and Java is clearly not going to be moved out of the enterprise by .Net, at least not any time soon.
I also believe, however, that .Net is going to achieve critical mass as well. Partly because of the power of Microsoft but also because the architecture is quite good. .Net borrows a bunch of ideas from the Java community, and to be fair, it introduces some new ones that the Java community is borrowing back.
Is this a good thing?
The competition is very good for technology end users, it drives innovation, and it drives price competition, which goes along with innovation. And frankly, the competitive threat from Microsoft helps keep the Java community cooperating as well, and moving forward.
What does that competition look like?
Well, both Java and .Net span platforms. They each work on very small wireless devices like phones and PDAs, and they both have a client side that supports the PC environment.
The Java community — and BEA — obviously has invested a lot of effort on the server side. With the launch of the .Net application server, which will be released early next year, Microsoft is clearly going to compete for that business as well.
Will this force people to choose one platform or the other?
No, no one need make a monolithic decision between Java or .Net. In fact, most large IT enterprises won’t be able to, because they’re going to be using both.
And Web services is what allows them to talk to each other?
It’s the shared XML Web services stack that allows a customer to build a Visual Studio application on their PC, or use a Microsoft smart phone or PocketPC and talk directly into a WebLogic server, or a WebSphere server or another J2EE technology on the server side.
And that same model works in reverse, J2ME mobile devices, J2SE, the PC client Java applications, can call into .Net services over those same Web services protocols. That is a key part of the co-existence.
And don’t forget that you can run Java on Windows. Windows is our second largest server platform today. People do deploy WeblLogic on Windows servers, although at least at this point, not at the same size level as systems on Sun or HP-UX or other RISC processors. But Windows is quite a popular deployment platform. People are not just using it as a development platform.
So you can build applications which integrate both worlds?
You certainly can. We’re already seeing people do client side in .Net and server side in Java. In general, though, it’s easier if you can stay in one environment. For any one particular server application you probably want to stay in either Java or in .Net. You don’t want to introduce too much hetrogeneitity within an application.
So today, if someone is running WebLogic on the server side, and Windows clients, how do they connect?
If it’s an existing Visual Basic, or Visual C++ application, the most common model is to use COM. BEA has a COM linking technology that allows us to tie in COM components on both clients and servers. If it’s a new Visual Studio application, however, you’d probably go through Web services.
Is there a performance hit with Web services?
Yes. XML is indeed a more expensive encoding than passing binary objects back and forth between two systems. Expensive in terms of size, and in terms of processing cost. The size is easy to address. If you zip an XML document, it will almost certainly be smaller than the best binary encoding you can come up with. So for networks that are lower bandwidth, there are very easy ways to take care of XML size issues.
The processing costs are real. It’s not out of line to think that you’re going to double the processing cost for an XML communication over a binary object communication.
But I would argue that the same thing is true for HTML. And the reason that HTML has been so successful is this notion of loose encoding. HTML and XML allow you to make significant changes to either side of the network, without breaking compatibility.
If you’re building a new application, it makes sense to stick to either Java or .Net. But when you’re talking between two different applications, then XML and Web services are your best bet. Even though they’re a little more expensive in terms of CPU time, the overall robustness and ease of development vastly outweighs that processing cost.