Interview: The Java Web Server team gives you the skinny

In recent months, JavaSoft has taken steps to release its Java Web Server as a commercial product. Built in Java, Java Web Server (previously named Jeeves) includes the Servlet API as a way of dynamically extending the server’s functionality. Servlets written to this API can work with modules written for Netscape, Microsoft IIS, and Apache servers. Many developers have been eagerly awaiting the commercial release of Java Web Server as a supported path toward writing server-side functionality in Java. In the following interview, which includes a sidebar on server-side Java companies, you can find out what the JavaSoft team behind Java Web Server has to say.

This interview was conducted with the following representatives of the Java Server team at JavaSoft: Carole Amos, product line manager; Sandeep Khanna, engineering manager; David Brownell, staff engineer; and Satish Dharmaraj, project leader and staff engineer.

PIC: I have the notion that server-side Java has been somewhat neglected up to this point. It has the potential for coming much more into the limelight and attracting a lot more interest. Any thoughts?

Carole: Back when the project was started, Java was very Web-oriented and people hadn’t started pushing it into the enterprise or enterprise applications yet. So the server group started building a lot of foundation classes and capabilities, and the project kind of morphed a couple of times. Alpha went up on the Web site maybe two months after JavaOne last year, and that helped us get a lot of good feedback about what the product needed to do.

Satish: Alpha Two came out shortly thereafter, in October 1996.

Carole: Then we really started focusing in on the underlying foundation, the capabilities people wanted as the basis for their server, things like administration, security, and all of the server management: thread management, connection management, session management. In the meantime, people were working on creating services on top of this stuff: HTTP and proxies specifically for the Java Web Server. So we went out beta in early March with the Java Web Server, and we are now working on finalizing a Java Server Toolkit product.

[A presentation is displayed on a laptop, showing the Java Server architecture.]

This lays out how we think of the Java Server architecture — protocol-independent foundation classes with the Server API on top of them. [The diagram shows the following foundation classes: Admin, Security, Thread Management, Connection Management, Session Management, and Custom Classes, with the Server API on top.] This is what we’re going to provide to the marketplace as the Java Server Toolkit. And on top of that we build HTTP and proxy services and the binary of all this is the Java Web Server.

Now we see people using this by either taking the binary product and adding capability to it through servlets, building their own service packages out of servlets and redistributing them, or actually licensing the Server Toolkit and building servers based on that. And we’re seeing these going into middle tiers, if you think of a three- or four-tier client/server architecture. So these are connecting basically with applications either to database servers on the backend or other databases.

We have some customers, people who’ve expressed interest, who are middleware vendors. We’ve seen people build things like an interactive learning system that’s fetching HTTP information from data repositories, instructors using it on a Unix machine, and the students are all on PCs. So the platform independence feature of the Java Web Server is very interesting to people, as well as its extensibility. Those are two features that people really key in on. It’s like, “Oh, I can extend this from a standard language to a standard API,” and because they’re written to the API, those extensions drop into the existing administration and security capabilities of the server, and I can put this on any platform that’s got the JDK.

PIC: How is that Server API related to the Servlet API?

Satish: Servlets are part of the Server API. That’s how I would characterize it. Server API is a bunch of things: it’s administration, it’s security, it’s logging —

Carole: It’s the API for all of these classes [points to bottom of architecture diagram].

Satish: So with the Server API you can build a server. For example, we built a Web server using the Server API. Servlets are add-ons, like extensions to a server. So, a good example is you build a Web server using the Server API, and you write servlets to do things that you would have traditionally done with CGI-bin scripts, for instance, or any of the other platform-specific APIs that are out there. You would use servlets instead to do your platform-independent extensions to your server. That is the analogy that captures the relationship of server to servlets.

PIC: So the services are groups of servlets that are built to the Server API?

David Brownell: Could be. You could build a server in that way. There are a lot of different ways to build a server. If you look at the way networks are run today, there are — I’ll just pick a small number — 1,000 different protocols out there. For many of those, servlets are really good, as servlets are really well-tuned to certain kinds of protocols. We can build other kinds of servers with this Toolkit, binary servers. There are people out there who are rolling their own server technologies, their own thread management, logging, security stuff. These people are very interested in getting out of that infrastructure business. They want to have JavaSoft help them focus on their particular value add.

Satish: And it gives you a unified administration audit. So you have all these servers that often have the same look and feel from the admin tool. And the uniform way of extending those servers, servers built on our Server API, is by using servlets. That’s what we’re trying to do. We’re trying to come up with a standardized way of helping developers build servers as well as extensions to those servers.

PIC: What I’m trying to get at here is the extensibility. Is that the layer that you’re talking about, as the extensibility? [Points to Server API] Or is it also this? [Points to services]

Sandeep: It’s both. What we’re trying to provide is (A) an architecture for the server-side solution. There’s none. Everybody’s doing different things. Here’s a coherent model of doing server-side. (B) Provide extensibility for writing services. For example, we would be using the same Toolkit that we have used to develop the Web server to develop our NC services. Once we’re writing those core competencies, we could extend over time to provide the greatest number of protocols. For example, we start with NFS protocol on the file service. We could extend that to encompass DFS or some other file protocol after that. So it’s extensibility on both levels, which is (A) at the bottom level, at the Toolkit level. If you want to add more security functionality, you could add that at the Toolkit level and make it available to all the services that you write. And (B) actually extend the services that you write.

To summarize, there are three points: One is the extensibility at both the Toolkit level and the services level. And another point is the dynamic part. You can load the services dynamically and then you can extend them dynamically using servlets. Third would be common security and common administration.

PIC: How do you guarantee that the services are extensible through the Servlet API?

Satish: First, they’re all Java and they’re not final classes. And we’re designing the APIs in such a way that you can override methods. There are protected methods that you can override and define your own functionality. An example is with the Server Toolkit, as the Web server and CGI bin. Or you could build, for example, a mail server using the Server Toolkit and use servlets to do filtering of mail. Or if you build a news server using the Server Toolkit, threading of newsgroups you could do with a servlet. Those are the kind of analogies that I can give you.

David: There are a lot of other protocols in addition to text-based protocols. For example, we see RMI [Remote Method Invocation] right there [points to diagram with RMI going into and out of a service]. We’ve had customers say they want to be able to leverage the facilities in the server. And they also take advantage of RMI. So RMI is another technology that has a server-side component. What people really need to be doing, they’re starting to look at Java as not just a client application framework, but also a client/server full application and we’re starting to get in the business of making sure that both sides of that equation are working together.

PIC: And in a way, this is the more ambitious side of it.

Sandeep: The client side is the easier part. This is a lot tougher problem. The expectations are a lot higher. You have to provide connectivity with all sorts of legacy applications.

Satish: And everything is exaggerated. Like the security is much more crucial on the server side than it is on the client side. And we’re doing things like downloadable servlets. We made a real special effort to make sure that the server sandbox is well defined and secure. And all that functionality we added in even before we released network-downloadable servlets. We made sure the security was in place.

PIC: That brings up an interesting issue. Are you sort of leading security issues or are you following them?

Carole: I think that where we’re trying to take our platform, we certainly have gotten ourselves onto the forefront of customer needs. And we’re trying very hard to make sure that security is thorough and always built in from the ground up with everything that you do. That’s one of the big benefits of the Java language and the virtual machine. So we certainly strive to enforce that and reinforce that in our products.

Sandeep: As far as this part is concerned, we are providing very good security mechanisms. One of the key things that we’re providing here, which leverages the JDK 1.1 functionality, is the servlet signing support.

David: I talk about that kind of capability as part of directions for future JDK work, much more enhanced facilities in that area.

PIC: Despite deficiencies with AWT, in a way Java got pegged as an animation language for the client.

David: But people could see, real easily, anyone who can download and run Java in their browser could actually see: “Hey, I have the vision here. I can download this code. I can do better graphics surely in the next release, I know I can.” But it was on every user’s desktop and that’s probably why it had such appeal.

Sandeep: I think we turned the corner on the server side. The response that we saw [at JavaOne] was tremendous.

PIC: Right. Now, the markets that we’re referring to here are basically tool developers and also corporate enterprise developers?

Carole: I think those are going to be some of the initial markets.

Sandeep: IT. IT is looking to deploy this in a big way —

Carole: Because they’re forced to deal with heterogeneous environments. And they think, “Oh my gosh. I could put this on any platform.”

Sandeep: Then there are loads of needs that they have that they want to extend over time. And this framework that we have provides them with the first step to easy extensibility. On any platform.

David: They want to be able to develop tools, component class libraries that can run anywhere, on any of those tiers. That means they’re going to have Java on the servers, not just the clients.

Sandeep: ISVs are very interested in this. Financial people are interested in this. We talk to lots of people.

PIC: In essence, it’s the custom application business.

Sandeep: Yes. That’s why we want to provide the base framework to people so they can leverage off the work we’ve done.

David: Absolutely. Custom applications are always leading-edge sort of stuff. They’re always pushing the curve.

PIC: Does this mean that you’re entering the official intranet/extranet market that is currently dominated by certain other companies, or are you confining yourself to a certain niche or a number of niches?

Carole: Well, one of the big missions at JavaSoft is to make our partners successful. And one of the reasons that we feel we’ve succeeded at that is by working hard to provide standard APIs and capabilities for things that are non-differentiators that everybody has to do. So certainly that is a big direction with our Java Server Toolkit. As people have said, folks are getting tired of rolling their own stuff, and the fact that our product happens to be in Java just adds to its appeal. Now, certainly with the Web server, we believe that we have to be out there in the marketplace so we understand the customer issues and we get the feedback. So Web server is our entree into that marketplace.

Sandeep: The good part is our Web server runs on any platform and has the same administration on all platforms. And it’s small enough to be embedded in lots of applications. The other thing that we have that other servers don’t have is the capability of providing your own custom protocols at the back. Because our own Toolkit is totally protocol-independent. We’re actually trying to get the ISVs to leverage off of that work and build their own services for their own protocols, which is a unique feature that nobody else in the industry has right now.

PIC: In other words, it sounds like you’re making a very big push into this market. You really want to be competing out there.

[Laughter]

Carole: We certainly are going out into the market with this. We believe that this is a very interesting space to be in. There’s lots of places for people to go with this. You’ve heard about the different ranges of Java — expect to see us everywhere. I think this is certainly one facet of that strategy.

David: You asked if we’re going big into the market? So what about those other people there? I think everyone in the market benefits from seeing some commonality of core functionality.

PIC: Let’s say you were just going to extend the JVM and all of a sudden you get all kinds of server-based capabilities that come with the JDK, essentially. That’s a little different than: You’re coming out with this server architecture and an actual product, and a toolkit. Which is all very welcome. But it’s a different stance in the market.

Carole: Well, there are some spaces that we have said nobody was there and we decided to push in that direction with the product. And we definitely do want to be out in the marketplace competing with these products, because otherwise we are not going to know enough of what is really needed in the base capability.

David: And there are also examples in this area where we have focused in on server-side problems and those have led directly to improvements in the JDK and the core set of APIs.

PIC: That is what I was getting at. Yes, I would be very interested in those details.

David: I can give you two examples. One is some of the security APIs. Access control lists, just as one example. There are also networking APIs, a variety of improvements in the Java.net classes came because we said, “We are going to rate servers, and we need to be able to do the following sorts of things.” Things like binding to different interfaces on a server that has multiple network interfaces. Things like defining new kinds of sockets, subclassing them. Things like having options on sockets, so that you have fine-grained control over the behavior of, say, TCP. Those are examples of things that — we weren’t the only ones, but we certainly pushed on this and were really helping the JDK team to make sure these things got addressed in JDK 1.1.

PIC: So, any predictions for what’s going to happen here?

Carole: Define “here.”

PIC: I guess what you’re proposing is a very extensible and uniform environment on the server side. That’s a very enabling concept.

Carole: I think we’re going to be working very closely with third parties, primarily with ISVs to make sure we’ve got all the right sort of things in the APIs. These will be people who are both in business as developers and IT organizations. Then I would see a wave of people who are strictly VARs. Once the word about Java on the server side gets out there and once people are using servlets to extend functionality, there are going to be people who will take the binary product, add value to it, and redistribute it. I think we’ll get into the vertical markets that way.

PIC: Do you think this is going to be a significant step in, say, getting Java out of the browser and out of quote/unquote the Web?

David, Carole: Absolutely.

David: Moving beyond it.

Sandeep: I personally think that lots of VCs are going to focus on funding server-side applications.

PIC: That’s a good prediction.

Satish: We talked a lot about Server Toolkit and I think it’s one of the most important things we’re going to do over the next few months here. We’re going to also focus on the Web Server. It’s not just a by-product we built. It’s a real product that has a really swanky admin tool. You’re a member of the news area so you’ve been reading the kind of stuff that we’ve been getting — a lot of people have been saying that the admin tools are much better than anything that’s out there today. It’s all dynamic, extensible, platform-independent, and you will have commitment and support from us with regards to that product. I just want to say that the Java Web Server is real.

Carole: We’ve done some estimated SPECWEB work and performance is looking pretty damn good.

Sandeep: What we have to do to conform to the benchmark is submit a proposal to SPECWEB, and they need to approve it before we can say anything official. If we say anything before then, they won’t be too happy.

Satish: You can say we’re doing better than Apache on the SPARC platform. We’re running on NT and are being comparable with all the other popular Web servers.

David: And getting better all the time.

PIC: The last issue that I have right now is the concept of server-side Java APIs on other Web servers. I get a lot of questions about that. People are wondering what they’re supposed to do. Supposedly Netscape has killed their original API and is moving toward something else. Are they really, in fact, moving toward your servlet API?

Sandeep: You should ask Netscape that.

PIC: I know that. But, from your perspective?

Sandeep: From our perspective, we will make servlets ubiquitous by providing support so that you can run your servlets in most popular Web servers out there, whether it’s Netscape, or IIS, or Apache, or what have you. Tomorrow when some new XYZ server becomes the most popular server out there, we’ll make servlets run there. That’s what our position is. And the JSDK, which is the Java Servlets Development Kit, comes with a mini servlet tester. So you can develop your servlet and test it, and then you can decide which server you want to deploy it under. Since the Java Web server is written in Java and has capabilities to load servlets, they run faster on the Java Web Server. We have support for you to run the servlets on all the servers that are out there. That’s our party line, then.

PIC: How true is that? Can you, just through NSAPI, for instance, dig in deep enough to Netscape Enterprise server to do all the same things you would on the Java Web Server?

Satish: The servlet API is completely potent under Netscape. So anything you can do with the Servlet API, you can do it under Netscape.

David: That works today.

Sandeep: Let me try to recap. (A) We could provide Servlet API, both the interface and implementation, for anybody to embed themselves, natively. (B) We would embed and provide the modules for popular servers. We’re working with other vendors, and I think the demand will drive the native support in those respective servers.

On our side, the advantages people will see if they use our server will be common administration, dynamic extensibility, loading and unloading, and all that functionality that people like. On the other servers, until they provide the Servlet API in native form, developers may not see some of those capabilities.

PIC: So that creates some pressure in that direction.

Sandeep: I think the market really drives this.

Satish: Yes, we want developers to ask for servlet support in other servers, and that’s how we want to play this game. We don’t want to push it. We are offering full technology here, and we hope it’s going to be accepted by the developer community. That’s how we want to do things.

David: Do you know, for example, product schedules? When could other companies incorporate the technology? That’s a different set of issues.

PIC: Netscape finally delivered a 1.1 JVM in beta 3 of Enterprise server 3.0. The server is way behind the browsers. Then there is the issue of how the Servlet API will be incorporated. That’s a whole other discussion.

Conclusion

Whether developers are seeking the benefits of on-the-fly administration or dynamic loading of servlets, Java Web Server is now a commercial product that clearly has a team committed to its ongoing support.