Best practice adoption (and lack there of)
-
Upload
john-pape -
Category
Technology
-
view
376 -
download
3
description
Transcript of Best practice adoption (and lack there of)
© 2008 IBM Corporation
Best Practice Adoption (and lack there-of)
John Pape, WebSphere SWAT
IBM Software Group
Confidential | Date | Other Information, if necessary
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation2
Agenda
What is a best practice?Why do we care about them?Best PracticesDevelopment
Infrastructure
Procedural
Anti-Practices
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation3
Agenda
What is a best practice?Why do we care about them?Best PracticesDevelopment
Infrastructure
Procedural
Anti-Practices
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation4
What is a “best practice”?
“Best Practice is a management idea which asserts that there is a technique, method, process, activity, incentive or reward that is more effective at delivering a particular outcome than any other technique, method, process, etc. “ – Wikipedia.org
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation5
Agenda
What is a best practice?Why do we care about them?Best PracticesDevelopment
Infrastructure
Procedural
Anti-Practices
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation6
Why do we care about them?
Simple, doing things the best, most advantageous way results in less work and re-work for all partiesSecondly, it provides a standard way of accomplishing a task successfully and with known measuring points.
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation7
Agenda
What is a best practice?Why do we care about them?Best PracticesDevelopment
Infrastructure
Procedural
Anti-Practices
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation8
Development Best Practices
Keep applications as stateless as possibleThe HTTP Session is NOT a place to cache data.If you must place data in the HTTP session, make sure it is serializableMost things that are stuffed into the session could be put in the request instead.
Remember to invalidate your sessions when done.
Stay away from stateful session beans unless you have to use them.
If your JSP’s don’t use the “session” object, use <%@page session=“false” %> for a performance boost
Design all applications to be wholly distributedReady for session persistenceCapable of rapid scalingMinimal dependencies on the environmentUtilize transaction management wherever possibleDo transactional logic in stateless session beans
Use an EJB Façade Pattern, combine with a Delegate PatternDon’t expose Entity Beans directly to the clientUtilize the declarative methods of transaction management via J2EE deployment descriptors (isolation levels, access intents, transaction requirements)
Cache your EJB Home interfaces, they are costly to create over and over again
JDBC activity inside a servlet keeps a connection out of the free pool for the length of the doPost() or doGet() methodResults in short SQL query times, but long JDBS use times and possibly exhaustion of connection pool resources.
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation9
Development Best Practices (cont.)
MVC is a good thing, use itCleanly separate model from view.
JSP’s should not contain business logic!!!
Limit scriptlets to presentation logic and formatting onlyTags are a good thingUnit testing is good
Write code to J2EE and industry specifications, not to the application server implementation Open standards provide the highest levels of flexibility and interoperability
Utilize the security implementations of your platform and server infrastructureTo attain true SSO environments you must stop using application defined security measures and start using the stuff that comes with your products (WebSphere security, LTPA, CSIv2, SAS, etc)
Stay away from string concatenationString x = “Bob” + “,” + “John” + “Nate”
Use Stringbuffers, they cost less.. StringBuilders, even better.
Use DataSources, preferably from the application serverDon’t spawn threads in the web or EJB containerThere are better ways to do this (AsyncBeans, SchedulerBeans)
Don’t override the finalize() method, at all…..ever….Don’t use System.out.println() as your logging mechanism
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation10
Development Best Practices (cont.)
Use proven J2EE design patterns and stick with themStandardize on design patterns
Standardize on common libraries, stop mashing new things together
Consolidate programming frameworks
Be unified in the solution approach – use the same frameworks (the tried and true)
Utilize UML modelingGenerating good documentation and modeling will help out when things go wrong
Unify and consolidate source control systemsPick a source control method and standardize on it
Helps to improve automation around building and deploying applications
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation11
Agenda
What is a best practice?Why do we care about them?Best PracticesDevelopment
Infrastructure
Procedural
Anti-Practices
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation12
Infrastructure Best Practices
Automate, automate, automateUse your scripting interfaces instead of the GUIs for your changes
Scripts are artifacts that can be put in change controlsScripts assure that the activity is performed the same way, every timeScripts help reduce repetition and tedious workEstablish a naming standard for WebSphere resourcesServer names
Application names
Resource names
Utilize shared libraries for common application librariesYou still need to propagate the files out to the hosts
DON’T ADD LIBRARIES TO THE SERVER CLASSPATH
That is, unless, that is the only way or IBM tells you to.Don’t arbitrarily put JVM arguments on new servers because they worked somewhere elseEvery application is unique and the runtime must be tuned to the application behavior for optimal performance
If you need to cache something, use DynaCache or WebSphere eXtreme ScaleDon’t grow your own – unless you like to support it
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation13
Infrastructure Best Practices (cont.)
Enable security on your deployment managersThis should be common sense
Keep Core Groups down to <=50 JVMSLower the better
Determine the amount of sessions that you will encounter and set the max in-memory session count to that number + 20% (growth). Don’t leave growable checked unless you have no concern for OOM or memory usage
Be considerate of your backend resourcesJust because you can setup the connection pool at 999 does not mean you should!
Use hostnames on your profiles and cell configurationThey rarely need to be changed, using IP addresses is bound for failure somewhere down the road.
Enable verbose GCProbably the single most effective tool for diagnosing JVM heath
Very cheap to implement, costs some disk space (but you can rotate the files!)
Make sure your box is setup to produce good system coresUse InstallFactory to do new installs and maintenanceVery handy tool – eliminates complexity of upgrading products
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation14
Infrastructure Best Practices (cont.)
Utilize Type 4 (network-based) database drivers where possibleAllows the greatest flexibility
Lowers licensing requirements (does not require DB client to be installed)
Take advantage of dynamic runtime logging operationsYou CAN enable/disable tracing while the server is running
Possible through scripting and admin console access
Don’t create JMX client applications that register for ALL JMX eventsYou’ll kill the deployment manager
When your cell gets large (maybe <= 200 JVM’s), consider turning off automatic synchronization on the node agent.200 is not the published limit as there is no published limit. HOWEVER, if automatic synchronization is occuring too frequently, that is, not all nodes can complete a sync before the process kicks off again, consider disabling auto sync or lengthening the interval.
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation15
Agenda
What is a best practice?Why do we care about them?Best PracticesDevelopment
Infrastructure
Procedural
Anti-Practices
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation16
Procedural Best Practices
Planning for infrastructureBegin with capacity plans, detail flows in-out of application
Know when the load will come
Know where it will come from
Know how much load will come
Know how long the load will last
Stress test applications in a test environment that will resemble the production system as closely as possible
Document the load test findings, including response times and other metrics
Baseline data is invaluable 1 year down the road.
Have a clearly defined promotion plan/path for moving apps between stage-gate systems (test into stage/pre-prod into production)
Educate all parties on the technologies that will be required for a system or application
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation17
Procedural Best Practices (cont.)
Planning for developmentAgree on the standards and frameworks to be used in the application
Conform to the company standard
If one does not exist, invest time in creating one
Make sure the infrastructure teams are involved in the design phase
They may have experience or products at their disposal that can change the way the application may be designed (simplification of design)
Construct and execute formal design and code review procedures
Minimizes defect introduction into the code stream
Keeps everyone on the same page – align the vision
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation18
Procedural Best Practices (cont.)
Planning for deploymentSet the expectation for deployment timelines early in the project timeline
Prevent springing a new deployment on the infrastructure team 1-2 days before target date
Determine application dependencies and communicate these things to the infrastructure team(s)
They have to set it up – let them know!!
Package library requirements into shared libraries in WebSphere
Determine if the application EAR file contains any resource definitions (databases, J2C resources, etc..)
This is also called an enhanced EAR
Determine if the EAR file contains settings for session timeouts and other parameters that might override the server level configuration settings
Application updates should be done either using a whole EAR file or the partial update capabilities provided in the WebSphere administration console.
Don’t get into the business of copying JSP’s and property files into the installedApps directory
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation19
Agenda
What is a best practice?Why do we care about them?Best PracticesDevelopment
Infrastructure
Procedural
Anti-Practices
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation20
Anti-Practices
Where do we do things wrong/inefficiently?Lets look at it (case study format)
If we bring out our pain points and discuss them, we can determine how we can avoid or repair the situation.First step to fixing a problem is to realize that a problem exists!
The following anti-practices were observed while working with customers at various locations....
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation21
Anti-Practices (cont.)
Using finalize() method to ensure database connections get closedDevelopers did not trust each other to code to standards
Caused impact on several applications due to sharing of the defective code base
Using JDBC from a servletDevelopers either did not understand EJB’s or JPA or chose not to use them/it
Even after connection is released, it is not returned to free pool until the doGet() or doPost() method completes (shared connections)
Causes database connection pool to be 100% utilized
Not load testing a new application before production deploymentFailure to follow testing guidelines – process was known, yet not executed
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation22
Anti-Practices (cont.)
Failure to set retry values on MDB Listener PortsImpact is that application is up, server is up, but no work is being done, queues are filling up
No reason why this should happen – no one took ownership for ensuring that the changes were made
OutOfMemory due to large HTTP Session objects in heapImpact was outage to application due to consistent heap dumps
Development team was told to change but no one enforced the required changes
Not using indirect JNDI lookups for JNDI resourcesDirect JNDI lookups were deprecated starting with WebSphere 6.0
Using resource references assures optimal flexibility for resource behavior configuration.
IBM Software Group
Best Practice Adoption © 2008 IBM Corporation23