Use of Applet and Servlet

Applet security constraints

The Applet code comes from the web host and runs in the browser of the end user's machine. Harmful viruses containing the Applet may cause destructive effects. to prevent such an Applet, the Applet is restricted by security, that is, the Applet can only communicate with the host that provides the Applet, moreover, the Applet cannot operate the end user's machine. They cannot read or write the user's file system, execute the above program, or check some sensitive environment parameters. In fact, there is a way to circumvent this restriction, that is, developers can use the digital signature technology to mark the Applet, which will ask users whether they can give the Applet some special treatment. But this is beyond the scope discussed in this article .) In addition, the Applet cannot establish or accept external socket connections. The external connection means that the connection exceeds the host that provides the Applet file, not the host that provides the HTML that references the Applet ).

Because of this security restriction, we must adopt a special policy for communication with the Applet. The only way to communicate is the network connection between the host that provides the Applet and the host that provides the corresponding HTML.

Servlets

Java Servlet is a server component and has many similarities with CGI. It can process web requests and return data or HTML. Servlet can access the database for computing and communicate with components such as Enterprise JavaBean. Unlike CGI programs, Servlet is persistent, that is, as long as it is used as an example, it can continuously process requests at the same time ). Therefore, Servlet is more efficient than CGI.

Servlet runs in a Servlet engine, usually on a web server or application server. Both Netscape Enterprise Server 4.0 and Netscape Application Server support the latest Java Servlet specification. Unlike Applet, Servlet is not restricted by security constraints. Because the Servlet runs completely on the server, it has the performance allowed by all operating systems.

Servlet can be used to easily establish connections between clients such as Applet and Web browser and the core of enterprise applications. For the client, the requests sent to the Servlet are no different from other web requests. The client accepts the returned information through a URL. As we can see, the returned information is not only HTML. In fact, we can send and accept any type of data through the HTML protocol.

Constructor

An enterprise-level application can use several methods to construct the Applet and Servlet. I will introduce three different constructor methods and compare their advantages and disadvantages.

The first method actually only uses the Applet instead of the Servlet, although the Applet is restricted by their security mode, however, the Applet can still use protocols such as JDBC and RMI to access backend information such as databases, LDAP directories, and Enterprise JavaBeans components. This construction method 1 is shown. Although this method looks very simple, it is not a good method, it will bring a lot of problems. First, this arrangement requires you to embed all the access information directly into your Applet code. Database usernames, passwords, and server identifiers. All this information must be included in your Applet code, so that end users may collect this information from class files. In addition, the database or any other system you access must be on the same server that provides the Applet. This means that your server will have to bear both the burden of being a web server and a database server. In typical cases, your backend resources may be protected by the firewall, but in this case, this is impossible, because the Applet running on the client must directly access your machine. Finally, if you want to use a web server cluster using this method, it is at least difficult if it is not impossible.

A double-layered application structure

A better way is to encapsulate the transactions that communicate with the backend resources into the Servlet, while the Applet is only used to process the front-end work. In this constructor, as shown in figure 2, Servlet overcomes the inherent security constraints of Applet and is used to control Applet access to the enterprise information system and transaction logic. When the Servlet receives a request, it will query information in the backend database, execute computing, process the acquisition of information representing the Applet, and act on the information from the Applet. One major improvement of this method is that the Applet and Servlet pairs can be distributed in a cluster of backend web servers, and all the communication with a shared database exists in the backend. In addition, Servlet design helps design modularization, abstract the backend of an application to process business logic, and improve design flexibility.

A three-tier application structure

If you build your application around Enterprise JavaBeans, Servlet becomes the middleware. The EJB component can be used to separate the business logic from the Servlet and make it more abstract. In this case, an Applet communicates with the Servlet, And the Servlet communicates with the EJB component. As shown in figure 3. Introducing a hierarchy of EJB components, Servlets, and front-end applets/HTML in application construction can provide us with maximum flexibility and performance. Even if you do this, you must attach the cost of complexity and cost.

Multi-layered application Construction

Communication Policy

If you use this structure: Use the Applet on the front end and use the Servlet on the back end, you will need to execute the communication between the Applet and the Servlet. Because the Applet is restricted by the security mode of the browser, we do not have much choice when accessing data and information of an Applet. As we mentioned earlier, we cannot read the file system of the client or run the client program. Because the Applet is not running on the server, we cannot access the file system on the server. We can only establish a network connection to a service running on our host. In addition, do not forget that applications are published on a public Internet, and the firewall may restrict sessions sent from HTTP to Servlet or other web-server modules. In fact, because the Applet itself is published over HTTP on the network, we must accurately grasp the communication policy.

Assume that the network connection between the client Applet and the server Servlet is the only communication path we can use. We can exchange information in several ways. As you know, text streams can be distributed by servers over HTTP. However, you may not know that Java objects can be issued in this way. We will introduce in detail the use of HTTP text streams and HTTP object streams. In addition, we will briefly introduce the method of communication through Socket. When an application is copied and copied? Br> HTTP text stream

The simplest way to exchange information between an Applet and a Servlet is through an HTTP text stream. The Java URL and URLConnection types make it easy to read data from a URL, so you don't have to worry about Socket and other complex issues related to network work. All we need is a server-side component, which can issue information through URL. This is why Servlet is used here.

1. Servlet 2.5 termination response
2. Wizard for creating Servlet Filters
3. User cache Servlet
4. Extract Servlet and JSP page content using the filter
5. Servlet Context and Config