DB2 for z/OS and WebSphere: The Perfect Couple

90 DB2 for z/OS and WebSphere: The Perfect Couple

4.1 Introduction to J2EE data access architecture

For most applications, data access is the last tier and the endpoint of an application. Good

designs generally provide separate application layers for presentation (or user interface);

business processing or logic; and then finally a data access layer that retrieves, stores, or

massages data within the relational database.

The separation of these functions into separate components should be a requirement for any

application architecture. History tells us that application requirements, implementation

technologies, and pretty much everything else will change. Without separating applications

into components, the work required to update, maintain, and troubleshoot grows

exponentially with the complexity of today’s enterprise applications.

This chapter makes the assumption that you have chosen to implement a Java-based

application and will be accessing data that resides on DB2 UDB for z/OS. Each of the Java

technologies are described and considered for use as the data access portion. For

components that should not access data directly, we attempt to position their usage within a

larger architecture.

As in all decisions, attempting to decide which technology to exploit is ultimately an exercise

in weighing trade-offs—performance and scalability versus ease of development, operations,

and maintenance.

4.2 Servlets and JavaServer Pages

Servlets were one of the first server-based execution environment implementations for the

Java programming language. Widely implemented and platform independent, servlets are

Java programs that are executed at the server instead of at a local client such as within an

applet or application.

Servlets are Java code that has access to the full family of Java APIs, but their primary goal is

to handle requests and generate responses. Servlets are almost exclusively invoked by

HTTP requests. Once an HTTP request for a servlet causes a Web server to invoke the

servlet, the servlet executes some set of functions, and ultimately generates a dynamic HTML

response, which is sent back to the client for rendering. The client is usually a Web browser.

In implementation, the servlet execution environment provides excellent performance when

compared to other request response mechanisms such as Common Gateway Interface

(CGI), since the servlets are loaded once, pooled, and continuously reused.

Coupled with early entrance to the marketplace, widespread vendor support, and with the

evolution of the JDBC standard, servlets were the first widespread server-based Java

environment for accessing relational databases.

The JDBC standard provides a vendor-independent mechanism for submitting SQL

statements to a relational database management system (RDBMS) for processing, as

described throughout this book.

JavaServer Pages (JSPs) are an extension to the servlet architecture. JSPs provide the

same request and dynamic response function, except authors of the JSPs can generate

dynamic content without understanding the Java language. This tag-based language is

ultimately translated into servlets for execution. Servlets and JSPs are almost identical from

an architectural point of view in that they both are tied to the HTTP protocol, allow for the

execution of Java code, are platform independent, and provide dynamic content generation.