j2ee architecture workshop peter varhol product manager, compuware columnist, java pro june 6, 2004
TRANSCRIPT
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
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