Sun Educational Services - SL-425 - Architect Ing and Designing J2EE Applications

Sun Educational Services

Architecting and Designing J2EE Applications August 2000

Architecting and Designing J2EEApplications

SL-425


Architecting and Designing J2EE Applications 2 of 2Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000 Revision A

Copyright 2000 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, California 94303, 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 maybe 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.

Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California.

Sun, Sun Microsystems, the Sun Logo, Enterprise JavaBeans, Java, J2EE, EJB, JavaServer Pages. JSP, J2EE Blue Prints , JDBC, JavaMail, Java Naming and Directory Interface, JNDIl, JVM,Java API for XML Parsing, Java Pet Store and Write Once, Run Anywhere, are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.

The OPEN LOOK and Sun Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researchingand developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, whichlicense also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements.

U.S. Government approval required when exporting the product.

RESTRICTED RIGHTS: Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-14(g) (2)(6/87) and FAR 52.227-19(6/87), or DFAR 252.227-7015(b)(6/95) and DFAR 227.7202-3(a).

DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS, AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTYOF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS AREHELD TO BE LEGALLY INVALID.



About This Course


Architecting and Designing J2EE Applications About This Course, v of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Course Goal

This course provides you with knowledge and skills to:

• Create architectures using Java™ 2 Platform,Enterprise Edition (J2EE™) best practices and designguidelines

• Use design patterns to create scalable, extensible,multi-tiered J2EE solutions

• Form a sound basis for further study in architectureand design


Architecting and Designing J2EE Applications About This Course, vi of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Course Overview

• Basic architectural principles

• J2EE technology and basic architectural principles

• J2EE Patterns

• Best practices and design guidelines

• J2EE technology’s applicability to the followingapplications:

▼ Business-to-Business (B2B)

▼ Enterprise Resource Planning (ERP)

▼ Workflow


Architecting and Designing J2EE Applications About This Course, vii of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services, August 2000, Revision A

Course Map

Architectural Principles

Architect andArchitecture

Principles ofArchitecture

Creating anArchitectureUsing J2EETechnology

Best Practices and Guidelines

J2EE BestPractices –Overview

J2EE BestPractices –Web Tier

J2EE BestPractices –

EJB Tier


EIS IntegrationTier


Services

Patterns

J2EEPatterns

Legacy Applications

Special Topics


Architecting and Designing J2EE Applications About This Course, viii of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Module-by-Module Overview

• Module 1 – Architect and Architecture

• Module 2 – Principles of Architecture

• Module 3 – Creating an Architecture Using J2EETechnology

• Module 4 – J2EE Best Practices – Overview

• Module 5 – J2EE Best Practices – Web Tier

• Module 6 – J2EE Best Practices – EJB Tier

• Module 7 – J2EE Best Practices – EIS Integration Tier


Architecting and Designing J2EE Applications About This Course, ix of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Module-by-Module Overview

• Module 8 – J2EE Best Practices – Services

• Module 9 – J2EE Patterns

• Module 10 – Special Topics


Architecting and Designing J2EE Applications About This Course, x of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Course Objectives

• Differentiate between architecture and design.

• Explain the architectural process.

• List and describe the capabilities and design goals of anarchitecture.

• List and define the trade-offs that result fromarchitectural decisions.

• Describe the effects of J2EE technology on thecapabilities and design goals.


Architecting and Designing J2EE Applications About This Course, xi of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Course Objectives

• Describe best practices and design guidelines fordeveloping multi-tier architectures based on J2EEtechnology.

• Describe the J2EE patterns and explain how they helpsolve key issues for enterprise applications.

• Explain the use of J2EE technology in the areas ofBusiness-to-Business (B2B), Enterprise ResourcePlanning (ERP), and Workflow applications.


Architecting and Designing J2EE Applications About This Course, xii of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Skills Gained by Module

Module

Skills Gained 1 2 3 4 5 6 7 8 9 10

Differentiate between architecture and design.

Explain the architectural process.

List and describe the capabilities and design goalsof an architecture.

List and describe the trade-offs that result fromarchitectural decisions.

Describe the effects of J2EE technology on thecapabilities and design goals.

Describe best practices and design guidelines fordeveloping multi-tier architectures based on J2EEtechnology.

Describe the J2EE patterns and explain how theyhelp solve key issues for an enterprise application.

Explain the applicability of J2EE technology in theareas of B2B, ERP, and Workflow.


Architecting and Designing J2EE Applications About This Course, xiii of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Guidelines for Module Pacing

Module Day 1 Day 2 Day 3 Day 4

"Architect and Architecture" A.M.

"Principles of Architecture" P.M.

"Creating an Architecture Using J2EETechnology"

A.M.

"J2EE Best Practices – Overview" P.M.

"J2EE Best Practices – Web Tier" P.M.

"J2EE Best Practices – EJB Tier" P.M.

"J2EE Best Practices – EIS Integration Tier" A.M.

"J2EE Best Practices – Services" A.M./P.M.

"J2EE Patterns" A.M.

"Special Topics" P.M.


Architecting and Designing J2EE Applications About This Course, xiv of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Topics Not Covered

• Object-oriented concepts

• Object-oriented design and analysis

• Unified Modeling Language (UML)

• Java™ programming language constructs

• Distributed computing

• In-depth study on the Java 2 Platform, EnterpriseEdition (J2EE™) technologies


Architecting and Designing J2EE Applications About This Course, xv of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

How Prepared Are You?

• Experience with the Java™ programming language

• Familiarity with component architecture concepts

• Familiarity with the Enterprise JavaBeans™architecture

• Familiarity with multi-tier architecture

• Familiarity with the J2EE framework

• Familiarity with relational or object databaseprogramming requirements

• Familiarity with transaction models


Architecting and Designing J2EE Applications About This Course, xvi of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Introductions

• Name

• Company affiliation

• Title, function, and job responsibility

• Object-oriented design and analysis

• Distributed computing experience

• Architecture and J2EE technology experience

• UML

• Reasons for enrolling in this course

• Expectations for this course


Architecting and Designing J2EE Applications About This Course, xvii of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

How to Use Course Materials

• Objectives

• Relevance

• Overhead image

• Lecture

• Exercise

• Check Your Progress

• Think Beyond


Architecting and Designing J2EE Applications About This Course, xviii of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

How to Use the Icons

Additional resources

Exercise objective


Architecting and Designing J2EE Applications About This Course, xix of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Typographical Conventions andSymbols

• Courier is used for the names of command, files, anddirectories, as well as on-screen computer output.

• Courier bold is used for characters and numbers thatyou type.

• Courier italic is used for variables and command-line placeholders that are replaced with a real name orvalue.

• Palatino italics is used for book titles, new words orterms, or words that are emphasized.


Architecting and Designing J2EE Applications About This Course, xx of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Java Programming language examples use the followingadditional conventions:

• Courier is used for the class names, methods, andkeywords.

• Methods are not followed by parentheses unless aformal or actual parameter list is shown.

• Line breaks occur where there are separations,conjunctions, or white space in the code.


Architecting and Designing J2EE Applications About This Course, xxi of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Common Abbreviations andAcronyms

• API – Application programming interface

• CORBA – Common Object Request Broker Architecture

• DB – Database

• DBMS – Database Management System

• EIS – Enterprise Information System

• EJB™ – Enterprise JavaBeans™

• ERP – Enterprise Resource Planning

• HTML – Hypertext Markup Language

• HTTP – Hypertext Transfer Protocol

• HTTPS – Hypertext Transfer Protocol over SSL

• IDL – Interface Definition Language


Architecting and Designing J2EE Applications About This Course, xxii of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A


• JAF – JavaBeans Activation Framework

• JAR – Java Archive

• J2EE – Java 2 Platform, Enterprise Edition

• JMS – Java™ Message Service

• JNDI – Java Naming and Directory Interface™

• JSP – JavaServer Pages™

• JTA – Java Transaction API

• JTS – Java Transaction Service

• MTBF – Mean Time Between Failures

• OMG – Object Management Group

• ORB – Object Request Broker


Architecting and Designing J2EE Applications About This Course, xxiii of xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A


• OS – Operating System

• RMI-IIOP – Remote Method Invocation-Internet Inter-ORB Protocol

• SSL – Secure Socket Layer

• TCP/IP – Transmission Control Protocol/Internet Protocol

• UML – Unified Modeling Language

• URL – Uniform Resource Locator

• XML – eXtensible Markup Language



Module 1

Architect and Architecture


Architecting and Designing J2EE Applications Module 1, slide 2 of 18Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000 Revision A

Overview

• Objectives

• Relevance



The Architect’s Role

• The architect:

▼ Visualizes the behavior of the system

▼ Creates the blueprint for the system

▼ Defines the way in which the elements ofthe system work together

▼ Distinguishes between functional and non-functional system requirements

▼ Is responsible for integrating non-functionalrequirements into the system



Development Team

• The architect is a member of a developmentteam.

System designers

Team leads

Enterprise modeler

Developers

Testers

QA staff

Configuration experts

Business domain experts

Customer

Beta tester

End users

Architect



Defining Architecture

• Architecture refers to an abstract representationof a system’s components and behaviors.

• Architecture does not contain details aboutimplementation.

• Architectures are best represented graphically.

Boxes represententities

Lines representcontrol or data flow



The Art of Architecture

• An architect communicates thedesign of the system to othermembers of the team.

• Defining an architecture is acreative process.

• The creative process can havepositive and negative aspects.

• Architects try to balance creativity with science in theform of models, frameworks, and patterns.



Defining Architecture Terminology

Term Definition

Abstraction A symbol for something used repeatedly in a design that hides details andis a clear representation.

Boundaries The area where two components interact.

Brittleness The degree to which small changes will break large portions of thesystem.

Capabilities Non-functional, observable system qualities including scalability,manageability, performance, availability, reliability, and security whichare defined in terms of context.

Friction How much interaction occurs between two components. Friction ismeasured based on how a change in one affects both components.

Layering A hierarchy of separation.

Surface Area The methods that are exposed to the client.



Architecture and Design

• Key difference is in the level of details.

• Architecture operates at a high level of abstraction.

• Design operates at a low level of abstraction.



Architectural Building Blocks

• Capabilities and design goals

• Process and artifacts

• Communication mechanisms

To build an architecture, the architect uses the following:

• Architectural fundamentals

• Experience:

▼ Best practices

▼ Frameworks, patterns, and idioms



Capabilities and Design Goals

Capabilities:

• Are non-functional, observable system qualities thataffect the long term viability of your architecture.

• Depend on the context of your system.

• Can be specified, measured, and prioritized.

▼ Example of specifying reliability — No more than 1failure per 1000 attempts or 99.9 percent.

Design goals:

• Are non-functional, non-observable system qualitiesdesigned into a system to achieve the capabilities.



Process and Artifacts

• A process consists of an orderly sequence of stepsfrom initiation to delivery to deployment.

• The purpose of a process is to:

▼ Address assumptions

▼ Minimize the impact of risks

▼ Identify constraints

• Artifacts result from the process.

• UML is used to communicate the architectureand design to other members of the team, both presentand future.



Communication Mechanisms

• HTTP, HTTPS

• RMI

• IIOP

• Messaging

• Transactions (ACID)



Architectural Fundamentals

• Top-down design approach

• Identifying layers, tiers, and services

• Establishing service-based architectures

• Abstraction



Abstraction

• Abstraction refers to creating symbols that hide designdetails:

Example 1

Example 2

Example 3

Browser DB

WebServer

Servlet

JSP

Client Notification Service Event Service



Abstraction – Surface Area

• Well-defined modules interact with one another insimple, well-defined ways.

• Surface area is the different ways that modules interact.

Customer

+getName()+getAddr()+getPhone()

Customer

+getName()+getAddr()+getPhone()+getBalance()+getTransactions()+makeDeposit()+makeWithdrawal()

Checking Account

Threeinterfacemethods

Seveninterfacemethods



Abstraction – Surface Area

• The greater the surface area, the more ways a change inone module can affect another.

Customer

+getName()+getAddr()+getPhone()

Customer

+getName()+getAddr()+getPhone()+getBalance()+getTrans()+makeDeposit()+makeWithdrawal()

Checking Account

Account

+getBalance()+getTrans()+makeDeposit()

JSP Page

+makeWithdrawal()

JSP Page

Smaller surface areasLarge surface area



Check Your Progress

• Define the role of an architect

• Define the term “architecture”

• Explain architectural terms such as abstraction,boundaries, brittleness, and capabilities

• List the differences between “architecture” and“design”

• Identify the fundamentals of system architecture

• Identify and define key architectural principles

• Explain the concept of abstraction, and how it isimplemented in system architecture



Think Beyond

The architect has many issues to consider, as discussed in thismodule.

How absolute are these issues?

Can you think of how they relate to each other?

Can you think of other issues that should be considered?



Module 2

Principles of Architecture



Overview

• Objectives

• Relevance



Architecture and the Cube

Layers

Capabilities

TiersClie

ntPre

sent

atio

nBus

ines

sIn

tegr

atio

nRes

ourc

e

Scalability

Security

Manageability

Reliability

Availability

Application

Virtual Platform

Upper Platform

Lower Platform

Application

Virtual Platform

Upper Platform

Lower Platform

Client

Presentation

Business

Integration

Resource

Security

Manageability

Reliability

Availability

Scalability



Layers and Tiers

Client

Application

Virtual Platform

Upper Platform

Lower Platform Operating system

Operating environment:Web server or application server

APIs, specifications

Components

ResourcePresentation Business Integration

Parnas’s Law: Every class, object, tier, or layer keeps a secret— the secret of how services are presented to the adjacentclass, object, tier, or layer.

Composescontent using

businessinformation

Tier Tier Tier Tier Tier

Containsresources

Containsessentialbusinessthemes

Logicalintegration

to resources such asdata

Renders UI,Provideshuman

interaction

Reliability

Availability

Scalability

Manageability

Security



Capabilities

• Nonfunctional, observable system qualities:

▼ Do not represent separate specified functions

▼ Cannot be satisfied by any one component

• Example:

▼ Retail toy store’s web site cannot handle the loadand crashes:

▼ Two weeks before Christmas

▼ After a $50 million advertisement campaign

▼ Expansion of capacity will take six weeks



Capabilities

SystemQuality

Definition As Used In This Course

Availability The assurance that a service/resource is always accessible. This aspect of a system is oftencoupled with measures of its performance.

Capacity The ability to run a number of jobs per unit time.

Extensibility The ability to economically modify or add functionality.

Flexibility The ability to support architectural and hardware configuration changes.

Manageability The ability to manage the system to ensure the continued health of a system with respect to theother capabilities.

Performance The ability to execute functions fast enough to meet performance goals.

Reliability The ability to ensure the integrity and consistency of an application and its transactions.

Scalability The ability to support the required quality of service as load increases.

Security The ability to ensure that information is neither modified nor disclosed except in accordancewith the security policy.

Testability The ability to determine what the expected results should be.



Availability and Reliability

Availability

• The assurance that a service or a resource is highlyaccessible. (time available) / (time possible)

• Example – 201 seconds down/week

Reliability

• The ability to ensure the integrity and consistency ofthe application and all of its transactions.

• Example – Users will experience failed sessions nomore than 1 time in 1000 attempts (99.9 percentreliability).



Improving Reliability

• Assume a web server has a MTBF of 100,000 hours.

• What is the reliability of the following?

• Availability increases.

Webserver

MTBF =1015

hoursWebserver

Webserver

MTBF=105

hours



Manageability

• The ability to manage the system to ensure thecontinued health of a system with respect to the othersystem qualities.

• Metric example – Number of staff hours permonth to perform normal upgrades.



Flexibility

• Is the ability to change architecture to meet newrequirements in a cost-efficient manner

• Is the key to an available, reliable, and scalableapplication

• Can be improved through location independence ofapplication code



Flexibility

• Example

• Allows you to change what is affected by changing thepresentation language (for example, English toGerman)?

• What must change to add a “fat client” for intense use?

ClientWeb

ServerApplication

Server Data



Flexibility Metrics

• No standard way of measuring flexibility

• Basic measure is cost of change but this depends onwhat change is probable.

• Use change cases to evaluate what in system mustchange.



The Effect of Flexibility

Clients

Clients

Webserver

Applicationserver

Applicationserver

Webserver

Applicationserver

Webserver

Applicationserver

Webserver

Data

Data

2. Location transparency

3. Reconfigurability

on server-side

Flexibility

Reliability

Availability

Manageability

1. Location transparencyon client-side

21

3



Performance

• The ability to execute functions fast enough to meetperformance goals.

• Response time is important to an application.

• Identify and control expensive calls.

• State performance goals before implementing.

• Example—first visible response in browser undermaximum specified load occurs in less than 3 seconds,95 percent of the time. Measurement is made atcompany external firewall.



Performance

• Identify and control access to expensive process andnetwork boundaries.

Host 1Process 1 Process 1

Client

Local

Process 2

Local Server

Remote Server

Network

Host 2

Boundaries



Performance

• Identify the class of expensive calls.



Capacity

• The ability to run a certain number of jobs per unittime.

• Example

CPU

Processes

1 2 3 . . . . . 32

CPU

Processes

1 2 3 . . . . . 32

CPU

Processes

1 2 3 . . . . . 32

CPU

Processes

1 2 3 . . . . . 32

Application server Application server

Total is 28*4=112 (total not including overhead)



Latency Space

• Latency is the inherent communication delay, such asping time.

ClientWeb

serverApp

server

Distance

Minimize surface area of communication pipe.Request more data with fewer calls.

Data

1500 msec

Num

ber

of M

essa

ges



Scalability

• The ability to economically support the requiredquality of service as the load increases.

• Vertical scalability comes from adding capacity(memory, CPUs) to existing servers.

▼ Makes fewer demands on the architecture

▼ Is constrained by resource limits

• Horizontal scalability comes from adding servers.

▼ Distributed state, load balancing



Vertical Scalability

WebServer

ApplicationServer

DBMSServer

Capacity

Reliability

Availability

Manageability

Any machine failure leads to a system failure.



Horizontal Scalability

• All Web servers or all application servers must fail fora system failure to occur.

LBR LBR LBR

ApplicationServer

DBMSServer

DBMSServer

Capacity

Reliability

Availability

Manageability

WebServer

WebServer

WebServer

ApplicationServer



The Effect of Scalability

How are other capabilities driven by scalability?

• Availability and reliability are obtained throughscalability.

• Capacity is affected by scalability:

▼ One machine handles 500 transactions

or

▼ 5 machines handle 100 transactions each

▼ 50 machines handle 10 transactions each



Extensibility

• The ability to modify or add functionality withoutimpacting the existing functionality.

• Requires careful modeling of the business domain toadd new features based on the business model.

Functionality delivered

Cos

t

k

k

1.05-1.3

.9

Traditional

Object-orienteddevelopment

development



Extensibility

Rough guidelines:

• More than 25 top-level classes will lead to problems.

• Every use case can be directly implemented usingdomain model methods.

• On average, every change touches about 1.3 classes.



ExtensibilityMonolithic Application

ManagesConcurrencyDatabase AccessQueryTransactionsServe data

ManagesSession stateConcurrencyResourcesBusiness calls

ManagesRenderingi18n*FormattingEditing

Minor change in requirements

Breaks when Breaks when businessrules change.

Breaks when dataschema changes.UI changes.

break the whole application.

Create tiers to manage responsibilities.

ManagesEverything

*i18n = internationalization



Testability

• The ability to determine what the expected resultsshould be.

• Multi-tier architecture provides for many test pointsfor intermediate testing and debugging.

Webserver

Applicationserver

DataClient

tp

tp = test point

tp tp



Security

Principle Definition

Identity Trust that the user is correctly identified through anauthentication mechanism

Authority Trust that the user can perform only allowed actions

Integrity Trust that data can be modified only in allowable ways

Privacy Trust that data is disclosed to authorized entitites only inauthorized ways

Auditability Trust that the system maintains valid records of actionstaken for later analysis



Security

• Proper use of technology.

• More than just technology.

▼ Hiring a trusted employee

▼ Procedural – intrusion detection

▼ Keep server in locked room

• Trade-off between privacy, ease-of-use, and expense



Security Policy

• A security policy should state the acceptable risks andcosts.

It requires at least 30 hours using the best knownattacks to compromise one customer account. Threeor more successive login failures will be logged.



Service-based Capabilities

Scalable, available architectures are typically service-basedarchitectures with collections of cooperating, communicatingservices.

• Small, coherent sets of APIs to the business

• Provides “outlets” for connecting to services

• Decouples clients from implementations

• Proper implementation of services is the key tosecurity, scalability, and availability



Why Service-based Architectures?

Service-based architectures:

• Are less brittle

• Respond easily to changes in business demands.

• Can tune each system for the functionality it provides

Alternatives:

• Partition by tiers

• Partition by special functions



Creating Service-based Architectures

• Vertical services:

▼ Content-based services

▼ Reflect the business model

• Horizontal services:

▼ Infrastructure-based services

▼ Accessed at many layers

Accounting Inventory

Security

Vertical

Infrastructure Load-Balancing Integration



Heuristics for Developing Service-based Architectures

• A service is like a server in Client-Server architecture:

▼ Represents shared resources

▼ Accessed concurrently

▼ Maintaining integrity

• Services map to essential business themes, which mapto top-level domain objects.



Architectural Design Goals

• To achieve capabilities, an architect creates anarchitecture with the following goals in mind.

▼ Modularity

▼ Protection and exposure

▼ Component extensibility

▼ Roles and responsibilities

▼ Contracts

▼ Pluggable behavior



Modularity

Separate the code into self-sufficient, highly cohesive, low-coupling pieces.

• Modularity creates good code abstractions.

• Modularity hides details.

• Modular code is like a black box.



Protection and Exposure

• Guard expensive resources to prevent inappropriateuse.

• Shared resources are usually expensive to access.

• Protection mandates controlled exposure usingvisibility access classes.



Component Extensibility

Modify or add functionality without impacting the existingfunctionality.

• Subclass

• Composition



Component Extensibility UsingSubclassing

• Extending by subclassing creates powerfulspecialization mechanisms.

HRServiceExtension

MyHRService

+ initialize (ctx : Context)+ addEmployee( e : Employee)



Component Extensibility UsingComposition

• Composition provides a powerful and dynamicextension mechanism.

• Provides for a more “pluggable” architecture.

HRServiceExtensionHRServiceDelegate

+ initialize (ctx : Context)+ addEmployee ( e : Employee)

+ addEmployee(e: Employee)

MyHRDelayedService MyHRRealtimeService



Roles and Responsibilities

• To create clear abstractions, you must identify rolesand responsibilities.

• Identify roles and responsibilities for the abstraction.

AccountJSP

AccountHelper

AccountDelegate

Role: Dynamic presentation Role: Account data formatter Role: Control account accesscreator

JSP ROLE: Dynamic Presentation creator

Should: Create presentationShould Not: Execute business logic or make remote calls

ARTIST NOTE:Adjust graphic to top and flush left of bounding box.

AccountJSP

Role: Dynamic presentation creator




• Define roles to identify valid data input and output

:AccountJSP :AccountHelper :AccountDelegate

Legacy ordatabaselookup

HTTP requestgetAccountInfo

getAccountInfo

return

return

HTML

AccountJSP

AccountHelper

AccountDelegate

Role: Dynamic presentation Role: Account data formatter Role: Control account accesscreator



Contracts

• Contracts are the client-visible API.

• Also known as “programming to the interface.”

• Contracts are architecturally represented asabstractions.

• Contracts mandate business access and data type.

• Identify “pre” and “post” conditions.

This:

Becomes: Client

Service

Service

Client

Contract



Types of Contracts

• There are two types of contracts:

▼ Contract-based – Action and data are explicitlydefined in the contract.

▼ Message-based – Action and data are packaged inthe request. The contents of the message are parsedto identify the requested function.



Pluggable Behavior

• In general, you expect to use a method by simplypassing parameters.

aTextArea.insertText(“This is inserted”, 42);

• You can also put complicated behavior into aparameter object, such as fonts, paragraph layouts, andso on in aStyledDocument .

aJTextPane.setStyledDocument(aStyledDocument);

• The ability to pass complex objects makes a systemmore flexible.



Providing SystemRequirements

Capacity

Reliability

Availability

ManageabilitySecurity

Architecture thatmeets functionalrequirements

XML

HTML

Presentation Business Integration Resources

Web-basedReliabilityAvailability

Webserver

Appserver

Webserver

Webserver

Appserver

Data

Webserver

Appserver

Webserver

Webserver

Appserver

DataFirewall Firewall

Security

Transformation 1

Transformation 2

Transformation 3

Why?

Why?Flexibility

Why?

Client



Process

• Architects use processes to build a system that meetsthe requirements.

• A process should be iterative and driven by use-cases.

Requirements Elaborate

Test/Deliver Development

Gather requirements (Use cases)

Code derived from artifactsVerify thatrequirements are met

Spiral model

Identify Assumptions, Risks,Identify service abstractions

Model business andcreate artifacts

and Constraints (ARC)



Assumptions, Risks, and Constraints(ARC)

Imperative to identify assumptions, risks and constraints.

Term Definition Examples

Assumptions Refers to preconditions, the absence ofwhich can affect the architecture of asystem

Only one content languageFewer than 50 page views/second95% reliability is adequate

Risks The cost (in probability of remediation)of making specific assumptions

Localize text content for easytranslationScalable architectureTranslation and i18n

Constraints Rules or imposed assumptions to whichthe system must adhere.

Static content is out sourcedSPARC/SolarisimplementationPure HTML at client



Model the Business

• Model the business with use cases.

• Use cases drive the architecture at every view.



Check Your Progress

• List and define the key architectural capabilities

• List and define the key architectural design goals

• List and describe the trade-offs that result fromarchitectural decisions.



Think Beyond

How does J2EE technology work with the principles ofarchitecture, specifically capabilities?



Module 3

Creating an Architecture Using J2EETechnology



Overview

• Objectives

• Relevance



What Is J2EE Technology?

• Not just a set of APIs.

J2EE Technology Purpose

Platform Specification Defines a standards-based component framework forbuilding enterprise applications

Reference Implementation Provides a compliant and operational J2EE platform

J2EE Blueprints Describes how to construct J2EE applications

Compatibility Test Suite Validates J2EE platform compatibility (end-to-end) toguarantee code portability and to eliminate vendor lock




• Components:

▼ Application clients

▼ Applets

▼ Web components

▼ Business components

• Containers:

▼ Manage lifecycle of business components

▼ Provide a federated view of J2EE APIs

▼ Provide runtime support for components

Businesscomponent

Workenvironment

Container




JVM

Old way

ThreadsConnectorsConcurrency

.

.

EJB container

Application is responsible forsupporting business logic (hardest part):

Container is responsiblefor supporting business logic.

New way

JVM

SynchronizationResource sharing

.




• Connectors:

▼ Contract between container and EnterpriseInformation System (EIS).

▼ Proprietary and under the hood.

▼ Implementation is available with J2EE specificationversion 1.3.



J2EE Architecture

• J2EE architecture is multi-tier

Applet

J2SE

HTTPs1

2

HTTPs

3

4

Web Container

JSP Servlet

JavaMail

JAF

JDB

C

JND

I

RM

I-IIOP

JMS

JTAJ2SE

Container

JDB

C

JND

I

RM

I-IIOP

JMS

5

J2SE

EJB Container

EJB

JavaMail

JAF

JDB

C

JND

I

RM

I-IIOP

JMS

JTA

6

DB

ApplicationClient

J2SE

Container



J2EE Architecture

network transport layer (IIOP * )

lookup

Stub JNDI

Naming andDirectoryService

JNDI Skeleton

Server

bind

TransactionService

JTA

JDBC

Container

Remoteobject

Homeobject

Security

EJB

Persistsence

JavaMail

Client

DB



Layers and Tier With J2EE Technology

Client

Virtual Platform

Upper Platform

Lower Platform Operating system

Operating environment:Web server or application server

APIs, specifications (EJB, JSP, servlet )

ResourcePresentation Business Integration

Composescontent using

businessinformation

Tier Tier Tier Tier Tier

Containsresources

Containsessentialbusinessthemes

Logicalintegration

to resources such asdata

Renders UI,Provideshuman

interaction

Reliability

Availability

Scalability

Manageability

SecurityApplication

J2EE focus

Components (EJB, JSP, servlet)



Flexibility and J2EE Technology

Clients

Clients

Webserver

Applicationserver

Applicationserver

Webserver

Applicationserver

Webserver

Applicationserver

EJB

JSP

Servlet EJB

EJB

Webserver

JSP

Data

Data


3. Reconfigurability(JNDI)

on server-side

Flexibility

Reliability

Availability

Manageability

(component-based )


(Web access or JNDI )on client-side

21

3



Manageability and J2EE Technology

• Multi-tier architecture impacts manageability

• J2EE technology’s component-based frameworkimproves manageability.

Flexibility

Reliability

Availability

Manageability

Applicationserver

Webserver

Applicationserver

Webserver

Applicationserver

EJB

JSP

Servlet EJB

EJB

Webserver

JSP

Data



J2EE and Latency Space

Client Webserver

Appserver

Distance

JSP

S

EJBC Data

Content composed close to App server.Reduces back and forth between client and Web server.

Connector can cache data fromresource tier, reducing requests.N

um

ber

of

Mes

sag

es



Vertical Scalability

• Make vertical scalability transparent to the clients.

• Automatic life-cycle management supports morecomponents, such as EJBs, JSPs, and servlets.

WebServer

ApplicationServer Capacity

Reliability

Availability

Manageability

Container

EJB

Container

JSP

DBMSServer



Horizontal Scalability

• Automatic life-cycle management supports clusteringand load-balancing techniques.

LBR

LBR = Load Balancing Router

LBR LBR

ApplicationServers

DBMSServer

DBMSServer

Capacity

Reliability

Availability

Manageability

Web servers

Container

JSP

Container

JSP

Container

Servlet

Container

EJB

Container

EJB



Extensiblity and J2EE Technology

• Distinct roles enhance extensibility.

▼ JSPs and servlets handle the presentation.

▼ EJBs handle the business logic.

ManagesConcurrencyDatabase AccessQueryTransactionsServe data

ManagesSession stateConcurrencyResourcesBusiness calls

ManagesRenderingi18nFormattingEditing

Breaks when Breaks when businessrules change.

Breaks when dataschema changes.UI changes.

Create tiers for managing responsibilities.

JSP, servlet EJB



Essential Patterns

• J2EE framework employs patterns to support thesecapabilities.

• J2EE uses the following core patterns to enable flexibleassociation of EJB classes with other components.

Pattern Use

Proxy Provides a separate implementation of interfaceand working code for location transparency

Decorator Provides a similar contract for a class but withadded functionality

FactoryMethod

Provides ability to define a contract for creatingan object but defers instantiation to subclasses

Abstractfactory

Provides a contract for creating families of relatedor dependent objects without specifying concreteclasses



Proxy Pattern

• Decouples interface and implementation by providingtwo objects.

• If the Work Code class changes, the proxy remains thesame.

• An example is the EJB’s remote interface.

Proxy Work Code

+ getA()+ getB()+ setC()

+ getA()+ getB()



Decorator Pattern

• Provides the same contract for a class but withextended functionality.

Canvas

+ draw + draw

DecoratedCanvas

DecoratedCanvasdraw{

// draw decorationcanvas.draw();// display page

}

Drawing CanvasDrawing x



Decorator Pattern

• The EJB object is a decorator for the bean because thebean’s functionality is expanded to include remotebehavior.

AccountEJBObject

javax.ejb.EJBObject

Account<<interface>>

javax.ejb.EntityBean

AccountBean



Factory Method Pattern

• Provides the ability to define an interface for creatingan object but defers instantiation to subclasses.

• J2EE technology uses this pattern for the EJB homeinterface, which creates new EJB objects.

Design Patterns by Gamma, Helm, Johnson, Vlissidespublished by Addison-Wesley

Document

+ Open()+ Close()+ Save()

Application

+ CreateDocument()+ NewDocument()+ OpenDocument()

MyDocument MyApplication

+ CreateDocument()

* docs



Abstract Factory Pattern

• Provides an interface for creating families of related ordependent objects without specifying concrete classes.

• J2EE technology uses this pattern for the EJB homeinterface, which creates new EJB objects.

Design Patterns by Gamma, Helm, Johnson, Vlissidespublished by Addison-Wesley

WidgetFactory

+ CreateScrollBar()+ CreateWindow()

MotifWidgetFactory


PMWidgetFactory




Check Your Progress

• Describe how J2EE architecture affects thenonfunctional requirements of a system.

• Describe the use of patterns in the J2EE framework.



Think Beyond

Vendor implementations of J2EE provide the Virtual Platformlayer on which you can build an enterprise application. As anarchitect, how do you know how to structure the componentsof your application?



Module 4

J2EE Best Practices – Overview



Overview

• Objectives

• Relevance



Experience in Creating Architectures

Experience yields blueprints for solving recurring problems.

• Best Practice–A suggested practice used to drive designat the component level.

▼ Example–Use session beans as facadesto entity beans.

• Guideline–A rule applied horizontally to the design.

▼ Example–Minimize network traffic bymaximizing data requests.



J2EE Architecture

• Three basic tiers in the J2EE platform.

• Client tier

• Middle tier

• Backend tier

Browser

Presentationtier

Businesstier

Integrationtier

Client Middle Backend

EnterpriseInformation

System (EIS)(Web) (EJB)



J2EE Best Practices and Guidelines

• You can apply best practices and guidelines in eachtier.

▼ Client tier

▼ Web tier (presentation)

▼ EJB tier (business)

▼ EIS Integration tier (integration)

• You can apply best practices and guidelines toorthogonal services that span tiers.

▼ Security

▼ Transactions



Best Practice – Client Tier

• Decouple the client type from the enterpriseapplication:

▼ HTML browser

▼ Applet

▼ Java application

▼ Non-Java application



Best Practice – MVC Pattern

• Use Model-View-Controller (MVC) pattern to facilitatereuse.

UserGestures

ViewSelection

Method Invocations

Events

View Controller

Presentation tier

ChangeNotification

StateQuery

Model* Encapsulates application state* Responds to state queries* Exposes application functionality* Notifies views of change

Statechange

* Defines application behavior* Maps user actions to model updates* Selects view for response* One for each functionality

* Renders the models* Requests updates from models* Sends user gestures to controller* Allows controller to select view



Best Practice – Business Objects

• Business objects are software abstractions ofapplication data.

• Avoid duplicating code by sharing business objectsamong different client types

• To reuse business objects, you can apply:

▼ Encapsulation

▼ Delegation

▼ Inheritance



Best Practice – Controllers

• Use inheritance or delegation for the Controllers toaccommodate many types of clients (Views).

• Controller should translate user gestures into businessevents.

Javaapplication

HTMLclient

Businessobjects

Businessevents

Javatranslator

HTMLtranslator

Con

trol

ler




• Potentially brittle controller design

Controller




• Less brittle controller design

Controller



Check Your Progress

• Define the concepts of “best practice” and “guideline”

• Describe the J2EE best practices that you can applyacross all tiers

• Describe the J2EE client tier best practices



Think Beyond

Thin-client solutions (HTML on a browser) are important toInternet-based applications. The browser acts as your clientfor rendering the presentation as encoded in HTML. Whatother solutions are available to render content in a Webbrowser?

In a Web application, what type of component is usually usedfor the View and controller elements of the MVC pattern?

What type of component is usually used for the Modelelement?



Module 5

J2EE Best Practices – Web Tier



Overview

• Objectives

• Relevance



Web Tier

• Four types of Web applications using J2EE technology



Applying the MVC Pattern To WebTier Architecture

• MVC architecture implemented using JSP, servlets,and modular components.



Best Practice – Web Tier Components

• Servlets and JSPs provide a means to separatepresentation logic from content.

• J2EE web components can serve two roles:

▼ Front component

▼ Presentation component



Front Component

• Manages other components

• Translates and dispatches the HTTP request

• Front component acts as a controller

• Provides a single entry point to facilitate:

▼ Security

▼ Application state maintenance

▼ Uniform presentation



Presentation Component

• Generates the HTML/XML response.

• Should be modular and reusable.

• Modular design allows for separation of roles.

• Presentation components create consistent lookand feel, but also allows you to personalizeyour user interface.



Best Practices – JSPs and Servlets

• No single correct answer on using JSP or servlets. Candepend on:

▼ Team composition

▼ Time constraints

▼ Application architecture

• You can use both servlets and JSPs for modular,reusable presentation components.



Best Practices – JSPs and Servlets

• Use servlets for low level application functions

▼ Control selection of view (front component)

▼ Generate binary/image data

• Use JSP for presentation-centric declarativemeans of binding dynamic content and logic

▼ Handle HTML representation generatedby a page



JSP Features

• JSP can contain both presentation logic and content

• Options for binding content to logic

Options Use

JavaBeanscomponent

Data-centric model objects

Ideal for processing requestsreceived from the frontcomponent

Custom Actions Ideal for iterating through a listof data and state display

ScriptletsIdeal when small portions ofcode are needed

Should not be used when largeamount of code is required.



Localization and Internationalization

• Localization (l10n) is the process of adapting anapplication or applet to a specific language or region.

• Internationalization (i18n) is the process of designing anapplication or applet to adapt to various languages andregions.

• The presentation tier is the focus of internationalizationand localization efforts to be able to

▼ Add new languages without recompilation

▼ Provide regionally dependent data, such as currency

▼ Provide regionally dependent behavior



Internationalization Process

1. Separate the display text from the code and place ina properties file.

2. Define as many Locale objects and ResourceBundleobjects as the number of languages to be supported.

▼ Locale objects contain information (metadata)about which language or region.

▼ ResourceBundle objects contain the text for thatlanguage.

3. Access the ResourceBundle objects from the code toobtain the language-specific text.



Internationalization

• In addition to Locale and ResourceBundle objects injava.util , java.text provides support forinternationalization:

▼ Currency formatting (DecimalFormat )

▼ Date Formatting (SimpleDateFormat )

▼ Messages with variable ordering to the words

▼ English — subject-verb-object

▼ Hebrew — verb-subject-object

▼ German — object-verb-subject-verb



Check Your Progress

• Describe the components and categories of the WebTier

• Define how you can apply the MVC pattern to the Webtier

• Specify the best practices and guidelines of thePresentation components in the Web Tier

• Describe the use of “localization” and “internalization”



Think Beyond

Because of the ubiquity of the Web, this tier is critical for manyenterprise applications. You have seen that the Web tier isresponsible for a) selecting a view and b) separating thepresentation of the data from the business objects, and c)performing localization and internationalization.

What other responsibilities does the Web tier have?



Module 6

J2EE Best Practices – EJB Tier



Overview

• Objectives

• Relevance



The EJB Tier

• The Enterprise JavaBeans (EJB) tier hosts the following:

▼ Application-specific business objects

▼ System-level services (such as transactionmanagement, concurrency control, and security)

• The EJB tier is a critical link between the web tier andthe EIS integration tier.

▼ Entity beans and session beans

▼ Data access objects and value objects

▼ Session beans as a facade to entity beans

▼ Master-detail modeling using enterprise beans



Guidelines – Using Session Beans

• Stateful session beans:

▼ Maintain client-specific state

▼ Represent non-persistent objects

▼ Represent workflow between business objects

• Stateless session beans:

▼ Model reusable service objects

▼ Provide high performance

▼ Operate on multiple rows in the database

▼ Provide procedural view of data



Guidelines – Using Entity Beans

Use entity beans to model business objects when thefollowing circumstances apply:

• Coarse-grained business objects:

▼ Represent persistent data

▼ Provides behavior beyond accessor methods

• Shared, concurrent access by clients

• Represent a single logical record in the database

• Provide robust, long-lived persistent data managementthat can recover from crashes



Best Practice – Data Access Objects

• Encapsulate access to data

• Maintain clean separationof bean and databaseaccess code

• Ensure easier migration tocontainer-managed persistence for entity beans

• Allow for cross-database and cross-schema capability.

Client EntityBean

SessionBean

DataAccessObject

DataAccessObject

JDBC

EJB tier



Best Practice – Value Objects

• Modeling every business object as EJBs is expensive

• Use value objects for:

▼ Fine-grained business objects that representstructure with get/set behavior only

▼ Dependent objects

▼ Immutable objects

Client

Valueobject

Enterprise DataBean



Best Practice – Session Bean Facade

• Provides a simple, single point of entry to shared entitybeans

• Shields the client from complex entity beanrelationships

• Manages workflow on client’s behalf

• Reduces remote calls to the server

ClientSession

Entity

EntityDatabase

Entity

Entity



Master-Detail Modeling

• Master-detail modeling is a one-to-many type ofrelationship among data sets.

• Master holds a list to many detailed objects.

• Expanded view is contained in the detail objects.

• Master is usually a stateful session bean.

• Entity beans provide a detailed view.

Enity BeansSession Bean Database rows

A

B

C

DCatalog Listing

AB

CD



Check Your Progress

• List the best practices and guidelines for using entitybeans and session beans

• Define Data Access Objects and describe their purpose

• Define Value Objects and describe their purpose

• Describe the use of Session Bean Facades



Think Beyond

You have seen two ways of hiding the details of the EIS tier:Data Access Objects and Master-Detail encapsulation. Thesetwo are specifically used for integrating to a database. Whatother EIS resources might an application need to integrate?

In this module you saw that you can control the client’s accessto the application using a session bean facade pattern and inModule 4, ‘‘J2EE Best Practices – Overview" you learned thatcentral controllers can be brittle. How can the SEF pattern beextended to minimize the brittleness of the session bean?



Module 7

J2EE Best Practices – EIS Integration Tier



Overview

• Objectives

• Relevance



EIS Integration Tier

• EIS Integration tier provides the informationinfrastructure for an enterprise.

• Accessing EIS can be complex, requiring vendorspecific knowledge of:

▼ Application programming model

▼ Transactions

▼ Security

• J2EE reduces the complexity of accessing an enterpriseinformation system by relying on the Web and EJBcontainers to handle transactions, security, andscalability.



Integrating an EIS

J2EETechnology

Use

JDBC Accesses relational data

JNDI Accesses enterprise name anddirectory services

JMS Sends and receives messagesusing enterprise messagingsystems

JavaMail Sends and receives mail

JavaIDL Calls CORBA services

JNI Calls services written in otherlanguages

JNI Can interact with nativelanguages



EIS Guidelines – Data Access

• Rely on vendor tools for EIS integration:

▼ Data and function mining tools

▼ Object-oriented analysis and design tools

▼ Application code generation tools

▼ Application composition tools

▼ Deployment tools

• Rely on deployers to set transaction, security, anddeployment requirements



EIS Access Objects

• Abstract complex, low-level details of EIS systemaccess into access objects:

▼ Provide a common, consistent access to varioustypes of EIS

▼ Separate access objects from business objects

▼ Access objects can be made into well knowJavaBeans for use in development tools



Guidelines – Access Objects

• Access objects abstract the complex, low-level details ofaccessing an EIS system:

▼ Provide a common, consistent access to varioustypes of EIS systems

▼ Separates access objects from business objects

▼ Access objects can be made into well knownJavaBeans for use in development tools



Guidelines – Access Objects

• When implementing access objects, do not makeassumptions about environments outside accessobjects.

• Design for reusability across tiers and components.

• Access objects should not define declarativetransactions or security requirements.

• Maintain consistency in programming restrictionsbetween business objects and access objects.



Guidelines – Connections

• Components should acquire and release connectionswithin a single method

• Account for differences across component types inconnection management:

▼ JSP and servlet

▼ Stateful and stateless session beans

▼ Entity beans

• Components should avoid opening multipleconcurrent connections to a single database (notsupported by some JDBC drivers)



Check Your Progress


• Describe the best practices using J2EE technology thatyou can apply across all tiers




Think Beyond

• Integration to backend resources can be challenging.Even dealing with a relational database is not trivial.Can you imagine what an access object might need todo to adapt to a legacy database?



Module 8

J2EE Best Practices — Services



Overview

• Objectives

• Relevance



Security

• Threats to enterprise-critical assets can include:

▼ Disclosure of confidential information

▼ Modification or destruction of information

▼ Misappropriation of protected resources

▼ Compromise of accountability

▼ Misappropriation that compromises availability



Security

• Exposure to threats can be mitigated using:

▼ Authentication

▼ Authorization

▼ Protecting Messages

▼ Auditing



Security Guidelines

• Support a consistent end-to-end security architecture

• Seamlessly integrate with security environment of EIS

• Support authentication and authorization

• Are transparent to application components

• Enable applications to be portable across securityenvironments



Security Terminology

• An entity is something that can have access rightsapplied to it.

• A principal is an entity to which privileges can beassigned.

• A role is a collection of privileges.



Authentication

• Mechanism by which callers and service providersprove that they are acting on behalf of specific users orsystems.

• Web-tier authentication:

▼ HTTP basic authentication

▼ Form-based authentication

▼ HTTPS mutual authentication



Authentication in the EJB and EISIntegration Tiers

• EJB-tier authentication:

▼ Protection domains

▼ Put a protected web resource in front of a protectedEJB resource

▼ Link protected web resources on every web resourcethat calls EJB resources

• EIS integration tier authentication:

▼ Container-managed resource manager sign-on

▼ Application-managed resource manager sign-on



Protection Domains

• In a J2EE application, protection domain refers to a setof entities that are assumed, or known to trust eachother.



Authorization

• Authorization entails applying security policies toregulate what specific users, or groups of users, canaccess in the system.

• Access control limits the resources a user has access tobased on the user’s permissions.

• Access control can also be used to limit the type ofaccess a user has to a resource, such as read or writeaccess.



Authorization

• Two approaches to defining access control rules:

▼ Capabilities focus on what a caller can do

▼ Permissions focus on who can do what

• J2EE application programming model focuses onpermissions



Declarative and ProgrammaticAuthorization

• Declarative authorization can be used by specifyingsecurity roles and:

▼ Associating them with components in the EJB tierdeployment descriptor

▼ Controlling access to a HTTP request, such as GET

• Programmatic authorization can be used for very fine-grained access control:

▼ EJB tier: EJBContext.isCallerInRole

▼ Web tier: HttpServletRequest.isUserInRole



Declarative and ProgrammaticAuthorization

• Use declarative authorization where possible andprogrammatic authorization when more functionalityis required.

• When using declarative authorization, ensure accesscontrol is not bypassed.

▼ Apply same access control rules to all the methods ina component.



Controlling Access to Resources

• To control access to web resources, specify theconstraint in the deployment descriptor.

• To control access to EJB resources, specify the roles inthe deployment descriptor.

• You can also specify the methods of the remote andhome interface that each security role is allowed toinvoke.

• The proper assignment of users to roles determineswhether a resource is protected.



Protecting Messages

• To ensure message integrity the following measurescan be used:

▼ Message signature: a cryptographically encipheredmessage digest of the message contents

▼ Message confounder: ensures message authenticationis useful only once

• Message signatures might be required for component-to-component invocations that traverse unprotectednetworks.

• Specify message protection only for critical messagesand components in the deployment descriptor.



Auditing

• Auditing is the practice of capturing a record ofsecurity-related events for accountability purposes.

• Audit records must be protected so that attackerscannot escape accountability.



Transactions

• Ensure data integrity by controlling access to data.

• Free an application programmer from the complexissues of failure recovery and multi-userprogramming.

• Are a mechanism for simplifying the development ofdistributed multiuser enterprise applications.

• Span across all tiers.



Transaction Guidelines in Web Tier

• A servlet or JSP can use JNDI to lookup aUserTransaction and use JTA to demarcatetransactions.

• A servlet should only start a transaction in its servicemethod

• A transaction should not span multiple web requests.

• In multi-tier environment using EJB, use of JTA in theWeb tier is not recommended.



Transaction Guidelines in EJB Tier

• Bean-managed transaction demarcation:

▼ EJB bean uses UserTransaction

▼ Only session beans can choose to use bean-managedtransactions

• Container-managed transaction demarcation:

▼ EJB container is responsible for transactiondemarcation

▼ You should use container-managed transactiondemarcation



EJB Tier – Container-ManagedTransaction Demarcation

• Transaction behavior of EJB is specified declarativelyand frees the developer from writing code.

• Less error-prone because of container handling.

• Easier to compose multiple enterprise beans to performa certain task with transaction behavior.

• Can result in improved performance.



Transaction Attributes

• Use Required for the default transaction attribute.

• RequiresNew attribute is useful when the beanmethods need to commit unconditionally.

• The NotSupported attribute can be used when theresource manager is not supported by the J2EEproduct.

• The blueprint recommends not using the attributeSupports.

• Mandatory and Never can be used when it is necessaryto verify the transaction is associated with the client.



Transaction Guidelines in EISIntegration Tier

• Recommends that a component use JTA wheneverpossible when accessing EIS systems.



Compensating Transactions

• A compensating transaction is a transaction, or group ofoperations used to undo the effect of a previouslycommitted transaction.

• Useful if a component needs to access an EIS that does notsupport JTA.

• Pitfalls of using compensating transactions:

▼ Not always possible to undo the effect of a committedtransaction

▼ Atomicity could be broken if the server crashes when acompensating transaction is used

▼ Inconsistent data might be seen by concurrent EIS access



Check Your Progress

• Describe security guidelines, terminology, and formsof authentication

• Define the key features of security

• Describe the role of transactions

• List the best practices and guidelines relating totransactions in each tier



Think Beyond

• What are some patterns that can be used with J2EEtechnology?



Module 9

J2EE Patterns



Overview

• Objectives

• Relevance



Introducing J2EE Patterns

• J2EE is a relatively new platform for deliveringWeb-based applications.

• Difficulty in designing reusable, flexible object-oriented applications.

• Task becomes more complex withdistributed and transactional objects.

• Facilitate the design process with a collection of provendesign patterns.



Defining Patterns

• A pattern is a common repeatable solution.

• Patterns are generic and take many forms:

▼ Architectural

▼ Design

▼ Deployment



Defining Idioms

• Are technology-specific patterns

• Can be specific to languages

• Generic to solution, but specific implementation

Servlet JSP JavaBean Helper



Using the J2EE Patterns

• You use J2EE patterns to ensure the following:

▼ Modularity

▼ Protection and exposure

▼ Component extensibility

▼ Roles and responsibilities

▼ Contracts

▼ Pluggable behavior

▼ Performance



Modularity

• Maintain modularity at each abstraction.

• Hide details in each abstraction.

• J2EE patterns extends J2EE’s component architectureby allowing different components to be interchanged.



Protection and Exposure

• Protect the expensive resources.

▼ The J2EE patterns limit calls to expensive resources.

▼ The J2EE patterns protects access to sensitive data.



Component Extensibility

• The J2EE patterns can address limitations.

• EJB specification does not specify the conceptof object inheritance.

▼ How does the primary key of the derived classrelate to the primary key of the parent class?

▼ How does component inheritance affect theparent component’s persistence?

• Home and Remote interfaces can be extended,as well as corresponding enterprise beanimplementations.

• Factory and Facade patterns can offer an alternative.




• Identifying roles keeps the abstractions and data flowdefinition clear.

• The J2EE patterns support this by clarifyingabstractions, interactions, and data flow.

Helper BusinessContract

SessionEJB

Role : Business data retriever Role : Business client access Role : Business service



Contracts

• Create business contracts for clients to enforce clientaccess to services.

• For example, JSP helper and an applet would call thebusiness services through the same contract.

• Keep the contract business oriented.

NetworkHelper

Applet

Business Contract Session EJB



Pluggable Behavior

• Command and strategy patterns are examples ofpluggable behavior that enforce client access toservices.

• The ability to pass complex objects dynamically makesa system much more flexible.

• J2EE supports the ability to pass data dynamicallyusing XML as well as the ability to pass complexobjects.



Performance

• Create abstractions to support caching and optimizedremote service access.

• Can use a J2EE pattern to cache large data sets andallow client to access data from the session bean.

This:

Business Contract

Business Contract

Becomes this:

network

network

12

3

1

12

3

1

SessionEJB

SessionEJB



Performance

• Be aware of the amount of data going across the wire.

• Partial data can be cached remote to the client.



J2EE Patterns Categories

• Presentation tier patterns:

▼ J2EE patterns that cover presentation tier

▼ Consists of Web tier components

• Business tier patterns:

▼ Patterns that cover the provision of business services

▼ Consists of EJB tier and EIS tier components



Sample J2EE Patterns

• The following patterns are described:

▼ Mediator View - JSP (MVJSP)

▼ Session Entity Facade (SEF)

▼ Business Delegate (BD)

Note: These patterns can also be referred to as idioms.



Mediator View - JSP (MVJSP)

• Used in the web Tier

Requirements Scenario

• The application is non-trivial, with dynamicpresentation content.

• Allows web access to business services usingWeb Tier components.

• Responses require server side processing, andformulation of dynamic presentation.

• Sophisticated business requirements with a fewpossible views for a request.



MVJSP Pattern Participants, Roles andResponsibilities

• Dispatcher

• View

• Helper



MVJSP Pattern StructureClient

(CommonServices)<<Servlet>>

Dispatcher

dispatch()

<<JSP>>View

BusinessDelegate(com.sun.j2ee.patterns)

<<JavaBeans>>Helper

1..*

1..*



MVJSP Pattern Collaborations

Client :Dispatcher :View :Helper :BusinessDelegate

1: Request2: Process

3: Forward4: getProperty

5: getData

6: return

7: return

8: Response



MVJSP Pattern Constraints

• The Dispatcher is the initial contact point for therequest.

• The Dispatcher dispatches to the View.

• The View delegates to one or more Helpers.

• Helpers can delegate to a business delegate.



MVJSP Pattern Benefits

• You can clearly separate roles, thereby reducingcoupling

• The Dispatcher handles processing that is commonacross requests, for example, authentication.

• Suitable for handling work flow situations withmultiple and varied invocations to perform dataretrieval of the presentation model.



MVJSP Pattern Drawbacks

• Can lead to more work in a simple application.

• The View also shares some responsibility forcontrolling business processing.



Session Entity Facade (SEF)

• Applied to the EJB tier.


• Business objects have the responsibility of persistence,and the ability ot manage attributes.

• Business objects need to be represented by EntityBeans.

• You may need to use multiple entity beans to fulfill abusiness transaction.

• Business rules are also present in the transaction.



SEF Pattern Participants, Roles, andResponsibilities

• Attribute

• BusinessEntity

• BusinessSession

• DataAccessor



SEF Pattern StructureEJBSession

BusinessSession

<<EJBEntity>>BusinessEntity

<<Interface>>DAO

Attributemanages <<creator>> create()

<<accessor>> get..()

<<mutator>> set..()

<<finder>> findByPrimaryKey()

<<remove>> remove()

connect()

load()

store()

disconnect()

<<creator>> create()

<<accessor>> get..()

<<mutator>> set..()

<<user>> businessMethod()

<<user>> createBusinessEntity()

<<state>>isBoundToEntity()

<<state>>setBoundToEntity()

<<state>> bindBusinessEntity()

<<finder>> findBusinessEntity()

1..* 1..*

has

uses



SEF Pattern Collaborations (Steps 1-11)Client :BusinessSession :BusinessEntity :DAO

2: bindBusEntity(pk)

3: findBusEntity(pk)

4: findByPrimaryKey(pk)

5:load()

6:setBoundToEntity(Boolean)

7: get...()

9: set...(Attribute)

8: get...()

11:store()


1: create()



SEF Pattern Collaborations (Steps 12-20)

15: store()

Client :BusinessSession :BusinessEntity :DAO

19: store()

20: setBoundToEntity(Boolean)

17: setBoundToEntity(Boolean)

18: create(PrimaryKey)

16: createBusEntity(PrimaryKey, List)

13: get...()


12: busMethod(List)



SEF Pattern Constraints

• BusinessEntity represents the business object andits attributes

• BusinessEntity cannot contain any business logic.

• BusinessEntity must not expose all its attributes(using getters and setters) to the client tier

• Business logic is coded in a separateBusinessSession layer



SEF Pattern Benefits and Drawbacks

Benefits

• There is a separation of business logic and thepersistent object.

• None of the attributes and the get/set methods areexposed to the client layer, which avoids erroneous(intended or otherwise) operations on theBusinessEntity .

• If the method calls from the client are frequent, thenthis pattern is suitable because the BusinessSessionretains the state.

Drawback

• The facade must change if you add a new entity.



Business Delegate (BD)

• Can be used in the client tier, Web tier, and EJB tier.


• Business services represented by EJB beans must beaccessed by clients, either as Java technologyapplications or as Web tier components.

• Decouple the client requiring business service accessfrom the details of locating home interfaces, andinvoking remote methods.



BD Pattern Participants, Roles, andResponsibilities

• BusinessDelegate

• BusinessSession

• ServiceHandler



BD Pattern Structure

ServiceHandler

getService()

<<EJBSession>>BusinessSession

BusinessDelegate

<<EJBHome>>

get<...>()set<...>()

BusinessHome

lookup



BD Pattern Collaborations

:ServiceHandler :BusinessHome :BusinessSession:BusinessDelegate

1: getService()

2: lookup

3: create/remove/find

4: invoke



BD Pattern Constraints

• Busier delegate hides the service access.

• ServiceHandler handles the BusinessHomelookup.



BD Pattern Benefits

• Provides a contract for client access to business services

• Maintains uniformity of access to business services

• Decouples client business logic from access logic

• Allows for separation of client development roles

• Provides transparent access to legacy services.



BD Pattern Drawbacks

• Requires CORBA expertise

• Requires CORBA ORB on legacy system



Using J2EE Patterns – A HotelReservation System

• Princess Inn Hotel reservation system:

▼ Use case diagram

▼ Domain model

▼ Sequence diagram

▼ Patterns applied



Hotel Reservation Use Case Diagram

RegisterLogin

Check availability

Reserve room

View confirmed reservation

Cancel reservation



J2EE Patterns in the Domain Model

ReservationManager

ScheduleManager Room

reserveRoom()getAvailableRooms()

Reservation

checkAvailability()

selectRoom()

create()cancel()

makeReservation()getAvailableRooms()cancelReservation()

schedules

holds

creates

uses reserves



Reserve Room Sequence Diagram

:ReservationManager :ScheduleManager :Reservation:Customer

1: makeReservation()

2: checkAvailability()

:Room

3: create()

4: reserveRoom()5: selectRoom()

6: return

confirmation7: return

confirmation



J2EE Patterns in Reserve Room

• Requirements

▼ User interaction: Reserve Room

▼ Mediator View

• Workflow: Reserve Room

▼ Session Entity Facade

• Integrate: UI and Workflow

▼ Business Delegate



J2EE Patterns in Reserve Room

:Dispatcher :Helper :Delegate:Customer :Room:View:Reservation :Schedule

Mediator View PatternBusinessPattern

Session Entity FacadePattern

Man Manager :Reservation

RequestReservation authenticate

forwardgetProperty

getConfirmationmakeReservation

checkAvailability

create

reserveRoomselectRoom

return confirmationreturn

returnreturn

display



Check Your Progress

• Define Patterns

• Define Idioms

• List the goals of J2EE Patterns

• Describe the following J2EE patterns in detail:

▼ Mediator View - JSP (MVJSP)

▼ Session Entity Facade (SEF)

▼ Business Delegate (BD)



Think Beyond

• This module has presented only a few J2EE patterns.However, there are many morepatterns. Can you guesswhy these are important patterns in J2EE pplications?

• Of the “best practices” that you have seen in thiscourse, can you guess which of these contribute toother J2EE patterns, and why?



Module 10

Special Topics



Overview

• Objectives

• Relevance



Applicability of J2EE Technology

• The J2EE™ Blueprints’ Java™ Pet Store application isan example of Web-enabled consumer transactions.

▼ Business-to-Consumer (B2C)

• You can apply the J2EE programming model to manydifferent kinds of applications.

▼ Business-to-Business (B2B) web systems

▼ Enterprise resource planning (ERP)

▼ Workflow applications



Business-to-Business (B2B)

• Applications that web-enable business transactions:

▼ Interbank transactions

▼ Chemical feedstock auctions

▼ Distributor-to-distributor inventory exchange



When Is it a B2B Application?

• Difficult to tell the difference between B2B and B2Cbecause the division is somewhat arbitrary.

• Some B2B systems are almost identical to B2C.

▼ Example: www.grainger.com provides officeproducts using the web.



Interbank Transactions

• Banks require secure, auditable, “non-repudiable”transactions for:

▼ Letters of credit

▼ Interbank transfers

▼ “Signature guaranteed” transactions



Chemical Feedstock Auctions

• “Chemical feedstocks” are materials used in chemicalmanufacturing:

▼ Formaldehyde

▼ Methanol

▼ Ethylene

• Online feedstock auctions allow pharmaceuticalcompanies to find supplies nearby, optimizingfeedstock cost and shipping cost.



Distributors Sharing Inventory

• Heavy-equipment manufacturers and distributorsoften exchange inventory:

▼ For spare parts

▼ For unusual or popular configurations

• Existing systems require proprietary networks:

▼ Expensive

▼ Inflexible



Identrus for Interbank Transactions

• Identrus transactions are XML documents (structureddocuments).

• XML documents are signed using the sender’scertificate, which establishes the sender’s identity(authentication).

Identrusroot

Bank 1 Bank 2

TradingPartner

Manufacturer

3b

4

3a

1

2

56



Identrus, XML, and EDI

• EDI - Electronic Data Interchange is a standard forexchanging business transcations.

• Other similar standards are x.12 and EDIFACT

• EDI transactions are “structured documents”

• EDI transactions exchanged using X-25 VAN

• Combine EDI with XML to get ebXML

• Identrus allows trusted exchange of XML transactions

• Therefore, Identrus and XML yields a universal EDIusing the Web.



Why XML and EDI?

• Using XML-based EDI reduces cost of entrydramatically

• Web-based communications

• Common protocol (HTTP, HTTPS)

• Eliminates expensive X.25 VANS

• Standard software supports XML



Enterprise Resource Planning

• Really means enterprise integration.

• Integrated management of business data throughoutthe enterprise

• Major vendors: SAP, Peoplesoft, and JD Edwards

• Provides:

▼ Uniform data representation

▼ Uniform user interface

▼ Flexible reporting tools



Web-based ERP

• Web-based applications can provide a simple way toget a uniform thin-client interface.

• Most ERP applications have a Web-based interfaceavailable.

• Where does EJB fit in?

Client Presentation

Application Resource Data

tier tier

layer layer layer

Enterprise resource planning layer(ERP)



J2EE Technology Used in B2B

Client Presentation Business Integration Resource B2B Types

Member banksystems

XMLtransactionformating

Transactionsignedtransactions

Communicationconnector

Bankinglegacysystems

Interbanktransactions

Web clients List of offers Offer, order Web services,connector

ChemicalSystemLegacy

Chemicalauction

Distributorinventory sys-tems

XML Connector DistributorInventorySystem

Distributor-distributorinventory

JSP, servlet EJB Connector

Inventory

*

Parts



Workflow Application

• In any multistep business process, such as:

▼ Entering, verifying, packing, and shipping an order

▼ Receiving, entering, processing, and closing atrouble ticket or problem report

▼ Drafting, reviewing, and finalizing a contract

• Can be done by one person or many people

• Has a number of discrete steps over a relatively longtime, for example: a person interacts with anotherpeoson at each step like an assembly line.



Managing Workflows

• Workflows manage the work piece as it progresses..

Receivesorder

Verifiescredit

Order withcredit

authorization

Packitems forshipping

Receivesbox and

ships

Order entryclerk

Creditmanager

Packingclerk

Shippingdock

Transportationagency

Label forshipping

Customer

Order

s: shipment

[packed]

Order

s: shipment

[labelled]



A Workflow-based System

• Has the objects for the work pieces

• Has the objects for the worker roles (or workstations)

ORDER

items: list of items

addItem(item)

listItems()

Order Creditmanager

Packingclerk

Shippingdock

Transportationagententry

WorkStation



Work Pieces

• Work pieces are also called jobs or tasks.

• Usually contains a complicated state machine.

• Work stations have a queue of jobs to be performed.

Neworder

Authorizedorder

Packedorder

Creditauthorization

failed

Back-ordereditems

Orders waiting forcredit authorization

Creditmanager

Orders tobe placed



J2EE Technology in a WorkflowApplication

• A workflow system is just another domain model.

• Often the work piece has a set of workflow rules.

• Workflow is a common place to apply the strategypattern.



Check Your Progress


• Describe the best practices using J2EE technology thatcan be applied across all tiers




Think Beyond

• Are there other areas where you think J2EE technologywould work? If yes, please list them.

• Are there other areas where you think J2EE technologywould not work well? If so, please list them.



Appendix A

UML Quick Reference


Architecting and Designing J2EE Applications Appendix A, slide 2 of 21Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000 Revision A

Model the Business

• A modeling language such as UML is a graphicalnotation used with a process to communicate a design.

• Artifacts are documents that are developed during theprocess stages.



Package Dependency and Note

Package 1name

Stereotype name

namePackage 2

Note text



Class Diagram

Class name

AttributeAttribute: data_typeAttribute: data_type=init_value

OperationOperation(arg_list):result_type

Class name



Visibility and Properties

Class name

publicprotectedprivate

OperationOperation(arg_list):result_type

class attribute

+#-

ClassOperation()



Generalization and SpecializationRelationships

Class A

Class B Class DClass CClass B

Class A

<<interface>>

ClassA_Impl

Class A

Generalization

Interface Implementation



Association Classes

Class 1 Class 2Association Name

AssociationClass name

Attribute

Operation



Role Names and Derived Associations

Class 1 Class 2

AssociationAssociation Name

Role 1 Role 2* 0..1



Aggregation, Multiplicity WithDirection Indicators

Whole class name

Part1 class name Part2 class name

Aggregation Composite aggregation

Unidirectionalnavigability

Bidirectionalnavigability



Use Case Diagram

Use-case name

Actor name



State Diagram

Runnable

Blocked

Running

Initial stateTransition

Unblocked Blocking event

Scheduler

State node Final state

run() completesstart()



Object Diagrams

Count

- counter : int = 0- serialNumber : int

c1 : Count

serialNumber=1

c2 : Count

serialNumber=2

<<instanceOf >> <<instanceOf >>



Sequence Diagrams

Object 2Object 1

:Class nameActor name:actor class

2:Operation

3:Operation

4:Operation (parameter list)

1:Event(parameter

list)

5:Operation(parameter

list)

Scripttext

Morescript

text

Object 2 Object 2

return



Collaboration Diagrams

Object 1 : Class name

2:Operation

3:Operation(parameter list)

Object 2

Object 3 : Class name

1:Event

5:Operation (parameter list)

4:Operation (parameter list)Actor name:actor class



Deployment Diagram

:HTTPD :HTMLBrowser

TCP/IP

form

:Servlet Engine

:MyServlet

:Bean

Servlet

Printer

:Corporate Web Server:Bob’s PC

Parallel port



Use Case Driven Design

• Model the business with use cases.

• Use cases drive the architecture at every view.

Deployment ViewProcess View

Logical View

Use Case

Implementation View



Use CaseView

• This view shows the user’s requirements and is usedthrough all phases of the process and in allarchitectural views.

Checkbalance

<<uses>>

<<uses>>

Createaccount

Makedeposit

Makewithdrawal

Transferfunds

Checkbalance



Logical View

• Shows the functional requirements (or what the systemshould do for the end user).

Account1..* 1

1

*

Customer

TransactionSavings AccountChecking Account



Implementation View

• Shows the organization of static software modules interms of packaging and layering.

Session

Entity

DataAccess

UI

BusinessDelegate



Process View

• Shows the concurrent aspect of the system at runtime.

Receivewithdrawaltransaction

Checkmoney

Dispensemoney

Updateaccount

Completetransaction

Canceltransaction



Deployment View

• Shows how the components are mapped to theunderlying platforms.

Session

Entity

DataAccess

Database

UI

BusinessDelegate

TCP/IP

Persistenceserver



Appendix B

J2EE Technology Overview


Architecting and Designing J2EE Applications Appendix B, slide 2 of 42Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000 Revision A

The J2EE Architecture

HTTPSSL

Database

Applet Container

J2SE

Applet

EJB Container

J2SE

EJB

HTTPSSL

ApplicationClient Container

J2SE

ApplicationClient

JMS

JND

I

JDB

C

Web Container

J2SE

ServletJSP

JavaMail

JAF

JMS

JTA JD

BC

JND

I JTS

JavaMail

JAFJM

S

JTA JD

BC

JND

I JTS



The Client Tier

Browser

ApplicationClient Container

ApplicationClient

EIS TierWeb Tier

HTTP(S)

HTML

SSLHTMLXML

EJB Tier

firew

all

HTTPHTML RMI

RMI-IIOPXML

Browser

Applet

XML

HTTP(S)

JDBC



The Web Tier

• HTML supplies static content to the browser

• JSP supplies dynamic content to the browser

▼ JSP are the primary means for generating dynamicHTML and XML

▼ Use tag libraries (custom actions) to eliminatescriplet code

• You can use servlets to select a view (dispatching themamong a set of JSP pages)

• You can use servlets to generate non-textual media



Servlets

Client Browser

Data

Web Tier

SourceServlet

HTTP(S)

HTML

Query

Result

2. Servlet retrievesuser data from the

data source.

1. User requests a Web page from the Web server.

3. Using the data, the servlet generates a personalized page.



The Servlet Lifecycle

1. The Web server creates an instance of the servlet.

2. The Web server calls the servlet’s init method.

3. Each time a servlet is requested, the service methodis called.

4. The Web server calls the destroy method anddestroys the instance.

Ready

New Destroyed

destory()init()

service()



Why Use JSP?

• JSP pages are “inside-out” servlets:

▼ A JSP page is like an HTML page with embeddedJava technology code

▼ A JSP page is compiled (once) into a servlet class andthen executed for each request of that page

• With JSP, you can separate the presentation from thelogic

• JSP are similar to Active Server Pages (ASP), but JSPhave the power of Java technology



How Does JSP Technology Work?

This diagram shows how a JSP page is converted into a servletclass

Has the JSP filechanged?

Convert JSP intoservlet code

Compile servlet code

Load servlet class fileWeb server executesservlet

Yes

No

page request



The Application Tier

There are three main concepts to understand about the EJBtier:

• Distributed object frameworks and the networkprotocols that allow objects to communicate

• Remote object lookup using the Java Naming andDirectory Interface

• Enterprise JavaBeans that represent distributedbusiness services and objects



Distributed Object Frameworks

• RMI, JRMP

• CORBA

• JavaIDL

• RMI-IIOP



Stubs and Skeletons: the Proxy Pattern



RMI-IIOP

• A mapping of RMI to use the CORBA IIOP protocol.

org.omg.CORBA.Skeleton

RemoteObject

Caller

network transport layer (IIOP )

ORB ORB

Helper

Holder

COS NamingService

Stubnarrow

Object

Remote JVMCaller JVM

string_to_object

Functionality supplied by the CORBA API

Functionality generated by IDL compiler

Functionality written by the developer



JNDI

• Lookup service to decouple information from client

▼ Location of remote objects

▼ Environment variables

▼ Access to DataSource connections



Using JNDI

JNDI

Loose coupling to client through JNDI

Client

Hard coded in namespace

Homeobject

Homeobject

Server A

Server B



Using JNDI

<res-ref-name> jdbc/AccountDB </res-ref-name>

1. Look updata source

Namespace

AccountEJB

<res-type> javax.sql.DataSource </res-type>

2. Reference to a

Container

resource factory

3. Open aconnection

Resource factory

that accessesresource manager

4.

AccountDB

creates object



Defining EJB Technology

• Is a server component specification (for vendors)where components are:

▼ Customizable at deployment time

▼ Deployed on a compatible application server

▼ Portable to other application servers

• Separates and defines development stages:

▼ Component creation

▼ Application assembly

▼ Application deployment



Defining EJB Technology

• EJB technology enhances simplified access to services

▼ Transaction

▼ Security

▼ Naming

▼ Persistence

▼ Life cycle



EJB Programming Paradigm

(Deployer role)

Homeinterface

Remoteinterface

classEnterprise Bean

Container

Server A

EJBobject

Homeobject

Environment Properties

DDDeploymentdescriptor

file

Client interfaces

Business Logic

Environmentinformation

(Component developer)



EJB Architecture Overview

Container

Server A

Homeobject

EJBobject

EJBobject

Client A

Client B



The EJB Environment

Container

createfindremove

Server A

1

2

3

4

7

5

9

Server BServices

8

6

11

JNDI

EJBobject

Homeobject

Client

Naming Transaction Persistence Security

10

Environment Properties

JNDI



Types of EJBs

Session Bean Entity Bean

Private client resource Accessed by multiple clients concurrently

Client affects Bean’s state Bean represents state of data

Bean is not persistent; state can be storedin secondary memory

Bean is persistent; state is synchronizedwith corresponding state of data

Lifetime is normally controlled by client Lifetime corresponds to its persistent store

Normally created for use Normally located for use

Transaction participant (optional) Transactional by nature

Single-threaded Single-threaded by default

Mandatory since 1.0 specification Mandatory since 1.1 specification



Types of EJBs

Type When to use

Stateful session beans

Maintain information specific to a client betweenmethod calls.

Represent non-presistent objects

Represent work flow between business objects

Stateless session beans

Model reusable service objects

Provides high performance

Operates on multiple rows at a time

Provides procedural view of data

Entity beans Maintain persistent state as an object view of adatabase row.



Types of EJBsClient

Client

Client

Session Bean(client state)



row 1

row 2

row 3

row 4

row 5

Entity Bean(db row state)

row 1

row 2

row 3

row 4

row 5

EJB Object

EJB Object

EJB Object

EJB Object

Client

Client

Client



Session Bean

Stateful

• Contains client’s conversational state

• Can be passivated to release resources (save state whilepassivated)

Stateless

• No need to passivate, since no state is held

• Can be pooled for better performance



Entity Beans

• Transactional by nature and the state is synchronizedto data store.

• Represent state of data.

• Lifetime corresponds to persistent store.

• Normally located for use.



Overview of the Entity Bean RuntimeArchitecture

EJB object(key)

EJB object(key)

EJB object(key)

EJB object(key)

EJB object(key)

EJB object(key)

Entitybean

instance

Entitybean

instance

EJB object(key)

Entitybean

instance

Entitybean

instance

HomeObject Free

Pool

Entitybean

Entitybean

Entitybean

Entitybean

Entitybean

Entitybean

newInstance()setEntityContext(ctx)

ejbPassivate()

ejbactivate()

unsetEntityContext



Creating Entity Beans

EJBObject(key)

EJB object(key)

Entitybean

instance

1. Freepool

Entitybean

Entitybean

Entitybean

Entitybean

Entitybean

Entitybean

Data

2.create

3

4

5

6

7

11

8

Client

10

9

Homeobject Container



J2EE Application Life Cycle



Deployment Descriptor

• Portable property sheet for the EJB

• XML document

• Describes various attributes of one or more EJBs:

▼ Structural information

▼ Application assembly information

▼ Declaration of required resources

• One deployment descriptor per jar (multiple EJBs)

▼ META-INF/ejb-jar.xml

• Allows for post-compile customization of EJB



J2EE Roles

• Bean provider

• Application assembler

• Deployer

• Container developer

• Server developer

• System administrator



The EIS Integration Tier

• JDBC – the Java interface to relational databases

• Transactions – a mechanism to control data integrity

• Connectors – an adaptor mechanism for a variety ofbackend services, such as database, enterprise resourceplanning, and transaction processing systems

• Java Message Service – a mechanism for asynchronouscommunication between enterprise systems

• JavaMail – a mechanism to communicate to usersthrough electronic mail

• XML – a tool for data formatting



JDBC Overview

An API for database-independent connectivity between theJ2EE platform and databases.

DriverManagerAccess a Driver

Data

Statement

DatabaseDriver

Resultsset

Open a connection

Create a communication object

Execute an SQL query

Receive the results



JDBC Overview

DataSource

• Preferred way to open a connection

▼ Can offer automatic connection pooling anddistributed transactions

▼ Provides consistent access through JNDI for betterportability

• Required for EJB 1.1 and greater

• JDBC connections obtained throughjavax.sql.DataSource (resource factory)

• EJB container provides resource factory classes



Transactions

• J2EE supplies local and distributed transactions:

▼ A transaction is a group of actions; if one action fails,then all effects are “rolled back”; if all actionssucceed, then the effects are “committed”

• Declarative transactions:

▼ Declared through the deployment descriptor

▼ Separates transaction issues from business logic

• Programmatic transactions:

▼ Gives programmer control over transactionmechanisms through the Java Transaction API (JTA)



Transactions — JTA

• Java Transaction API (JTA)

▼ Allows applications to access transactions in amanner that is independent of specificimplementations.

▼ Specifies standard Java interfaces between atransaction manager and transactional application,the J2EE server, and the manager that controls accessto the shared resources.



Transactions — JTS

• Java Transaction Service (JTS)

▼ Specifies the implementation of a transactionmanager which supports JTA

▼ Implements the Java mapping of the OMG ObjectTransaction Service 1.1 specification



Connectors

• This architecture specification defines a set of contractsfor a resource adapter to support to plug in to anapplication server.

• Provides a Java solution to connectivity betweenapplication servers and Enterprise InformationSystems (EIS).

• Examples

▼ JDBC driver to connect to a relational database.

▼ A resource adapter to connect to an ERP system.

▼ A resource adapter to connect to a TP system.



Connectors

Following is a set of standard contracts between anapplication server and EIS:

• Connection management contract

Enables connection pooling

• Transaction management contract

Enables transactional access to EIS resourcemanagers

• Security contract

Enables a secure access to an EIS



JMS

• Java Message Service is a guaranteed form ofdelivering messages asynchronously.

• The middleware service handles the message’s routing,delivery, and network transfer.

• It supports:

▼ Point-to-point (PTP or Queue)

▼ Publish-and-subscribe (Topic)



JMS

• Used by EJB components (in EJB 2.0) to send messages

• Easy to deploy and administer

▼ Defines ConnectionFactories and Destinationsas administered objects (placed in a JNDI namingcontext)

▼ JMS clients look up and use these preconfiguredobjects

• Supports IMAP and SMTP (existing protocols)



JavaMail/JAF

• An API for sending and receiving email.

• The JavaBeans Activation Framework (JAF) integratessupport for MIME data types into the Java platform.



XML

• Standard and interoperable

• Platform-independent, not browser-specific

• Structured for business and other data

• Data-centric, not presentation-centric

Copyright 2000 Sun Microsystems Inc., 901 San Antonio Road, Palo Alto, California 94303, Etats-Unis. Tous droits réservés.

Ce produit ou document est protégé par un copyright et distribué avec des licences qui en restreignent l’utilisation, la copie, la distribution, et la décompilation. Aucune partie de ceproduit ou document ne peut être reproduite sous aucune forme, par quelque moyen que ce soit, sans l’autorisation préalable et écrite de Sun et de ses bailleurs de licence, s’il y en a.

Le logiciel détenu par des tiers, et qui comprend la technologie relative aux polices de caractères, est protégé par un copyright et licencié par des fournisseurs de Sun.Des parties de ce produit pourront être dérivées du systèmes Berkeley 4.3 BSD licenciés par l’Université de Californie. UNIX est une marque déposée aux Etats-Unis et dans d’autrespays et licenciée exclusivement par X/Open Company Ltd.

Sun, Sun Microsystems, le logo Sun, Java, JavaBeans, Enterprise JavaBeans, Solaris, Java Server Pages, JDBC, JavaMail, et Write Once, Run Anywhere sont desmarques de fabrique ou des marques déposées de Sun Microsystems, Inc. aux Etats-Unis et dans d’autres pays.

Toutes les marques SPARC sont utilisées sous licence sont des marques de fabrique ou des marques déposées de SPARC International, Inc. aux Etats-Unis et dans d’autres pays.

Les produits portant les marques SPARC sont basés sur une architecture développée par Sun Microsystems, Inc.

UNIX est une marques déposée aux Etats-Unis et dans d’autres pays et licenciée exclusivement par X/Open Company, Ltd.

L’interfaces d’utilisation graphique OPEN LOOK et Sun™ a été développée par Sun Microsystems, Inc. pour ses utilisateurs et licenciés. Sun reconnaît les efforts de pionniers de Xeroxpour larecherche et le développement du concept des interfaces d’utilisation visuelle ou graphique pour l’industrie de l’informatique. Sun détient une licence non exclusive de Xerox surl’interface d’utilisation graphique Xerox, cette licence couvrant également les licenciés de Sun qui mettent en place l’interface d’utilisation graphique OPEN LOOK et qui en outre seconforment aux licences écrites de Sun.

L’accord du gouvernement américain est requis avant l’exportation du produit.

Le système X Window est un produit de X Consortium, Inc.

LA DOCUMENTATION EST FOURNIE “EN L’ETAT” ET TOUTES AUTRES CONDITIONS, DECLARATIONS ET GARANTIES EXPRESSES OU TACITES SONT FORMELLEMENTEXCLUES, DANS LA MESURE AUTORISEE PAR LA LOI APPLICABLE, Y COMPRIS NOTAMMENT TOUTE GARANTIE IMPLICITE RELATIVE A LA QUALITE MARCHANDE, AL’APTITUDE A UNE UTILISATION PARTICULIERE OU A L’ABSENCE DE CONTREFAÇON.

Architecting and Designing J2EE Applications iCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Course Contents

About This Course ....................................................................................................................ivCourse Goal ................................................................................................................................................ vCourse Overview ...................................................................................................................................... viCourse Map ...............................................................................................................................................viiModule-by-Module Overview ..............................................................................................................viiiCourse Objectives ....................................................................................................................................... xSkills Gained by Module ......................................................................................................................... xiiGuidelines for Module Pacing ..............................................................................................................xiiiTopics Not Covered ................................................................................................................................ xivHow Prepared Are You? ......................................................................................................................... xvIntroductions ........................................................................................................................................... xviHow to Use Course Materials ..............................................................................................................xviiHow to Use the Icons ............................................................................................................................xviiiTypographical Conventions and Symbols .......................................................................................... xixCommon Abbreviations and Acronyms .............................................................................................. xxi

Architect and Architecture ....................................................................................................1-1Overview .................................................................................................................................................. 1-2The Architect’s Role ................................................................................................................................ 1-3Development Team ................................................................................................................................. 1-4Defining Architecture ............................................................................................................................. 1-5The Art of Architecture .......................................................................................................................... 1-6Defining Architecture Terminology ..................................................................................................... 1-7Architecture and Design ........................................................................................................................ 1-8Architectural Building Blocks ............................................................................................................... 1-9Capabilities and Design Goals ............................................................................................................ 1-10


Architecting and Designing J2EE Applications iiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Process and Artifacts ............................................................................................................................ 1-11Communication Mechanisms .............................................................................................................. 1-12Architectural Fundamentals ................................................................................................................ 1-13Abstraction ............................................................................................................................................. 1-14Abstraction – Surface Area .................................................................................................................. 1-15Check Your Progress ............................................................................................................................ 1-17Think Beyond ........................................................................................................................................ 1-18

Principles of Architecture ......................................................................................................2-1Overview .................................................................................................................................................. 2-2Architecture and the Cube ..................................................................................................................... 2-3Layers and Tiers ...................................................................................................................................... 2-4Capabilities .............................................................................................................................................. 2-5Manageability .......................................................................................................................................... 2-9Flexibility ................................................................................................................................................ 2-10Flexibility Metrics .................................................................................................................................. 2-12The Effect of Flexibility ........................................................................................................................ 2-13Performance ........................................................................................................................................... 2-14Capacity .................................................................................................................................................. 2-17Latency Space ........................................................................................................................................ 2-18Scalability ............................................................................................................................................... 2-19Vertical Scalability ................................................................................................................................ 2-20Horizontal Scalability ........................................................................................................................... 2-21The Effect of Scalability ........................................................................................................................ 2-22Extensibility ........................................................................................................................................... 2-23Testability ............................................................................................................................................... 2-26Security ................................................................................................................................................... 2-27Security Policy ....................................................................................................................................... 2-29Service-based Capabilities ................................................................................................................... 2-30Why Service-Based Architectures? ..................................................................................................... 2-31


Architecting and Designing J2EE Applications iiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Creating Service-Based Architectures ................................................................................................ 2-32Heuristics for Developing Service-Based Architectures ................................................................. 2-33Architectural Design Goals .................................................................................................................. 2-34Modularity ............................................................................................................................................. 2-35Protection and Exposure ...................................................................................................................... 2-36Component Extensibility ..................................................................................................................... 2-37Component Extensibility Using Subclassing .................................................................................... 2-38Component Extensibility Using Composition .................................................................................. 2-39Roles and Responsibilities ................................................................................................................... 2-40Contracts ................................................................................................................................................ 2-42Types of Contracts ................................................................................................................................ 2-43Pluggable Behavior ............................................................................................................................... 2-44Providing System Requirements ........................................................................................................ 2-45Process .................................................................................................................................................... 2-46Assumptions, Risks, and Constraints (ARC) .................................................................................... 2-47Model the Business ............................................................................................................................... 2-48Check Your Progress ............................................................................................................................ 2-49Think Beyond ........................................................................................................................................ 2-50

Creating an Architecture Using J2EE Technology .............................................................3-1Overview .................................................................................................................................................. 3-2What Is J2EE Technology? ..................................................................................................................... 3-3J2EE Architecture .................................................................................................................................... 3-7Layers and Tier With J2EE Technology ............................................................................................... 3-9Flexibility and J2EE Technology ......................................................................................................... 3-10Manageability and J2EE Technology ................................................................................................. 3-11J2EE and Latency Space ....................................................................................................................... 3-12Vertical Scalability ................................................................................................................................ 3-13Horizontal Scalability ........................................................................................................................... 3-14Extensiblity and J2EE Technology ...................................................................................................... 3-15


Architecting and Designing J2EE Applications ivCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Essential Patterns .................................................................................................................................. 3-16Proxy Pattern ......................................................................................................................................... 3-17Decorator Pattern .................................................................................................................................. 3-18Factory Method Pattern ....................................................................................................................... 3-20Abstract Factory Pattern ...................................................................................................................... 3-21Check Your Progress ............................................................................................................................ 3-22Think Beyond ........................................................................................................................................ 3-23

J2EE Best Practices – Overview ...........................................................................................4-1Overview .................................................................................................................................................. 4-2Experience in Creating Architectures .................................................................................................. 4-3J2EE Architecture .................................................................................................................................... 4-4J2EE Best Practices and Guidelines ...................................................................................................... 4-5Best Practice – Client Tier ...................................................................................................................... 4-6Best Practice – MVC Pattern .................................................................................................................. 4-7Best Practice – Business Objects ............................................................................................................ 4-8Best Practice – Controllers ..................................................................................................................... 4-9Check Your Progress ............................................................................................................................ 4-12Think Beyond ........................................................................................................................................ 4-13

J2EE Best Practices – Web Tier ............................................................................................5-1Overview .................................................................................................................................................. 5-2Web Tier ................................................................................................................................................... 5-3Applying the MVC Pattern To Web Tier Architecture ...................................................................... 5-4Best Practice – Web Tier Components ................................................................................................. 5-5Front Component .................................................................................................................................... 5-6Presentation Component ....................................................................................................................... 5-7Best Practices – JSPs and Servlets ......................................................................................................... 5-8JSP Features ............................................................................................................................................ 5-10Localization and Internationalization ................................................................................................ 5-11


Architecting and Designing J2EE Applications vCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Internationalization Process ................................................................................................................ 5-12Internationalization .............................................................................................................................. 5-13Check Your Progress ............................................................................................................................ 5-14Think Beyond ........................................................................................................................................ 5-15

J2EE Best Practices – EJB Tier ..............................................................................................6-1Overview .................................................................................................................................................. 6-2The EJB Tier ............................................................................................................................................. 6-3Guidelines – Using Session Beans ........................................................................................................ 6-4Guidelines – Using Entity Beans ........................................................................................................... 6-5Best Practice – Data Access Objects ...................................................................................................... 6-6Best Practice – Value Objects ................................................................................................................. 6-7Best Practice – Session Bean Facade ..................................................................................................... 6-8Master-Detail Modeling ......................................................................................................................... 6-9Check Your Progress ............................................................................................................................ 6-10Think Beyond ........................................................................................................................................ 6-11

J2EE Best Practices – EIS Integration Tier .........................................................................7-1Overview .................................................................................................................................................. 7-2EIS Integration Tier ................................................................................................................................. 7-3Integrating an EIS .................................................................................................................................... 7-4EIS Guidelines – Data Access ................................................................................................................ 7-5EIS Access Objects ................................................................................................................................... 7-6Guidelines – Access Objects .................................................................................................................. 7-7Guidelines – Access Objects .................................................................................................................. 7-8Guidelines – Connections ...................................................................................................................... 7-9Check Your Progress ............................................................................................................................ 7-10Think Beyond ........................................................................................................................................ 7-11


Architecting and Designing J2EE Applications viCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

J2EE Best Practices — Services ............................................................................................7-1Overview .................................................................................................................................................. 7-2Security ..................................................................................................................................................... 7-3Security Guidelines ................................................................................................................................. 7-5Security Terminology ............................................................................................................................. 7-6Authentication ......................................................................................................................................... 7-7Protection Domains ................................................................................................................................ 7-9Authorization ........................................................................................................................................ 7-10Declarative and Programmatic Authorization ................................................................................. 7-12Controlling Access to Resources ......................................................................................................... 7-14Protecting Messages ............................................................................................................................. 7-15Auditing ................................................................................................................................................. 7-16Transactions ........................................................................................................................................... 7-17Transaction Guidelines in Web Tier ................................................................................................... 7-18Transaction Guidelines in EJB Tier ..................................................................................................... 7-19EJB Tier – Container-Managed Transaction Demarcation .............................................................. 7-20Transaction Attributes .......................................................................................................................... 7-21Transaction Guidelines in EIS Integration Tier ................................................................................ 7-22Compensating Transactions ................................................................................................................ 7-23Check Your Progress ............................................................................................................................ 7-24Think Beyond ........................................................................................................................................ 7-25

J2EE Patterns ..........................................................................................................................9-1Overview .................................................................................................................................................. 9-2Introducing J2EE Patterns ...................................................................................................................... 9-3Defining Patterns .................................................................................................................................... 9-4Defining Idioms ....................................................................................................................................... 9-5Using the J2EE Patterns .......................................................................................................................... 9-6Modularity ............................................................................................................................................... 9-7Protection and Exposure ........................................................................................................................ 9-8


Architecting and Designing J2EE Applications viiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Component Extensibility ....................................................................................................................... 9-9Roles and Responsibilities ................................................................................................................... 9-10Contracts ................................................................................................................................................ 9-11Pluggable Behavior ............................................................................................................................... 9-12Performance ........................................................................................................................................... 9-13J2EE Patterns Categories ...................................................................................................................... 9-15Sample J2EE Patterns ............................................................................................................................ 9-16Mediator View - JSP (MVJSP) ............................................................................................................. 9-17MVJSP Pattern Participants, Roles and Responsibilities ................................................................. 9-18MVJSP Pattern Structure ...................................................................................................................... 9-19MVJSP Pattern Collaborations ............................................................................................................ 9-20MVJSP Pattern Constraints .................................................................................................................. 9-21MVJSP Pattern Benefits ........................................................................................................................ 9-22MVJSP Pattern Drawbacks .................................................................................................................. 9-23Session Entity Facade (SEF) ................................................................................................................. 9-24SEF Pattern Participants, Roles, and Responsibilities ...................................................................... 9-25SEF Pattern Structure ............................................................................................................................ 9-26SEF Pattern Collaborations (Steps 1-11) ............................................................................................ 9-27SEF Pattern Collaborations (Steps 12-20) .......................................................................................... 9-28SEF Pattern Constraints ....................................................................................................................... 9-29SEF Pattern Benefits and Drawbacks ................................................................................................. 9-30Business Delegate (BD) ........................................................................................................................ 9-31BD Pattern Participants, Roles, and Responsibilities ....................................................................... 9-32BD Pattern Structure ............................................................................................................................. 9-33BD Pattern Collaborations ................................................................................................................... 9-34BD Pattern Constraints ......................................................................................................................... 9-35BD Pattern Benefits ............................................................................................................................... 9-36BD Pattern Drawbacks ......................................................................................................................... 9-37Using J2EE Patterns – A Hotel Reservation System ........................................................................ 9-38Hotel Reservation Use Case Diagram ................................................................................................ 9-39J2EE Patterns in the Domain Model ................................................................................................... 9-40


Architecting and Designing J2EE Applications viiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Reserve Room Sequence Diagram ...................................................................................................... 9-41J2EE Patterns in Reserve Room ........................................................................................................... 9-42

Special Topics .......................................................................................................................10-1Overview ................................................................................................................................................ 10-2Applicability of J2EE Technology ....................................................................................................... 10-3Business-to-Business (B2B) .................................................................................................................. 10-4When Is it a B2B Application? ............................................................................................................. 10-5Interbank Transactions ......................................................................................................................... 10-6Chemical Feedstock Auctions ............................................................................................................. 10-7Distributors Sharing Inventory ........................................................................................................... 10-8Identrus for Interbank Transactions ................................................................................................... 10-9Identrus, XML, and EDI ..................................................................................................................... 10-10Why XML and EDI? ............................................................................................................................ 10-11Enterprise Resource Planning ........................................................................................................... 10-12Web-based ERP ................................................................................................................................... 10-13J2EE Technology Used in B2B ........................................................................................................... 10-14Workflow Application ....................................................................................................................... 10-15Managing Workflows ......................................................................................................................... 10-16A Workflow-based System ................................................................................................................ 10-17Work Pieces .......................................................................................................................................... 10-18J2EE Technology in a Workflow Application ................................................................................. 10-19Check Your Progress .......................................................................................................................... 10-20Think Beyond ...................................................................................................................................... 10-21

UML Quick Reference ...........................................................................................................A-1Model the Business ................................................................................................................................ A-2Package Dependency and Note ........................................................................................................... A-3Class Diagram ......................................................................................................................................... A-4Visibility and Properties ....................................................................................................................... A-5


Architecting and Designing J2EE Applications ixCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

Generalization and Specialization Relationships .............................................................................. A-6Association Classes ................................................................................................................................ A-7Role Names and Derived Associations ............................................................................................... A-8Aggregation, Multiplicity With Direction Indicators ....................................................................... A-9Use Case Diagram ................................................................................................................................ A-10State Diagram ....................................................................................................................................... A-11Object Diagrams ................................................................................................................................... A-12Sequence Diagrams .............................................................................................................................. A-13Collaboration Diagrams ...................................................................................................................... A-14Deployment Diagram .......................................................................................................................... A-15Use Case Driven Design ...................................................................................................................... A-16Use CaseView ....................................................................................................................................... A-17Logical View ......................................................................................................................................... A-18Implementation View .......................................................................................................................... A-19Process View ......................................................................................................................................... A-20Deployment View ................................................................................................................................ A-21

J2EE Technology Overview ..................................................................................................B-1Servlets ......................................................................................................................................................B-5The Servlet Lifecycle ...............................................................................................................................B-6Why Use JSP? ...........................................................................................................................................B-7How Does JSP Technology Work? .......................................................................................................B-8The Application Tier ...............................................................................................................................B-9Distributed Object Frameworks ..........................................................................................................B-10Stubs and Skeletons: the Proxy Pattern .............................................................................................B-11RMI-IIOP ................................................................................................................................................B-12JNDI ........................................................................................................................................................B-13Using JNDI .............................................................................................................................................B-14Using JNDI .............................................................................................................................................B-15Defining EJB Technology .....................................................................................................................B-16


Architecting and Designing J2EE Applications xCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services August 2000, Revision A

EJB Architecture Overview ..................................................................................................................B-19The EJB Environment ...........................................................................................................................B-20Types of EJBs .........................................................................................................................................B-21Types of EJBs .........................................................................................................................................B-23Session Bean ...........................................................................................................................................B-24Entity Beans ...........................................................................................................................................B-25Overview of the Entity Bean Runtime Architecture ........................................................................B-26Creating Entity Beans ...........................................................................................................................B-27J2EE Application Life Cycle .................................................................................................................B-28Deployment Descriptor ........................................................................................................................B-29J2EE Roles ...............................................................................................................................................B-30The EIS Integration Tier .......................................................................................................................B-31JDBC Overview .....................................................................................................................................B-32JDBC Overview .....................................................................................................................................B-33Transactions ...........................................................................................................................................B-34Transactions — JTA ..............................................................................................................................B-35Connectors .............................................................................................................................................B-37JMS ..........................................................................................................................................................B-39JMS ..........................................................................................................................................................B-40JavaMail/JAF .........................................................................................................................................B-41XML .........................................................................................................................................................B-42

Documents

Sun Educational Services - SL-425 - Architect Ing and Designing J2EE Applications