Architecting and Designing JavaEE Applications SL-425-EE5

Student Workbook with Instructor Notes

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

2

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 Lab 2-1
3

Understanding System Qualities
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

CONTENTS

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

Exercise 1

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

Task 1 Strategies to Address Availability Concerns . . . . . . Lab 2-5 Task 2 UML Diagrams . . . . . . . . . . . . . . . . . . . . . . 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 Exercise 3 Alternatives and Their Trade-offs . . . . . . . . . . Lab 3-10 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 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

CONTENTS

CONTENTS

Task 2 UML Model . . . . . . . . . . . . . . . . . . . . . . . . Lab 4-4 Exercise 2 5 Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . Lab 4-5 Lab 5-1

Developing an Architecture for the Web Tier Exercise 1 Exercise 2 Exercise 3 Exercise 4

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

Frameworks . . . . . . . . . . . . . . . . . . . . . . Lab 5-6 Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . Lab 5-7 Lab 6-1

6

Developing an Architecture for the Business Tier Exercise 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 Exercise 3 Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . Lab 6-5 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 Lab 7-1 Exercise 1 Designing the Integration Tier . . . . . . . . . . . . Lab 7-2

Task 1 Technologies Applicable . . . . . . . . . . . . . . . . . Lab 7-3 Task 2 UML Diagram . . . . . . . . . . . . . . . . . . . . . . . Lab 7-3 Exercise 2 Exercise 3 Integration using Web Services (optional) . . . . . Lab 7-4 The Auction system as a Service . . . . . . . . . . . Lab 7-5
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

5

CONTENTS

CONTENTS

Task 1 Defining Service APIs . . . . . . . . . . . . . . . . . . Lab 7-5 Task 2 UML Diagrams . . . . . . . . . . . . . . . . . . . . . . Lab 7-5 Exercise 4 8 Orchestrating Multiple Services . . . . . . . . . . . Lab 7-6 Lab 8-1

Developing a Security Architecture Exercise 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

6

Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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.
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 1-1

Exercise 1: Designing an Architectural Model

Lab 1

Exercise 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

Exercise 1: Designing an Architectural Model

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.
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 1-3

Exercise 1: Designing an Architectural Model

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-4 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 1

Exercise 1: Designing an Architectural Model

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 user’s 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:
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 1-5

Exercise 1: Designing an Architectural Model

Lab 1

Figure 1.2: Domain Types for the Auction System Portability It’s 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 application’s 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-6 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 1

Exercise 1: Designing an Architectural Model

The intent is to have students think about the consequences of introducing transactions into the design, re: locking when placing concurrent bids on the same auction, or when updating current bid prices as new bids are placed on the same transaction, or when looking up auctions. It’s been suggested that students should treat with scalability and performace together, on this first attempt to address these concerns. Although scalability and performance are different non-functional requirements, there is a relationship between them: bad multi-user scalability inevitably leads to bad single-user performance. 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
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 1-7

Exercise 1: Designing an Architectural Model

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-8 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 1

Exercise 1: Designing an Architectural Model

– 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)

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 1-9

Exercise 1: Designing an Architectural Model

Lab 1

Task 4

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-10 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 1

Exercise 2: Multi-tier, Distributed Application

Exercise 2
Preparation

Multi-tier, Distributed Application

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)
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 1-11

Exercise 2: Multi-tier, Distributed Application

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-12 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 1

Exercise 2: Multi-tier, Distributed Application

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
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 1-13

Exercise 2: Multi-tier, Distributed Application

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-14 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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.
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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 1-16 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 2

Understanding System Qualities
Objectives
Upon completion of this lab, you should be able to: • 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

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 2-1

Exercise 1: Deployment Strategies for Scalability

Lab 2

Exercise 1

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-2 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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.

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 2-3

Exercise 2: Capacity Planning

Lab 2

Exercise 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-4 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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.
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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-6 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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 application’s 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:
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 2-7

Exercise 4: Trade-offs

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 application’s 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 2-8 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 3

Examining System Architecture Development Heuristics and Guidelines
Objectives
Upon completion of this lab, you should be able to: • Understand the impact of transactions on application performance • Understand the impact of distributed operations on application performance

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 3-1

Exercise 1: The placeBid Use Case

Lab 3

Exercise 1

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 client’s 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-2 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 3

Exercise 1: The placeBid Use Case

Figure 3.1: Flow for placeBid Use Case

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 3-3

Exercise 1: The placeBid Use Case

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.
convenience, we have left out of the diagram any getters and setters for simple attributes, in Figure 3.2. Lab 3-4 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.
1 For

Lab 3

Exercise 1: The placeBid Use Case

Figure 3.2: Domain classes for placeBid Use Case

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 3-5

Exercise 1: The placeBid Use Case

Lab 3

Figure 3.3: Flow for placeBid Use Case

Lab 3-6 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 3

Exercise 1: The placeBid Use Case

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 de¸ sign.
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 3-7

Exercise 1: The placeBid Use Case

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-8 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 3

Exercise 1: The placeBid Use Case

• 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).
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 3-9

Exercise 2: Alternatives and Their Trade-offs

Lab 3

Exercise 2

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-10 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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.
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 3-11

Exercise 3: Fine-Tuning Distributed Interactions

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-12 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 3

Exercise 3: Fine-Tuning Distributed Interactions

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 pat¸ terns 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).

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 3-13

Exercise 3: Fine-Tuning Distributed Interactions

Lab 3

Lab 3-14 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 4

Developing an Architecture for the Client Tier
Objectives
Upon completion of this lab, you should be able to: • Compare different options for developing and deploying a Java client to access Enterprise JavaBean (EJB) applications

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 4-1

Exercise 1: Improving the User Experience

Lab 4

Exercise 1

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. It’s 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-2 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 4

Exercise 1: Improving the User Experience

Figure 4.1: Sample findAuction interaction with repeated queries to narrow down result.

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 4-3

Exercise 1: Improving the User Experience

Lab 4

• changes to address these concerns ought not compromise the application’s 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-4 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 4

Exercise 2: Trade-offs

Exercise 2

Trade-offs

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.

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 4-5

Exercise 2: Trade-offs

Lab 4

Lab 4-6 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 5

Developing an Architecture for the Web Tier
Objetives
Upon completion of this lab, you should be able to: • 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.

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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-2 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 5

Figure 5.1: Sample placeBid interaction
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 5-3

Exercise 1: Web Tier for simple HTML-based UI

Lab 5

Exercise 1

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-4 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 5-5

Exercise 3: Frameworks

Lab 5

Exercise 3

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-6 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 5

Exercise 4: Trade-offs

Exercise 4
Instructor-led.

Trade-offs

1. Pool your solution to Exercise 2 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 Exercise 2, consider as a group what other alternatives there ould have been.

The course will supply a number of alternatives to discuss, to complement those the students will have described.

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 5-7

Exercise 4: Trade-offs

Lab 5

Lab 5-8 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 6

Developing an Architecture for the Business Tier
Objectives
Upon completion of this lab, you should be able to: • 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.

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 6-1

Exercise 1: Designing the Business Tier

Lab 6

Exercise 1

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 client’s 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-2 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 6

Exercise 1: Designing the Business Tier

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 ¸
Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 6-3

Exercise 1: Designing the Business Tier

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-4 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 6

Exercise 2: Trade-offs

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)

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 6-5

Exercise 3: Fine-Tuning The Model (optional)

Lab 6

Exercise 3

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-6 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 6

Exercise 3: Fine-Tuning The Model (optional)

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

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 6-7

Exercise 3: Fine-Tuning The Model (optional)

Lab 6

Lab 6-8 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 7

Developing an Architecture for the Integration and Resource Tiers
Objectives
Upon completion of this lab, you should be able to: • , 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

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 7-1

Exercise 1: Designing the Integration Tier

Lab 7

Exercise 1

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-2 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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.

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 7-3

Exercise 2: Integration using Web Services (optional)

Lab 7

Exercise 2

Integration using Web Services (optional)

This exercise is optional, since the lecture will not have covered the technology in question in enough detail to allow the students to answer this question purely from the lecture contents. However, it is important to know that the the JAX-WS Dispatch API is available, and how to take advantage of it. The instructor may want to turn this into an instructor-led demonstration/discussion. 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. We expect the students will draw a UML sequence diagram that describes how to implement this case using the JAX-WS Dispatcher API.

Lab 7-4 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

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.

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 7-5

Exercise 4: Orchestrating Multiple Services

Lab 7

Exercise 4

Orchestrating Multiple Services

Lab 7-6 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 8

Developing a Security Architecture
Objectives
Upon completion of this lab, you should be able to: • 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

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 8-1

Exercise 1: Addressing Security Risks

Lab 8

Exercise 1

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-2 Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 8

Exercise 1: Addressing Security Risks

Task 2

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.

Architecting and Designing JavaEE Application
Copyright 2007 Sun Microsystems, Inc. All rights reserved, Sun Services.

Lab 8-3

Sign up to vote on this title
UsefulNot useful