03/19/2007

Introduction to
Java EE (J2EE)
1

1
03/19/2007

Session Objectives
? Understanding the value propositions of
J2EE
? Getting a big picture of J2EE architecture
and platform
? Getting high-level exposure of APIs and
Technologies that constitute J2EE
– You don't have to understand the details
? Understanding why J2EE is a great
platform for development and deployment
of web services
2

These are the session objectives.

At the end of this session, I expect you to get a big picture of J2EE
architecture and platform. So I am trying to cover J2EE at 10,000 feet
level. in this session.

I also expect you to understand the value propositions of J2EE, that is, why
J2EE is the platform of choice for building and deploying enterprise
applications.

I will also cover all the major API's and technologies that constitute J2EE
in this session so that you know what they are and how they are related to
each other.

Finally, I will talk about why J2EE is the platform of choice not only for
building we-based based enterprise applications but also building web
services.

2
03/19/2007

Agenda
? What is J2EE?
? Evolution of Enterprise Application Development
Frameworks
? Why J2EE?
? J2EE Platform Architecture
? J2EE APIs and Technologies
? Standard Impl (J2EE 1.4), Compatibility Test Suite
(CTS)
? BluePrints
? J2EE and Web Services
? How to get started
3

This is the agenda of this session. First, we will briefly talk about what J2EE
architecture and platform is. Then, we will talk about how the enterprise
application development framework has evolved into J2EE architecture of
today. Then we will talk about value-propositions of J2EE not only from
developer standpoint but also from user and business standpoint. Then we will
spend some time talking about J2EE platform architecture during which we
will talk about 3 or 4 tier architectures. We will then spend various J2EE APIs
and technologies that make up the J2EE architecture. The rest of the
presentation will be devoted to standard implementation, compatibility test
suite and blue prints. The last part of this presentation is to let people know on
how to get started on learning J2EE technology.

3
03/19/2007

What is J2EE?

Now let's talk what J2EE really is, first.

4
03/19/2007

Enterprise Computing
Challenges Key Products
Portability Technologies App Servers
Diverse J2SE™ Web Servers
Environments J2EE™ Components
Time-to-market JMS Databases
Core Competence Servlet Object to DB
Assembly JSP tools
Integration Connector
XML
Legacy
Data Systems
Binding
Databases
XSLT
TP Monitors
EIS Systems
5

So what is enterprise computing? What are the challenges that enterprise application
developers like yourselves are facing today? We all know the enterprise computing
has come a long way from the old, mainframe-based, monolithic model where
everything is lumped up together through the client-server model of early 1990s
where fat clients are talking to backend databases directly to the current model where
applications are web-based, n-tier, well-distributed over the heterogeneous
environment where software are to be built as objects and components.
And of course, the set of challenges you face have changed as well. For a start, the
applications you are building have to be portable, scalable, reliable, secure,
maintainable, and of course, they have to function in high-performance. And they also
have to be adaptable and flexibile to accommodate the constant changes in business
requirements.
Given the challenges you face, you also have to decide which key technologies and
products and architeural platform to use in order to meet those challenges. The
problem is there are simply too many of them and it is hard to come up with your own
architecture or framework where everything is in a well-integrated and cohesive form.
Another important issue you ask yourself is integration of legacy systems. That is,
how are you going to integrate the existing database and EIS systems into the overall
architecture?
These are all valid questions and issues of enterprise computing today. The good
news is J2EE is specifically designed to address all these issues.

5
03/19/2007

What Is the J2EE?

l Open and standard based platform

for
l developing, deploying and managing
l n-tier, Web-enabled, server-centric,
and component-based enterprise
applications

What is J2EE? In short, it is an open, standard-based, development and

deployment platform for building n-tier, web-based and server-centric, and
component-based enterprise applications.

6
03/19/2007

The Java™ Platform

Java Technology Java Technology Workgroup High-End

Enabled Devices Enabled Desktop Server Server

By now, most of you know there are three flavors of Java - Micro Edition,
Standard Edition, and Enterprise Edition. These three flavors of Java represent
three distinct target market segments each of which has unique issues and
requirements that need to be addressed somewhat differently.

Micro Edition addresses of market segment of small devices such as PDAs, cell
phones and settop boxe, which are typically constrained in terms of memory space
and processing power.

Standard Edition represents the Java that we all know and love, a Java for desktop
and workgroup server environments that require a full feature functionalities
including rich graphical user interface.

Enterprise Edition covers the Java platform for developing and deploying
enterprise qualitiy applications which are typically transactional, reliable and
secure.

Also note that the “Enterprise Edition” box in the graphic extends into the standard
edition, that is, Enterprise edition is built over standard edition.

7
03/19/2007

The Java TM Platform

Java 2 Platform Micro Edition
(J2ME TM)

Optional
Packages

Optional
Packages

Personal Personal
Java 2 Java 2 Basis Profile Profile
Enterprise Standard
Edition Edition Foundation Profile MIDP
(J2EE) (J2SE) Java
CDC CLDC Card
APIs

JVM KVM CardVM

* Under development in JCP

8

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.

8
03/19/2007

What Makes Up J2EE?

? API and Technology specifications
? Development and Deployment Platform
? Standard and production-quality
implementation
? Compatibility Test Suite (CTS)
? J2EE brand
? J2EE Blueprints
? Sample codes

So now some of you might be ready to ask “What exactly do I get from J2EE?” .
This slide shows the list of things that come with J2EE.

First and foremost, J2EE is a set of API and technology specifications. And we
will see the detailed list of APIs and technologies of J2EE in the following slide.

J2EE also provides you with a standard development and deployment platform.
What does this mean? From developer’s perspective, it means is that J2EE
provides a standard framework of building server components. From platform
vendors’ perspective, it means their platforms should be able to run any
applications that uses J2EE-compliant APIs.

Reference implementation and compatibility suite. Just like any other Java
initiative based on Java community process, J2EE also comes with its own
reference implementation and compatibility test suite. J2EE is also a brand of all
compliant products. That is, J2EE compliant app servers are stamped with J2EE
branding after they passed regorous J2EE compatibility testing.

Finally, J2EE also provides something unique called J2EE BluePrints, which is a
documentation and sample program in which best practice guidelines and design
principles for building J2EE-based enterprise applications are described in detail.

9
03/19/2007

Evolution of
Enterprise Application
Frameworks

10

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.

10
03/19/2007

Evolution of Enterprise
Application Framework
? Single tier
? Two tier
? Three tier
– RPC based
– Remote object based
? Three tier (HTML browser and Web server)
? Proprietary application server
? Standard application server
11

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.

11
03/19/2007

About Enterprise Applications

? Things that make up an enterprise
application
– Presentation logic
– Business logic
– Data access logic (and data model)
– System services
? The evolution of enterprise application
framework reflects
– How flexibly you want to make changes
– Where the system services are coming from
12

Now if you think about the things that make up a typical enterprise application,
they include presentation logic, business logic, data access logic, and system
services.

The presentation logic deals with how to present information to the end-users.
The business logic includes the business logic of the application. And the data
access logic deals with accessing data in the back-end database. The system
services includes security, caching, logging, transaction, and other services that
typical enterprise application would use.

Now the way the enterprise application framework evolves reflects how
flexibly you want to make changes in the presentation logic, business logic and
data access and data models. The other factor reflects how the system services
are provided by the framework.

12
03/19/2007

Single Tier (Mainframe-based)

? Dumb terminals are directly connected to

mainframe
? Centralized model (as opposed distributed
model)
? Presentation, business logic, and data
access are intertwined in one monolithic
mainframe application 13

In the beginning of computing era, the model is pretty much a single

tier model in which dumb terminals are directly connected to a
mainframe. Here the mainframe is centralized point of computing
intelligence in which presentation, business logic, and data access are
all intertwined in a single monolithic mainframe application.

13
03/19/2007

Single-Tier: Pros & Cons

? 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

14

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.

14
03/19/2007

Two-Tier
SQL
request
Database
SQL
response

? Fat clients talking to back end

database
– SQL queries sent, raw data returned
? Presentation,Business logic and Data
Model processing logic in client
application 15

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.

15
03/19/2007

Two-Tier
? Pro:
– DB product independence (compared to single-tier model)
? Cons:
– Presentation, data model, business logic are intertwined (at
client side), difficult for updates and maintenance
– Data Model is “tightly coupled” to every client: If DB
Schema changes, all clients break
– Updates have to be deployed to all clients making System
maintenance nightmare
– DB connection for every client, thus difficult to scale
– Raw data transferred to client for processing causes high
network traffic
16

The advantage of using two-tier model is that it provides database

independence and database access protocol is standard SQL language
compared to single-tier model.

Yet, it has very significant disadvantages as well. First, the presentation,

business logic and data model are now intertwined, this time, at the client side,
thus suffers same problem of difficult maintenance and updates. Second,
because the data model of the server also has to be maintained at the client,
every time there is a data model change, for example, a schema change, then all
the clients need to be updated. This could be a very serious deficiency if the
number of clients are in the range of thousands even in the range of hundreds.

Now since each client has to have a database connection, it would be rather
difficult to scale in that it is not possible to provide “connection
pooling”scheme., which is typical mechanism for supporting scalability.

Because the data is in the form of raw data, there could be very high demand
on network bandwidth.

16
03/19/2007

Three-Tier (RPC based)

SQL
RPC request request
Database
RPC response SQL
response

? Thinner 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. 17

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.) 17
03/19/2007

Three-tier (RPC based): Pros & Cons

? 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)
18

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.

18
03/19/2007

Three-Tier (Remote Object based)

Object request SQL

request
Database
Object SQL
response response

? Business logic and data model captured in

objects
– Business logic and data model are now described
in “abstraction” (interface language)
? Object models used: CORBA, RMI, DCOM
– Interface language in CORBA is IDL
– Interface language in RMI is Java interface 19

Now the next evolution is remote object-based three tier model.

The key difference of this model from the three tier RPC model is
that now the business logic and data model are captured in objects,
which means they can be expressed in the abstract terms.

For example, the most popular remote object model is CORBA and
RMI. In the case of CORBA, the business logic is abstractly
expressed in IDL (Interface Definition Language) while in the case
of RMI, it is in the form of Java interface type.

19
03/19/2007

Three-tier (Remote Object

based): Pros & Cons
? Pro:
– More loosely coupled than RPC model
– Code could be more reusable
? Cons:
– Complexity in the middle-tier still need to be
addressed

20

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, reusability can be increased.

However, the issue that the server still has to deal with system level services
still remain the same.

20
03/19/2007

Three-Tier (Web Server)

SQL
HTML request WEB request
Server
Database
HTML response SQL
response

? 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)
21

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.

21
03/19/2007

Three-tier (Web Server based):

Pros & Cons
? Pro:
– Ubiquitous client types
– Zero client management
– Support various client devices
? J2ME-enabled cell-phones
? Cons:
– Complexity in the middle-tier still need to be
addressed

22

Now the obvious reason browser is popular is that the presentation logic and
the communication model between the clients and the server are based on
standards, HTML browser and HTTP protocol respectively. And you certainly
have less to worry about as far as client management is concerned.

Another advantage of this model is because HTML and HTTP are standards,
any client types, for example, J2ME-enabled cell-phones, can communicate
with the server via HTTP.

The downside is that the middle-tier complexity still needs to be addressed.

22
03/19/2007

Trends
? Moving from single-tier or two-tier to multi-
tier architecture
? Moving from monolithic model to object-
based application model
? Moving from application-based client to
HTML-based client

23

So based on this evolution, we can observe a few trends. First, moving from a
single tier or two-tier model to multi-tier model. Second, moving from the
monolithic code to object-based application model. Lastly, HTML browser
based clients are taking some strong hold.

23
03/19/2007

Single-tier vs. Multi-tier

Single tier Multi-tier
l No separation l Separation among
among presentation, presentation,
business logic, business logic,
database database
l Hard to maintain l More flexible to
change, i.e.
presentation can
change without
affecting other tiers

24

Now let's compare the single-tier model against multi-tier model. In a single tier model
or even two-tier model, there is no separation among presentation, business, and data
access logic, which makes it harder to maintain the code while in multi-tier model, there
are separation among those three functionality. And because they are separated, a
change in one area should not impact the others, which provides much more flexible
way of maintaining the code.

24
03/19/2007

Monolithic vs. Object-based

Monolithic Object-based
l 1 Binary file l Pluggable parts
l Recompiled, l Reusable
relinked, l Enables better
redeployed every design
time there is a l Easier update
change l Implementation
can be separated
from interface
l Only interface is
published
25

Now let's compare monolithic model and object-based model. In a monolithic model,
everything is intertwined. This means every time you make a change, the whole thing
has to be recompiled and re-linked and redeployed. In the object-based model, things
are more flexible and reusable. Again, the implementation can change without affecting
the other programs residing in different tiers as long as interface remains the same.

25
03/19/2007

Outstanding Issues & Solution

? Comlexity at the middle tier server still remains
? Duplicate system services still need to be
provided for the majority of enterprise
applications
– Concurrency control, Transactions
– Load-balancing, Security
– Resource management, Connection pooling
? How to solve this problem?
– Commonly shared container that handles the above
system services
– Proprietary versus Open-standard based
26

Now the issue of “middle tier still need to deal with system level issues such as
concurrency control and resource management” still remains the same.
Furthermore, since every application has to deal with these issues, there could
be duplication among the applications in the area of system services.

So what could be the solution? The solution is to come up with an architecture

or framework where the common container which can be shared among all
applications provide system services mentioned above.

And that is where next evolution has occurred, initially with proprietary form
and later on based on an open-standard.

26
03/19/2007

Proprietary Solution
? Use "component and container" model
– Components captures business logic
– Container provides system services
? The contract between components and
container is defined in a well-defined but
with proprietary manner
? Problem of proprietary solution: Vendor
lock-in
? Example: Tuxedo, .NET
27

So in both proprietary and standard based model, the idea is to use component
and container model in which business logic is captured as components and the
container provide host execution environment where system services are also
provided. Of course, the proprietary model locks you in a single product and
single vendor and the examples are good old Ttuxedo and of course .NET is
another prime example of this.

27
03/19/2007

Open and Standard Solution

? Use "component and container" model in
which container provides system services
in a well-defined and as industry standard
? J2EE is that standard that also provides
portability of code because it is based on
Java technology and standard-based Java
programming APIs

28

Open and standard based solution is that a standard specification defines the
contract of the component and container model in a well-defined and in an
industry-standard.

And J2EE is that standard. And because it is based on Java technology, the
portability of code also can be achieved regardless underlying OS or hardware
architecture.

28
03/19/2007

Why J2EE?

29

OK, by now, I assume you get the sense of how enterprise application
architecture has evolved into what it is today, namely open standard
basedJ2EE framework.

Now I would like to spend some time talking about the concrete value that
J2EE provides to different players in the scene of enterprise computing.

29
03/19/2007

Platform Value to Developers

? Can use any J2EE implementation for
development and deployment
– Use production-quality standard implementation
which is free for development/deployment
– Use high-end commercial J2EE products for
scalability and fault-tolerance
? Vast amount of J2EE community resources
– Many J2EE related books, articles, tutorials,
quality code you can use, best practice
guidelines, design patterns etc.
? Can use off-the-shelf 3rd-party business
components
30

First, let's talk about J2EE platform value to developers.

Now with J2EE, developers do not have to be tied up with particular vendor
platform because they can use any J2EE-compliant implementation as their
development platform while application portability is still guaranteed. For
example, you can use freely available J2EE implementations such as Sun Java
System App Server Platform Edition for development while you might want to
use high-end commercial platforms for actual production deployment
especially when scalability, reliability, fault-tolerance, and high-performance
are important factors.

Second,J2EE is, for that matter, Java, is all about community. There is vast
amount of J2EE community resource that be leveraged by J2EE developers, for
example, books, articles, tutorials, and quality code that you can use, best
practice guidelines and design patterns people have spent time to develop. If
you think about it, these are very significant value.

Thirdly, because J2EE is based on component model, that is, 3rd party
components can be used to build enterprise applications thus saving time and
money.

30
03/19/2007

Platform Value to Vendors

? Vendors work together on specifications
and then compete in implementations
– In the areas of Scalability, Performance,
Reliability, Availability, Management and
development tools, and so on
? Freedom to innovate while maintaining the
portability of applications
? Do not have create/maintain their own
proprietary APIs
31

So what are the J2EE value proposition to vendors? First vendors work
together on creating specifications and then they compete in implementations.
And the areas they compete include scalability, performance, reliability,
availability, management and development tools, and so on.

This way, vendors have freedom to innovate in their implementations while

maintaining the portability of their applications. So bottom line is that vendors
can influence the future of Java while they can continue to innovate.

And vendors are free from having to maintain their own proprietary APIs.
Instead they focus on better implementations.

31
03/19/2007

Platform Value to Business

Customers
? Application portability
? Many implementation choices are possible
based on various requirements
– Price (free to high-end), scalability (single CPU to
clustered model), reliability, performance, tools,
and more
– Best of breed of applications and platforms
? Large developer pool

32

Now what about the business customers? First and foremost, to customers,
application portability is guaranteed, which means they can choose best of
breed applications as well as best of breed platforms based on many criteria, for
example, price, scalability, reliability, and performance, and tools, and so on.

There are large developer pool they can tap with. And then they can use many
quality open source implementations such Tomcat, Struts, Cocoon, and Axis
and so on, over the J2EE platform

32
03/19/2007

J2EE APIs &

Technologies

33

Now let's talk J2EE APIs and technologies. I don't intend to give detail
description of these technologies here since we have the remaining
sessions talking about these technologies in detail. But I want to give you
a big picture so that you understand where these individual technologies fit
in under the big picture of J2EE. So if you don't understand the details of
these technologies, don't worry about it. Instead just get some sense on the
roles these technologies play for particular application requirements.

33
03/19/2007

J2EE 1.4 APIs and Technologies

? J2SE 1.4 (improved) ? Servlet 2.4
? JAX-RPC (new) ? JSP 2.0
? Web Service for ? EJB 2.1
J2EE ? JAXR
? J2EE Management ? Connector 1.5
? J2EE Deployment ? JACC
? JMX 1.1 ? JAXP 1.2
? JMS 1.1 ? JavaMail 1.3
? JTA 1.0 ? JAF 1.0
34

So this is the summary slide of all Java APIs and technologies that will be
part of J2EE 1.4. I put it here for your reference. The ones in red color
are newly added features while the ones in blue color are the ones whose
functionality is enhanced from the previous version.

34
03/19/2007

Java EE 5
? JAX-WS 2.0 & JSR 181
? Java Persistence
? EJB 3.0
? JAXB 2.0
? JavaSever Faces 1.2 – new to Platform
? JSP 2.1 – Unification w/ JSF 1.2
? StAX – Pull Parser – new to Platform

35

35
03/19/2007

Servlet &
JSP (JavaServer Pages)
36

OK. Let's talk about servlet and JSP, which are cornerstone technologies of
J2EE.

36
03/19/2007

What is a Servlet?
? Java ™ objects which extend the
functionality of a HTTP server
? Dynamic contents generation
? Better alternative to CGI, NSAPI, ISAPI,
etc.
– Efficient
– Platform and server independent
– Session management
– Java-based
37

What is Servlet? A servlet is a Java object that extends the functionality of

HTTP server by providing the capability of dynamic contents generation.

Now you might remember that people used to use CGI for dynamic contents
generation. “What is wrong with CGI?” Lots of things. First, inefficiency. In
CGI, every HTTP request from client results in a creating of a new process,
even if they are from a same client, which is quite inefficient and of course
because of that, cannot scale to handle large number of clients at the same time.

The servlet technology is designed to solve these problems associated with

using CGI, or proprietary APIs such as NSAPI or ISAPI. For example, Servlet
handles the HTTP client requests much more efficiently than CGI because it
does not have to create new process every time there is a new client request.
Instead, it creates a new thread. Because it is Java and because it is standard-
based, most of the web servers out there support servlet. It also handles session
management for you so that you don’t have to deal with it yourself. By being
Java code, it is cross-platform technology as opposed to vendor-specific or
product-specific technologies such as NSAPI or ISAPI.

37
03/19/2007

Servlet vs. CGI

Request
RequestCGI1
CGI1 Child
Childfor
forCGI1
CGI1
Request CGI
CGI
RequestCGI2
CGI2 Based Child
Based Childfor
forCGI2
CGI2
Webserver
Webserver
Request
RequestCGI1
CGI1 Child
Childfor
forCGI1
CGI1

Request
RequestServlet1
Servlet1 Servlet
ServletBased
BasedWebserver
Webserver
Request Servlet1
RequestServlet2
Servlet2 Servlet1
JVM
JVM
Request Servlet1 Servlet2
Servlet2

38

This picture shows difference between CGI and servlet-based model. In CGI, for
every HTTP request, a new process has to be created while in servlet model, it is
the thread that gets created in the same Java VM (Virtual Machine) and that thread
can stay there for serving other requests.

38
03/19/2007

What is JSP Technology?

? Enables separation of business logic
from presentation
– Presentation is in the form of HTML or
XML/XSLT
– Business logic is implemented asJava
Beans or custom tags
– Better maintainability, reusability
? Extensible via custom tags
? Builds on Servlet technology
39

JSP, Java Server Pages, was introduced as a follow-on technology to the Servlet. Even though
the Servlet solves many problems associated with CGI for dynamic contents generation, it has
one downside. The downside is that, under Servlet, the presentation, typically HTML pages, has
to be generated as part of the servlet Java code, for example, using printf statement. What this
means is that whenever you have to make some change to the presentation, the Java code has to
be changed and then recompiled, redeployed. This in turn result in maintenance problem of your
applications. Also it makes web-page prototyping effort rather a difficult task.

JSP is designed to address of this shortcoming of the Servlet while maintaining all the benefits of
Servlet. That is, it provides a clear separation between the presentation and business logic code.
That is, the presentation will be designed by Web page designers in the form of either HTML or
XML or JSP page while the business logic will be implemented by Java programmers either in
the form of Java Beans or custom tags. This separation will result in a better maintainability of
both presentation pages and business code. And because the business logic is encapsulated into
Java beans or custom tags, it increased reusability of the code as well.

I mentioned about custom tags. Custom tags are basically specialized Java beans which
encapsulate the application-specific business logic. The functionality of enterprise applications
can be extended by building more custom tags.

Finally, JSP technology is built over servlet. In fact, JSP pages when deployed get converted
into servlet first. Because it is built over servlet, it maintains all the benefits of servlet. For
example, all the ready-to-use objects in a servlet such as session objects can be also available to
JSP page designers and custom tag developers. 39
03/19/2007

EJB
(Enterprise Java
Beans)
40

40
03/19/2007

What is EJB Technology?

? A server-side component technology
? Easy development and deployment of
Java technology-based application
that are:
– Transactional, distributed, multi-tier,
portable, scalable, secure, …

41

What is EJB? In short, it is a server-side component technology, which enable

the easy development and deployment of Java-based enterprise applications in
the form of components that have to be enterprise-quality, meaning they are
transactional, distributed, multi-tier, portable, scalable, secure, and reliable, and
the list can go on.

41
03/19/2007

Why EJB Technology?

? Leverages the benefits of component-model
on the server side
? Separates business logic from system code
– Container provides system services
? Provides framework for portable components
– Over different J2EE-compliant servers
– Over different operational environments
? Enables deployment-time configuration
– Deployment descriptor

42

Why EJB? By providing a standard component model on the server side, it leverages all the
benefits that are inherent in component technology, for example, simplified development and
deployment and reuse of the code.

Another key benefit of EJB is the separation of business logic from system code. That is, the EJB
server platform provides all the system services such as resource management, transaction
coordination and persistence management. Since the system services are provided by the server
platform itself, you, as a developer, can now focus your development effort to building business
logic components rather than system code.

Because EJB is built around industry-standard component framework, because it is based on

Java, it allows portability of your components. That is, the business logic components you build
will be portable across different vendors’ server platforms as well as different operational
environments without any change in your code or without even recompiling. It is truly binary
portability we are talking about.

Now you might want to ask? How do these components adapt themselves to the different
operational environments? That is, different operational environments have different
requirements on security policy, they have different databases in place , different transactional
model maybe have to be used. How do you instruct your business components to a different
behavior without actual change of code? It is done by what is called deployment descriptor. The
deployment descriptor is essentially an XML file that specifies the runtime behavioral
characteristics of your business component. And it gets constructed or changed at the time of
deployment not at the time of code development.

42
03/19/2007

EJB Architecture

43

This picture shows a somewhat simplified architecture of EJB. We will talk about
the concept of containers and components later on. But a key architectural concept
of EJB is that there is a separation of business logic components from the hosting
execution environment in which those components are running. The business logic
components under EJB architecture are represented as EJB beans while the hosting
environment is represented by EJB container (sometimes called as EJB server).

As a business component developer, you have to write three Java files and a
deployment descriptor. First you have to write EJB home interface which defines
the methods that will be used by clients in order to create and locate your bean
through the container. Second, you have to write EJB remote interface which
defines the business methods of your bean. Finally, you will build your bean and
deployment descriptor which specifies which Java interface is home interface and
which Java interface is remote interface, and which class is in fact your bean class.

Now container, at the time of deployment of your beans, will create two internal
and intermediary objects, EJB home object and EJB remote object. These objects
are implementation of home and remote interface you have defined. So when the
client wants to invoke some business methods of the EJB bean you created, it is
actually talking to these two intermediary objects instead. Why this indirection?
This is to allow the container to intercept the calls so that it can provide system
services such as security, transaction, persistence, resource management, life cycle
management, and so on. 43
03/19/2007

Enterprise JavaBeans
Enterprise JavaBeans

Synchronous communication Asynchronous communication

Session Bean Entity Bean Message-Driven Bean

Stateless Stateful

Bean managed Container managed

Persistence Persistence
(BMP) (CMP)
44

Now EJB has three bean type - session bean, entity bean, and message
driven bean. And session bean can be either stateful or stateless session
bean. And entity bean can be either bean managed or container managed.

And you as a developer choose which bean type to use depending on the
needs and requirements of your application. For example, you use session
bean when you have to have a client session and you use entity beans to
reflect persistent data and you use message driven bean to receive
messages in an asynchronous fashion. And we will talk about these bean
types and their usage in gory detail later in this course.

44
03/19/2007

JMS
(Java Message
Service)
45

Now let’s talk about JMS, Java Messaging Service. The Java Message Service
(JMS) API has been developed by Sun working in close cooperation with the
leading enterprise messaging vendors.

45
03/19/2007

Java Message Service (JMS)

? Messaging systems (MOM) provide
– De-coupled communication
– Asynchronous communication
– Plays a role of centralized post office
? Benefits of Messaging systems
– Flexible, Reliable, Scalable communication
systems
? Point-to-Point, Publish and Subscribe
? JMS defines standard Java APIs to
messaging systems 46

Messaging has been around for quite a while even before JMS as a way to build reliable, flexible, and scalable
communication system. Some of you might have heard the term, Message-Oriented-Middleware, or MOM in
short. In fact, in the mainframe world, product like IBM’s MQ_Series has been around for quite a while.
Now let’s talk about the concept of messaging and get some sense of what it is and why you want to use it and
when you want to use it.

Messaging enables de-coupled communication (or sometimes called loosely coupled communication) in that
the sender does not have to know the details of the receiver, for example, the sender does not have to know
whether a receiver is a live process or not or the location information of it such as IP address or port number.
Instead the sender and receiver of messages communicate via an intermediary communication framework
called messaging system. This is a departure from tightly-coupled communication systems such as RPC,
socket, or RMI in which the communicating parties are talking each other directly instead of an intermediary
server. In this sense, messaging server functions like a post office. It provides an asynchronous
communication in that a sender of a message does not have to wait for an acknowledgment from the receiver.
Or the receiver of the message can be notified when a message arrives. And because the sender and receiver
are de-coupled, the only means of communication is via sending and receiving messages.

The benefits of using messaging system is that it provides a flexible, reliable, and scalable communication
systems. For example, it provides flexible communication system because the sender and receiver do not have
to know each other, it provides reliable communication system because the intermediary server handle
persistently maintain the message until there is an acknowledgment from the receiver. It is scalable because
the system can handle larger number of clients by adding more server capability at the messaging system itself.

I mentioned that under the model of de-coupled communication, there is an intermediary communication
framework called messaging system. And it is this underlying messaging system, by playing a role of a post
office, that provides necessary support so that applications can send or receive messages.
46
03/19/2007

Connector
Architecture
47

47
03/19/2007

Connector Architecture
? Defines standard API for integrating J2EE
technology with EIS systems
– CICS, SAP, PeopleSoft, etc.
? Before Connector architecture, each App
server has to provide an proprietary adaptor
for each EIS system
– m (# of App servers) x n (# of EIS's) Adaptors
? With Connector architecture, same adaptor
works with all J2EE compliant containers
– 1 (common to all App servers) x n (# of EIS's)
Adaptors
48

As more businesses move towards an e-business strategy, integration with

existing Enterprise Information Systems (EIS) becomes a key to success.
Enterprises with successful e-businesses need to integrate their existing EISs
with new web-based applications. They need to extend the reach of their EISs
to support business-to-business (B2B) transactions.

Before the J2EE Connector architecture was defined, no specification for the
Java platform addressed the problem of providing a standard architecture for
integrating EISs to J2EE application server in a standard-fashion. Most EIS
vendors and application server vendors use non-standard vendor-specific
adaptors to provide connectivity between application servers and enterprise
information systems.

The J2EE Connector architecture provides a Java solution to the problem of

connectivity between the many application servers and EISs already in
existence. By using the J2EE Connector architecture, EIS vendors no longer
need to customize their product for each application server. Application server
vendors who conform to the J2EE Connector architecture do not need to add
custom code whenever they want to add connectivity to a enterprise
information system. So it solves the m (appservers) times n (enterprise
information systems) adaptor problem. That is with connector architecture, the
number of adaptors that need to be developed are the same number of
enterprise information systems since a common adaptor can be used for all 48
J2EE compliant application servers.
03/19/2007

m x n Problem Before
Connector Architecture
m n
App SAP
Server1
App EIS
Server2 2

App EIS3
Server3
App EIS4
Server

49

So this picture shows the m times n adaptor problem before connection

architecture. Again, the connector architecture will reduce it to 1 times n
adaptor scenario.

49
03/19/2007

JAAS (Part of J2SE 1.4)

(Java Authentication &
Authorization Service)
50

Now let's talk about a bit on JAAS, Java Authentication and Authorization
Service. It is now part of J2SE 1.4. That is, every J2SE 1.4 should have JAAS.
Before J2SE 1.4, it used to be an optional package and J2EE 1.3 specifies that
JAAS is to be supported by any J2EE 1.3 compliant implementation.

50
03/19/2007

JAAS: Authentication
? Pluggable authentication framework
– Userid/password
– Smartcard
– Kerberos
– Biometric
? Application portability regardless of
authentication schemes underneath
– JAAS provides authentication scheme independent
API
– Authentication schemes are specified Login
configuration file, which will be read by JAAS
51

JAAS addresses both authentication and authorization. So let's talk about

authentication aspect of JAAS first.

JAAS provides pluggable authentication framework. It is expected that

different business organizations would employ different authentication
schemes. Examples of authentication schemes they might use include
userid/password based authentication, smartcard, Kerberos, or Biometric
authentication.

The idea of JAAS pluggable authentication framework is to allow Java

application that performs the authentication to be portable regardless of the
underlying authentication schemes. So JAAS provides authentication
scheme independent API that can be used by the Java application. There is
also login configuration file that contains information on the authentication
schemes that are deployed for a particular operational environment. And
this login configuration file will be read by JAAS runtime.

51
03/19/2007

JAAS Pluggable Authentication

52

This picture shows the pluggable authentication framework of JAAS. The

application uses the API that is provided by the JAAS runtime
implementation. So the boxes of purple color represents the
implementation code that is provided by the JAAS. And this code reads
the login configuration file during runtime. And each authentication
scheme should provide a class file that is compliant to loginModule service
provider interface that JAAS architecture defines.

52
03/19/2007

JAAS: Authorization
? Without JAAS, Java platform security are
based on
– Where the code originated
– Who signed the code
? The JAAS API augments this with
– Who’s running the code
? User-based authorization is now possible

53

In terms of authorization, JAAS now adds the concept of “who is running

the code” to the matrix of access control. Before JAAS, the access control
is based on two things: where the code originated and who signed the
code. Now with JAAS, the access control is based on three things: where
the code come from, who signed the code, and who is running the code.
So with JAAS, user-based authorization is finally possible.

53
03/19/2007

Other J2EE APIs &

Technologies
54

Now let's go over other Java programming APIs and technologies that
constitute J2EE.

54
03/19/2007

JNDI
? Java Naming and Directory Interface
? Utilized by J2EE applications to locate
resources and objects in portable
fashion
– Applications use symbolic names to find
object references to resources via JNDI
– The symbolic names and object references
have to be configured by system
administrator when the application is
deployed.
55

JNDI stands for Java naming and directory interface and it is a common method for
locating resources or objects under J2EE framework.

JNDI is utilized by J2EE applications to locate resources and objects in a portable

fashion. That is, in your application, you are using a symbolic name to refer an object
assuming that symbolic name has been configured to real object reference or
resource by the system administrator. Because the system administrator can
configure the association of the symbolic name and actual object at the time of
deployment, the code portability is still assured.

55
03/19/2007

JDBC
? Provides standard Java programming
API to relational database
– Uses SQL
? Vendors provide JDBC compliant
driver which can be invoked via
standard Java programming API

56

56
03/19/2007

J2EE Management (JSR-77)

? Management applications should be able to
discover and interpret the managed data of
any J2EE platform
? Single management platform can manage
multiple J2EE servers from different
vendors
? Management protocol specifications ensure
a uniform view by SNMP and WBEM
management stations
? Leverages JMX 57

With J2EE 1.2 and recently with 1.3, pretty much all architectural components that
are considered as fundamental aspects of J2EE have been standardized. During the
past year or so, J2EE community also has been working on tools standardization
mainly in the areas of management, deployment, performance bench mark, and
portability because they felt that as more and more J2EE applications and platforms
are being deployed, these issues are increasingly becoming more important.

So let's talk about, the J2EE Management Specification effort, JSR-77, first. The goal
of JSR-77 is to provide server vendors and tool vendors with a standard model for
managing the J2EE Platform.

What are the things J2EE management is trying to address? First, management
applications should be able to discover managed objects and then interpret the data
collected in a standard fashion.

Second, a single management platform should be able to manage multiple J2EE

servers which might be from different vendors.

Thirdly, uniform view should be presented regardless what management protocols

are used to access the data. For example, whether data is collected using SNMP or
WBEM, the data should be consistent.

Finally it leverages JMX (Java Management Extension), which is an framework and

APIs for creating Java based management agents.
57
03/19/2007

J2EE Deployment (JSR-88) - J2EE 1.4

Tools J2EE Platforms
Standard
IDEs Deployment API
(Universal Remote)

Vendor Deploy
Tools

Management
Tools

58

Now let's talk about J2EE deployment.

J2EE platform vendors currently implement their own proprietary

deployment interface to their server because there is no standard
deployment API. This makes it cumbersome for companies who need to
deploy J2EE applications over J2EE platforms from different vendors,
because they must run the different deploy tool for different servers.

A standard deployment API will enable any J2EE application to be

deployed by any deployment tool that uses the deployment APIs onto any
J2EE compatible environment. In this sense, the standard deployment API
functions as a universal remote control that can be used to perform the
deployment process over multiple J2EE platforms from different vendors.

58
03/19/2007

JMX
JMX API into Dynamic Deployment
the J2EE 1.4 platform

JMX

JMX
App
J2EE App Server

JMX defacto

A single technology for the J2EE platform

59

59
03/19/2007

JACC (Java Authorization Contract

for Containers) - J2EE 1.4
? Defines contract between J2EE
containers and authorization policy
modules
– Provider configuration subcontract
– Policy configuration subcontract
– Policy enforcement subcontract
? Enable application servers to integrate
with enterprise user registries and
authorization policy infrastructure
60

JACC, Java authorization contact for containers, defines a contract

between J2EE containers and authorization policy modules such that
container authorization functionality can be provided as appropriate to
suit the operational environment.

The contract defined by JACC specification is divided into three

subcontracts - provider configuration subcontract, policy configuration
subcontract, policy enforcement subcontract. Taken together, these
subcontracts describe the installation and configuration of authorization
providers such that they will be used by containers in performing their
access decisions.

The end result is that now application servers are well integrated with
enterprise user registries and authorization policy infrastructure.

60
03/19/2007

J2EE is an End-to-End
Architecture

61

Now let's talk about J2EE as an end-to-end architecture. One important

aspect of J2EE as an architecture is that it covers end-to-end. That is, it
covers from the client tier on the left all the way to the enterprise
information systems on the rightmost tier.

61
03/19/2007

The J2EE Platform Architecture

B2B
Applications

Existing
B2C Applications
Applications

Web
Services
Application Server
Wireless Enterprise
Applications Information
Systems

62

This is somewhat simplified J2EE platform architecture. The key point in

the picture is that regardless of who is the user of the service that is
provided by the J2EE, that is, whether it is B2B application, or B2C
application, or web services client, or J2ME based wireless devices, J2EE
platform is the platform of choice for implementation because it provides
highly scalable, highly available, highly reliable, and high performing
implementation platform regardless of the fact that whether the services
are exposed as web services or not.

62
03/19/2007

J2EE is End-to-End Solution

Firewall
J2EE
Application
Client Server

Enterprise
Enterprise Information
JavaBeans™ Systems (EIS):
Client
Client Relational
Database,
Web Enterprise Legacy
Client Server JavaBeans Applications,
JSP,
ERP Systems
Servlets
Client
HTML/XML
Other Services:
JNDI, JMS, Enterprise
Client Middle JavaMail™ Information
Tier Tier Tier

63

I mentioned that J2EE is about building n-tier, web-based enterprise applications. That is, J2EE
provides an end-to-end architecture covering from the client tier on the left side to the middle tier
where Web server and Application servers reside and enterprise information tier on right side
which connects the middle tier systems to the backend enterprise information systems such as
relational databases, and legacy applications.

The clients can be either a full-blown Java applications or applet running inside a browser. Or
more typically, the client could be a just regular HTML or XML browser communicating with the
web server through HTTP. Another form of client that is getting more pervasive in an enterprise
environment is 3rd-party application which performs B2B transaction with your application
typically through XML. On the other side of the spectrum, the client could be wireless phones or
cell phones with some kind of communication facilities. The clients could reside either behind the
firewall or within the firewall. The point here is that J2EE architecture accommodate these diverse
set of client types.

The middle tier typically contain web servers and application servers. In actual deployment, they
could be running in a single physical platform or on multiple platforms. In some cases where
reliability and scalability are important, there could be multiple web servers and application
servers. The web server receives HTTP requests from the clients and handle dynamic content
generation through either JSP or servlet or both. The JSP or servlet can then delegate any business
logic processing to enterprise java beans running on the application server.

The key point here is that J2EE provides an end-to-end solution and deals with all these tiers with
open and standard technologies.

63
03/19/2007

N-tier J2EE Architecture

Web Tier EJB Tier

64

This picture shows the same architecture in which web-tier and EJB tier are more
clearly divided.

64
03/19/2007

J2EE
Component & Container
Architecture

65

OK, one of the most significant architectural characteristics of J2EE, in my

mind, is its component and container model. So let's talk about it in a bit
more detail.

65
03/19/2007

J2EE Containers & Components

Applet Container Web Container EJB Container

Applet HTTP/ JSP Servlet RMI EJB

HTTPS

J2SE

RMI/IIOP

RMI/IIOP
JavaMail JavaMail

JDBC
JDBC
JTA
JNDI

JNDI
JMS

JMS
JTA
App Client JAF
Container JAF
App HTTP/ J2SE
Client HTTPS
RMI
RMI/IIOP

JDBC
JNDI
JMS

J2SE J2SE

Database
66

This is what I call the J2EE Container & components diagram. As this diagram
illustrates, containers and components are the key concepts of J2EE.

As for the relationship between components and containers, as you might have
guessed it, the components are running within containers. That is, the containers
provides the host execution environments for the components. In this picture, the
components are colored in green and the containers are in purple. The types of
components within J2EE environment are
•Client components that are running on client either as a stand-alone or applet
• JSP or servlet as web components running inside web container
•EJB beans as business components running inside EJB container

And you developers are responsible for the implementation of these components. On
the other hand, the containers are provided by the platform vendors. The containers
provide runtime system services such as life-cycle management of the components,
transaction coordination, persistence management, resource pooling

The containers are also responsible for providing the enterprise APIs, shown in gold,
and the distributed communication protocols, shown in brown.
In a typical multi-tier, thin client enterprise application, most of the development
effort will be focused on building web-tier components at web-tier and enterprise
Java beans at EJB tier..
66
03/19/2007

Containers and Components

Containers Components
Handle Handle
l Concurrency l Presentation
l Security l Business Logic
l Availability
l Scalability
l Persistence
l Transaction
l Life-cycle
management
l Management
67

We touched upon the roles of container and components a bit in the previous slide. Now let’s compare
the tasks that are being performed by containers and the ones performed by components side by side. As
we talked about in the previous slide, the platform vendors provide containers while you, as application
developers, develop your applications in the form of components and deploy them over the containers. As
you probably will notice, many of the tasks that the containers perform are system services that a typical
enterprise application would need.

First., container handles concurrency. That is, it handles concurrent access from multiple clients to your
business component so that you don’t have to deal with it. Each platform vendor might use different
synchronization schemes to support concurrency, however. Second, containers provide built-in security
framework so that implementing secure applications can be a matter of configuring some options on
authentication and access control at the time of deployment not at the time of code development. Next,
availability and scalability. We mentioned already that platform vendors compete in their
implementations especially in the area of availability and scalability. For example, one J2EE container
vendor might provide high availability by maintaining session state on a persistent storage. Another
vendor might choose to implement it in a different way.

Persistence and transaction can be also handled by the container if you choose to do so. Or you might
want to implement them on your own in your code, if more customized behavior is desired. Life-cycle
management. Containers handle the creation and destruction of your component instances according to
its own implementation scheme. Finally management and administration, some vendors might provide
better management tool for managing and administering various resources in the container.

So what do you have to do as developers? Very little really. You handle only presentation and focus
majority of your development effort on building business components.

67
03/19/2007

Containers & Components

? Containers do their work invisibly

– No complicated APIs
– They control by interposition
? Containers implement J2EE
– Look the same to components
– Vendors making the containers have great
freedom to innovate

68

This container based architecture is the key to J2 EE’s

simplicity and flexibility.

It decouples the component from the container so both are

free to handle their part of the problem in the most effective
way.

As the slide says, containers don’t have complicated API’s,

they exert their control transparently.

This gives the container vendors great flexibility to provide

innovation that is immediately accessible to all components.

68
03/19/2007

J2EE Application
Development & Deployment
Life Cycle

69

Now let's talk about J2EE application development and deployment life
cycle and roles involved in this life cycle

69
03/19/2007

J2EE Application
Development Lifecycle
? Write and compile component code
– Servlet, JSP, EJB
? Write deployment descriptors for
components
– From Java EE 5, you can use annotations
? Assemble components into ready-to-
deployable package
? Deploy the package on a server
70

The development life cycle of J2EE application is not that much

different from the one of other Java application except that there are
certain J2EE specific aspects such as deployment descriptor.

First, as a component developer, you write and compile component

code. The component code again can be servlet, JSP, EJB.

Then, you a write deployment descriptor again as a component

developer. As mentioned previously, deployment descriptor is an XML
file that describes your J2EE components.

Then these J2EE components will be assembled into a ready-to-

deployable package.

Then the package gets deployed over J2EE platform.

70
03/19/2007

Life-cycle Illustration
Creation Assembly Deployment
Assembled
Created by J2EE Modules and Augmented J2EE APP Processed
Component by Application by Deployer
Developer Assembler

Deploy

J2EE Container

Enterprise
Components

71

This is a bit more detailed description of the process.

The first step is to create all the necessary business and web components. For
example, developers build business logic components such as EJB beans. They
might also get involved in building servlets or Java beans or custom tags of
JSP pages. UI designers also create web pages at this stage. One important
point here is that you don’t have to build everything yourself. That is, you
might want to purchase 3rd-party, off-the-shelf business components instead of
building your own. After all, that is the whole point of component technology.
Again, this is possible because of the open and standard based component
technologies such as EJB and J2EE.

Next step is to assemble these business and web components into an J2EE
application. This step is performed by an application assembler. His role is
basically to create a package that contains all the necessary components and
descriptors that describe those components.

Finally this assembled application gets deployed in a operational environment

by a deployer. The role of deployer is to take the application package that was
assembled and then deploy it in a particular operational environment.
Typically the deployer will set or tune configuration parameters of deployment
descriptors in order to achieve the behavioral characteristics that is desired in
a particular operational environment. 71
03/19/2007

J2EE Development Roles

? Component provider
– Bean provider
? Application assembler
? Deployer
? Platform provider
– Container provider
? Tools provider
? System administrator

72

Roles. In the previous slide, we talked about the steps involved in building J2EE-based
enterprise application. And along with the process, we identified a few development roles
already. First, the component provider, or sometimes called bean provider, create business
components. These people are Java programmers who also understand the business domain.
I assume most of the audience here are going to play the role of component provider.

As we talked about, an application assembler assembles business components and web

components into a ready-to-deployable package and the deployer then deploys it in a
particular operational environment.

We also talked about platform vendors, who actually provides platform implementations.
Sometimes they are called container providers. And there are many platform vendors that
now provide both commercial or freely available versions of J2EE compliant platforms.

There are a few more roles. Tools provider. Typically the same platform vendor will
provide tools for development and deployment of J2EE applications. As I said before, tools
is one area platform vendors might compete and want to differentiate themselves from the
others.

System administrator performs management and administration of the overall system. Again
platform vendors might provide their own administration and management tools.

72
03/19/2007

The Deployment Descriptor

? Gives the container instructions on how
to manage and control behaviors of the
J2EE components
– Transaction
– Security
– Persistence
? Allows declarative customization (as
opposed to programming
customization)
– XML file
? Enables portability of code 73

We already talked about the concept of deployment descriptor.

The concept of deployment descriptor is critical in
understanding J2EE architecture because it is this deployment
descriptor that enables the portability of J2EE application.

So deployment descriptor is an XML file that specifies runtime

instruction to the container regarding how system services are to
be handled, for example, transaction, security, life-cycle, state
management, persistence, and so on.

It is called declarative customization because you are specifying

the instruction in the XML file rather than in the code

73
03/19/2007

J2EE Application
Anatomies

74

Now I would like to spend sometime talking about various ways J2EE
applications can be created. As you will see there is no single fixed way of
developing J2EE applications. Some people think that in order to build
J2EE application, you have to use EJB. That is not really true. Using EJB
is just one way of building J2EE application.

74
03/19/2007

Possible J2EE Application

Anatomies
Web Server EJB Server

DB & EIS
Resources

Browser Web Server EJB Server

Stand-alone

75

So this slide shows several different ways J2EE application can be built. Different
forms of J2EE application can be built by combining the path between tiers.

One of the most common forms of J2EE application is represented in combined

red arrows. In this form, browser talks to web tier in which servlet and and JSP
components are created and deployed and these web tier components then talk to
EJB tier in which EJB beans are created and deployed and these EJB beans in turn
talk to backend databases or enterprise information systems.

Another common form is browser talks to web-tier and then the web-tier
components talk to directly to backend databases or enterprise information
systems. It is represented by red arrow between browser and web server and then
dark brown arrow between web server and backend database.

It is also possible that the client could be standalone application, which can talk to
directly to web-tier, EJB tier, or even directly to backend databases.

Also web tier components and EJB tier components can use components deployed
in other web-tier or EJB tiers.

The point of this slide is to show that there are several different ways to build J2EE
applications.
75
03/19/2007

J2EE Application Anatomies

? 4-tier J2EE applications
– HTML client, JSP/Servlets, EJB, JDBC/Connector
? 3-tier J2EE applications
– HTML client, JSP/Servlets, JDBC
? 3-tier J2EE applications
– EJB standalone applications, EJB,
JDBC/Connector
? B2B Enterprise applications
– J2EE platform to J2EE platform through the
exchange of JMS or XML-based messages 76

So this slide is just recapturing what I just said. So depending

on how you build J2EE applications, they can be in fact in
several different forms.

76
03/19/2007

Which One to Use?

? Depends on several factors
– Requirements of applications
– Availability of EJB tier
– Availability of developer resource

77

Now you might want to ask which form of J2EE application

should I build? The answer is of course “it depends”. It
depends on the requirements of application or even non-
technical factors such as availability of EJB tier or availability
of developer resource.

77
03/19/2007

J2EE 1.4
Standard Implementation,
Compatibility Suite, Brand

78

Now let's talk other aspects of J2EE, reference implementation,

compatibility test suite, and J2EE branding.

78
03/19/2007

Standard Implementation
? Under J2EE 1.4 SDK, it is Sun Java
Application Server Platform Edition 8
? Production-quality J2EE 1.4 compliant
app server
? Free to develop and free to deploy
? Seamless upgrade path to Sun Java
Application Server Enterprise Edition

79

79
03/19/2007

Compatibility Test Suite (CTS)

? Ultimate Java™ technology mission:
– Write Once, Run Anywhere™
– My Java-based application runs on any
compatible Java virtual machines
– My J2EE based technology-based
application will run on any J2EE based
Compatible platforms

80

Compatibility test suite. The idea is simple. Just like any JVM has to go
through quite a bit of compatibility testing to make sure “write once and run
anywhere” Java paradigm works, any platform that wants to be stamped with
“J2EE compliance” has to pass the J2EE compatibility test suite. This in turn
ensures the portability of your applications over any J2EE compliant platforms.

80
03/19/2007

J2EE Application Verification Kit

(J2EE AVK)
? How can I test my J2EE application
portability?
• Obtain the J2EE RI 1.3.1 and the J2EE
Application Verification Kit (J2EE AVK)
? Self verification of application
– Static verification
– Dynamic verification
? Obtain the tests results, verify that all
criteria are met
81

Another very important development in J2EE community is making sure

J2EE applications are in fact portable over various J2EE compliant
platforms.

The reason this is important is that the reality has been that J2EE platform
vendors provide various extensions as product differentiator in a sense at
the expense of the portability of the applications.

Now you have a way to verify if an application you are writing is in fact
bit by bit portable by running them with J2EE application verification kit
along with J2EE reference implementation.

81
03/19/2007

Compatible Products
for the J2EE Platform (Brand)
ATG iPlanet
Bea Systems Macromedia
Borland NEC
Computer Oracle
Associates Pramati
Fujitsu SilverStream
Hitachi Sybase
HP Talarian
IBM Trifork
IONA
82

There are the list of J2EE vendors as of March 2002.

Many of these products are application servers, but tools vendors such as
TogetherSoft, WebGain, and Borland have also made the commitment to
J2EE compatibility. With their experience in modeling and Rapid
Application Development, these vendors will help make developing J2EE
applications easier and faster.

Again, this is what J2EE branding is all about. We believe having J2EE
branding give customers of J2EE products high-level of assurance of
quality and compatibility.

82
03/19/2007

The J2EE Platform “Ecosystem,”

Application Servers and…
? Tools
– IDE’s: Borland JBuilder Enterprise, WebGain
Visual Cafe’, IBM Visual Age for Java™, Forte™
for Java™, Oracle JDeveloper, Macromedia Kawa
– Modeling, Performance, Testing, etc.
? Enterprise Integration: Connectors,
Java Message Service (JMS) API, XML
? Components
? Frameworks
? Applications
83

So J2EE community itself built an ecosystem in which many different

commercial vendors, open source community, and individual developers
are working together to develop many different parts of J2EE starting
from application servers and then tools, connectors, components, and
frameworks, and finally applications, and so on. And I believe this
ecosystem is only possible because of openness of J2EE.

83
03/19/2007

Major Investment in
Compatibility by the Industry
? Sun has spent scores of engineer years
developing tests
? Licensees have spent scores of engineer
years passing the tests
? Testing investment on top of specification
investment, implementation investment,
business investments
? In total, tens of millions of dollars invested in
J2EE platform compatibility by the industry
84

As mentioned before, ensuring compatibility among J2EE products is

important. This slides lists a few important investments that J2EE
community as a whole has made to ensure the compatibility.

First, Sun invested huge amount of its engineering resource to create

compatibility test kit. And licensees also spent scores of their engineering
years to make sure their products are J2EE compliant.

Overall, the investment dollars for ensuring the J2EE compatibility by the
J2EE community and industry is something that is not talked about that
much but that is really a hidden value proposition to many J2EE
customers.

84
03/19/2007

J2EE Blueprint &

Pet Store Application

85

85
03/19/2007

J2EE Blueprint
? Best practice guidelines, design patterns
and design principles
– MVC pattern
? Covers all tiers
– Client tier
– Web tier
– Business logic (EJB) tier
– Database access tier
? Sample codes come with J2EE 1.4 SDK
– Java Pet Store, Adventure builder
86

Now J2EE Blueprints. In addition to the customary trio of specifications: reference

implementation and compatibility test suite, J2EE comes with something called
blueprints. This is something unique about J2EE.

Blueprint specifies the best practice guidelines, design patterns and design principles
that will help you to build production-quality enterprise applications . And one of the
design patterns it talks about is so-called MVC pattern, which stands for Model,
View, and Controller pattern.

Blueprint covers all the tiers including client-tier, web-tier, business logic-tier, and
database access tier. And on each tier, it describes several design options along with
their their pros and cons. For example, on the client tier, it talks about a variety of
client types and their pros and cons. On the web tier, it talked about the most
effective way of using servlet and JSP. On the business logic tier, it talks about
when to use session beans and when to use entity beans and how they can be used
together in order to achieve the desired application behavior. On the database access
tier, it introduces concepts such as Value objects and Data Access Objects (DAO) as
optimization techniques.

It also comes with a sample e-commerce application called Java Pet Store which
demonstrates and exercises the design guidelines that are described in the
documentation.
86
03/19/2007

Why J2EE
for Web Services?

87

So far we have talked about what is J2EE and why J2EE is the platform of
choice for development and deployment of web-based, multi-tier,
transactional, component-based enterprise applications. Now let's talk
about why we believe J2EE is the best platform for the development and
deployment of web services.

87
03/19/2007

Why J2EE for Web Services?

? Web services is just one of many
service delivery channels of J2EE
– No architectural change is required
– Existing J2EE components can be easily
exposed as Web services
? Many benefits of J2EE are preserved
for Web services
– Portability, Scalability, Reliability
– No single-vendor lock-in
88

Now, let's talk about the motivation for using J2EE as development and deployment
platform for web services.

As most of you already know, J2EE is an open standard platform for building enterprise
applications in which business logic are captured and deployed as components. J2EE is
also an end-to-end architecture where there are multiple programming models to
implement and deploy these business logic. That is, there is servlet, there is JSP, there are
EJB beans, and there is JMS. All these programming models provide somewhat different
ways of implementing and deploying business logic over J2EE and you as developers
choose one ore more of these programming models according to the needs and
requirements of your applications.

Now if you think about it, web services model is just another way of exposing the
business logic of these components. What this means is there is no architectural or code
change required to expose the existing J2EE components as web services . For example,
as a service provider, in addition to exposing business functions captured in EJB beans
by EJB remote interface over RMI/IIOP, you can also expose them via WSDL and handle
the service by receiving SOAP message and send the result back in SOAP messages.

What it means is that the existing J2EE components can be exposed as web services
without any change in their code which also means the key benefits of J2EE such as open
and standard platform, portability of code, availability of highly scalable and highly
reliable platform products, are still preserved. And most of all, you can still choose the
best of breed J2EE platform or J2EE applications including web services components
without compromising the code portability. 88
03/19/2007

Web Services Model Over J2EE

Rich Clients J2EE Server JSP™/ JavaServlet API / EJB™

XMLP/SOAP
JSP JDBC
DBMS

MIDP XMLP/SOAP
Devices
XHTML/WML
JMS
Connectors
Existing
Existing
EJB Apps
Apps
HTML/XML

Browsers XMLP/SOAP

Services

89

This picture shows how Web services model is supported over J2EE
platform. The implementation of web services will leverage the existing
programming models such as servlet and EJB. On the J2EE platform, the
Java APIs for web services, for example, JAX-RPC and JAXM will
enable SOAP based communication with various types of clients
including J2ME-enabled devices and standalone applications.

89
03/19/2007

Where Are We Now?

? Java APIs for Web Services are being
developed very rapidly
• Web services support on WUST (WSDL, UDDI,
SOAP) ready now
• Next layer Web services work in progress
? Tools are available now for exposing existing
J2EE components as Web services
? J2EE community has defined overall
framework for Web Services (J2EE 1.4, Web
services for J2EE)
90

So J2EE has proved itself as the platform of choice for building enterprise applications.
Now what about web services? Where are we now and where are we going in terms of
using J2EE as Web services platform?

As many of you already know, Java community is feverishly working on defining Java
APIs for web services. And THE primary platform that these Java APIs are designed
for is J2EE. At this point, Web services based on WUST trio, SOAP, WSDL, UDDI are
well supported. And the next layer of web services stack are being worked on right
now. And we will talk about those Java APIs for web services later on in this session.

Tool vendors already have products out there that you can use to expose existing J2EE
components such as EJBs as web services by basically providing a tool that can
generate WSDL document from those EJB beans and from the WSDL, a client stub can
be generated which knows how to send and receive SOAP messages in order to use the
service defined in WSDL. So you can expose business functions that you already have
in J2EE as web services right now.

Finally J2EE community is in the works to define overall Web services framework for
J2EE through J2EE 1.4 and JSR 109 for the sake of portability of Web services. And we
will talk about this in detail in the rest of this session.

90
03/19/2007

Design Goals J2EE 1.4 Web

Services Framework
? Portability of Web services component
– Over different vendor platform
– Over different operational environment
? Leveraging existing J2EE programming
models for service implementation
? Easy to program and deploy
– High-level Java APIs
– Use existing deployment model
91

So what are the design goals of J2EE web services framework?

I already explained the container and component model of J2EE. And one of the
benefits of building application as components is its portability. And the same benefit
applies to web services as well. That is, the web services components will be portable
over different vendor platforms as well as different operational environments in the
same way other J2EE components such as EJBs, JSP and servlets are portable over
different vendor platforms and different operational environments.

Another important goal is that the existing J2EE programming models such as EJBs and
servlets or message driven beans should be leveraged for service implementation.

Next, we want to make sure that building and deploying web services is easy. What that
means is that programmers will be able to use high-level Java APIs for building web
services instead of dealing with low-level plumbings and the existing deployment
model such as based on deployment descriptor will be used for web services component
as well.

91
03/19/2007

J2EE 1.4 Web Services Framework

? J2EE 1.4 (JSR 151)
? Web services for J2EE (JSR 109)
? JAX-RPC (JSR 101)
? JAXR (Java API for XML Registries)
? SAAJ (SOAP with Attachments API for
Java)
? EJB 2.1
92

So J2EE 1.4 provides the umbrella framework for web services in which various
individual web services related work are combined to provide well-integrated
web services support for J2EE.

And those individual web services initiative include Web services for J2EE effort,
JSR 109, JAX-RPC, SAAJ, JAXR, EJB 2.1, and Connector Architecture 1.5 for
providing JAXM provider as one of the provider.

92
03/19/2007

How to Get Started

93

OK, we have talked about J2EE until now more from concept and
architecture perspective. So now let's talk about how you can get started
with J2EE.

93
03/19/2007

Step1: For Beginners and

Intermediate J2EE Programmers
? Follow along with this course
? Start using J2EE IDE of your choice
? Try open source IDE's
– NetBeans IDE 5.0 (netbeans.org)
? Excellent out of the box J2EE support

? We will use NetBeans IDE 5.0 or NetBeans IDE 5.5

as our default IDE in this course

? Lots of tutorials
– Eclipse
94

Once you get to a point where you feel comfortable with building basic J2EE
application leveraging all the programming models that are available in the
architecture, you can try to use commercially or freely available J2EE IDE's.
Sun has Sun ONE Studio 4 Enterprise Edition (EE), which is downloadable for
60 day free trial. Sun ONE Studio site also has a bunch of sample applications
you can play around. You are also welcome to try other vendors' tools.

94
03/19/2007

Step2: Next Step (For Advanced

J2EE Programmers)
? Learn practical open-source solutions
– Spring framework (for light-weight framework)
– Hibernate (for O/R mapping)
– JDO (for transparent persistence)
– Struts, WebWork, Tapestry (for Web-tier
frameworks)
– JUnit (for unit testing)
– Log4j (for logging)
– Many more
95

There are several useful open-source solutions for building production quality
J2EE applications. Examples include Spring framework for light-weight
framework, Hibernamte for object to relational database mapping, JDO for
transparent persistence, Struts/WebWor/Tapestry for web-tier frameworks,
Junit for unit testing, and Log4j for logging.

95
03/19/2007

Step3: Next Step (For Advanced

J2EE Programmers)
? There is no shortage of quality J2EE
online resources
– java.sun.com/j2ee
– www.theserverside.com
– www.javapassion.com/j2ee/J2EEresources.html#J2
EEResourceSites

96

Once you become a J2EE programmer, there is no shortage of resources that

you can leverage to further enhance your J2EE knowledge. One good site is
www.theserverside.com, which is a very popular J2EE knowledge website.

96
03/19/2007

Summary &
Resources

97

97
03/19/2007

Summary
? J2EE is the platform of choice for
development and deployment of n-tier,
web-based, transactional, component-
based enterprise applications
? J2EE is standard-based architecture
? J2EE is all about community
? J2EE evolves according to the needs
of the industry

98

98
03/19/2007

Resources
? J2EE Home page
– java.sun.com/j2ee
? J2EE 1.4 SDK
– java.sun.com/j2ee/1.4/download.html#appserv
? J2EE 1.4 Tutorial
– java.sun.com/j2ee/1.4/download.html#appserv
? J2EE Blueprints
– java.sun.com/blueprints/enterprise/index.html

99

99
03/19/2007

NetBeans Resources
? NetBeans IDE Homesite
– http://www.netbeans.org
? NetBeans IDE Tutorials/Articles
Master index
– http://www.javapassion.com/netbeans
/masterindex.html

100

100
03/19/2007

Passion!

101

101