You are on page 1of 34

J2EE Basics

C S C. C O M

C

O

N

S

U

L

T

I

N

G

S

Y

S

T

E

M

S

II

NN TT EE G RR AA TT I I O NN G O

••

O UU TT SS O UU RR CC I I NN G O O G

Agenda
Distributed Multitiered Applications Type of Tiers J2EE Components J2EE Clients Web Components Business Components Enterprise Information System Tier J2EE Containers Container Services Container Types Design Patterns MVC Architecture MVC 1 MVC 2 Components and Components APIs Servlets JSPs

© Copyright CSC PLOENZKE AG

Distributed Multitiered Applications

The J2EE platform uses a distributed multitiered application model for enterprise applications. Application logic is divided into components according to function, and the various application components that make up a J2EE application are installed on different machines depending on the tier in the multitiered J2EE environment to which the application component belongs. •Client-tier components run on the client machine. •Web-tier components run on the J2EE server. •Business-tier components run on the J2EE server. •Enterprise information system (EIS)-tier software runs on the EIS server.

© Copyright CSC PLOENZKE AG

Types of Tiers

Tiers are logical subdivisions addressing the “separation of concerns”. Tiers may be described as the partitioning of the enterprise components based on their roles and responsibilities. • • • • • Client Tier Presentation Tier Business Tier Integration Tier Data/Resource Tier

Client Tier :-- Client tier is the user interface part of the enterprise application. This tier consists of components and containers that are helpful in projecting information/data to the end user in a meaningful manner.Browser based clients are one of the examples of the client tier. Presentation Tier:-- This tier houses those components and containers that occupy intermediate position among the tiers. Their responsibilities are :-1. Receive requests from the components of the client tier, process the same and then appropriately route it to the appropriate component(s) in the business tier. Receive the results from the business tier, compute an appropriate view and route the view back to the respective client.

2.

© Copyright CSC PLOENZKE AG

Types of Tiers

Business Tier:-- This tier houses the components and containers that carry business logic crucial to the enterprise. A good Practice could be to shield these components so that the business logic is not exposed directly to the clients. The responsibility of this tier is to compute the business logic based on the client request and, if necessary, apply changes to the database(s) at the back-end. It should then report the results to the presentation tier. Integration Tier:-- This is an intermediate tier, connecting to the components of the business logic tier in the front –end and the resource tier at the back-end.The components of this tier need to ensure an almost seamless integration with different resources such as databases on the one side, and the components of the business logic tier, on the other. Resource Tier:-- This is the logical and physical end of the tier system. This tier supports systems and applications that deal with the enterprise information/data. The data/information in this tier are the data that need to be persisted. The data/information referred to in this tier is often accessed/modified/deleted by multiple processes/threads in an enterprise situation. It is important that this data be accessed in a transactional environment so that the data integrity is ensured.

© Copyright CSC PLOENZKE AG

J2EE Components
J2EE applications are made up of components. A J2EE component is a selfcontained functional software unit that is assembled into a J2EE application with its related classes and files and that communicates with other components. The J2EE specification defines the following J2EE components: •Application clients and applets are components that run on the client. •Java Servlet and JavaServer Pages (JSP ) technology components are web components that run on the server. •Enterprise JavaBeans (EJB ) components (enterprise beans) are business components that run on the server.

J2EE components are written in the Java programming language and are compiled in the same way as any program in the language. The difference between J2EE components and "standard" Java classes is that J2EE components are assembled into a J2EE application, are verified to be well formed and in compliance with the J2EE specification, and are deployed to production, where they are run and managed by the J2EE server.

© Copyright CSC PLOENZKE AG

Client Components or Client Tier Components

A J2EE client can be a web client or an application client. Web Clients A web client consists of two parts: (1) dynamic web pages containing various types of markup language (HTML, XML, and so on), which are generated by web components running in the web tier, and (2) a web browser, which renders the pages received from the server. A web client is sometimes called a thin client. Thin clients usually do not query databases, execute complex business rules, or connect to legacy applications. When you use a thin client, such heavyweight operations are off-loaded to enterprise beans executing on the J2EE server, where they can leverage the security, speed, services, and reliability of J2EE server-side technologies.

© Copyright CSC PLOENZKE AG

Application Clients
Application Clients An application client runs on a client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a markup language. It typically has a graphical user interface (GUI) created from the Swing or the Abstract Window Toolkit (AWT) API, but a commandline interface is certainly possible. Application clients directly access enterprise beans running in the business tier. However, if application requirements warrant it, an application client can open an HTTP connection to establish communication with a servlet running in the web tier. J2EE Server Communications The client communicates with the business tier running on the J2EE server either directly or, as in the case of a client running in a browser, by going through JSP pages or servlets running in the web tier.

© Copyright CSC PLOENZKE AG

Web Components and Presentation Tier Components
J2EE web components are either servlets or pages created using JSP technology (JSP pages). Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content. Static HTML pages and applets are bundled with web components during application assembly but are not considered web components by the J2EE specification. Server-side utility classes can also be bundled with web components and, like HTML pages, are not considered web components.

© Copyright CSC PLOENZKE AG

Business Components or Business Tier Components
Business code, which is logic that solves or meets the needs of a particular business domain such as banking, retail, or finance, is handled by enterprise beans running in the business tier. Figure shows how an enterprise bean receives data from client programs, processes it (if necessary), and sends it to the enterprise information system tier for storage. An enterprise bean also retrieves data from storage, processes it (if necessary), and sends it back to the client program.

© Copyright CSC PLOENZKE AG

Enterprise Information System Tier
The enterprise information system tier handles EIS software and includes enterprise infrastructure systems such as enterprise resource planning (ERP), mainframe transaction processing, database systems, and other legacy information systems. For example, J2EE application components might need access to enterprise information systems for database connectivity.

© Copyright CSC PLOENZKE AG

J2EE Containers
J2EE Containers Normally, thin-client multitiered applications are hard to write because they involve many lines of intricate code to handle transaction and state management, multithreading, resource pooling, and other complex low-level details. The component-based and platform-independent J2EE architecture makes J2EE applications easy to write because business logic is organized into reusable components. In addition, the J2EE server provides underlying services in the form of a container for every component type. Because you do not have to develop these services yourself, you are free to concentrate on solving the business problem at hand.

© Copyright CSC PLOENZKE AG

Container Services
Containers are the interface between a component and the low-level platform-specific functionality that supports the component. Before a web component, enterprise bean, or application client component can be executed, it must be assembled into a J2EE module and deployed into its container. •The J2EE security model lets you configure a web component or enterprise bean so that system resources are accessed only by authorized users. •The J2EE transaction model lets you specify relationships among methods that make up a single transaction so that all methods in one transaction are treated as a single unit. •JNDI lookup services provide a unified interface to multiple naming and directory services in the enterprise so that application components can access naming and directory services. •The J2EE remote connectivity model manages low-level communications between clients and enterprise beans. After an enterprise bean is created, a client invokes methods on it as if it were in the same virtual machine.

© Copyright CSC PLOENZKE AG

Type of Containers

J2EE server :--The runtime portion of a J2EE product. A J2EE server provides EJB and web containers. Enterprise JavaBeans (EJB) container :--Manages the execution of enterprise beans for J2EE applications. Enterprise beans and their container run on the J2EE server. Web container :--Manages the execution of JSP page and servlet components for J2EE applications. web components and their container run on the J2EE server. Application client container :--Manages the execution of application client components. Application clients and their container run on the client. Applet container :--Manages the execution of applets. Consists of a web browser and Java © Copyright CSC the client Plug-in running on PLOENZKE AG together.

Design Patterns

A design pattern describes a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution. There are many good reasons to use design patterns. Here are three: 1)They are proven. You tap the experience, knowledge and insights of developers who have used these patterns successfully in their own work. 2) They are reusable. When a problem recurs, you don't have to invent a new solution; you follow the pattern and adapt it as necessary. 3) They are expressive. Design patterns provide a common vocabulary of solutions, which you can use to express larger solutions succinctly.

© Copyright CSC PLOENZKE AG

J2EE Patterns

Pattern Name
Business Delegate [ACM01] Composite Entity [ACM01] Composite View [ACM01] Data Access Object (DAO) [ACM01] Fast Lane Reader Front Controller [ACM01] Intercepting Filter [ACM01] Model-View-Controller Service Locator [ACM01] Session Facade [ACM01] Transfer Object [ACM01] Value List Handler [ACM01] View Helper [ACM01]

Description
Reduce coupling between Web and Enterprise JavaBeansTM tiers Model a network of related business entities Separately manage layout and content of multiple composed views Abstract and encapsulate data access mechanisms Improve read performance of tabular data Centralize application request processing Pre- and post-process application requests Decouple data representation, application behavior, and presentation Simplify client access to enterprise business services Coordinate operations between multiple business objects in a workflow Transfer business data between tiers Efficiently iterate a virtual list Simplify access to model state and data access logic

© Copyright CSC PLOENZKE AG

MVC Pattern

The goal of the MVC design pattern is to separate the application object (model) from the way it is represented to the user (view) from the way in which the user controls it (controller).

© Copyright CSC PLOENZKE AG

Model, View and Controller

The Model object knows about all the data that need to be displayed. It also knows about all the operations that can be applied to transform that object. However, it knows nothing whatever about the GUI, the manner in which the data are to be displayed, nor the GUI actions that are used to manipulate the data. The data are accessed and manipulated through methods that are independent of the GUI. The model represents enterprise data and the business rules that govern access to and updates of this data. The View object refers to the model. It uses the query methods of the model to obtain data from the model and then displays the information. A view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. The Controller object knows about the physical means by which users manipulate data within the model. A controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.

© Copyright CSC PLOENZKE AG

MVC1

In GUIs, views and controllers often work very closely together. For example, a controller is responsible for updating a particular parameter in the model that is then displayed by a view. In some cases a single object may function as both a controller and a view. Each controller-view pair is associated with only one model, however a particular model can have many view-controller pairs.

© Copyright CSC PLOENZKE AG

MVC2
• Model = business data and rules, shared by all clients • Controller = defines the application behavior, interprets user actions and maps them into actions performed on the model • View = renders the contents of the Model

© Copyright CSC PLOENZKE AG

Various Interactions between J2EE Components

CLIENTS TIER
(Web Components)

J2EE WEB APPLICATION SERVER TIER PRESENTATION LOGIC BUSINESS LOGIC
(EJB Container )

BACK END TIER

External Clients from INTERNET (Browsers , WAP etc.)

SERVLETS

EJB Java Beans

EJB Java Beans

Applets JSP EJB Java Beans EJB Java Beans

Enterprise Information Systems (Databases, ERP, Legacy Systems)

EJB Java Beans XML

EJB Java Beans

Internal Clients from INTRANET (Browsers , Desk top Applications etc.) Applets, Javabeans WML JDBC HTML

ENTERPRISE SERVICES

JNDI

JMS

JTS

RMI - IIOP

© Copyright CSC PLOENZKE AG

Components and Components APIs

Java Servlet Technology:--Java servlet technology was created as a portable way to provide dynamic, user-oriented content. A servlet is a Java programming language class that is used to extend the capabilities of servers that host applications access via a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by web servers. For such applications, Java Servlet technology defines HTTP-specific servlet classes. Two packages make up the Servlet architecture – • javax.servlet and javax.servlet.http 1. 2. javax.servlet package contains the generic interfaces and classes that are implemented and extended by all servlets. javax.servlet.http package contains the classes that are extended when creating HTTP specific servlets (servlets that respond to HTML)

At the heart of this, is the interface javax.servlet.Servlet – it provides the framework for all servlets. It defines five methods.

© Copyright CSC PLOENZKE AG

A High Level Object Model of Servlet Framework
<<Interface>> javax,.servlet.Servlet init() getServletConfig() service() getServletInfo() destroy() <<Interface>> javax,.servlet.ServletConfig

getIntiParameter() getServletContext() getInitParameterNames()

<<Interface>> javax,.io.Serializable

javax,.servlet.GenericServlet javax,.servlet.http.HttpServlets getServletContext() getIntiParameter() getInitParameterNames() log() getServletInfo() init() getServletConfig() service() destroy()

doDelete( ) doGet( ) doOptions( ) doPost( ) doPut( ) doTrace( ) service() getLastModified()
© Copyright CSC PLOENZKE AG

GenericServlet and HttpServlet
•Java servlets do not have a main () method, which is why all servlets must implement the javax.servlet.Servlet Interface. •The HttpServlet class is extended from the GenericServlet class. • The two objects that the service() method receives are the ServletRequest and ServletResponse. •ServletRequest Object holds the information that is being sent to the servlet. •ServletResponse object is where we place the data we want to send back to the server. What happens when you extend HttpServlet – Do you implement the service() method?? - No, because it has already been implemented for you

© Copyright CSC PLOENZKE AG

GenericServlet and HttpServlet

Response

Client
Request Web server

GenericServlet Service( )*

HttpServlet Response

Client
Request Web server *abstract method
© Copyright CSC PLOENZKE AG

Service( )

doDelete( ) doGet( ) doOptions( ) doPost( ) doPut( ) doTrace( )

Servlet Life Cycle
The life cycle of a servlet is controlled by the container in which the servlet has been deployed. When a request is mapped to a servlet, the container performs the following steps. 1. If an instance of the servlet does not exist, the web container a. Loads the servlet class. b. Creates an instance of the servlet class. c. Initializes the servlet instance by calling the init method. Invokes the service method, passing request and response objects. If the container needs to remove the servlet, it finalizes the servlet by calling the servlet's destroy method.

1. 3.

© Copyright CSC PLOENZKE AG

Init() method

The init() method is where the servlet life begins. 1. 2. 3. 4. 5. It is called only once It is called by the server immediately after the servlet is instantiated. The init() method is defined as follows – public void init(ServletConfig config) throws ServletException; If, for some reason, the servlet cannot initialize the resources necessary to handle requests, the init() method throws an exception.

The most common way of saving the object ServletConfig for later references, is to have the init() call the super.init(), passing it the ServletConfig object.

© Copyright CSC PLOENZKE AG

Service() method

1. 2. 3. 4.

The service() method handles all requests sent by a client (typical role of a client services manager). It starts after the init() method has been executed. The most common implementation of the service() is in the HttpServlet class (done by extending the GenericServlet abstract class). The signature of the service() is: public void service(ServletRequest req, ServletResponse res) throws ServletException, IOException;

5.

The ServletRequest object contains information about the servlet request, encapsulating information provided by the client. The ServletResponse object contains the info returned by the client.

© Copyright CSC PLOENZKE AG

Destroy() method

1. 2. 3. 4.

This method signifies the end of the servlet’s life. This is where any resources that were created in the init() should be cleaned up. (If you have an open database connection, you should close it here) The signature of destroy() is – public void destroy(); This is also a very good place to save any persistent information that will be used the next time the servlet gets loaded.

© Copyright CSC PLOENZKE AG

JSP (Java Server Pages)

1. 2. 3. 4. 5. 6.

Another set of server side Java APIs to enhance web server functionality. JavaServerPages (JSP) technology allows web developers to rapidly develop dynamic web pages and easily maintain them. JSP technology enables rapid development of web-based applications that are platform independent and enjoy cross-web-server support. Collecting data / presenting processed results to the client. Java snippets can be embedded into normal HTML code. Closely linked interaction with JavaBeans API.

© Copyright CSC PLOENZKE AG

JSP Architecture

JSP pages are subject to two phases. • • Translation phase Request processing phase

Translation phase : The JSP page is translated only once, until the JSP page changes again.

Request processing phase : After the page has been translated, the request processing phase is handled by the servlet

© Copyright CSC PLOENZKE AG

JSP Translation

© Copyright CSC PLOENZKE AG

JSP Translated Servlet

© Copyright CSC PLOENZKE AG

© Copyright CSC PLOENZKE AG