Java EE Enterprise Application applet and servlet communication

In the design of today's multi-tier Web applications, we can use both Java applets and servlet. Applets provide a convenient mechanism for creating powerful dynamic interfaces that provide an efficient means of processing requests from Web servers or other application servers.

The Sun's application model describes the best specification for developing enterprise-class Java applications under the JAVA2 platform. A recommended specification is to use applets, HTML, and JSPs on the front end, using the servlet and other components supported by Enterprise JavaBeans at the back end.

The key to this architecture is the communication between the client applet and the Ervlet in the server. However, because applets are subject to browser-safe mode, accessing data and information in an applet is not as simple as it seems. In this article, we will explain the limitations faced by developers in the Applet-servlet architecture, and explore several different communication strategies that can be transferred between applets and servlet data.

If you are already familiar with applets and servlet, this will certainly help you read this article, if you are not so familiar with it, it doesn't matter, we will briefly introduce them.

Introduction to applets and servlet

The applet Java applets is actually a Java program that runs on a Web page. It is a Java class that inherits from Java.applet.applet, which is embedded into an HTML page by reference, just like an image. A combination of applets and HTML to create a more powerful dynamic interface.

For applets that are used only to scroll the body and play animations, we can use it in an enterprise-class application to display and process data from resources on the server. For example, an applet can be used to browse and modify records in a database or to control other applications running on the server.

In addition to being able to use its own defined class files, Java applets can also use other classes, whether they exist independently or packaged into a jar file. The applet and its class files are distributed through standard HTTP requests, so applets can be sent over the firewall of the platform on which the Web page data resides.

Unless it is a matter of maintaining application integrity, applets will automatically refresh each time a user accesses the web host again and remain on the client for a period of time.

We have to appreciate the platform independence of the Java operating system, which allows applets to run on any browser that has a Java Virtual machine (JVM). Sun's Java plug-in can even use the latest version of the JVM to make pages without worrying about the version of the JVM on your user's browser.

Because applets are extensions of the Java platform, you can reuse existing Java components as you build an interface to build your Web application with applets.

As we can see in the following example, you can use complex Java objects in your applet's components to develop the work that would have been done by a server-side application. In fact, you can write Java code that can be executed either on the applet or within the application.

Applets have the functionality of all traditional Java applications, including the use of sun Company's jfc/swing components. Applets can also be used to make graphics and the user interface in the application (although some auxiliary windows will be flagged as "Warning, Java applet window").

But no matter how similar they are, there are some key differences between the application and the applet. For example, we have to consider that our applets are restricted by Safe mode.

Security constraints for applets

The applet code comes from the web host and runs in the browser of the end user's machine. Harmful virus-containing applets can have devastating effects, and to prevent such applet,applet from being subject to security constraints, the applet can only communicate with the host that provided the applet, and the applet cannot operate the end-user's machine.

They cannot read and write to the user's file system, perform the above procedures, or check for sensitive ambient parameters. (In fact, we have a way to avoid this limitation, that is, developers can use digital signature technology to flag applets, which will ask users whether they can give the applet a special treatment.)

But this is beyond the scope of the discussion in this article. Additionally, the applet cannot establish or accept a foreign socket connection. The term "foreign" means that the connection is beyond the host that provides the applet class file (not the host that hosts the HTML that references the applet).

Because of this security restriction, we must use a special strategy for communication with the applet. The only way to communicate is by providing a network connection before the host of the applet and the host that provides the corresponding HTML.

The Servlets Java servlet is a server-side component, and it has a lot in common with CGI. It can process Web requests and return data or HTML. The servlet can access the database, perform calculations, and communicate with components such as Enterprise JavaBean.

Unlike CGI programs, the servlet is persistent and efficient, that is, it can be processed continuously as long as it is sample (these requests are likely to occur concurrently). As a result, the servlet is more efficient than CGI.

The servlet runs in a servlet engine, typically on a Web server or application server. Netscape Enterprise Server 4.0 and Netscape Application Server all support the latest version of the Java servlet specification.

Unlike applets, the servlet is not restricted by security constraints. Because the servlet is running entirely on the server, it has the performance allowed by all operating systems.

The servlet can be used to easily establish a connection between the client and the core of the enterprise application, such as applets and web browsers. For clients, requests made to the servlet are not any different from other Web requests. The client receives the returned information through a URL, and as we see it, the returned information is not necessarily HTML, and we can actually send and receive any type of data through the HTML protocol.