There are some things to note to note about Servlets as opposed to Applets.
Firstly, the servlet and its environment is completely under the control of those deploying it. That is, you have control of which JVM is used and that this is independent of the browser used by the user. This is important as it removes concerns associated with the so-called “browser” wars.
Secondly, a servlet is not constrained by the applet sandbox. This means that a servlet can reside behind a firewall and can communicate with any and all systems that it needs to. For example, JavaIDL can be used to connected to a CORBA compliant Object Request Broker (ORB) or sockets to connect to legacy systems (for example implemented in C).
Thirdly, the client Web browser does not communicate directly with the servlet. Rather the browser communicates with the Web server, which in turn communicates with the servlet. Thus if the web server is secure behind a firewall, then the servlet is also secure.
Fourthly a single Servlet can process multiple user requests. That is one instance (by default) of a Servlet is loaded into the web server and this instance services all user requests. This does not mean that each request is queued. Rather it means that each request is handled by a separate thread (of execution) that uses the same servlet instance.
Fifthly, as each Servlet is shared amongst multiple users, care must be taken with user specific data. For example, this means that sensitive user information should not be stored in an instance variable as the instance is shared amongst many users. This can be overcome by using a HttpSession object that can be obtained from the initial request. Each session object is linked to a single user.
Firstly, the servlet and its environment is completely under the control of those deploying it. That is, you have control of which JVM is used and that this is independent of the browser used by the user. This is important as it removes concerns associated with the so-called “browser” wars.
Secondly, a servlet is not constrained by the applet sandbox. This means that a servlet can reside behind a firewall and can communicate with any and all systems that it needs to. For example, JavaIDL can be used to connected to a CORBA compliant Object Request Broker (ORB) or sockets to connect to legacy systems (for example implemented in C).
Thirdly, the client Web browser does not communicate directly with the servlet. Rather the browser communicates with the Web server, which in turn communicates with the servlet. Thus if the web server is secure behind a firewall, then the servlet is also secure.
Fourthly a single Servlet can process multiple user requests. That is one instance (by default) of a Servlet is loaded into the web server and this instance services all user requests. This does not mean that each request is queued. Rather it means that each request is handled by a separate thread (of execution) that uses the same servlet instance.
Fifthly, as each Servlet is shared amongst multiple users, care must be taken with user specific data. For example, this means that sensitive user information should not be stored in an instance variable as the instance is shared amongst many users. This can be overcome by using a HttpSession object that can be obtained from the initial request. Each session object is linked to a single user.
Comments
I'd like to disagree with this statement:
>Firstly, the servlet and its environment is completely under the control of those deploying it.
Traditionally, servlets are accessed by a web browser. Servlets usually output HTML. How this HTML is interpreted is up to the browser that the user is using, which may not be under the control of the deployer of the servlet. There are countless examples of something working in Internet Explorer and not working in Netscape, or vice versa. With DHTML, CSS, javascript, etc. there are countless incompatibilities that a servlet deployer has to take into account when writing a servlet.
Rich
I agree with your point of view. The statement made in the Post was a generalized one and was made in the context of distinguishing Servlet from an Applet.