Beginning Java EE 5 From Novice to Professional phần 1 doc

Just as Java provides a uniform way to program GUI applications on any underlying oper-ating system, Java also provides a uniform way to program enterprise applications on any underlying

Trang 1

Beginning Java EE 5 From Novice to Professional

■ ■ ■

Kevin Mukhar and Chris Zelenak

with James L Weaver and Jim Crume

Mukhar_470-3Front.fm Page i Tuesday, October 4, 2005 6:20 AM

Trang 2

Beginning Java EE 5: From Novice to Professional

All rights reserved No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher.

ISBN (pbk): 1-59059-470-3

Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1

Trademarked names may appear in this book Rather than use a trademark symbol with every occurrence

of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.

Lead Editor: Steve Anglin

Technical Reviewer: Dilip Thomas

Editorial Board: Steve Anglin, Dan Appleman, Ewan Buckingham, Gary Cornell, Tony Davis, Jason Gilmore, Jonathan Hassell, Chris Mills, Dominic Shakeshaft, Jim Sumser

Project Manager: Sofia Marchant

Copy Edit Manager: Nicole LeClerc

Copy Editors: Marilyn Smith, Ami Knox, Nicole LeClerc

Assistant Production Director: Kari Brooks-Copony

Production Editor: Laura Cheu

Compositor: Susan Glinert Stevens

Proofreader: Elizabeth Berry

Indexer: Broccoli Information Management

Artist: Kinetic Publishing Services, LLC

Cover Designer: Kurt Krames

Manufacturing Director: Tom Debolski

Distributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor, New York, NY 10013 Phone 1-800-SPRINGER, fax 201-348-4505, e-mail orders-ny@springer-sbm.com, or visit http://www.springeronline.com

For information on translations, please contact Apress directly at 2560 Ninth Street, Suite 219, Berkeley, CA

94710 Phone 510-549-5930, fax 510-549-5939, e-mail info@apress.com, or visit http://www.apress.com The information in this book is distributed on an “as is” basis, without warranty Although every precaution has been taken in the preparation of this work, neither the author(s) nor Apress shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly

by the information contained in this work

The source code for this book is available to readers at http://www.apress.com in the Source Code section.

Trang 3

■ ■ ■

C H A P T E R 1

Java EE Essentials

The word enterprise has magical powers in computer programming circles It can increase the

price of a product by an order of magnitude and double the potential salary of an experienced

consultant Your application may be free of bugs, and cleanly coded using all the latest

tech-niques and tools, but is it enterprise-ready? What exactly is the magic ingredient that makes

enterprise development qualitatively different from run-of-the-mill development?

Enterprise applications solve business problems This usually involves the safe storage,

retrieval, and manipulation of business data: customer invoices, mortgage applications, flight

bookings, and so on They might have multiple user interfaces: a web interface for consumers

and a graphical user interface (GUI) application running on computers in the branch offices,

for example Enterprise applications must deal with communication between remote systems,

coordinate data in multiple stores, and ensure the system always follows the rules laid down by

the business If any part of the system crashes, the business loses part of its ability to function

and starts to lose money If the business grows, the application needs to grow with it All this

adds up to what characterizes enterprise applications: robustness in the face of complexity

When we set out to build a GUI application, we don’t start by working out how to draw

pixels on the screen and build our own code to track the user’s mouse around the screen; we

rely on a GUI library, like Swing, to do that for us Similarly, when we set out to create the

components of a full-scale enterprise solution, we would be crazy to start from scratch

Enterprise programmers build their applications on top of systems called application

servers Just as GUI toolkits provide services of use to GUI applications, application servers

provide services of use to enterprise applications—things like communication facilities to talk

to other computers, management of database connections, the ability to serve web pages, and

management of transactions

Just as Java provides a uniform way to program GUI applications on any underlying

oper-ating system, Java also provides a uniform way to program enterprise applications on any

underlying application server The set of libraries developed by Sun Microsystems and the Java

Community Process that represent this uniform application server application programming

interface (API) is what we call the Java Platform, Enterprise Edition 5 (Java EE 5), and it is the

subject of this book

This chapter provides a high-level introduction to Java EE In this chapter, you will learn:

• Why you would want to use Java EE

• What the benefits of a multitier application architecture are

• How Java EE provides vendor independence and scalability

Mukhar_470-3.book Page 1 Saturday, October 1, 2005 6:14 AM

Trang 4

2 C H A P T E R 1 ■ J A V A E E E S S E N T I A L S

• What the main Java EE features and concepts are

• How to use common Java EE architectures

So, without further ado, let’s get started!

What Is Java EE?

Since you’re reading this book, you obviously have some interest in Java EE, and you probably have some notion of what you’re getting into For many fledgling Java EE developers, Java EE equates to Enterprise JavaBeans (EJBs) However, Java EE is a great deal more than just EJBs While perhaps an oversimplification, Java EE is a suite of specifications for APIs, a distributed computing architecture, and definitions for packaging of distributable components for deploy-ment It’s a collection of standardized components, containers, and services for creating and deploying distributed applications within a well-defined distributed computing architecture Sun’s Java web site says, “ Java Platform, Enterprise Edition 5 (Java EE 5) defines the standard for developing component-based multitier enterprise applications.”

As its name implies, Java EE is targeted at large-scale business systems Software that functions

at this level doesn’t run on a single PC—it requires significantly more computing power and throughput than that For this reason, the software needs to be partitioned into functional pieces and deployed on the appropriate hardware platforms That is the essence of distributed computing Java EE provides a collection of standardized components that facilitate software deployment, standard interfaces that define how the various software modules interconnect, and standard services that define how the different software modules communicate

How Java EE Relates to J2SE

Java EE isn’t a replacement for the Java 2 Standard Edition (J2SE) J2SE provides the essential language framework on which Java EE builds It is the core on which Java EE is based As you’ll see, Java EE consists of several layers, and J2SE is right at the base of that pyramid for each compo-nent of Java EE

As a Java developer, you’ve probably already learned how to build user interfaces with the Swing or Abstract Window Toolkit (AWT) components You’ll still be using those to build the user interfaces for your Java EE applications, as well as HTML-based user interfaces Since J2SE

is at the core of Java EE, everything that you’ve learned so far remains useful and relevant

In addition, Java EE provides another API for creating user interfaces This API is named JavaServer Faces (JSF) and is one of the newest Java EE technologies You’ll also see that the Java EE platform provides the most significant benefit in developing the middle-tier portion of your application—that’s the business logic and the connections to back-end data sources You’ll use familiar J2SE components and APIs in conjunction with the Java EE components and APIs to build that part of your applications

Why Java EE?

Java EE defines a number of services that, to someone developing enterprise-class applications, are as essential as electricity and running water Life is simple when you simply turn the faucet and water starts running, or flip the switch and lights come on If you have ever been involved with building a house, you know that there is a great deal of effort, time, and expense in building

Trang 5

C H A P T E R 1 ■ J A V A E E E S S E N T I A L S 3

the infrastructure of plumbing and wiring, which is then so nicely hidden behind freshly painted

walls At the points where that infrastructure is exposed, there are standard interfaces for

controlling (water faucets and light switches, for example) and connecting (power sockets,

lamp sockets, and hose bibs, for example) to the infrastructure

Suppose, though, that the wiring and plumbing in your home wasn’t already there You

would need to put in your own plumbing and electricity Without standard components and

interfaces, you would need to fabricate your own pipes, wiring, and so on It would be terrifically

expensive and an awful lot of work

Similarly, there is a great deal of infrastructure required to write enterprise-class

applica-tions There are a bunch of different system-level capabilities that you need in order to write

distributed applications that are scalable, robust, secure, and maintainable Some vital pieces

of that infrastructure include security, database access, and transaction control Security ensures

that users are who they claim to be and can access only the parts of the application that they’re

entitled to access Database access is also a fundamental component so that your application

can store and retrieve data Transaction support is required to make sure that the right data is

updated at the right time If you’re not familiar with some of these concepts, don’t worry—

you’ll be introduced to them one at a time throughout this book

Putting in a distributed computing infrastructure—the plumbing and wiring of an

archi-tecture that supports enterprise applications—is no simple feat That’s why Java EE-based

architectures are so compelling; the hard system-level infrastructure is already in place

But why not custom build (or pay someone to custom build) an infrastructure that is

designed around your particular application? Well, for starters, it would take a fantastic amount

of time, money, and effort And even if you were to build up that infrastructure, it would be

different from anyone else’s infrastructure, so you wouldn’t be able to share components or

interoperate with anyone else’s distributed computing model That’s a lot of work for

some-thing that sounds like a dead end And if you were lucky enough to find a vendor that could sell

you a software infrastructure, you would need to worry about being locked into that single

vendor’s implementation, and not being able to switch vendors at some point in the future

The good news is, no surprise, that Java EE defines a set of containers, connectors, and

components that fill that gap Java EE not only fills the gap, but it’s based on well-known,

published specifications That means that applications written for Java EE will run on any

number of Java EE-compliant implementations The reference implementation supplied with

the Java EE Software Development Kit from Sun (Java EE SDK) provides a working model that

we’ll use throughout this book, since it’s the implementation that Sun has built from the

specifi-cation and is freely available In the next chapter, you’ll get an introduction to installing and

testing the Java EE SDK

Multitier Architecture

One of the recurring themes that you’ll run into with Java EE is the notion of supporting

applications that are partitioned into several levels, or tiers That is an architectural cornerstone

of Java EE and merits a little explanation If you are already familiar with n-tier application

architectures, feel free to skip ahead Otherwise, the overview presented here will be a good

introduction or review that will help lay the foundation for understanding the rationale behind

much of Java EE’s design and the services it provides

If you think about a software application composition, you can break it down into three

fundamental concerns, or logical layers:

Trang 6

• The first area of concern is displaying stuff to the user and collecting data from the user

That user interface layer is often called the presentation layer, since its job is to present

stuff to the user and provide a means for the user to present stuff to the software system The presentation layer includes the part of the software that creates and controls the user interface and validates the user’s actions

• Underlying the presentation layer is the logic that makes the application work and handles the important processing The process in a payroll application to multiply the hours worked by the salary to determine how much to pay someone is one example of

this kind of logic This logical layer is called the business rules layer, or more informally the middle tier.

• All nontrivial business applications need to read and store data, and the part of the soft-ware that is responsible for reading and writing data—from whatever source that might

be—forms the data access layer.

Single-Tier Systems

Simple software applications are written to run on a single computer, as illustrated in Figure 1-1 All of the services provided by the application—the user interface, the persistent data access, and the logic that processes the data input by the user and reads from storage—all exist on the same physical machine and are often lumped together into the application That monolithic

architecture is called single tier, because all of the logical application services—the presentation,

the business rules, and the data access layers—exist in a single computing layer

Single-tier systems are relatively easy to manage, and data consistency is simple because data is stored in only one single location However, they also have some disadvantages Single-tier systems do not scale to handle multiple users, and they do not provide an easy means of sharing data across an enterprise Think of the word processor on your personal computer:

It does an excellent job of helping you to create documents, but the application can be used by only a single person Also, while you can share documents with other people, only one person can work on the document at a time

Figure 1-1 In the traditional computer application, all of the functionality of the application exists on the user’s computer.

Trang 7

Client/Server (Two-Tier) Architecture

More significant applications may take advantage of a database server and access persistent

data by sending SQL commands to a database server to save and retrieve data In this case, the

database runs as a separate process from the application, or even on a different machine than

the machine that runs the rest of the program As illustrated in Figure 1-2, the components for

data access are segregated from the rest of the application logic The rationale for this approach is

to centralize data to allow multiple users to simultaneously work with a common database,

and to provide the ability for a central database server to share some of the load associated with

running the application This architecture is usually referred to as client/server and includes

any architecture where a client communicates with a server, whether that server provides data

access or some other service

Figure 1-2 In a client/server architecture, an application client accesses services from another

process to do its job

It’s convenient and more meaningful to conceptualize the division of the responsibility

into layers, or tiers Figure 1-3 shows the client/server software architecture in two tiers

Trang 8

Figure 1-3 The client/server architecture shown in a layer, or tier, diagram

One of the disadvantages of two-tier architecture is that the logic that manipulates the data and applies specific application rules concerning the data is lumped into the application itself This poses a problem when multiple applications use a shared database Consider, for example, a database that contains customer information that is used for order fulfillment, invoicing, promotions, and general customer resource management Each one of those appli-cations would need to be built with all of the logic and rules to manipulate and access customer data For example, there might be a standard policy within a company that any customer whose account is more than 90 days overdue will be subject to a credit hold It seems simple enough to build that rule into every application that’s accessing customer data, but when the policy changes to reflect a credit hold at 60 days, updating each application becomes a real mess

You might be tempted to try to solve this problem by building a reusable library that encapsulates the business rules When the rules change, you can just replace that library, rebuild the application, and redistribute it to the computers running the application There are some fundamental problems with that strategy, however First, that strategy assumes that all of the applications have been created using the same programming language, run on the same platform, or at least have some strategy for gluing the library to the application Next, the appli-cations may need to be recompiled or reassembled with the new library Moreover, even if the library is a drop-in replacement without requiring recompiling, it’s still going to be a royal pain

to make sure that each installation of the application has the right library installed simultaneously (it wouldn’t do to have conflicting business rules being enforced by different applications at the same time)

In order to get out of that mess, the logical thing to do is to physically separate those busi-ness rules out from the computers running the applications onto a separate server so that the software that runs the business rules needs to be updated only once, not for each computer that runs the application

N-Tier Architecture

Figure 1-4 shows a third tier added to the two-tier client/server model In this model, all of the business logic is extracted out of the application running at the desktop The application at the desktop is responsible for presenting the user interface to the end user and for communicating

to the business logic tier It is no longer responsible for enforcing business rules or accessing databases Its job is solely as the presentation layer

Trang 9

■ Note Bear in mind that at this point we’re talking somewhat abstractly and theoretically In a perfect

world, without performance and other implications, the division of responsibility in an application would be

very clear-cut You’ll see throughout this book that you must make practical, balanced implementation decisions

about how responsibilities are partitioned in order to create an application that is flexible and performs well

Figure 1-4 A common enterprise architecture consists of three tiers: presentation, business,

and data.

Typically, in a deployed application, the business logic tier executes on a server apart from

the workstation (you’ll see shortly that this isn’t absolutely required, though) The business

logic tier provides the logical glue to bind the presentation to the database Since it’s running

on a server, it’s accessible to any number of users on the network running applications that

take advantage of its business rules As the number of users demanding those services increases,

and the business logic becomes increasingly complex and processor-intensive, the server can

be scaled up or more servers can be added Scaling a single server is a lot easier and cheaper

than upgrading everyone’s workstations

One of the really great things that this architecture makes possible is the ability to start to

build application models where the classes defined in the business logic tier are taken directly

from the application domain The code in the business logic layer can work with classes that

model things in the real world (like a Customers class) rather than working with complex SQL

statements By pushing implementation details into the appropriate layer, and designing

applications that work with classes modeled from the real world, applications become much

easier to understand and extend

It’s possible to continue the process of partitioning the application functionality into

increasingly thin functional layers, as illustrated in Figure 1-5 There are some very effective

application architectures based on n-tier architecture The application architect is free to

partition the application into as many layers as appropriate, based on the capabilities of the

computing and network hardware on which the system is deployed However, you do need to

be careful about reaching a point of diminishing returns, since the performance penalty for the

network communication between the layers can start to outweigh any gains in performance

Trang 10

Figure 1-5 An enterprise application is not limited to two or three tiers The software architect can design the system to consist of any number of layers, depending on the system requirements and deployment configuration.

In summary, n-tier application architecture is intended to address a number of problems,

including the following:

• The high cost of maintenance when business rules change N-tier applications have

improved maintainability

• Inconsistent business rule implementation between applications N-tier applications

provide consistency

• Inability to share data or business rules between applications N-tier applications offer

interoperability

• Inability to provide web-based front ends to line-of-business applications N-tier

appli-cations are flexible

• Poor performance and inability to scale applications to meet increased user load N-tier

applications are scalable

• Inadequate or inconsistent security across applications N-tier applications can be

designed to be secure

The Java EE architecture is based on the notion of n-tier applications Java EE makes it very

easy to build industrial-strength applications based on two, three, or more application layers, and provides all of the plumbing and wiring to make that possible

Định dạng
Số trang	10
Dung lượng	514,25 KB