2.3 Server-Side Java Technology

Running Java technology on the server side can greatly simplify the work of software developers, especially of distributed architectures. Although the majority of client systems might be personal computers (PCs) running some version of Microsoft Windows, most of the world's crucial business data is kept on mainframe, Linux, and UNIX servers. A server-side distributed application developed in Java technology can be run on almost any of these servers, whether they run z/OS, ^[3] Virtual Machine (VM), Windows, Operating System/2 (OS/2), AS/400, one of the many flavors of UNIX, or Linux.

^[3] Previously known as Operating System/390 (OS/390) and Multiple Virtual Storage (MVS).

In many ways, the Java environment is ideal for server applications. The multithreaded environment is well suited for supporting simultaneous requests to a server. Even the standard classes are simplified, as many server programs are unlikely to need the java.awt windowing classes as well as several others, which is where most cross-platform problems often arise. As an example, because it is written in the Java language, the gateway component of the CICS Java gateway can run on any Web server system, reducing porting and testing costs.

Web application servers supplement and even surpass traditional Web servers in their use and functionality in enterprise environments. Unlike a traditional Web server, a WAS provides a robust and flexible foundation for dynamic transactions and objects. Traditional Web servers are constrained to servicing standard HTTP requests, returning the contents of static HTML pages and images or the output from executed CGI scripts. Some Web servers have extended their functionality by including support for Java servlets, JSP applications, and EJB components .

• Servlets allow Java applications to be executed on the server side and return dynamically generated information, in much the same way that a CGI script can dynamically generate information. However, servlets have additional capabilities. A servlet, a Java class residing on a Web server, accepts requests and generates responses over various communication protocols. The most common type of servlet is an HTTP servlet, which is implemented by the javax.servlet.http.HttpServlet class. An HttpServlet accepts HTTP requests and generates HTTP responses. As a server resource, a servlet has access to other server resources, such as other servlets, EJB components, JSP applications, and databases. The purpose of a servlet is to generate a dynamic response.

  However, grafting servlet support onto a Web server does not provide a complete solution to meet e-business requirements. A WAS provides a more scalable environment for modeling enterprise solutions, partly through the use of Java technology. A WAS supports Java objects in their simple and compound manifestations . Servlet support plays an important role, but a WAS also supports EJB and JSP technologies.

• EJB technology provides an architecture for distributed, transaction-based objects, called enterprise beans , which allow developers to concentrate on the business logic rather than its interaction with the underlying infrastructure.

• Similarly, JSP technology provides developers and administrators with a convenient way to produce HTML or XML via template data, custom elements, scripting languages, and server-side Java objects to generate dynamic information and return it to a client.

The blend of EJB, servlets, and JSP provides the foundation for representing a Model-View-Controller (MVC) architecture ^[4] to developers. Typically, the modularity and focus of purpose in EJB represents the model; JSP and servlets represent the view through their ability to dynamically generate HTML and XML information; the client system represents the controller.

^[4] The MVC architecture is a popular object-oriented (OO) design pattern for the creation of user interfaces. Its goal is to separate the application object ” model ”from the way it is represented to the user ” view ”and from the way in which the user controls it ” controller . Before MVC, user interface designs tended to lump such objects together. MVC decouples them, thus allowing greater flexibility and possibility for reuse. MVC also provides a powerful way to organize systems that support multiple presentations of the same information.

2.3.1 WAS Components

A Web application server must contain a servlet container and an EJB container.

2.3.1.1 Servlet Container

A servlet container , a Java environment within which servlets execute, constitutes an intermediary between the Web server and the servlets in the WAS. The servlet container is responsible for managing the life cycle of servlets by loading, initializing, and executing them (see Section 4.3 on page 107). A servlet container ensures that memory contains a single instance of a servlet and dispatches a thread that executes the servlet for each request.

When a request arrives, a servlet container maps the request to a servlet and then passes the request to the servlet. The servlet processes the request and produces a response. The servlet container translates the response into the network format and sends the response back to the Web server. For this process to work, a servlet container must provide the network services over which the requests and responses are sent and is responsible for decoding and formatting MIME-type requests and responses. All servlet containers must support HTTP as a protocol for requests and responses but may also support additional request/response protocols, such as HTTP over SSL (HTTPS).

A servlet container is designed to perform well while serving large numbers of requests. A servlet container can hold any number of active servlets. Both a servlet container and the objects in it are multithreaded. A servlet container creates and manages threads as necessary to handle incoming requests. It can handle multiple requests concurrently, and more than one thread may enter an object at a time. Therefore, each object within a servlet container must be thread safe. Additionally, to support JSP applications, a servlet container provides an engine that interprets and processes JSP pages into servlets.

A servlet container can manage numerous distinct applications. As noted in Section 4.4 on page 111 and Section 4.10.3 on page 150, an application may consist of any number of servlets, JSP applications, filters, listeners, utility classes, and static Web pages. A collection of such components working together is a Web application . A servlet container uses a context to group - related components. The servlet loads the objects within a context as a group; objects within the same context can easily share data. Therefore, each context corresponds to a distinct Web application. A context is represented as an instance of the javax.servlet.ServletContext interface. Therefore, a servlet container is responsible for creating one ServletContext instance for each invocation of a Web application. Programmers can use the ServletContext object to make resources available to all servlets within a Web application.

2.3.1.2 EJB Container

An EJB container is a runtime environment that manages one or more enterprise beans. It manages the life cycles of enterprise bean objects, coordinates distributed transactions, and implements object security. Generally, each EJB container is provided by a WAS and contains a set of enterprise beans that run on the WAS.

An EJB container acts as the interface between an enterprise bean and the WAS. In essence, the EJB container is an abstraction that manages one or more EJB classes while making the required services available to EJB classes through standard interfaces as defined in the EJB specification. The EJB container vendor is also free to provide additional services implemented at either the container or the server level. An EJB client never accesses an enterprise bean directly. Any access to the enterprise bean is done through the methods of the container-generated classes, which in turn invoke the enterprise bean's methods. Multiple EJB component instances typically exist inside a single EJB container.

Having an EJB container interposed on all enterprise bean invocations allows the EJB container to manage transactions and resources, load enterprise bean instances, and provide such services as versioning, scalability, mobility, persistence, concurrency, deployment, and security to the EJB components it contains. Because the EJB container handles all these functions, the Enterprise Bean Provider can concentrate on business rules and leave database manipulation and other details to the EJB container. For example, if it needs to abort the current transaction, a single EJB component simply tells its EJB container; the EJB container is responsible for performing all rollbacks and doing whatever is necessary to cancel a transaction in progress.

2.3.2 WAS Security Environment

A WAS is more than a grouping of Java objects. In the multiuser enterprise environment, a WAS also provides integrated authentication and authorization support for user transactions, whether they originate from Web browsers, client applications, or another WAS. This complex environment of both friendly and potentially malicious entities requires answers to a number of questions:

• How can users be authenticated to a WAS?

• After authentication, to which objects and actions are the users authorized?

• How can the details of users' transactions remain hidden from unauthorized entities?

These questions deal with the security issues of authentication, authorization, and encryption.

Objects that play a major role in the WAS environment are client objects and server objects. Client objects include Web clients and application clients . Server objects include Web servers, WASs, security servers, and user registry servers.

The physical WAS executing the supported Java objects plays an important role, but it is only one member of the entire ensemble of processes that complete the WAS environment. Note the distinction between the WAS and the WAS environment, depicted in Figure 3.1 on page 56. The WAS represents the server that handles requests for EJB objects, servlets, and JSP pages. The WAS environment encompasses all the client and server objects that have a direct or indirect interaction with the WAS, including the WAS itself.

Clients to a WAS include Web browsers, Java client applications or applets, and pervasive devices, such as mobile appliances. Client objects can originate from many different sources but can be categorized into those from traditional Web browsers and those from stand-alone applications.

A WAS typically does not directly service client requests. Web servers respond to HTTP requests for HTML pages or to execute CGI scripts. For more complex tasks , such as the manipulation of EJB objects, Web servers pass the service requests to the WAS.

The security server is an essential element in the WAS environment, maintaining a consistent security schema and arbitrating user authentication and authorization access to objects. To authenticate users, as well as to obtain the user's authorization attributes and digital certificate information, the security server obtains the information from an enterprise user registry, such as a Lightweight Directory Access Protocol (LDAP) server, RACF, or IBM Tivoli Access Manager.

Security in the WAS environment is not limited to authentication and authorization. Between the various server and client objects, security also comes into play through the use of encryption technologies.