Jump to content

Execution

75% developed
From Wikibooks, open books for an open world

Navigate Getting Started topic: v  d  e )


There are various ways in which Java code can be executed. A complex Java application usually uses third party APIs or services. In this section we list the most popular ways a piece of Java code may be packed together and/or executed.

JSE code execution

[edit | edit source]

Java language first edition came out in the client-server era. Thick clients were developed with rich GUI interfaces. Java first edition, JSE (Java Standard Edition) had/has the following in its belt:

  • GUI capabilities (AWT, Swing)
  • Network computing capabilities (RMI)
  • Multi-tasking capabilities (Threads)

With JSE the following Java code executions are possible:

Figure 1: Stand alone execution
Stand alone Java application
(Figure 1) Stand alone application refers to a Java program where both the user interface and business modules are running on the same computer. The application may or may not use a database to persist data. The user interface could be either AWT or Swing.
The application would start with a main() method of a Class. The application stops when the main() method exits, or if an exception is thrown from the application to the JVM. Classes are loaded to memory and compiled as needed, either from the file system or from a *.jar file, by the JVM.
Invocation of Java programs distributed in this manner requires usage of the command line. Once the user has all the class files, he needs to launch the application by the following command line (where Main is the name of the class containing the main() method.)
Computer code Execution of class
java Main
Java 'jar' class libraries
Utility classes, framework classes, and/or third party classes are usually packaged and distributed in Java ' *.jar' files. These 'jar' files need to be put in the CLASSPATH of the java program from which these classes are going to be used.
If a jar file is executable, it can be run from the command line:
Computer code Execution of archive
java -jar Application.jar
Client Server applications
The client server applications consist of a front-end, and a back-end part, each running on a separate computer. The idea is that the business logic would be on the back-end part of the program, which would be reused by all the clients. Here the challenge is to achieve a separation between front-end user interface code, and the back-end business logic code.
The communication between the front-end and the back-end can be achieved by two ways.
  • One way is to define a data communication protocol between the two tiers. The back-end part would listen for an incoming request. Based on the protocol it interprets the request and sends back the result in data form.
  • The other way is to use Java Remote Invocation (RMI). With the use of RMI, a remote object can be created and used by the client. In this case Java objects are transmitted across the network.
More information can be found about client-server programming, with sample code, at the Client Server Chapter in this book.
Web Applications
For applications needed by lots of client installations, the client-server model did not work. Maintaining and upgrading the hundreds or thousands of clients caused a problem. It was not practical. The solution to this problem was to create a unified, standard client, for all applications, and that is the Browser.
Having a standard client, it makes sense to create a unified, standard back-end service as well, and that is the Application Server.
Web Application is an application that is running in the Application Server, and it can be accessed and used by the Browser client.
There are three main area of interest in Web Applications, those are:
Wikipedia also has an article about Web application.

J2EE code execution

[edit | edit source]

As the focus was shifting from reaching GUI clients to thin client applications, with Java version 2, Sun introduced J2EE (Java 2 Extended Edition). J2EE added :

With J2EE the following Java component executions are possible:

Figure 2: Servlet Execution
Java Servlet code
(Figure 2) Java got its popularity with server side programming, more specifically with J2EE servlets. Servlets are running in a simple J2EE framework to handle client HTTP requests. They are meant to replace CGI programming for web pages rendering dynamic content.
The servlet is running in a so called servlet-container/web container. The servlet's responsibility is to:
  • Handle the request by doing the business logic computation,
  • Connecting to a database if needed,
  • Create HTML to present to the user through the browser
The HTML output represents both the presention logic and the results of the business computations. This represents a huge problem, and there is no real application relying only on servlets to handle the presention part of the responsibility. There are two main solutions to this:
  • Use a template tool (Store the presentation part in an HTML file, marking the areas that need to be replaced after business logic computations).
  • Use JSP (See next section)
Wikipedia also has an article about Servlets.
Figure 3: Jsp Execution
Java Server Pages (JSP) code
(Figure 3) JSP is an HTML file with embedded Java code inside. The first time the JSP is accessed, the JSP is converted to a Java Servlet. This servlet outputs HTML which has inside the result of the business logic computation. There are special JSP tags that helps to add data dynamically to the HTML. Also JSP technology allows to create custom tags.
Using the JSP technology correctly, business logic computations should not be in the embedded Java part of the JSP. JSP should be used to render the presentation of the static and dynamic data. Depending on the complexity of the data, 100% separation is not easy to achieve. Using custom tags, however may help to get closer to 100%. This is advocated also in MVC architecture (see below).
Figure 4: EJB Execution
EJB code
(Figure 4) In the 1990s, with the client server computing, a trend started, that is to move away from Mainframe computing. That resulted in many small separate applications in a Company/Enterprise. Many times the same data was used in different applications. A new philosophy, "Enterprise Computing", was created to address these issues. The idea was to create components that can be reused throughout the Enterprise. The Enterprise Java Beans (EJBs) were supposed to address this.
An EJB is an application component that runs in an EJB container. The client accesses the EJB modules through the container, never directly. The container manages the life cycle of the EJB modules, and handles all the issues that arise from network/enterpise computing. Some of those are security/access control, object pooling, transaction management, ... .
EJBs have the same problems as any reusable code: they need to be generic enough to be able to be reused and the changes or maintenance of EJBs can affect existing clients. Many times EJBs are used unnecessarily when they are not really needed. An EJB should be designed as a separate application in the enterprise, fulfilling one function.


Figure 5: MVC Execution
Combine J2EE components to create an MVC architecture
This leads us to the three layers/tiers as shown in (Figure 5).
In modern web applications, with lots of static data and nice graphics, how the data is presented to the user became very important and usually needs the help of a graphic artist.
To help programmers and graphic artists to work together, the separation between data, code, and how it is presented became crucial.
  • The view (User Interface Logic) contains the logic that is necessary to construct the presentation. This could be handled by JSP technology.
  • The servlet acts as the controller and contains the logic that is necessary to process user events and to select an appropriate response.
  • The business logic (model) actually accomplishes the goal of the interaction. This might be a query or an update to a database. This could be handled by EJB technology.
For more information about MVC, please see MVC.

After J2EE Sun had a vision about the next step of network computing. That is Jini. The main idea is that in a network environment, there would be many independent services and consumers. Jini would allow these services/consumers to interact dynamically with each other in a robust way. The basic features of Jini are:

  • No user intervention is needed when services are brought on or offline. (In contrast to EJBs where the client program has to know the server and port number where the EJB is deployed, in Jini the client is supposed to find, to discover, the service in the network.)
  • Self healing by adapting when services (consumers of services) come and go. (Services periodically need to renew a lease to indicate that they are still available.)
  • Consumers of JINI services do not need prior knowledge of the service's implementation. The implementation is downloaded dynamically and run on the consumer JVM, without configuration and user intervention. (For example, the end user may be presented with a slightly different user interface depending upon which service is being used at the time. The implementation of the user interface code would be provided by the service being used.)

A minimal Jini network environment consists of:

  • One or more services
  • A lookup-service keeping a list of registered services
  • One or more consumers

Jini is not widely used at the current writing (2006). There are two possible reasons for it. One is Jini a bit complicated to understand and to set it up. The other reason is that Microsoft pulled out from Java, which caused the industry to turn to the use of proprietary solutions.