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


Agenda


Infrastructure

Procedural

Anti-Practices

IBM Software Group


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

http://en.wikipedia.org/wiki/Management_fad

http://en.wikipedia.org/wiki/Technique

IBM Software Group


Agenda


Infrastructure

Procedural

Anti-Practices

IBM Software Group


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


Agenda


Infrastructure

Procedural

Anti-Practices

IBM Software Group


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


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


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


Agenda


Infrastructure

Procedural

Anti-Practices

IBM Software Group


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


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


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


Agenda


Infrastructure

Procedural

Anti-Practices

IBM Software Group


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


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


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


Agenda


Infrastructure

Procedural

Anti-Practices

IBM Software Group


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


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


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 (and lack there of)

Technology

best practices development

development best practices

best practice adoption

procedural antipractices

http session

stateless session beans

session object

session persistence