Tue Dec 9, 1997
| Hello and welcome to Java Live. Our guest today is Satish Dharmaraj, project lead for the JavaServerTM team. The server team has been active--you may have noticed recent Early Access releases for the JavaTM Web ServerTM (JWS) and JavaServer Toolkit (JST). Feel free to send in your questions about either of these productsor the JavaServer or servlets. | |
| Satish, I've read little about JavaServer. But I am curious, will it take advantage of JACL? What about TCL/TK? | |
| There is no plan to integrate JACL or TCL/TK with the toolkit. There is a technology that we currently have called "page compilation" that allows one to write JavaTM code in web pages. We will enhance that to support beans, so you can access JavaBeansTM components from your web pages. | |
| My apologies for not being particularly astute about JavaServer. Can you describe in a nutshell how I would exploit JavaServer over say, CGI or a "roll your own" RMI object server? | |
| That is a two-part question. As far as CGI goes, we have a way to load and instantiate Java servlets with the JavaServer. Servlets are an easy, extensible, platform-independent way to do the same thing, and it is about an order of magnitude faster.
When compared to RMI, the JavaServer Toolkit is positioned as follows: Using the toolkit one can write a network service. For example, we wrote the Java Web Server using the toolkit. So it is a server development platform. It does not contain ways to remote objects like RMI does. But if you are writing a server that talks a particular protocol (like DHCP, LDAP, NNTP, or your own fancy protocol), then you can use the toolkit to build robust, secure, dynamically-administrable server using the toolkit. | |
| What is the target release date for JWS 1.1 and the corresponding JavaServer Development Kit (JSDK)? | |
| We do not give FCS dates for JWS, except to say, "Real soon now!" | |
| Could you please tell us about the plans regarding updates on the JSDK? Will it be updated as frequently as the JWS? Also, could you please discuss the toolkit and how it fits in with/extends the JWS? | |
| The Java Servlet Development Kit is being rolled into JDKTM 1.2 as a standard extension. Standard extensions are APIs in javax.*. So you can expect to see javax.servlet.* and javax.servlet.http.* in JDK 1.2. So to answer your first question, JSDK will be updated as frequently as the JDK moves forward.
The relationship between JST and JWS can be explained as follows: JST is a framework using which one can build network services. We have built a number of vertical server apps on top of JST. JWS is one such server that we built. So JWS will inherit all the functionality of JST and then its own HTTP web server specific functionality to it. | |
| Will the HTML generation package be in the next beta of JWS, or in the next release? | |
| We are still debating what kind of HTML generation support we should have. The three options we have are: a.) a template-driven mechanism, b.) an object-driven mechanism, or c.) an HTML-generation package chosen by users. We have chosen "c" for both beta and FCS. In the next release, we will address this issue further. Is there a particular choice between a, b, and c that you would like to see happen? | |
| So the idea is that object services are done in RMI, CORBA, or Enterprise JavaBeans (EJB), but protocols are done with the JavaServer? | |
| That is probably right. Although, one can very well imagine an EJB server or a CORBA server written using the toolkit. Basically write a server that talks the IIOP protocol. But you are correct in the above statement. I would like to add that we can export servlets and servlet beans from the JavaServer and access it via an URL. | |
| So, to return to the JSDK, will I be able to run servlets in the same way from Microsoft's IIS as I can with the current JSDK? | |
| Support to run servlets in IIS, Netscape, and Apache will be available from other ISVs. Our web site has a list of vendors from whom you can obtain production-quality support for servlets on these platforms. One or more of the platforms will also migrate to having support for servlets natively. We did the initial support to run servlets on IIS, Netscape, and Apache to enable the ISV industry to take over. Now that this has happened, we are not going to support it from the JavaServer Development Kit or JDK. But we will provide a list of vendors who do support it. | |
| Regarding HTML generation packages, I guess I'd like to see a package supplied by SunTM that would be placed in the JDK and could be used by any Java application. I haven't found that many packages out there yet, at least not many free ones. One thing we're struggling with is composing editable HTML forms that consist of text from a database. In that case, a template-driven mechanism would work nicely I think. | |
| I didn't spend much time with JST yet. But what is the servletbeans/ directory supposed to be for? The sample bean doesn't seem to be any kind of bean. Is this a step towards server-side beans? Enterprise JavaBeans? | |
| In the JST we support what are known as "servlet beans." This means two things. First, you can instantiate servlets from .ser files or from .jar files.
Second, once you install a servlet (which is a bean) in your server, you can set its properties using the admin tool. So basically we introspect and put up a property sheet editor on the admin tool, which you can use to set the servlet init properties. The servletbeans/ directory can be used to drop .jar files that contain servlet beans. This is a step towards server-side beans using servlets. EJB is the way to do beans that encapsulate business logic used in transactions. One can imagine a servlet being a client of an EJB, so that you have a web-based access for Enterprise JavaBeans.
As far as the sample bean goes, it is a simple bean that follows beans design patterns for properties and is an example of how to use a .jar file and a property sheet editor using the toolkit. You can just: a.) Drop it in the servlet beans directory. b.) Edit its properties dynamically. c.) Replace it with a new JAR file in the servletbeans/ directory--the server automatically picks up the new .jar (code and properties). We call this "hot swapping" servlet beans! | |
| I have two business questions: 1.) Will Sun/JavaSoft enhance the JSDK add-ons for NSAPI and ISAPI, or will this be left open for ISVs?
2.) Will Sun/JavaSoft develop high-functionality servlets, or will this be left open for ISVs? | |
| 1.) Yes, we will enable the ISV industry to support servlets in other servers. 2.) While we want to enable the ISV industry to support high-functionality servlets--I cannot say that JavaSoft will not be in this business. But, yes, we do want to do everything possible from our end to enable the ISV community to develop such servlets. | |
| I have yet another JSDK question: Would I need to use Live Software's product, JRun, instead to run servlets with IIS? | |
| Yes, that is correct. | |
| You seem to indicate that servlet beans will be evolving. Where do you see them going? | |
| The idea is to "componentize" most modules on the server side. So if you are familiar with the JavaServer Toolkit product, we have what are called "services." We currently load services from the disk by pointing to a directory. The direction we are headed towards making them load from a .jar file and treat them as beans. So you can drop services/servlets into a running server and expect the server to pick them up. That is the future direction. | |
| Regarding the servlet bean support you talked about: is that only in the JST at this point? I have not seen it in JWS or the JSDK. Should I expect it soon there as well? Also, please clarify: Enterprise JavaBeans are not the same as servlet beans, right? | |
| Yes, the servlet beans support is only in JST at this point. But JWS builds on top of the JST, so you can expect to see support for servlet beans in JWS soon. Enterprise JavaBeans are not servlet beans. They are two different things entirely--more specifically, we do not export a servlet's methods for remote access using RMI and IIOP as Enterprise JavaBeans do. | |
| Is the long-term strategy to move today's servlet concept to the servlet bean concept? | |
| That is the current strategy, i.e. servlets are already moving toward servlet beans. The long-term strategy is to move services to service beans as well. For example, the entire web service might be treated as a bean. I should reiterate that this is not true today or anytime soon, but is the long-term strategy for the JavaServer Toolkit--to be able to load services like web server, NNTP server, and DHCP server as beans that are referred to by a URL. | |
| Are there any plans to provide an industrial-strength server that does nothing except run servlets--like the servlet runner, but for real use? Installing the whole JavaServer is sometimes a bit too much overhead and the mentioned web server extensions are still beta, I think. | |
| The industrial-strength server that does nothing else but run servlets is probably what we call "jserv" and it ships with the toolkit beta. But jserv also knows to serve web pages. If you want a leaner version, the JST is well-suited for building such a service. There are APIs exposed for servlet loading and instantiating (called com.sun.server.ServletManager) in the toolkit. So writing such a service should be very easy. | |
| Can you give a brief description of the main differences, from a developers point of view, between today's servlet and a servlet bean? | |
| The main difference between servlets and servlet beans are as follows: Servlets get their properties from what are called initArgs, which can either exist as a property file or as a property in the servlets section of the admin tool. Servlet beans get their properties via .ser files.
Servlet beans can be loaded from a JAR file (or a SER file). A servlet bean is introspected for its properties and a property sheet editor is put up in the admin tool to edit its properties. You don't get that with plain servlets. Finally, both servlets and servlet beans are hot swappable, i.e. they can be dropped and the server automatically sees them. They can be changed and the server automatically reloads them. | |
| The JST isn't free. Can you give us a feeling for the costs, e.g. are there separate development and runtime licenses? Roughly how much do they cost? | |
| The JST beta is currently available for non-commercial purposes for free of cost. By the FCS timeframe, we will come up with the license agreements for commercial use. Sorry, I cannot comment on this any further. | |
| To follow up on servlets vs. servlet beans. So the main difference is how properties are set. In terms of implementation, do I still implement doGet(), doPost(), etc., and do I access the properties the same way I access initArgs? In other words, what does it take to turn a servlet into a servlet bean? | |
| Yes, the main difference is how properties are set. In terms of implementation, you still have to implement doGet(), doPost() etc. You can use getFoo(), getBar(), etc. to get at the properties directly (assuming that you have the corresponding setFoo() and setBar(). Also you can serialize your servlet and reload it the next time the server is restarted. Basically with the servlet beans initiative, we made the servlet API implement java.io.Serializable. So all it takes to turn a servlet into a servlet bean is: a.) follow design patterns for getting and setting properties, and b.) optionally distribute it in JAR files. | |
| I have one more question regarding JWS. Why is there no support for multiple servlet directories to load servlets from? Couldn't we have some sort of capability to add more servlet directories and use the servlet's class loader (the one that reloads the classes automatically when modified) for those directories? | |
| The idea is to have the servlet directory under the administrator's control. This is because all servlets in the servlet directory are trusted. Having multiple servlet directories would compromise this. | |
| Well, the hour has come to a close. Thank you, everyone, for joining us--especially Satish. Check the Discussion Fourms schedule for more online events. See you next time. |