J2EE Architecture WorkshopJ2EE Architecture Workshop

Peter VarholPeter VarholProduct Manager, Compuware

Columnist, Java Pro

June 6, 2004

About Peter VarholAbout Peter Varhol

Web application columnist for Java Pro– Numerous articles for Web Services Journal, Dr.

Dobbs Journal, XML, Byte, and others

Former college professor and department chair in computer science and mathematics

Graduate degrees in computer science and applied mathematics

Compuware product manager for developer products

peter@petervarhol.com

AgendaAgenda

Building Bulletproof Patterns Delivering on the Promise of SOA Working with Foreign Platforms Considering Security Architecture in Action Conclusions and Discussion

Building Bulletproof PatternsBuilding Bulletproof Patterns

What is a Pattern? The Pattern Lifecycle Gathering Data Across the Lifecycle Feedback and Modification

A Pattern . . .A Pattern . . .

Describes a single kind of problem. Describes the context in which the problem occurs. Describes the solution as a constructable software entity. Describes design steps or rules for constructing the

solution. Describes the forces leading to the solution. Describes evidence that the solution optimally resolves

forces. Describes details that are allowed to vary, and those that

are not Describes at least one actual instance of use. Describes evidence of generality across different

instances. Describes or refers to variants and subpatterns. Describes or refers to other patterns that it relies upon.

Kinds of Software PatternsKinds of Software Patterns

Design Patterns (software design; often object-oriented):– architecture (systems design) – design (component interactions) – programming idioms (language-specific

techniques/style)

Analysis Patterns (recurring & reusable analysis models)

Organization Patterns (structure of organizations/projects)

Process Patterns (software process design)

How Patterns Can Simplify LifeHow Patterns Can Simplify Life

Patterns are reusable code– Define code activities rather than objects

Only certain people in an organization can implement patterns– A separate business practices team– Candidate patterns can come from all developers

Patterns are useful across the entire life cycle– Patterns can be made “bullet-proof”– Incorporate best practices in design and

implementation– Tested in production and modified based on

operational feedback

Patterns Help Because They . . .Patterns Help Because They . . .

Solve "real world" problems Capture domain expertise Document design decisions and rationale Reuse wisdom and experience of master

practitioners Convey expert insight to novices Form a shared vocabulary for problem-solving Show more than just the solution:

– context (when and where) – forces (trade-off alternatives, misfits, goals+constraints) – resolution (how and why the solution balances the

forces)

Requirements of PatternsRequirements of Patterns

Codify a commonly used action– To prevent duplication of code

Define at a level that is useful but not limiting– Abstracted from an implementation

Express proven techniques clearly and simply– Communicate both problem and solution to developers

Offer different strategies for implementation– The developer can choose based on the requirements of

the application

Consider the Following PatternConsider the Following Pattern

What Makes a Pattern Bulletproof?What Makes a Pattern Bulletproof?

Developed to solve a class of problems Implemented for one or more of those

problems Functionally tested for correct behavior Load tested for performance and scalability Monitored in production for real world

behavior Feedback to the pattern at all checkpoints Incremental improvements to pattern

behavior and performance

The Pattern LifecycleThe Pattern Lifecycle

Identify a candidate pattern– similar problems recur across multiple projects

Document its characteristics using the pattern template

Apply the “Rule of Three”– Determine if it can be used across projects

Refine, document, and publish Monitor in test and production and modify

as needed

Using the LifecycleUsing the Lifecycle

Design Pattern Implementation

– Does the implementation properly reflect the pattern?

Functional test– Does it do what it supposed to do?

– Does the implementation catch error conditions?

Load test– Does the pattern scale?

Production– Does it use system and network resources sparingly?

Feeding Back to the Design PatternFeeding Back to the Design Pattern

Problems with implementation– Lack of developer training

Problems with QA– Lack of developer training, incorrect pattern

design, incomplete use cases

Problems with load testing– Poor pattern design, lack of forethought of real

world use

Problems with production– Poor pattern design, lack of understanding of real

world resource use

SummarySummary

Patterns codify best practices Patterns guide developers in

implementation Incorrect results must be reflected in

improvements to patterns Incremental improvements based on real

world feedback will make patterns more robust– Developers will rely on them– Projects will be implemented more quickly and

consistently

Delivering on the Promise of SOADelivering on the Promise of SOA

Loose coupling among interacting software agents– Data and logic become separated

Reduce (though not eliminate) dependencies among components

Making applications extensible means they can adapt– New versions are easier to build . . .– While still constraining the design

The Web Service is Not Just Another New The Web Service is Not Just Another New LibraryLibrary

Might be a different platform– Java, .NET, or mainframe

Rarely local to the application– . . . Or even the enterprise

It may do multiple tasks– Check the status of a shipment– Issue shipping authorization

Rarely static– The interface only may stay static; or– Query the WSDL

Architecting a Successful SOAArchitecting a Successful SOA

Technical challenges are significant– But not the biggest issue

More than just building web services– Services that support existing business practices– While enabling new ones to be implemented

rapidly

The latter is the hard part– Anticipating future application needs– Must be tied into corporate strategy activities

Steps to building an effective SOA

Know the BusinessKnow the Business

The concepts behind business processes, yes But also the mechanics

– What are the steps involved and why are they important

– It helps to have designed some of the processes involved

Why?– What parts of the process can be packaged as a

service– How users and client applications will interact with

that service– How a service might be useful in the future

Understand the Mechanics of Web ServicesUnderstand the Mechanics of Web Services

Interfaces– SOAP– WSDL– UDDI

Web service components– Listener– Façade– Business logic– Data access– The data itself

Narrow Down the CandidatesNarrow Down the Candidates

Consider these questions:– Is this basic function used across multiple

business processes?– Can it be generalized enough to serve multiple

roles?– Is it discrete enough to run efficiently and not

add complexity to the application architecture?– Can it fully operate without manual intervention?– Is it likely to be useful in future business

opportunities?

Choose a small set of candidate Web services based on these considerations

Implement a Candidate Web ServiceImplement a Candidate Web Service

Initially build one or two Web services– Get experience in applying the technology– Use these services as a test bed

Put that Web service into production Collect data

– Times called, by which client applications– Uptime and response statistics

Feed back results into SOA plans

Understand How SLAs Fit InUnderstand How SLAs Fit In

Run it with real users Support it when real users are counting on

it Collect data

– response time– Scalability– Reliability

Project that data across an entire SOA Does it meet SLAs for availability and

capacity?

Work Around Existing SuccessesWork Around Existing Successes

Understand why existing services work Apply those principles to expanding the

SOA– Determine critical data points– Determine processing required for critical data– Identify opportunities for bundling data/processing– Use these opportunities to create more Web

services

Continue measuring results and feeding back into the SOA

Working With Foreign PlatformsWorking With Foreign Platforms

J2EE and Microsoft .NET– Client and web service

What if the Web service doesn’t work? Characterizing the problem Diagnosing the problem Helping to make the Web service robust

Working With Foreign PlatformsWorking With Foreign Platforms

Is the platform really irrelevant?– Web services can provide the answer

How do you leverage the strengths of the platform– Java/J2EE– Microsoft .NET

A typical response:– .NET is use for the UI, because of the strength of

the development platform– Java is used for the Web service, because of

scalability and reliability

The DilemmaThe Dilemma

So what if it doesn’t work?– Application developers have no insight into the

Web service– The Web service owners can’t find a problem

How can you diagnose something you can’t see?

Typical ProblemsTypical Problems

The web service fails entirely– Could mean a bug or object leak

The web service returns the wrong answer– Logic error or unexpected behavior

The web service returns results too slowly– Is it the Web service or the database?

The web service fails to scale– Inefficient code or bottlenecks that aren’t caught

until load is applied

What Makes it a Challenge?What Makes it a Challenge?

How do you know there’s a problem?– Is it the Web service or your application?

How do you diagnose the problem?– You have no visibility– It may be on an unfamiliar platform

How do you convince the owners that there’s a problem?– Their tests come up okay– No other consumer has complained

Steps to Meet the ChallengeSteps to Meet the Challenge

Encounter a problem Characterize the problem Analyze the parameters of the

problem Do some diagnosis of the problem Turn over analysis and diagnosis to

the Web service owner

Consider the ScenarioConsider the Scenario

A Microsoft .NET Application– Consuming a Java Web service– Everything works in the development lab

During scalability test– The application scales to only 10 users

Then it crashes– The requirement is for 100 users

How to Measure ScalabilityHow to Measure Scalability

The “pizza test”– Everyone come in Saturday– When I say “go”, everyone hit the button

Well, it seemed slower– But how much slower?– OK, I have the stopwatch now, everyone

do it again

How to Measure ScalabilityHow to Measure Scalability

Automate the load test– One person, hundreds of users– Timings are exact– Behaviors are charted

No pizza necessary

Finding a Scalability ProblemFinding a Scalability Problem

Identifying the ProblemIdentifying the Problem

Characterize the problem– The Web service performs more slowly as the

number of users grows

Analyze the parameters of the problem– Memory use grows as users are added– Memory does not decrease as users are removed

Tentative Hypothesis– There is an object leak of some type in the Web

service

Problem DiagnosisProblem Diagnosis

In some cases, that may be enough for the Web services owner

But further diagnosis may be needed– Where is the leak?– How bad is it?– What does it prevent you from doing?

How do you find the object leak if you don’t own the code?

About Java and Object LeaksAbout Java and Object Leaks

Garbage collection doesn’t solve memory problems

Most developers take memory management for granted– Seemingly harmless constructs can have

significant consequences– Developers need to understand cause and

effect

Consider this ProblemConsider this Problem

java.lang.String:String r = new String ();For (int I-0< limit; I+=1) {

r = r + compute(i);}return r;

A new String r is allocated as a temporary object

The current r is copied into that new instance compute(i) is added to the new r string This is done each time through the above loop

Addressing the ProblemAddressing the Problem

The end result is the accumulation of temporary objects

Here’s how to resolve this problem:

java.lang.StringBuffer:StringBuffer r = new StringBuffer();For (int i=0; i< limit; i+=1) {r.append(compute(i));}return r.toString();

Finding Common GroundFinding Common Ground

This kind of problem can occur on any SOA platform

This example happens to be Java– It could just as easily be C# in .NET

Application developers may not be familiar with the service platform/language– But they can help make it bullet-proof– By collecting and analyzing data in the context of

their application

Finding the ProblemFinding the Problem

Benefits of this ApproachBenefits of this Approach

Developers better understand Web service strengths and limitations– This information is essential when architecting and

building applications

Service consumers can field test the work of service providers– May provide the only true test of the Web service

SOA participants can bullet-proof applications that use SOA

SummarySummary

SOA has the potential to improve and accelerate application development– While making applications more robust and

extensible

But only if the application can count on its services for performance and scalability

Service consumers can help– By testing the service with their application– By analyzing and diagnosing problems within the

context of their application

Considering SecurityConsidering Security

Types of intruders– External– Internal

Reason for intrusion– To show it could be done– To compromise data– To disrupt normal operations

Method of intrusion– Application-level– OS-level

Preventing CompromisePreventing Compromise

No practical system is immune to compromise There is a tradeoff between security and

usability– The more security an application, the less convenient

to use– And visa versa– So the question is really . . .

How can I manage application security to achieve the necessary level of protection while still getting the benefits of the application?

What Can Go Wrong?What Can Go Wrong?

Authentication– Authentication is inadequate– Account information is compromised

Access– Too much access– Session data available outside the session

Destruction– Delete running programs– Delete data

Denial of service

Bandwidth throttling reduces denial of service (DoS) attacks. This prevents applications from becoming swamped by continuous and undesired requests from malicious applications or users.

Encryption enables secure communication. Authentication prevents identity spoofing. Authentication verifies credentials against a data

store. Identity flows between the application tiers (optional). Auditing reduces repudiability. Authorization prevents data tampering and exposure

threats.

Security ConsiderationsSecurity Considerations

Security goals Security risks Authentication Authorization Securing data transmission Impersonation Delegation Operating system security Physical access Code access

Looking at Authentication on Multiple Looking at Authentication on Multiple LevelsLevels

JSP Authentication PatternJSP Authentication Pattern

Be aware of security requirements– from a business perspective– From a technical perspective

Implications that a chosen security model can have on:– Performance– Scalability– deployment

The Pattern DetailsThe Pattern Details

Use roles for authentication– Manager– Normal user– Administrator

Rules assigned to roles Authorization based on OS authentication Other Authorizations

– Checking whether a user has permissions to perform specific actions in the application.

– Checking whether a user has permission to access application resources

Authentication MethodsAuthentication Methods

Server and client operating systems Client browser type Number of users Location and type of:

– User name– Password database

Deployment considerations Application type Data sensitivity

Performing Authorization in an Enterprise Performing Authorization in an Enterprise Application Application

User interface tier Business tier Data tier

User Interface TierUser Interface Tier

Configure system authorization to control entry to the user interface

Defend against the user accessing the user interface elements at an incorrect stage– by authorizing the user when each form or page loads

Do not base security only on authorization in the UI

If the user interface limits the data the user can view, don't read unnecessary data– this prevents any potential leak of the restricted data

as it travels around the network

Authorization in the Business TierAuthorization in the Business Tier

Perform authorization whenever you have to execute a business process– Factor authorization capabilities into utility

components– Perform authorization checks at the beginning of

high-level processes– This allows you to configure authorization in fewer

places, thus easing maintenance– perform authorization within each publicly

accessible method because calls to these methods may not have passed an authorization check

Authorization in the Data TierAuthorization in the Data Tier

Perform authorization to limit access to data, or prevent data from being modified– Data Access Logic Components– Stored Procedures– Database Security Features

Security SummarySecurity Summary

We use security for a number of different goals– Authentication and authorization– Auditing– Managing risks

Authentication alone may not be enough Consider applying security at each tier Both grant and prohibit access

Architecture in ActionArchitecture in Action

Architecture After the Fact Structure Analysis of Applications Refactoring Application Structure

Architecture After the FactArchitecture After the Fact

Is it possible to rearchitect existing applications?– Refactoring– Web services

Automate the process– Identify code for refactoring and perform the

operation– Encapsulate existing code in a Web services

wrapper

Package Structure AnalysisPackage Structure Analysis

What is package structure analysis? Two automated methods

– Compuware Optimal Advisor– IBM Structural Analysis for Java (SA4J) (on

Alphaworks)

Design ValidationDesign Validation

Code ValidationCode Validation

Go to Line of CodeGo to Line of Code

Explore Package DesignExplore Package Design

Package with Most Cyclic DependenciesPackage with Most Cyclic Dependencies

Identifying Refactoring in the PackageIdentifying Refactoring in the Package

Refactored Package StructureRefactored Package Structure

Summary and ConclusionsSummary and Conclusions

Application lifecycle increasing in complexity– Web services– Multiple platforms– Security– Architecture and refactoring

Patterns can help– Patterns cover a wide range of development needs– Patterns must be bullet-proof

Don’t take on the application lifecycle alone– Tools and techniques