Download Introduction to J2EE Part 1-Introduction to Java Programming-Lecture Slides and more Slides Java Programming in PDF only on Docsity!
Agenda
2 cs420 Fall 2010
` Introduction to J2EE
` What is J2EE? Why J2EE? Understanding the benefits of J2EE
` Evolution of Enterprise Application Development Frameworks
Getting a big picture of J2EE architecture and platform Constituent APIs and Technologies
Reference Chapter 1: Overview" of Java EE 5 Tutorial (or "Chapter 1: Overview" of J2EE 1.4 Tutorial) - must read # J2EE introductory chapters (chapter 1 & 2) of J2EE blueprint (Very good introduction on J2EE) - must read # J2EE overview from java.sun.com (High-level description on J2EE) - read if you have time
3
What is J2EE?
Now let's talk what J2EE really is, first.
Slide 4
Enterprise Computing
4 cs420 Fall 2010
Challenges Portability Diverse Environments Time-to-market Core Competence Assembly Integration
Key Technologies J2SE⢠J2EE⢠JMS Servlet JSP Connector XML Data Binding XSLT
Products App Servers Web Servers Components Databases Object to DB tools
Legacy Systems Databases TP Monitors EIS Systems
Slide 5
The Java⢠Platform
7 cs420 Fall 2010
Optional Packages
Java 2 Enterprise Edition (J2EE)
Java 2 Standard Edition (J2SE)
JVM
JavaCard APIs CardVM
Packages^ Optional
Personal Basis Profile
Personal Profile
Foundation Profile
CDC
MIDP
CLDC
KVM
Java 2 Platform Micro Edition (J2METM)
*** Under development in JCP**
This is another picture that shows three flavors of Java technology. Java is being used at JavaCard at one end and
at the supercomputer at the other end.
The key point in this picture is that the syntax and semantics of Java programming language is preserved regardless
of which edition you use. And regardless where it is being used, it provides the secure, portable, and robust
application development and deployment platform.
Slide 8
What Makes Up J2EE?
8 cs420 Fall 2010
` API and Technology specifications
` Development and Deployment Platform
` Standard and production-quality implementation
` Compatibility Test Suite (CTS)
` J2EE brand
` J2EE Blueprints
` Sample codes
9
Evolution of
Enterprise Application
Frameworks
OK, we just took a look at the evolution of distributed computing from a very high level. Now let's talk about the
evolution of enterprise application framework and see how things have evolved into an architecture like J2EE. As
you will see, there have been quite a bit of evolution before we arrive an architecture like J2EE.
Slide 10
Evolution of Enterprise
Application Framework
10 cs420 Fall 2010
` Single tier
` Two tier
` Three tier
` RPC based
` Remote object based
` Three tier (HTML browser and Web server)
` Proprietary application server
` Standard application server
The evolution of enterprise application framework starts from singleâtier mainframe based model in the beginning,
moved to first phase of distributed framework, twoâtier client server model, then three tier model.
Within the threeâtier model, there are two communication models. First one is based on RPC (Remote Procedure
Call) model in which nonâobjectâbased procedures are invoked by the client. The other model incorporates the
concept of object in which remote object is accessed by the client.
When the Internet took off, the three tier model takes a very radical transformation in which HTML browser talks
to a Web server, which then talks to backend database or enterprise information systems.
The next two phases are advent of the concept of application server, first, app server based on proprietary
architecture and API and the next phase is where we are today with open standard based app server architecture,
which is what J2EE is all about.
Single-Tier: Pros & Cons
13 cs420 Fall 2010
Pros: No client side management is required Data consistency is easy to achieve Cons: ` Functionality (presentation, data model, business logic) intertwined, difficult for updates and maintenance and code reuse
In a single tier model, because the clients are dumb terminals and do not have any processing logic what so ever,
there is no client side management required. Also because the data access logic is in complete control of the
mainframe application, the data consistency is easy to achieve.
Now the negative side of single tier model is that there is no separation among presentation, business logic, and
data access. This doesn't facilitate code reâuse because all functionality is mixed together. Changing data or
business logic may affect every part of the application, making changes (for example, adding new functionality or
bug fixes) difficult task.
Two-Tier
14 cs420 Fall 2010
` Fat clients talking to back end database
` SQL queries sent, raw data returned
` Presentation, Business logic and Data Model
processing logic in client application
SQL request
SQL response
The next evolution phase is twoâtier model. The two tier model appears along with the advent of personal
computer, which was increasingly used as client platform of choice replacing dumb terminals.
In twoâtier model, fat clients are talking to backend database by using some database access protocol such as SQL.
The clients are called âfatâ clients because the clients have to maintain presentation logic, business logic, and have
to have detailed understanding on data model of the backend data and how to access it.
Three-Tier (RPC based)
16 cs420 Fall 2010
**T hinner client:** business & data model separated from presentation Business logic and data access logic reside in middle tier server while client handles presentation Middle tier server is now required to handle system services Concurrency control, threading, transaction, security, persistence, multiplexing, performance, etc.
SQL request SQL response
RPC response
RPC request (^) Databas e
The âdifficult to upgrade clientsâ problem of twoâtier model triggers the advent of next one, threeâtier model.
The most distinguishing characteristic of three tier model is that now there is a separation between presentation
logic from the other two. That is, the presentation logic is handled at the client while business and data access
logic are handled at the middle tier server. In this sense, the clients of threeâtier model is thinner than the ones in
twoâtier model. And the changes of business logic and data model can be done more flexibly than twoâtier model
because the only place the changes need to be reflected are at the middleâtier server not at the clients.
The three tier model, however, introduces an interesting problem of its own. Now because the middleâtier server
receives service requests from many clients at the same time, the middleâtier now has to deal with various system
level issues such as concurrency control, threading, transaction, security, persistence, multiplexing, performance,
and so on.
Now as mentioned before, the three tier model can be further divided into RPCâbased and Remote object based.
In RPC based model, the clients and the middleâtier server are more tightly coupled than the object model
because they have to agree upon on the implementation level (rather than interface level of remote object based
model.)Ăž
Three-tier (RPC based):
Pros & Cons
17 cs420 Fall 2010
` Pro:
` Business logic can change more flexibly than 2-tier
model
` Most business logic reside in the middle-tier server
` Cons:
Complexity is introduced in the middle-tier server Client and middle-tier server is more tightly-coupled (than the three-tier object based model) ` Code is not really reusable (compared to object model based)
So the benefit of using threeâtier model over twoâtier model is again the business logic and data model can be
more easily changed.
Now the downside of the threeâtier model is that now the middleâtier server has to deal with complex system level
issues as mentioned in the previous slide. And compared to objectâbased three tier model, it is more tightly
coupled because change of implementation on either side might require change on the other. And since it is not
really objectâmode based, the code is not reusable.
Three-tier (Remote Object based):
Pros & Cons
19 cs420 Fall 2010
` Pro:
` More loosely coupled than RPC model
` Code could be more reusable
` Cons:
` Complexity in the middle-tier still need to
be addressed
The advantage of this approach is that now the client and the server are more loosely coupled than RPC model
because the only agreement they have to have is abstract description of the service. How they are implemented
either at the client or at the server do not impact each other. So implementation change at the server side should
not force a change on the client side, for example, as long as the interface definition remains the same. And
because the code is in the form of object, reâusability can be increased.
However, the issue that the server still has to deal with system level services still remain the same.
Three-Tier (Web Server)
20 cs420 Fall 2010
` Browser handles presentation logic
` Browser talks Web server via HTTP protocol
` Business logic and data model are handled by
âdynamic contents generationâ technologies
(CGI, Servlet/JSP, ASP)
SQL request SQL response
HTML response
HTML request
Databas e
WEB Server
Now a completely different threeâtier model has emerged as the browser has become one of the most pervasive
form of user interface at the client platform. In this model, the browser basically provides common presentation
logic. And the browser and the server communicates using a standard protocol, HTTP. And the business logic and
data model are captured in dynamic contents generation technologies such as CGI, servlet/JSP, or ASP. These
technology components in turn talk to backend database or enterprise information system.
