Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

Interview: The Java Web Server team gives you the skinny

Is JavaSoft serious about server-side? These folks think so!

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone

Page 2 of 7

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.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources