Sl425 SW

Architecting and Designing
JavaEE Applications
SL-425-EE5
Sun Microsystems, Inc

UBRM03-195
500 Eldorado Blvd.
Broomfield, CO 80021
USA
Revision C
Copyright 2007 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California
95054, U.S.A. All rights reserved.
This product or document is protected by copyright and distributed under licenses
restricting its use, copying, distribution, and decompilation. No part of this product or
document may be reproduced in any form by any means without prior written
authorization of Sun and its licensors, if any.
Third-party software, including font technology, is copyrighted and licensed from Sun
suppliers.
Sun, Sun Microsystems, the Sun logo, EJB, Enterprise JavaBeans, Java, J2EE, Java Naming
and Directory Interface, JavaBeans, JavaServer Pages, JDBC, Solaris, and Sun Java are
trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other
countries.
Federal Acquisitions: Commercial Software Government Users Subject to Standard
License Terms and Conditions. Export Laws. Products, Services, and technical data
delivered by Sun may be subject to U.S. export controls or the trade laws of other
countries. You will comply with all such laws and obtain all licenses to export, re-export,
or import as may be required after delivery to You. You will not export or re-export to
entities on the most current U.S. export exclusions lists or to any country subject to U.S.
embargo or terrorist controls as specied in the U.S. export laws. You will not use or
provide Products, Services, or technical data for nuclear, missile, or chemical biological
weaponry end uses.
DOCUMENTATION IS PROVIDED AS IS AND ALL EXPRESS OR IMPLIED
CONDITIONS, REPRESENTATIONS, AND WARRANTIES, INCLUDING ANY
IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE
EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
THIS MANUAL IS DESIGNED TO SUPPORT AN INSTRUCTOR-LED TRAINING
(ILT) COURSE AND IS INTENDED TO BE USED FOR REFERENCE PURPOSES IN
CONJUNCTION WITH THE ILT COURSE. THE MANUAL IS NOT A STANDALONE
TRAINING TOOL. USE OF THE MANUAL FOR SELF-STUDY WITHOUT CLASS
ATTENDANCE IS NOT RECOMMENDED.
ExportControlClassicationNumber(ECCN)assigned:5March2003
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.
Contents
Lab Preface
Preface-1
Workbook Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preface-1

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preface-2
1
Introducing Fundamental Architectural Concepts

Exercise 1
Lab 1-1
Designing an Architectural Model . . . . . . . . . . Lab 1-2
Task 1 Creating UML Logical Diagrams . . . . . . . . . . . . Lab 1-7

Task 2 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lab 1-8
Task 3 Identifying Strategies to Mitigate Risks . . . . . . . . Lab 1-9
Task 4 Updating the UML Deployment Diagrams . . . . . . Lab 1-10
Exercise 2
Multi-tier, Distributed Application . . . . . . . . . Lab 1-11
Task 1 Decoupling the Model . . . . . . . . . . . . . . . . . . Lab 1-11

Task 2 Distributing a Multi-Tier Application . . . . . . . . . Lab 1-12
Task 3 Identifying Trade-offs . . . . . . . . . . . . . . . . . . Lab 1-13
Exercise 3
2
Choosing Alternative Technologies . . . . . . . . . Lab 1-15
Understanding System Qualities

Architecting and Designing JavaEE Application
Lab 2-1
3
CONTENTS
CONTENTS
Exercise 1
Deployment Strategies for Scalability . . . . . . . . Lab 2-2
Task 1 Strategies to Address Scalability Concerns . . . . . . Lab 2-2

Task 2 UML Diagrams . . . . . . . . . . . . . . . . . . . . . . Lab 2-2
Exercise 2
Capacity Planning . . . . . . . . . . . . . . . . . . Lab 2-4
Exercise 3
Deployment Strategies for Availability . . . . . . . Lab 2-5
Task 1 Strategies to Address Availability Concerns . . . . . . Lab 2-5

Exercise 4
Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . Lab 2-7
Task 1 Trade-offs Associated with Strategies for Scalability . Lab 2-7

Task 2 Trade-offs Associated with Strategies for Availability
3
Lab 2-8
Examining System Architecture Development Heuristics and Guidelines

Lab 3-1
Exercise 1
The placeBid Use Case . . . . . . . . . . . . . . . . Lab 3-2
Task 1 Streamline Execution . . . . . . . . . . . . . . . . . . . Lab 3-7

Task 2 Concurrency Issues . . . . . . . . . . . . . . . . . . . . Lab 3-9
Exercise 2
Alternatives and Their Trade-offs . . . . . . . . . . Lab 3-10
Exercise 3
Fine-Tuning Distributed Interactions . . . . . . . . Lab 3-11
Task 1 Distributed Overhead . . . . . . . . . . . . . . . . . . Lab 3-12

Task 2 Improving the Model . . . . . . . . . . . . . . . . . . . Lab 3-12
4
Developing an Architecture for the Client Tier

Exercise 1
Lab 4-1
Improving the User Experience . . . . . . . . . . . Lab 4-2
Task 1 Strategies . . . . . . . . . . . . . . . . . . . . . . . . . Lab 4-4

4
CONTENTS
CONTENTS
Task 2 UML Model . . . . . . . . . . . . . . . . . . . . . . . . Lab 4-4

Exercise 2
5
Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . Lab 4-5
Developing an Architecture for the Web Tier
Lab 5-1
Exercise 1
Web Tier for simple HTML-based UI . . . . . . . . Lab 5-4
Exercise 2
Web tier for sophisticated clients
Exercise 3
Frameworks . . . . . . . . . . . . . . . . . . . . . . Lab 5-6
Exercise 4
Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . Lab 5-7
. . . . . . . . . . Lab 5-5
Developing an Architecture for the Business Tier

Exercise 1
Lab 6-1
Designing the Business Tier . . . . . . . . . . . . . Lab 6-2
Task 1 Candidate JavaEE Technologies . . . . . . . . . . . . . Lab 6-3

Task 2 UML Models . . . . . . . . . . . . . . . . . . . . . . . Lab 6-4
Exercise 2
Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . Lab 6-5
Exercise 3
Fine-Tuning The Model (optional) . . . . . . . . . . Lab 6-6
Task 1 Alternative Technologies . . . . . . . . . . . . . . . . Lab 6-6

Task 2 Advanced Features of Platform Technologies . . . . . Lab 6-6
7
Developing an Architecture for the Integration and Resource

Tiers
Exercise 1
Lab 7-1
Designing the Integration Tier . . . . . . . . . . . . Lab 7-2
Task 1 Technologies Applicable . . . . . . . . . . . . . . . . . Lab 7-3

Task 2 UML Diagram . . . . . . . . . . . . . . . . . . . . . . . Lab 7-3
Exercise 2
Integration using Web Services (optional) . . . . . Lab 7-4
Exercise 3
The Auction system as a Service . . . . . . . . . . . Lab 7-5

CONTENTS
CONTENTS
Task 1 Defining Service APIs . . . . . . . . . . . . . . . . . . Lab 7-5

Exercise 4
8
Orchestrating Multiple Services . . . . . . . . . . . Lab 7-6
Developing a Security Architecture

Exercise 1
Lab 8-1
Addressing Security Risks . . . . . . . . . . . . . . Lab 8-2
Task 1 Security Risks . . . . . . . . . . . . . . . . . . . . . . . Lab 8-2

Task 2 Risks in the Auction system . . . . . . . . . . . . . . . Lab 8-3
Task 3 Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . . Lab 8-3
Lab Preface
Workbook Goals
Upon completion of labs in this course, you should be able to:
Describe the role of the architect and the products an architect delivers
Describe typical problems associated with large scale enterprise software systems
Utilize Java Platform, Enterprise Edition (Java EE) and relevant technologies to address quality-of-service requirements
Apply best practices and guidelines to the development of multitiered enterprise Java applications
Consider different alternatives for developing architectures for enterprise Java applications
Validate the architecture for an enterprise Java application

Preface-1
Conventions
Lab Preface
Conventions
The following conventions are used in this course to represent various
training elements and alternative learning resources.
Icons
Self-check - Identifies self-check activities, such as matching

and multiple-choice.
Additional resources Indicates other references that provide
additional information on the topics described in the module.
Discussion Indicates a small-group or class discussion on the
current topic is recommended at this time.
Note Indicates additional information that can help students
but is not crucial to their understanding of the concept being described. Students should be able to understand the concept or
complete the task without this information. Examples of notational information include keyword shortcuts and minor system
adjustments.
Caution - Indicates that there is a risk of personal injury from
a nonelectrical hazard, or risk of irreversible damage to data,
software, or the operating system. A caution indicates that the
possibility of a hazard (as opposed to certainty) might happen,
depending on the action of the user.
Typographical Conventions
Courier is used for the names of commands, les, directories, programming
code, and on-screen computer output; for example:
Use ls -al to list all les.
system# You have mail.
Preface-2Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.
Lab Preface
Conventions
Courier is also used to indicate programming constructs, such as class names,

methods, and keywords; for example:
The getServletInfo method is used to get author information.
The java.awt.Dialog class contains Dialog constructor.
Courier bold is used for characters and numbers that you type; for example:
To list the les in this directory, type:
# ls
Courier bold is also used for each line of programming code that is referenced in a textual description; for example:
1 import java.io.*;
2 import javax.servlet.*;
3 import javax.servlet.http.*;
Notice the javax.servlet interface is imported to allow access to
its life-cycle methods (Line 2).
Courier italics is used for variables and command-line placeholders
that are replaced with a real name or value; for example:
To delete a file, use the rm filename command.
Courier italic bold is used to represent variables whose values are to be
entered by the student as part of an activity; for example:
Type chmod a+rwx filename to grant read, write, and execute
rights for filename to world, group, and users.
Palatino italics is used for book titles, new words or terms, or words that
you want to emphasize; for example:
Read Chapter 6 in the User s Guide.
These are called class options.
Preface-3
Conventions
Lab Preface
Additional Conventions
JavaTM programming language examples use the following additional conventions:
Method names are not followed with parentheses unless a formal or
actual parameter list is shown; for example:
The doIt method... refers to any method called doIt.
The doIt() method... refers to a method called doIt that takes no
arguments.
Line breaks occur only where there are separations (commas), conjunctions (operators), or white space in the code. Broken code is indented four spaces under the starting code.
If a command used in the SolarisTM Operating Environment is different from a command used in the Microsoft Windows platform, both
commands are shown; for example:
If working in the Solaris Operating Environment
%cd $SERVER_ROOT/BIN
If working in Microsoft Windows
C:\>CD %SERVER_ROOT%\BIN
Preface-4Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.
Lab 1
Introducing Fundamental
Architectural Concepts
Objectives
Upon completion of this lab, you should be able to:
Design an architectural model
Understand architecture modeling using the Unified Modeling Language (UML)
Choose alternative technologies

Lab 1-1
Exercise 1: Designing an Architectural Model
Exercise 1
Lab 1
Designing an Architectural Model
In this exercise you construct a set of architectural diagrams for the Auction
application that you will design over the course of these labs.
The Auction application supports the set of use cases necessary to provide
an online auction web site, as illustrated by Figure 1.1 on page Lab 1-2:
Figure 1.1: Use Cases for Auction System
login All users of the Auction system must first log on to the system, before they can invoke other operations. To log on, users must authenticate themselves (perhaps by providing a userid and a password).
This use case includes either of the addUser or findUser use cases.
It might be important to distinguish between sellers and bidders,
since there are tasks in the Auction system that only one kind of user
may request. This may lead the student to consider the trade-offs associated with representing users as one single type (with an attribute
that identifies the kind of user they are, or as two different types of
users that may or may not be related to each other via inheritance.
Lab 1-2 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.
Lab 1
addUser Adds a new user to the system database. This use case is invoked
by the login use case, when a new user accesses the Auction system
for the first time. In addition to the user ID and password already
supplied, the system asks the user for additional personal information: name, address (both location and email). Optionally, the user
will be able to provide credit card information to be used as a default
method of payment.
If the interaction spans multiple pages, this could introduce a need
for session state to be maintained in order to add this information to
the database in a single operation.
findUser Finds an existing user in the system database. This use case is
invoked by the login use case, when an existing user returns to the
Auction system.
Information about the current user could also be kept in session state.
addItem Sellers are allowed to create items to be auctioned off. The item
to be auctioned and the auction for the item are considered to be independent from each other. This allows a seller who has multiples of
a given item to hold separate auctions for each copy, while reusing
the same item for each auction. Items hold information, such as the
name for the item, a description, and a picture. Note that it might
be possible to implement some of these domain objects as entities in
their own right, or as embeddables.
createAuction Sellers are allowed to create auctions, to auction items off.
Each auction holds information, such as the item being auctioned, the
initial bid price, the date the auction starts and the date it will end (or
how long the auction will last), and a list of all bids placed on it.
The Auction system should also allow the seller to create multiple
auctions for a number of copies of the same item conveniently. This
can be achieved by allowing the seller to create a first auction, and
then allowing the seller to create another just like it, or by allowing
the seller to specify the number of copies of an auction to create, as
part of the process of creating each auction.
The intent here is to motivate a need for the student to consider stateful vs stateless implementations of this use case.
It would also be possible - although it is beyond the scope of the exercise - to consider different types of auctions.
Lab 1-3
Lab 1
placeBid Bidders are allowed to bid on auctions. Given an auction, the

bidder is allowed to enter a bid on that auction. The Auction system should not allow a bidder to place a bid on an auction that is
lower than the current bid price for that auction. The Auction system
should also allow the user to find out what the current bid price for
the auction is, or even notify the user automatically when the current
bid price for the auction changes, or when the bidder is no longer the
current high bidder for the auction.
The bidder should be able to select a collection of auctions they are interested in bidding on, and to allow the bidder to place bids on any of
the auctions in that collection. In this case, the Auction system should
present the bidder with the current bid price for each of the auctions
in the collection, plus a running total of the amount of money the
bidder is currently bidding on all auctions in the list, taken together.
Also, bidders should be able to find out what the current bid prices
for all auctions in the list are, or be notified automatically when the
current prices change, or when the bidder is no longer the high bidder
for any of the auctions in the collection.
Students should identify two concerns associated with this use case:
the queries for current bid prices could place a high load on the
Auction system, specially when updates are implemented;
bidding may need to be transactional, to allow multiple bidders
to operate concurrently safely - which could also add to the load.
Unsafe concurrent operations would be show-stoppers - so it
may be that transactions need to be mandatory here.
findAuction Users must be able to provide criteria to be used to retrieve
a collection of bids in which the user might be interested. The user
must also be able to narrow down the results of a previous query.
These query operations must be supported while other users are using these same auctions. That is, users must be allowed to find auctions of interest while other users do the same, or bid on some of the
same auctions.
Students should identify issues like read/write conflicts, or large query
results (and its consequences). The first might be address through
local transactions (or some other kind of transaction locking), the
second (query/result overhead) through patterns such as Value List
Handler.
Lab 1
These two issues might be related: e.g. different VLH implementations (e.g. different caching strategies (if any)) may have an impact
on how to deal with read/write conflicts.
payBid Bidders must be able to pay for their winning bid on an auction,
once the action is over. The Auction system offers to use the credit
card information the user entered when the user first registered with
the system, although it also allows the user to provide an alternative
means of payment. The system should also notify the seller of that
auction, when the winning bidder actually pays for that auction.
This use case should lead the student to realize that it will be necessary for the Auction system to interact with third-party systems, like
a credit card clearinghouse, in order to process payments.
The business model for the Auction system represents all the information
necessary to support the use cases listed previously. Figure 1.2 on page Lab
1-6 illustrates the following abstractions, as a starting point:
Auction Each instance represents an auction. It is responsible for the dates
the auction starts and ends, the initial and winning bid price, and a
list of all bids placed on this auction.
Item Each instance represents an item that can be auctioned off. It is responsible for information about each item, such as its name, description, or a picture of the item.
Bid Each instance represents a bid that a user has placed on an auction.
It is responsible for information about the bid, such as the maximum
amount the bidder was willing to bid on this bid, the time the bid was
placed, and the bidder who placed the bid.
User Each instance represents a user of the Auction system. It is responsible for information about each user, such as the users name, address,
email, or credit card information.
Certification exam provides requirements only, while we provide an initial
set of business types already.
You are also given a number of issues that are non-functional requirements
to keep in mind as you consider how to build this Auction system:
Lab 1-5
Lab 1
Figure 1.2: Domain Types for the Auction System

Portability Its been requested that the Auction system be implemented as
a web-based application in which the client side is straight HTML.
This maximizes the likelihood that clients can interact with the Auction system, because almost every platform supports rendering of
straight HTML.
Asynchronous updates may require the introduction of AJAX, or a
move away from HTML to a rich client platform. Students will be
expected to discuss the trade-offs associated with this - but later, in
Lab X.
Scalability The applications runtime characteristics must remain acceptable as the number of clients, or requests per client, increases.
Other requirements that may have an impact on this requirement:
concurrently placing bids, finding auctions
higher bid notification
Performance Response time when placing bids, or when selecting auctions
to bid on, must remain short.
Lab 1
You can also assume that you are deploying the Auction system as an
enterprise application (including a web-application front-end) on a single JavaEE server. As a result, only logical deployment choices, like tiers
(client, presentation, business, resources) should be addressed. Physical
deployment choices, like distribution (deploying applications and/or their
components in many JVMs on many hosts), and the associated trade-offs,
will be discussed in Exercise 2.
Preparation
No preparation is needed for this exercise.
Task 1
Creating UML Logical Diagrams
In this exercise, you create a collection of UML logical (class and sequence)
diagrams that describe the object-oriented (OO) model you propose for the
Auction system.
As a starting point, you are provided with UML diagrams for the proposed
OO model in the form of a NetBeansTM UML project. This project is located
in your home directory, under exercises/Lab01. You can use this project
as a starting point for your own solution.
The domain model of the system is an essential artifact for which the architect should be responsible. You typically use UML diagrams to capture

Lab 1-7
Lab 1
essential components that represent the most stable parts of a software system, such as long-lived entities and stable business processing components.
Possible variations on the OO model that the students may present:
User as the root of a hierarchy with Bidder and Seller as children.
User with an attribute that controls whether user is a bidder or a
seller.
Bidder and Seller as two unrelated types.
User as the only abstraction representing users, with the determination as to whether a User is a seller or a bidder based on context.
Auction as the root of a hierarchy that captures different kinds of auctions as children. Possibilities include:
multiple-item auctions, in which sellers auction off lots of items,
and where several bidders can win together
auctions with different bidding rules
Instructors would need to be able to discuss pros and cons for each alternative.
Task 2
Risks
Some say that the job description for an architect is to do risk management:
to identify risks to a design and the strategies that address those risks. Consider the UML model that you produced for Task 1, and identify the risks
that might be associated with that design.
Possible risks:
maintainability.
Models that use inheritance might gain flexibility, at a price in
terms of complexity.
Lab 1
Domain types could be implemented as standalone entities, or

as embedded types.
other risks mentioned above
Task 3
Identifying Strategies to Mitigate Risks
For each of the risks you identified in Task 2, list strategies that might be
applicable to address each risks. For each of these strategies, enumerate
any trade-offs associated with applying that strategy to your OO model for
the Auction system.
You can limit your answer here to business-level or application-level strategies. Other alternative strategies that involve delegating some of the machinery needed to address these risks to the (JavaEE) platform are discussed in later labs.
placing concurrent bids load/notification
AJAX => higher load due to polling?
client AJAX / server JMS async updates
find auction server caching, Javascript, AJAX
concurrently placing bids: resource tier or business tier optimistic
locking
concurrently finding auctions: business tier and/or client tier caching
higher bid notification
business tier notification (push technology, using JMS - or pull
technology, using RMI)
client tier notification
browser, only poll technology, using AJAX
appclient, push technology, using JMS - or pull technology,
using RMI
webservice, push technology - or pull technology (various
choices)

Lab 1-9
Task 4
Lab 1
Updating the UML Deployment Diagrams
Update the UML models that you constructed in Task 1 to incorporate the
best strategies you identified in Task 3 to address the risks to your original
model that you identified in Task 2.
UML Deployment (high-level) per use case?
diagram with 2/3 client types web tier business tier resources
diagram with browser web tier business tier resources + rich
client business tier
web/business tiers
Lab 1
Exercise 2: Multi-tier, Distributed Application
Exercise 2
Multi-tier, Distributed Application
Preparation
No preparation is needed for this exercise.
Task 1
Decoupling the Model
In Exercise 1, you assumed that you would deploy the Auction system on
a single JavaEE server, so you could think of it as one monolithic application. Now, you are asked to assume the opposite: deploy the Auction as a
distributed application.
The first step is to identify the different parts that make up the Auction
system, and to decouple them from each other. This is the same process
you would follow to design the Auction system using a Service-Oriented
Architecture (SOA).
The first task is to produce an updated set of UML diagrams that present
the OO model for the Auction system in such a way that these different
parts are clearly decoupled: easy to identify, isolated from each other as
appropriate.
You might want to save a copy the NetBeans UML project that
you produced for Exercise 1. To do so, you can simply copy
the project folder for the project at the end of Exercise 1. You
can then continue to work on Exercise 2 by closing the original
NetBeans UML project, and opening the copy as another
NetBeans UML project.
Students should produce UML diagrams that result from the application of
appropriate patterns.
The inter-tier principles that matter are:
T1-to-T2 (incoming) complexity hider
(optional: also partial or full T2-to-T1 technology hider)
Lab 1-11
Lab 1
T1-to-T2 (outgoing) technology hider

T1-to-T2 and T2-to-T1 technology agnostic information
The JavaEE inter-tier patterns that matter are:
Front Controller
C-to-P complexity hider
P-to-C technology hider (full)
Business Delegate (P-to-B (or C-to-B) technology hider)
Session Facade
P-to-B (or C-to-B) complexity hider
B-to-P (or B-to-C) technology hider (partial)
Data Access Object (B-to-R (functionality oriented) technology hider)
Business Object (B-to-R (information oriented) technology hider)
Transfer Object
P-to-B (and C-to-B) and B-to-P (and B-to-C) technology agnostic
information
B-to-R (and R-to-B) technology agnostic information, when using DAO
Certification exam requires familiarity with these patterns.
Task 2
Distributing a Multi-Tier Application
The logical UML diagrams that you produced in Exercise 2 Task 1 describe
a multi-tier application. It supports deployment on a single JavaEE server,
or distributed over a cluster of JavaEE servers. However, it might be that
you can further evolve your logical UML models, if you also assume that
the application is deployed as a distributed, multi-tier application over a
cluster of JavaEE servers.
Complete the following steps:
Lab 1
1. Identify strategies for deploying the Auction system as you described

it in Task 1 as a distributed, multi-tier application.
2. Update your logical UML diagrams to describe any additional structure that would make your model better suited for a distributed, multitier deployment, or discuss how your existing multi-tier model will
be suitable as is for distributed deployment. You need to consider issues related to the distributed nature of the deployment, such as network overhead, and the implications of these issues for your model
from the point of view of the Quality of Service (QoS) characteristics
of your solution.
Students should present logical UML diagrams supporting a deployment
as multiple applications - deployment diagram should show network interactions in terms of facades (and TOs?). Students could also draw UML
deployment diagrams - though these will be the subject of Lab 2.
Task 3
Identifying Trade-offs
At this point you have UML models corresponding to three different strategies to organize the Auction system:
a low cohesion - high coupled design, with monolithic deployment
(from Exercise 1)
a high cohesion - low coupled design multi-tier design, with monolithic deployment (from Exercise 2 Task 1)
a high cohesion - low coupled design multi-tier design, with distributed deployment (from Exercise 2 Task 2)
List the advantages and disadvantages associated with each of the three
approaches.
There is this difference between
low cohesion - high coupled design not enough components doing to much
Lab 1-13
Lab 1
high cohesion - low coupled design enough components (logically living in different tiers) working in harmony toghether
on the one hand, and
monolithic deployment all components in one process
distributed deployment many components in different processes on different machines
This will lead into Lab02 so here it must remain high-level.
Lab 1
Exercise 3: Choosing Alternative Technologies
Exercise 3
Choosing Alternative Technologies
Sometimes, choosing alternative technologies to build an application can

lead to advantages, in terms of the QoS characteristics of the solution you
can deliver.
As an example, the original set of requirements for the Auction system
requested that you design the system as a web application that relies on
straight HTML on the client side, rather than using some rich-client technology, for portability. Having designed a first model for the application
that obeys this constraint, it would be interesting to consider what alternatives there might be, and what the consequences of using such alternatives
might be, as far as the QoS metrics for our application are concerned.
A specific requirement that turns out to be complex to design within the
bounds of a pure HTML presentation is the desire to provide asynchronous
updates to a client automatically, without the need to user intervention.
What alternative technologies could you choose to use to build the Auction
system, that would help implement this particular feature? Identify how
each of these technologies would help, and list the trade-offs associated
with each alternative.
Students could discuss:
web browser vs. PDA vs desktop
client types define interfaces in terms of Java interfaces, or even
platform neutral (like WSDL or IDL)
rich user experience (async update) : applet vs. AJAX vs. Swing
The trade-offs to consider with each alternative technology:
portability across browser types/versions or platforms
time to market
faster turnaround => simpler/known technologies, reduce application flexibility
Students could produce a UML Deployment diagram for rich client+web
client architecture here - though that will be the subject of a later lab.
Lab 1-15
Exercise 3: Choosing Alternative Technologies
Lab 1
Exercise Summary
Discussion Take a few minutes to discuss what experiences,

issues, or discoveries you had during the lab exercise.
Lab 2
Understanding System
Qualities
Objectives
Understand the trade-offs associated with using an application server
cluster to address scalability concerns
Understand the trade-offs associated with using an application server
cluster to address availability concerns
Understand the issues relevant to capacity planning

Lab 2-1
Exercise 1: Deployment Strategies for Scalability
Exercise 1
Lab 2
Deployment Strategies for Scalability
In Lab 1 we discussed a couple of alternative strategies to deploy our Auction system:
on a single application server;

on a cluster of applicaton servers, partitioning the Auction system
into a number of applications that would run separately, one on each
server in the cluster, and communicate with each other so as to continue to operate logically as one application.
A risk that every application has to address has to do with the scalability of
the solution: the system will have to maintain a minimal QoS level as load
(measured by number of concurrent users, for instance, or by overall number of requests) on the system increases. As architects, we are responsible
for taking steps in our architectural models to address this risk.
Task 1
Strategies to Address Scalability Concerns
Enumerate alternatives derived from each of the two strategies above, to

incorporate mechanisms into our architecture that would address this risk.
Students should come up with at least two alternatives, corresponding to
horizontal and vertical scalability.
Task 2
UML Diagrams
For each of the alternatives identified in Task 1, draw UML deployment

diagrams that illustrate the approach proposed.
Lab 2
Exercise 1: Deployment Strategies for Scalability
If you had already drawn deployment diagrams as part of

your answers to Lab 1, you could reuse those diagrams for this
exercise. Again, it might be safest if you would make a copy
of the project folder for your answer to Lab 1 that included
the deployment diagrams you will use as a starting point. You
could then use that copy for this exercise - and you would still
have the answer to the previous exercise available on its own.
Students ought to produce two different UML diagrams:

a deployment diagram corresponding to vertical scalability, in which
the application runs on a single large server;
a deployment diagram corresponding to horizontal scalability, in which
multiple copies of a tier are deployed on neighboring servers, with a
load balancer in front to distribute load.
We may need to further edit this question. In the Java world, where JVMs
play an important role, the distinction horizontal vs. vertical maybe not
be fully adequate.
One can have:
one virtual machine on one physical machine
many virtual machines on one physical machine
one virtual machine on many physical machines
many virtual machines on many physical machines
So, either we should make abstraction of virtual machines and just call
them machines, or we should deal with 4 possibilities.
Also - application servers are another thing, they are a piece of software
that can be deployed on one or many (virtual) machines.

Lab 2-3
Exercise 2: Capacity Planning
Exercise 2
Lab 2
Capacity Planning
In Exercise 1 you listed a number of alternative strategies to deal with scalability requirements that may be specified for our Auction system. However, these strategies are still lacking quantification: we can state that we
will require machines with more capacity, for instance - but at some point
it would be necessary to specify just what the actual capacity should be, in
order to meet a given set of QoS requirements. This process is known as
capacity planning.
How would you proceed, so as to perform a capacity planning analysis, to
figure out the actual resources that each alternative would require?
This exercise ideally would have supplied the student would algorithms
and formulas to perform capacity planning analysis for the Auction application, for a given set of requirements. However, we do not have such
information available - so the exercise becomes one of asking students to
propose ways in which they could figure out what the appropriate capacity for their chosen deployment strategy ought to be.
The resources folder will contain a number of articles that discuss this topic.
Lab 2
Exercise 3: Deployment Strategies for Availability
Exercise 3
Task 1
Deployment Strategies for Availability
Strategies to Address Availability Concerns
Another common QoS constraint that architects often have to ensure is met
by the design of an enterprise application has to do with availability: there
might be a requirement that the application be there when clients attempt
to reach it with certain requirements in terms of uptime, for instance.
Fortunately, the same strategies introduced in Lab 1, and that we used as
a starting point to develop strategies to ensure our design met scalability
constraints, also lend themselves to be the starting point to develop strategies that address availability concerns.
Starting with the two strategies outlined in Lab 1, outline strategies that
can be used to ensure that a design will meet given availability goals.
Students should identify two strategies:
the first of the original strategy deploying our application on a single host leads to a strategy that would achieve availability goals by
deploying the application to a single high availability (HA) server.
the second of the original strategies deploying our application on a
cluster leads to a strategy that would achieve availability goals by
deploying duplicate copies of the application (or its tiers) onto neighboring servers in such a way that the failure of a server would lead to
its traffic being redirected to one of those duplicate servers.
Task 2
UML Diagrams
For each of the alternatives identified in Task 1, draw UML deployment

diagrams that illustrate the approach proposed.
Lab 2-5
Exercise 3: Deployment Strategies for Availability
Lab 2
You have already drawn deployment diagrams, back in Exercise 1. You could reuse those diagrams for this exercise. Again,
it might be safest if you would make a copy of the project folder
for your answer to Exercise 1. You could then use that copy
for this exercise - and you would still have the answer to that
previous exercise available on its own.
Students ought to produce two different UML diagrams:

a deployment diagram corresponding to vertical availability, in
which the application runs on a single HA server;
a deployment diagram corresponding to vertical availability, in
which multiple copies of a tier are deployed on neighboring servers,
with a failover router in front. The solution should indicate which
failover strategy it will use to select which backup server to use, when
any primary server goes down: (N+1, pairs = topology + roles + capacity)
Their solution should also have one of:
some mechanism to synchronize state across duplicate servers;
or
some mechanism to centralize state that can be shared across
servers.
Lab 2
Exercise 4: Trade-offs
Exercise 4
Trade-offs
This task may be an instructor-led discussion, rather than a student activity.
Task 1
Trade-offs Associated with Strategies for Scalability
For each of the alternatives identified in Exercise 1, discuss the trade-offs

associated with each alternative: what advantages would each alternative
bring to the application, and what price would be paid if that alternative
was chosen. When you identify penalties associated with a particular strategy, you should also consider whether there is anything that could be done
to minimize the impact on the applications QoS characteristics.
For the alternative that corresponds to vertical scalability, the student should
identify the following concerns:
limited scalability
a single host may only get so powerful, before the configuration cannot grow any further.
For the alternative that corresponds to horizontal scalability, the student
should identify the following concerns:
TCO
maintainability
network overhead
duplication of state
when multiple clients share interest in common domain entities
when the same client is handled by different servers on separate
requests.
Among the strategies that could minimize the impact of these concerns,
students might mention:
Lab 2-7
Lab 2
session affinity
partitioning,
avoid via stateless (overhead in client or db?)
Task 2
Trade-offs Associated with Strategies for Availability
For each of the alternatives identified in Exercise 3, discuss the trade-offs

associated with each alternative: what advantages would each alternative
bring to the application, and what price would be paid if that alternative
was chosen. When you identify penalties assocaiteed with a particular
strategy, you should also consider whether there is anything that could be
done to minimize the impact on the applications QoS characteristics.
For the alternative that corresponds to vertical availability (a single host
with HA hardware), the student should identify the following concerns:
expense to buy HA hardware.
For the alternative that corresponds to horizontal availability (clusters
of servers that are duplicates), the student should identify the following
concerns:
TCO
maintainability
duplication of state:
network overhead to maintain duplicate state
database overhead to maintain centralized state.
Among the strategies that could minimize the impact of these concerns,
students might mention:
centralized state in shared (persistent) storage
avoid via stateless (overhead in client or db?)
Lab 3
Examining System Architecture

Development Heuristics and
Guidelines
Objectives
Understand the impact of transactions on application performance
Understand the impact of distributed operations on application performance

Lab 3-1
Exercise 1: The placeBid Use Case
Exercise 1
Lab 3
The placeBid Use Case
Our Auction systems allows users to place bids on open auctions: the user
must select the auction they are interested in, to place a bid on it, as illustrated in Figure 3.1. You will note that the placing of a bid is something like
a conversation between the bidder and the Auction system, spread across a
number of web pages (and their interaction with the system):
the user selects an auction of interest
the system presents information about the auction selected, including
the current high bid, if any
the user requests to place a bid on this auction
the system queries the user for bid information
the user submits a bid
the system validates that this bid would be valid - that it would be
higher than the current high bid, and asks the user to confirm the bid
the user submits a confirmation
the system places the bid on behalf of this user, and presents the user
with an updated display of th status of this auction.
As a convenience to our users, the Auction system allows a bidder to specify the maximum amount the bidder is willing to reach with this particular
bid but the system will not enter the maximum bid immediately. Instead,
the system will enter a bid only high enough to become the high bid on the
auction (if possible) - but it will raise the bid automatically as other bidders
attempt to out bid the first bidder, up to the limit the first bidder specified.
Much the same way EBay operates
Behind the scenes, our initial model for the Auction system has the web
tier components responsible for this interaction communicate with domain
objects to process the clients requests, and to retrieve any information that
may need to be presented to the user. Figure 3.2 is a UML diagram of our
Lab 3
Figure 3.1: Flow for placeBid Use Case

Lab 3-3
Lab 3
initial set of domain objects 1 , while Figure 3.3 is a UML diagram of the
interactions relevant to the placeBid use case.
The placeBid use case depends on the findAuction use case. findAuction
allows the user to select a list of auctions that the user can then choose from,
in order to place a bid. findAuction itself could be seen as a conversation
between the user and the system:
the user indicates that they wish to find a list of auctions of interest
the system presents the user with a page where the user can enter the
criteria to use to select auctions of interest. This could include an item
in particular that the user is interested in, or a partial description to
match against the descriptions of all items being auctioned off, or a
price range
the user submits the set of criteria that describes their interest
the system performs a search based on the criteria specified, and presents
a list of matches to the user, along with the possibility to further narrow the search
if the user selects to narrow the search, the system presents again the
page where the user can enter criteria, to fine tune the search.
Preparation
You may use the model for the Auction system you designed yourself in
Lab 1, instead of the one we propose here if your model has equivalent
detail on the machinery necessary to support the placeBid use case.
The UML models for the placeBid use case can be found
as a MagicDraw project in your home directory, under
resources/UML/placeBidWAE.mdzip.
1 For
convenience, we have left out of the diagram any getters and setters for simple
attributes, in Figure 3.2.
Lab 3
Figure 3.2: Domain classes for placeBid Use Case

Lab 3-5
Figure 3.3: Flow for placeBid Use Case
Lab 3
Lab 3
Figure 3.4: Single server deployment diagram for the placeBid use case.
Task 1
Streamline Execution
1. Identify significant sources of overhead in the model for the placeBid

use case.
2. Modify the model to address these concerns.
For the purposes of this task, you may assume that concurrency is not an
issue, when examining the model. But note that you should not propose
modifications to the model that will rely on this assumption remaining true
when our system is deployed - the next task will ask you to consider the impact of concurrency on our design. You may also assume that our Auction
system will be deployed on a single JavaEE application server, as illustrated
in Figure 3.4 Task 3 will ask you to assume otherwise.
The UML model proposed in this lab is intentionally designed with interactions between web and business tiers that are too fine-grained. Students
should introduce Facade and Transfer Object patterns to improvide the design.
Lab 3-7
Lab 3
Also, the bid shopping cart (in web session scope) in the Web Tier could be
seen as a (stateful) Business Delegate for the bid shopping cart (sfsb) in the
Business tier (in this case used to assemble fine-grained web-tier operations
into course-grained ejb-tier operations).
Further - the application-level model as presented is too simplistic. Students should address these issues:
in general, retrieving the current high bid requires that the Auction
retrieve the two top bids from the list of bids, in order to compute
what the current high bid by the top bidder really is. Remember that
the top bid will only be high enough for the top bidder to outbid the
second bidder, not necessarily the maximum amount the top bidder
was willing to go to.
the list of bids associated with the auction is not ordered - retrieving
the top bid, or the two top bids, requires that the client retrieve the
complete list of bids, then sort it.
should the confirmation that the user wants to place a bid be allowed
to fail because some other bidder already placed a higher bid?
Our model assumes this is possible: when actually placing a bid, the
system calls isValid(bid) before calling addBid(bid) - which results
in redundant work, since addBid() checks internally, to avoid errors.
So, there are two issues here:
avoiding redundant work
ensuring atomicity
If addBid(bid) checks internally, and isValid(bid) is not used, then
both issues are dealt with. If addBid(bid) checks internally, and isValid(bid) is used, then there is redundant work. If addBid(bid) does
not check internally, and isValid(bid) is used, then there is no atomicity.
the business model may also require that a user be able to place and/or
update a set of bids at once.
There are additional concerns that students might note, when thinking
about sources of overhead:
Lab 3
lazy vs eager retrieval of associations

one-directional vs. bi-directional associations
These will be the subjets of later labs.
Task 2
Concurrency Issues
Our discussion of the placeBid so far has ignored the possibility that multiple bidders may attempt to place bids concurrently on the same auction
(or perhaps just watch the current status of that same auction, which would
also access the same Auction entity within the application).
Examine the model to identify whether the model actually assumes that
concurrent operations are not possible. Modify it as needed to ensure that
an implementation of that model will operate both safely and efficiently,
when bidders attempt to place bids on the same auction (or otherwise examine that auction) concurrently.
You should consider the implications of any changes or additions you propose to the model, from the point of view of their effect on the QoS characteristics of the final application.
The intent here is for the students to introduce a transaction model for
the application, to ensure proper operation in concurrent scenarios. There
would be a number of possibilities, though, as far as what kind of transaction model to introduce:
one transaction per web interaction (one request/response)
one transaction per web converstation (many request/response)
This will lead to a discussion of extended persistent contexts in JPA,
and whether/when to use them.
one transaction per method call to a service facade (once the student
introduces them in Task 1).
It would also be important to consider the consequences of pessimistic
(EJB2) vs optimistic (EJB3) locking, or the consequences of application-level
caching (to emulate optimistic locking at application level).
Lab 3-9
Exercise 2: Alternatives and Their Trade-offs
Exercise 2
Lab 3
Alternatives and Their Trade-offs
In Exercise 1 we asked you to introduce a transaction model into our model

for the Auction system, to address the concerns associated with the execution of concurrent requests by multiple clients.
There are a number of ways to do so. You will have identified, and worked
out in some detail, one way to address these concerns in your solution to
Exercise 1. However, as an architect, you would want to be familiar with a
variety of approaches, and the consequences associated with each one.
1. Pool your solution to Exercise 1 with those of your fellow students.
2. For each of the solutions identified, discuss what the trade-offs associated with that solution are.
If everyone in the group turns out to have chosen the same

strategy, as an answer to Exercise 1, consider as a group what
other alternatives there could have been.
The course will supply a number of alternatives to discuss, to complement

those the students will have described. The kinds of things we are hoping
to bring up in discussion here include:
write-write conflict vs. read-read non-conflict to motivate read-only
vs update txns
optimistic (EJB3) vs pessimistic locking
optimistic application-level implementation of optimistic locking
Lab 3
Exercise 3: Fine-Tuning Distributed Interactions
Figure 3.5: Dual server deployment diagram for the findAuction use case.
Exercise 3
Fine-Tuning Distributed Interactions
Another decision that architects need to consider is whether to deploy systems onto a single server, or to partition them so as to deploy over a cluster
of servers. We discussed some of the trade-offs involved in this choice during Lab 2; we return to this choice now, to examine how we could modify
our application-level models to best advantage, given that we are going to
choose a distributed deployment. We will examine the findAuction use
case, in particular - assuming that our system will be deployed distributed
over two JavaEE servers, as ilustrated in Figure 3.5.
Lab 3-11
Lab 3
Preparation
You may use the model for the Auction system you designed yourself in
Lab 1, instead of the one we propose here if your model has equivalent
detail on the machinery necessary to support the findAuction use case.
The UML models for the findAuction use case can be found
as a MagicDraw project in your home directory, under
resources/UML/findAuctionWAE.mdzip.
Task 1
Distributed Overhead
Identify the sources of distributed overhead in the original model for the
findAuction use case, and discuss what the likely impact of each will be
on the QoS characteristics of a prototype for the Auction system, if it were
implemented according to that original model.
The model for the Auction system that we provide students with is designed with fine-grained interactions from the web tier directly against persistent domain objects in the business tier. Possible consequences of this:
additional network overhead due to the frequency of calls across the
network
additional overhead due to increased number of transactions required
to access persistend domain objects directly from the web tier (using
EJB2 entities)
it is possible that the introduction of distributed transactions in this
model will lead to additional overhead.
Task 2
Improving the Model
1. Modify the original model for the Auction system to address the concerns outlined in Task 1.
Lab 3
2. Explain the trade-offs involved in each of the modifications to the

model introduced in step 1. Remember that any change is likely to
involve advantages and disadvantages.
Students should realize that introducing Facade and Transfer Object patterns will reduce network overhead for remote interactions.
Students may also choose to use EJB3 entities, which would lead to a discussion of
lightweight vs. heavyweight Business Object based persistence implementations
managed vs detached entities - which could be delayed til Lab 6
overhead associated with using each of the two
maintanability considerations due to complexity of EJB3 entity lifecycle
when to call persist vs. merge
how/when/what to cascade
incomplete detached entities
Such a discussion may need to be delayed to Lab 6 (Business Tier).

Lab 3-13
Lab 3
Lab 4
Developing an Architecture for

the Client Tier
Objectives
Compare different options for developing and deploying a Java client
to access Enterprise JavaBean (EJB) applications

Lab 4-1
Exercise 1: Improving the User Experience
Exercise 1
Lab 4
Improving the User Experience
The Auction system supports the ability for users to select a list of auctions according to criteria specified by the user. This ability can be used,
for instance, to allow the user to select a list of auctions of interest, then
select a particular auction, then place a bit on that auction. Lab 3 presented
some of the UML diagrams that describe the part of the application model
responsible for this use case.
Let us consider a particular scenario in a little more detail, as illustrated in
Figure 4.1.
Our client has requested that we enhance the user experience in our Auction system. The suggestions that our client would like us to implement
include:
make the user interface more interactive. As currently implemented,
the user can request that the system find auctions that match criteria
the user specified - but the list of auctions found is static. Its been
suggested that it would be better if this list was interactive:
when new auctions are added to the system, and those new auctions match the criteria specified by a user currenly examining
the corresponding list of auctions, the list should automatically
update to include the new auctions
when information (such as the current high bid price) displayed
for an auction included in the result of a search is changed by
some other user (by placing a higher bid on that auction, for
instance), the list of auctions should automatically update to
present the new high bid price for the auction that changed.
This can be achieved currently, but only by asking the system to repeat the current search - which is unacceptably slow, and very userunfriendly.
the system seems to take too long, between the time the user requests
that a search be performed or updated, and the time the screen is
updated; or between the time the user requests to scroll to the next
page in the resulting list, and the time the screen is updated.
Lab 4
Figure 4.1: Sample findAuction interaction with repeated queries to narrow down result.

Lab 4-3
Lab 4
changes to address these concerns ought not compromise the applications ability to run on any platform currently supported.
Task 1
Strategies
Outline potential strategies, both conceptual and in terms of technology

choices, that could be used to address these requirements. For each strategy
listed, outline the way in which that choice could be used to address the
concerns listed above.
Among the application-level choices the student could list here:
server-push vs. client-pull
client caching
async ahead-of-time query
Among the technologies that could be introduced:
AJAX
Rich clients using Java with JWS, VB/.NET, JavaFX, AIR/Flash/Flex
Task 2
UML Model
Outline how our model for the Auction system would evolve to incorporate
some of the choices you listed, and how these changes would allow us to
address the concerns listed above.
In (1), we expect the student to list generally how the strategies or technogies could help. In (2), we expect the students to enumerate how the specific model for the Auction system would change to incorporate these choices,
and so address the concerns enumerated in the lab.
Ideally, different groups would sketch solutions based on different technologies. In practice, we may need to prepare ahead of time a solution
based on each of the candidate technologies (JWS Swing/SWT, AJAX, Flash/Flex).
Lab 4
Exercise 2
Trade-offs


strategy, as an answer to Exercise 1, consider as a group what
other alternatives there could have been.
The course will supply a number of alternatives to discuss, to complement

those the students will have described.

Lab 4-5
Lab 4
Lab 5

the Web Tier
Objetives
Get familiar with the Web Presentation tier design guidelines
Design the architecture for a web-based application that relies on simple MVC frameworks, such as Struts
Design the architecture for a web-based application that uses on advanced frameworks, such as AJAX, or JSF
Understand the trade-offs associated with different architectures for
the web tier of an enterprise application.

Lab 5-1
Lab 5
Our preferred designs for the Auction system have revolved around a webbased front-end to the application, for portability. On such designs, all the
client requires is a web-browser to render the HTML-based UI to the application - though we may want to incorporate some HTML-related client- or
server-side technologies to our design (such as AJAX) to improve its QoS
characteristics. We already introduced this idea in our exercises for Lab 4.
A consequence of this approach is that most of the logic responsible for the
front-end to the application actually resides on the server side - in the web
container that is responsible for generating the HTML-based UI on-the-fly,
on a per-client, or per-session basis.
We sketched a possible description for the findAuction interaction back in
Figure 4.1. We also propose a possible description for the placeBid interaction in Figure 5.1. However, you will notice that the actual applicationlevel structure of the web tier for our application is not really specified we only mention web components responsible for generating HTML at a
rather high level. This lab will ask you to design a more detailed structure
for the web tier for our Auction system.
We have been given certain constraints, as far as the characteristics of our
web-based application is concerned:
portability
Our application must be deployable to the widest variery of client
platforms.
maintainability
Changes to the flow through the user interface (in terms of the
order in which pages must be displayed, or the ability to introduce additional pages into the flow) must require minimal effort.
Duplication of effort should be avoided - for example, when
multiple pages incorporate the same fragments, we should not
have to recode this more than once.
Lab 5
Figure 5.1: Sample placeBid interaction

Lab 5-3
Exercise 1: Web Tier for simple HTML-based UI
Exercise 1
Lab 5
Web Tier for simple HTML-based UI
Build UML diagrams that describe the application-level structure of the

web tier for the Auction system. Assume that the application will only
provide interaction with the user purely in terms of simple HTML pages,
to maximize portability.
You will find a description for this simple UI interaction in the
introduction to Lab 4. The next exercise will ask you to consider
how to incorporate the technologies you idenfied in Lab 4 to
make the UI more user-friendly.
We expect the students to produce UML diagrams for an MVC-based web

application based on the Service-to-Worker pattern.
Lab 5
Exercise 2: Web tier for sophisticated clients
Exercise 2
Web tier for sophisticated clients
Modify your UML diagrams for the web tier from Exercise 1 to support
the more sophisticated types of interaction discussed in Lab 4 Exercise 1.
Your solution need not incorporate all of the strategies identified then - but
you should discuss what benefits result from those you do incorporate into
your design.
Students might produce UML diagrams for web tier that include XML+XSLT,JSF:
AJAX view fragments
rewrite model in terms of composite views with AJAX view fragments as components
use JSF renderers to present AJAX view fragments

Lab 5-5
Exercise 3: Frameworks
Exercise 3
Lab 5
Frameworks
1. Identify how the strategies you incorporated into your design address our requirements of portability, maintainability, and improved
user experience.
2. Enumerate other ways in which you could improve your model, even
if they go beyond the capabilities of the technologies you chose. We
would like to identify the characteristics of an ideal web-tier framework, by enumerating what we would have liked to have to help us
with our design, and then searching for frameworks that might include all of them.
Generalize features identified in Exercise 2. Students should identify these
characteristics of an ideal framework:
composite views with reusable (atomic and composite) components
(templates/tiles/...)
MVC, Front Controller (Struts, JSF), Filters (separation of concerns)
view components that are presentation-independent (JSF components)
technology-agnostic components and helpers
tool vendor support
state management
Lab 5
Exercise 4
Trade-offs
Instructor-led.

strategy, as an answer to Exercise Exercise 2, consider as a
group what other alternatives there ould have been.
s to discuss, to complement
those the students will have described.

Lab 5-7
Lab 5
Lab 6

the Business Tier
Objectives
Design the architecture of the business tier to an enterprise application using JavaEE technologies
Understand the trade-offs relevant when selecting the appropriate
JavaEE technologies to use in an application
Get familiar with the Business tier design guidelines.

Lab 6-1
Exercise 1: Designing the Business Tier
Exercise 1
Lab 6
Designing the Business Tier
We have discussed some of the services offered by our Auction application

in earlier labs, from the point of view of the clients interaction with the
system. In this lab, we switch perspectives, to consider how to design the
business tier of our application to support these same services.
We described earlier the basic functionality that the Auction system must
provide for two use cases:
the placeBid use case, introduced in Lab 3 Exercise 1, and described
by the diagrams in Figure 3.1, Figure 3.3, and Figure 5.1
the findAuction use case, introduced in Lab 4 Exercise 1, and described by the UML diagram in Figure 4.1.
When placing bids on an auction, the Auction system is required to allow
the bidder to see the current state of the auction they are bidding on - the
refresh action in Figure3.3 represents this ability, described as a bidderinitiated request of the system. We also mentioned earlier that the UI would
be more user-friendly if this screen update were to occur automatically every time the auction state changes, rather than on demand.
When searching for bids, the same improvement could be introduced: once
the user has performed a search, the search results ought to be presented
to the user in such a way that changes that would affect the search result
ought to update the display automatically, without requiring that the user
re-issue the same request again. Thus, for example, an new auction added
to the system that matches the criteria for an earlier search still displayed
ought to be incorporated into that display; an auction that has its high bid
price increase ought to update any search result displays in which that auction is displayed, so that the new high bid value is displayed.
We could also introduce another use case: in addition to allowing the user
to place bids on a single auction, the system ought to allow bidders to select
a number of auctions that they are interested in. These auctions ought to be
displayed together, in such a way that the user would be allowed to place
bids on any of the auctions in the list, and have the display track the current
high bid price for all the auctions in the list, and the current total amount
Lab 6
the bidder is bidding aggregating the bids for all auctions in that list. When
the high bid prices for any of the auctions change, the system would update
the high bid prices displayed for those auctions, and any matching changes
to the aggregate amount the bidder is bidding. This would help bidders
who are interested in bidding on a number of items in parallel, but who
have a budget to allocate for the set of auctions they are interested in.
We need an opportunity for introducing an interceptor into the business
model.
One suggestion: maybe one would like to find out how fast users react
to new auctions that fulfill their criteria. Maybe an interceptor that saves
the timestamps of the bids would be useful (comparing them against the
timestamp of the created auction).
We should consider the following non-functional requirements in our design:
maintainability
correctness
scalability
performance
Task 1
Candidate JavaEE Technologies
Enumerate JavaEE technologies that we could leverage to build the business tier for our auction system. Indicate how each of the technologies
selected could help us achieve any of the functional or non-functional requirements listed.
Students should find uses for SFSB, SLSB, MDB, and Entity Classes:
SFSB: find auction facade, place bids in parallel facade
SLSB: simple place bid facade
Lab 6-3
Lab 6
MDB: place bid use case includes requirement that a new high bid
appears on the display of every other user present who is bidding on
that same auction: high bidder places notice on topic that every other
bidder reads.
entity: Auction, Bid, User
JMS/MDB as means to avoid waiting for lengthy processing will be
mentioned in Ex7 re: expensive calls to legacy systems
(need example using an interceptor).
The instructor will complete this list, if students miss any of these entries.
Task 2
UML Models
Build a UML model for the business tier of the Auction system that describes what application-level structure you could use to support the functional and non-functional requirements listed above. Indicate where you
would introduce which JavaEE technologies to support your OO model.
You may want to build a UML class diagram to describe the logical structure of your solution, plus at least one sequence diagram to indicate how
this structure would be used to achieve one of the uses cases listed above.
Lab 6
Exercise 2
Trade-offs
For each of the choices made in Exercise 1 as to how you would address
any of requirements given in the your OO model for the Auction system,
consider whether there would have been another alternative for addressing the same requirement - whether it be by choosing to build applicationlevel functionality or by delegating it to the underlying JavaEE platform,
or in terms of the choice of JavaEE technology provided by the underlying
platform that you chose to leverage your application-level structure with.
When you identify alternative means to address the same requirement, discuss the trade-offs associated with each of the alternatives you identified.
The instructor will help students complete a table of pros/cons per technology that will include at least these:
code complexity (EJB2 vs. EJB3)
separation of concerns and cross-cutting aspects (AOP/interceptors)
SFSB vs. HttpSession
SFSB vs. SLSB
SB vs. POJO
EJB2 vs. EJB3/JPA entities
heavy vs. light framework
done by framework vs. do-it-yourself
EJB2.x, albeit a heavy framework (with transaction and security
interception that is not needed), had a simpler in-memory programming model (in-memory integrity was guarantied by the
framework).
entity classes vs. JDBC
async notification via JMS vs. client query for high bid on refresh
(find auction use case: bad using entity classes, good using VLH see
Lab 07 Exercise 4)

Lab 6-5
Exercise 3: Fine-Tuning The Model (optional)
Exercise 3
Lab 6
Fine-Tuning The Model (optional)
This exercise is optional. It may also need to be instructor-led, since it introduces technologies, and features of those technologies, that may not be
familiar to the students, and may not have been discussed in the corresponding lecture.
Task 1
Alternative Technologies
We narrowed our search for alternative technologies in Exercise 2 to JavaEE

technologies but these may not the only platform choices available. Consider now whether non-JavaEE technologies might be advantageous, to address some of the requirements on the business tier of the Auction system.
For any non-JavaEE technology that you identify, discuss the trade-offs associated with introducing that technology into the design of your business
tier.
Students should produce a table of pros/cons for each new alternative:
Spring
dependency injection for POJOs, non-invasive, complex AOP
Hibernate
lightweight persistent domain model
.Net
Microsoft alternative
Task 2
Advanced Features of Platform Technologies
When we described the findAuction use case, we mentioned we needed

to be able to perform a series of queries to narrow down the collection of
auctions that would be selected. We also mentioned that we were given
non-functional requirements that call for us to minimize response time, or
overhead, when perfoming each of the queries in that series.
Lab 6
1. Draw UML diagrams that describe the application-level structure and

the technoloogies that you could build that structure with, in order to
support the ability to perform incremental queries over auctions in
the Auction system.
2. Pool your solution with those of your fellow students.
3. Discusss the overhead associated with each solution.
Ideally, some of the students in class will hit on the notion of using an EJB3
extended context to perform the series of queries in the same context, even
spread over time, or across a number of web pages (or both).
The extended context ought to allow the application server to cache the
entities actually retrieved in earlier queries, so that their repeated retrieval
across a number of queries would not incur additional overhead for each
query.
Students may not be familiar with this feature of EJB3, and it may not be
discussed in enough detail in the lecture - so instructors should be prepared
to present this alternative themselves. The diagram needed to illustrated
this could be based on that for Lab 3 Exercise 1

Lab 6-7
Lab 6
Lab 7

the Integration and Resource
Tiers
Objectives
, Design an architecture for the integration tier of an enterprise application using the appropriate JavaEE technologies
Design a JavaEE application as a service, so that others will be able to
integrate with it
Understand the trade-offs involved in selecting the appropriate JavaEE
technologies necessary for integration
Get familiar with JMS and BPEL based integration solutions

Lab 7-1
Exercise 1: Designing the Integration Tier
Exercise 1
Lab 7
Designing the Integration Tier
Once a bidder wins an auction, our Auction system must also support the
ability for the bidder to pay for the auction, and for the payment to find its
way to the seller. We mentioned in an earlier lab that we could store default
credit card information for each bidder, as part of their initial configuration
- but we would need much more than that.
However, chances are we would not want to be responsible for the actual processing of credit card payment requests, or the actual transfers of
funds to the sellers (credit card, or bank) accounts. Traditionally, online
e-commerce web applications rely on third-party credit card processing or
bank clearinghouses to actually take care of financial operations. We will
need to interact with these third party clearinghouses over the Internet and it may well be that these clearinghouses will not be JavaEE-based services.
There are a number of non-functional requirements to keep in mind, as we
consider how to build this part of our Auction system:
portability
Our system needs to be able to interact with third-party clearinghouses, regardless of their protocol or implementation.
maintainability
The changes that would be required to switch our system from one
third-party clearinghouse to another should be minimal.
security
Communications between ourselves and the third-party clearinghouse may travel over public networks - but we cannot allow
eavesdropping, or for our communications to be tampered with.
non-repudiation
authorization
performance
The interaction with the third-party clearinghouse may be expensive
or slow, but out Auction system must never block clients for significant lengths of time. Also, it may be that the clearinghouse would
Lab 7
Exercise 1: Designing the Integration Tier
only accept financial transactions in batches but we cannot ask our

users to wait until other transactions are ready so as to issue them all
in batch form to the third-party clearinghouse.
correctness
Our system ought to perform its own operations plus the clearinghousebased financial processing as a single operation - we should not mark
our auction as paid until and unless the clearinghouse processes the
payment successfully.
Task 1
Technologies Applicable
1. List javaEE integration technologies that we could leverage to build

this part of the Auction application, along with the way in which you
would use each one to achieve any of the requirements listed above.
2. Discuss trade-offs associated with each of the choices you identified.
We expect students to come up with a list that include these technologies:
asynchronous: JMS (intranet) vs. JAX-WS (Dispatcher API)
synchronous: JAX-WS, CORBA
txn: CORBA, JAX-WS + WS-AT, JCA
non-txn: Web Services
Task 2
UML Diagram
Draw UML diagrams that describe how you would use some of the technologies identified in Task 1 to build the application-level structure needed
to support interaction with the third-party clearinghouse consistent to the
requirements listed above.

Lab 7-3
Exercise 2: Integration using Web Services (optional)
Exercise 2
Lab 7
Integration using Web Services (optional)
We could get lucky, and the third-party clearinghouse that we will rely
on to process payments could be defined as a service implemented using
Web Services technology. Under these conditions, we could implement the
Auction system client side interaction using the Web Services technology
built into the JavaEE specification, too.
Draw UML diagrams that describe how we could use Web Services technology to capture an interaction between the Auction system and the third
party clearinghouse that will allow the Auction system to initiate a request
to the clearinghouse to process a payment without requiring that the Auction system block waiting for a response from the clearinghouse - but that
will make said response available to the Auction system as soon as it is
available. Look for the most maintainable means to achieve this interaction.
Lab 7
Exercise 3: The Auction system as a Service
Exercise 3
The Auction system as a Service
So far, we have assumed our Auction system would be an interactive web

application to be used by individual buyers and sellers over the Internet.
However, it might be attractive for us to enter into partnership with other
retail sales outlets.
We could be approached by a large retailer (such as Buy More, Inc) to
allow them to offer auction services on their web site by relying on our
Auction system to provide them with back-end support: our Auction system would supply their system with the business knowledge necessary to
run auctions; they would provide a front-end to handle auctions in such a
way that the user interface integrates with the rest of their retail web site.
Task 1
Defining Service APIs
1. Define a service API that defines the business knowledge that we will
offer to the retail web application to support auctions.
2. List JavaEE technologies that could be leveraged to build the service
API to our Auction system, and sketch the way in which said API
would be implemented using each technology.
3. List trade-offs associated with each choice of technology.
Task 2
UML Diagrams
Draw UML diagrams that illustrate how the retail web application interacts
with our Auction system through the service API you defined, implemnted
using your choice of JavaEE technologies from above.

Lab 7-5
Exercise 4: Orchestrating Multiple Services
Exercise 4
Orchestrating Multiple Services
Lab 7
Lab 8
Developing a Security
Architecture
Objectives
Identify security risks associated with enterprise applications, and
the alternative strategies that are available to address those risks
Understand the trade-offs involved in selecting the appropriate strategies to address security risks in an enterprise application

Lab 8-1
Exercise 1: Addressing Security Risks
Exercise 1
Lab 8
Addressing Security Risks
All web-based, Internet-based applications have to deal with security risks

- since the application is deployed over the Internet, the server side does
not really have control over the actual user interacting with the system, nor
the application actually running on the client, nor over the network that
communications will travel on, between the client and server sides.
In this lab, we will consider
what security risks an architect ought to be familiar with,
what parts of the model for our Auction system are vulnerable to
these risks, and
what strategies we could employ to address these risks.
Task 1
Security Risks
Enumerate potential security risks for Internet-based applications. For each

one:
provide a one-line definition, and
list possible approaches to address it.
Students should identify at least these:
addAuction - SQL injection
placeBid non-repudiation,
admin authentication/authorization, id theft/phishing, DOS attacks
Lab 8
Task 2
Exercise 1: Addressing Security Risks
Risks in the Auction system
Back in Lab 1 Exercise 1, you sketched a number of UML diagrams to describe a number of use cases for the Auction system.
Annotate these UML diagrams with the security risks that are applicable
to each use case, indicating where in the interaction the security risk could
apply. Also indicate which strategy you would introduce to address each
risk, modifying the UML diagrams when needed.
Task 3
Trade-offs
Instructor-led.
1. Pool your solution with those of your fellow students.
2. Construct a table of pros/cons for each solution outlined to each of
the security risks.
The answer should include tech-based vs. business-based solutions. Students should also consider non-JavaEE choices: firewalls, packet filters.

Lab 8-3

Sl425 SW

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Sl425 SW

Enviado por

Direitos autorais:

Formatos disponíveis

Architecting and Designing

Sun Microsystems, Inc

Workbook Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preface-1

Introducing Fundamental Architectural Concepts

Designing an Architectural Model . . . . . . . . . . Lab 1-2

Task 1 Creating UML Logical Diagrams . . . . . . . . . . . . Lab 1-7

Multi-tier, Distributed Application . . . . . . . . . Lab 1-11

Task 1 Decoupling the Model . . . . . . . . . . . . . . . . . . Lab 1-11

Choosing Alternative Technologies . . . . . . . . . Lab 1-15

Understanding System Qualities

Deployment Strategies for Scalability . . . . . . . . Lab 2-2

Task 1 Strategies to Address Scalability Concerns . . . . . . Lab 2-2

Capacity Planning . . . . . . . . . . . . . . . . . . Lab 2-4

Deployment Strategies for Availability . . . . . . . Lab 2-5

Task 1 Strategies to Address Availability Concerns . . . . . . Lab 2-5

Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . Lab 2-7

Task 1 Trade-offs Associated with Strategies for Scalability . Lab 2-7

Examining System Architecture Development Heuristics and Guidelines

The placeBid Use Case . . . . . . . . . . . . . . . . Lab 3-2

Task 1 Streamline Execution . . . . . . . . . . . . . . . . . . . Lab 3-7

Alternatives and Their Trade-offs . . . . . . . . . . Lab 3-10

Fine-Tuning Distributed Interactions . . . . . . . . Lab 3-11

Task 1 Distributed Overhead . . . . . . . . . . . . . . . . . . Lab 3-12

Developing an Architecture for the Client Tier

Improving the User Experience . . . . . . . . . . . Lab 4-2

Task 1 Strategies . . . . . . . . . . . . . . . . . . . . . . . . . Lab 4-4

Task 2 UML Model . . . . . . . . . . . . . . . . . . . . . . . . Lab 4-4

Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . Lab 4-5

Developing an Architecture for the Web Tier

Web Tier for simple HTML-based UI . . . . . . . . Lab 5-4

Web tier for sophisticated clients

Frameworks . . . . . . . . . . . . . . . . . . . . . . Lab 5-6

Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . Lab 5-7

Developing an Architecture for the Business Tier

Designing the Business Tier . . . . . . . . . . . . . Lab 6-2

Task 1 Candidate JavaEE Technologies . . . . . . . . . . . . . Lab 6-3

Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . Lab 6-5

Fine-Tuning The Model (optional) . . . . . . . . . . Lab 6-6

Task 1 Alternative Technologies . . . . . . . . . . . . . . . . Lab 6-6

Developing an Architecture for the Integration and Resource

Designing the Integration Tier . . . . . . . . . . . . Lab 7-2

Task 1 Technologies Applicable . . . . . . . . . . . . . . . . . Lab 7-3

Integration using Web Services (optional) . . . . . Lab 7-4

The Auction system as a Service . . . . . . . . . . . Lab 7-5

Task 1 Defining Service APIs . . . . . . . . . . . . . . . . . . Lab 7-5

Orchestrating Multiple Services . . . . . . . . . . . Lab 7-6

Developing a Security Architecture

Addressing Security Risks . . . . . . . . . . . . . . Lab 8-2

Task 1 Security Risks . . . . . . . . . . . . . . . . . . . . . . . Lab 8-2

Architecting and Designing JavaEE Application

Self-check - Identifies self-check activities, such as matching

Courier is also used to indicate programming constructs, such as class names,

Architecting and Designing JavaEE Application

Exercise 1: Designing an Architectural Model

Designing an Architectural Model

Figure 1.1: Use Cases for Auction System

Exercise 1: Designing an Architectural Model

Exercise 1: Designing an Architectural Model

placeBid Bidders are allowed to bid on auctions. Given an auction, the

Exercise 1: Designing an Architectural Model

Exercise 1: Designing an Architectural Model

Figure 1.2: Domain Types for the Auction System

Exercise 1: Designing an Architectural Model