8.3 Introduction to the Java Platform
8.3 Introduction to the Java Platform In Chapter 5, we discussed a multitier architecture from the hardware perspective. In such an environment, we moved the application logic, which had in the two- tier world been supported on a fat client, to the middle tier. On the front end is the interface, the part of the application that communicates with the user. This is the proactive portion of the application. Through this interface, the user initiates the requests for the various services provided by the system. These processes are short-lived, starting and stopping at the request of the user. On the back end are the systems services, such as database management systems. These services are totally reactive and long-lived, theoretically running forever. We can see how this adds a level of complexity to the development of our application. In the two-tier environment, we had a simple many-to-one relationship in which many clients communicated to the one server process in the background. In a multitier environment, we have a many-to-many relationship in which multiple clients communicate with multiple middle-tier servers, which in turn communicate with many back-end services. The Java platform maps directly onto this multitier architecture. Both the front and back ends of the application are abstracted, leaving the middle tier free to focus on the application's business logic. There are a wide variety of client devices. To meet the needs of these different platforms, there are three different editions of Java. Figure 8.5 presents the relationship between these different editions. Figure 8.5. The Java platform. 8.3.1 THE JVMThe JVM is that part of the Java environment that makes a Java system independent. It is an abstraction of the underlying system. As shown in Figure 8.4, the JVM sits between the system and the application or applet and acts as a virtual system. The application does not see the underlying system; it sees only the JVM. The JVM in turn takes what it receives from the application and executes it on the system. The JVM can run on top of most operating systems. Figure 8.6 pulls back the covers on the how applications and applets execute on the JVM. Figure 8.6. Executing applets and applications on a JVM. The process begins with Java language source code. This code is saved in Java files, <YY>.java, where <YY> is the filename and .java is the filename extension. These files are compiled by the Java compiler into Java bytecodes, which are then stored as Java class files. These files are named <XX>.class, where <XX> is the filename and .class is the filename extension. Class files are machine-independent , allowing the output of the Java compiler to be sent to virtually any system. Prior to the JVM receiving these files as input, the Java Class Loader and bytecode verifier load the bytecodes into memory and verify them for security. The bytecode verifier is an important element in creating a robust Java environment. The Java code could have originated from any source. It is the job of the verifier to insure that the code does not corrupt the JVM. In examining the bytecodes, the verifier establishes the type information and checks the types of parameters that are passed to the bytecode instructions. Once the class file passes through the verifier, we know that there are no stack overflows, bytecodes are receiving appropriate parameters, and the object field accesses are legal. As we see in the figure, once the code has been received by the JVM, it can take one of two paths. The first path is through the interpreter. The interpreter takes the byte codes and runs them in the Java Runtime System. The runtime system is the piece of the JVM that interfaces with the actual operating system. The concept of linking a program as in some other high-level languages is not really performed within the JVM. When we look at loading a program in the object-oriented world, we are really talking about loading new classes. Older high-level languages do this in a static fashion. Once the source has been compiled, the output is linked. Bytecodes are different than object code; they are symbolic. The indices and offsets to methods are symbolic names. When a method is first invoked, the JVM searches a table of method names . Once found, the offset to the method is used to access the method for quicker access. This has the advantage that new methods can be added during runtime. Classes loaded from the Java Class Libraries are dynamically loaded as they are needed. 8.3.2 JAVA APPLETS AND APPLICATIONSNote in Figure 8.6 the difference between an applet and an application. Often, an applet is defined as a lightweight application; this is only partially correct. While applets are typically characterized as somewhat smaller applications, this is more of a function of how they are invoked, not a technical requirement. Applets are invoked differently than applications. An applet is invoked when the browser loads a Web page with an applet tag. When the browser encounters the tag, the program automatically downloads the applet from the server and runs it on the client. Since the program, or applet, downloads from the server, it is typically small in order to avoid lengthy download times. Also, note that applets are invoked when a browser downloads a Web page containing the applet's tag. This means that applets require a browser to run. Java applications are full-fledged applications. They are invoked and executed like any other type of program. Java applications, however, require that the Java platform be present. Currently, there are some functional differences between an applet and an application. The applet is less secure than an application, since it can come from just about any Web server on the Internet. Applets do not necessarily originate from a trusted environment. Applets are therefore restricted from reading or writing to any file system other than the server from which they came. 8.3.3 JAVA PLATFORM EDITIONSIn Figure 8.5, there are three versions of the Java platform: Java 2 Micro Edition (J2ME), Java 2 Standard Edition (J2SE), and Java 2 Enterprise Edition (J2EE). Each Java platform edition is designed to address a different segment of the market. J2ME addresses devices such as cell phones, pagers , and PDAstypically, the needs of small, mobile clients. J2SE is the next step up, addressing the development requirements for applets and applications. To address the development needs of the enterprise server-side applications, use J2EE. Across all of these environments, we have the Java language itself. As we look at the J2EE environment, we can see the developer has the option of either presenting services directly to a browser using Java Server Pages (JSPs), or providing those services to the browser via applets and JavaBeans. Figure 8.7 presents each alternative. On the one hand, we can support applications through HTML-based clients. Using JSPs, the application server dynamically generates HTML pages, which are sent directly to the client system's browser. Developers can combine static page templates with dynamic content. The structure of a JSP includes tags that invoke JavaBeans components to implement complex functionality. The alternative to the method described above is to build an applet that communicates directly with a mid-tier application. This moves the responsibility of formatting and often processing the data to the client-side applet. In many ways, this mimics the traditional two-tier client server model. Figure 8.7. Implementing multitier applications with Java. As we can see, the Java platform provides application developers with a foundation upon which they can build multitier applications. Through the use of J2ME, these applications can be deployed on a variety of devices, extending the reach of the IEBI system beyond the physical walls of the organization. The next step is to examine how the Java language has been extended to specifically address IEBI system requirements.  |
| | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 113