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.
