Professional Documents
Culture Documents
J2EEOverview Speakernoted PDF
J2EEOverview Speakernoted PDF
Introduction to
J2EE™
1
1
02/27/2006
Sang Shin
sang.shin@sun.com
www.javapassion.com/j2ee/
Java™ Technology Evangelist
Sun Microsystems, Inc.
2
2
02/27/2006
3
02/27/2006
Revision History
? 12/08/2002: draft version with speaker notes (Sang)
? 12/16/2002: speaker notes are cleaned up a bit (Sang)
? 4/9/2003: Speaker notes are revised. (Lucille Wilson)
? 07/25/2004: How to get started is modified to reflect
J2EE 1.4 SDK (Sang)
? 09/22/2004: Change Sun fonts to Arial fonts (Sang)
4
02/27/2006
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 the platform of
choice for development and deployment of
both web applications and web services
5
At the end of this session, I expect you folks 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 enterprise applications.
I will also cover all the major APIs 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 enterprise applications but also web services.
5
02/27/2006
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
6
6
02/27/2006
What is J2EE?
7
02/27/2006
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
8
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.
8
02/27/2006
9
02/27/2006
10
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.
10
02/27/2006
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
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.
11
02/27/2006
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.
12
02/27/2006
Evolution of
Enterprise Application
Frameworks
13
13
02/27/2006
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
14
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.
14
02/27/2006
15
02/27/2006
16
02/27/2006
17
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.
17
02/27/2006
Two-Tier
SQL request
Database
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.
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.
18
02/27/2006
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
19
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.
19
02/27/2006
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.) 20
02/27/2006
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.
21
02/27/2006
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.
22
02/27/2006
23
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.
23
02/27/2006
24
02/27/2006
25
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.
25
02/27/2006
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
26
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.
26
02/27/2006
27
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 functionalites. 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.
27
02/27/2006
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
28
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.
28
02/27/2006
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.
And that is where next evolution has occurred, initially with proprietary form
and later on based on an open-standard.
29
02/27/2006
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
30
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.
30
02/27/2006
31
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.
31
02/27/2006
Why J2EE?
32
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.
32
02/27/2006
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.
33
02/27/2006
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.
And vendors are free from having to maintain their own proprietary APIs.
Instead they focus on better implementations.
34
02/27/2006
35
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
35
02/27/2006
36
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.
36
02/27/2006
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.
37
02/27/2006
Servlet &
JSP (JavaServer Pages)
38
OK. Let's talk about servlet and JSP, which are cornerstone technologies of
J2EE.
38
02/27/2006
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
39
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.
What about NSAPI or ISAPI? You probably don't even remember them
because they rarely used in practice in their short lifespan. Well they address
some efficiency issues of CGI but they are vendor-specific or product specific
and thus applications written over those APIs will not be portable.
39
02/27/2006
Request
RequestServlet1
Servlet1 Servlet
Servlet Based
Based Webserver
Webserver
Request
RequestServlet2
Servlet2 Servlet1
Servlet1
JVM
JVM
Request Servlet1 Servlet2
Servlet2
40
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.
40
02/27/2006
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. 41
02/27/2006
EJB
(Enterprise Java
Beans)
42
42
02/27/2006
43
43
02/27/2006
44
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.
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.
44
02/27/2006
EJB Architecture
45
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. 45
02/27/2006
Enterprise JavaBeans
Enterprise JavaBeans
Stateless Stateful
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.
46
02/27/2006
JMS
(Java Message
Service)
47
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.
47
02/27/2006
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.
48
02/27/2006
Connector
Architecture
49
49
02/27/2006
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
50
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.
m x n Problem Before
Connector Architecture
m n
App SAP
Server1
App EIS
Server2 2
App EIS3
Server3
App EIS4
Server
51
51
02/27/2006
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.
52
02/27/2006
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
53
53
02/27/2006
54
54
02/27/2006
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
55
55
02/27/2006
Now let's go over other Java programming APIs and technologies that
constitute J2EE.
56
02/27/2006
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.
57
JNDI stands for Java naming and directory interface and it is a common method for
locating resources or objects under J2EE framework.
57
02/27/2006
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
58
58
02/27/2006
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.
Vendor Deploy
Tools
Management Tools
60
60
02/27/2006
JMX
JMX API into Dynamic Deployment
the J2EE 1.4 platform
JMX
JMX
App
J2EE App Server
JMX defacto
61
61
02/27/2006
The end result is that now application servers are well integrated with
enterprise user registries and authorization policy infrastructure.
62
02/27/2006
J2EE is an End-to-End
Architecture
63
63
02/27/2006
Existing
B2C Applications
Applications
Web
Services
Application Server
Wireless Enterprise
Applications Information
Systems
64
64
02/27/2006
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
65
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.
65
02/27/2006
66
This picture shows the same architecture in which web-tier and EJB tier are more
clearly divided.
66
02/27/2006
J2EE
Component & Container
Architecture
67
67
02/27/2006
J2SE
RMI/IIOP
RMI/IIOP
JavaMail JavaMail
JDBC
JDBC
JMS
JNDI
JNDI
JTA
JMS
JTA
App Client JAF
Container JAF
App HTTP/ J2SE
Client HTTPS
RMI
RMI/IIOP
JDBC
JNDI
JMS
J2SE J2SE
Database
68
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..
68
02/27/2006
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.
69
02/27/2006
70
70
02/27/2006
J2EE Application
Development & Deployment
Life Cycle
71
Now let's talk about J2EE application development and deployment life
cycle and roles involved in this life cycle
71
02/27/2006
J2EE Application
Development Lifecycle
? Write and compile component code
– Servlet, JSP, EJB
? Write deployment descriptors for
components
? Assemble components into ready-to-
deployable package
? Deploy the package on a server
72
72
02/27/2006
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
73
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.
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.
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.
74
02/27/2006
75
02/27/2006
J2EE Application
Anatomies
76
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.
76
02/27/2006
DB & EIS
Resources
Stand-alone
77
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.
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.
77
02/27/2006
78
02/27/2006
79
79
02/27/2006
J2EE 1.4
Standard Implementation,
Compatibility Suite, Brand
80
80
02/27/2006
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
81
81
02/27/2006
82
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.
82
02/27/2006
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.
83
02/27/2006
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
84
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.
84
02/27/2006
85
02/27/2006
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
86
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.
86
02/27/2006
87
87
02/27/2006
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
88
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.
88
02/27/2006
Why J2EE
for Web Services?
89
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.
89
02/27/2006
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. 90
02/27/2006
XMLP/SOAP
JSP JDBC
DBMS
MIDP XMLP/SOAP
Devices
XHTML/WML
JMS
Connectors
Existing
Existing
EJB Apps
Apps
HTML/XML
Browsers XMLP/SOAP
Services
91
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.
91
02/27/2006
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.
92
02/27/2006
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.
93
02/27/2006
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.
94
02/27/2006
95
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.
95
02/27/2006
96
We will study the web-tier technologies before EJB and other J2EE
technologies. And we are going to use Java Web Services Developer Pack
(Java WSDP) as our software for writing servlet and JSP.
By the way, even though Java WSDP is named as Web Services Developer
Pack, it contains all the pieces needed for building both web services and web
applications. Besides, it has all the pieces well integrated so that you don't
really have to deal with configuring different pieces to make it to work.
Once you downloaded Java WSDP, you also want to download the tutorial
package. (Yes, you have to download it separately from Java WSDP itself.)
And then go to the tutorial page as instructed in the document.
96
02/27/2006
97
Now once you get yourself familiarized with the basic building blocks of J2EE,
you can then study best practice guidelines and design patterns that are well
described in J2EE blue print document. You can also study the sample
application that comes with the blueprint, Java Pet Store, which demonstrates
the best practice guidelines and design patterns described in the Blueprint
documentation.
97
02/27/2006
this course
– Eclipse
98
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.
98
02/27/2006
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.
99
02/27/2006
100
100
02/27/2006
Summary &
Resources
101
101
02/27/2006
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
102
102
02/27/2006
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
103
103
02/27/2006
NetBeans Resources
? NetBeans IDE Homesite
– http://www.netbeans.org
? NetBeans IDE Tutorials/Articles
Master index
– http://www.javapassion.com/netbeans
/masterindex.html
104
104
02/27/2006
Passion!
105
105