The document outlines best practices in application development and infrastructure management, emphasizing the importance of using effective techniques to improve efficiency and reduce rework. It covers various aspects including stateless application design, automation in infrastructure, and the importance of adhering to industry standards and proven design patterns. Additionally, it identifies common anti-practices and inefficiencies that can lead to significant operational issues.

1. Best Practice Adoption (and lack there-of) John Pape, WebSphere SWAT IBM Software Group Confidential | Date | Other Information, if necessary

2. Agenda What is a best practice?

3. Why do we care about them?

4. Best Practices Development

5. Infrastructure

6. Procedural Anti-Practices

7. Agenda What is a best practice?

8. Why do we care about them?

9. Best Practices Development

10. Infrastructure

11. Procedural Anti-Practices

12. 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

13. Agenda What is a best practice?

14. Why do we care about them?

15. Best Practices Development

16. Infrastructure

17. Procedural Anti-Practices

18. Why do we care about them? Simple, doing things the best, most advantageous way results in less work and re-work for all parties

19. Secondly, it provides a standard way of accomplishing a task successfully and with known measuring points.

20. Agenda What is a best practice?

21. Why do we care about them?

22. Best Practices Development

23. Infrastructure

24. Procedural Anti-Practices

25. Development Best Practices Keep applications as stateless as possible The HTTP Session is NOT a place to cache data. If you must place data in the HTTP session, make sure it is serializable Most things that are stuffed into the session could be put in the request instead.

26. Remember to invalidate your sessions when done.

27. Stay away from stateful session beans unless you have to use them.

28. If your JSP’s don’t use the “session” object, use <%@page session=“false” %> for a performance boost

29. Design all applications to be wholly distributed Ready for session persistence

30. Capable of rapid scaling

31. Minimal dependencies on the environment Utilize transaction management wherever possible Do transactional logic in stateless session beans

32. Use an EJB Façade Pattern, combine with a Delegate Pattern Don’t expose Entity Beans directly to the client Utilize the declarative methods of transaction management via J2EE deployment descriptors (isolation levels, access intents, transaction requirements)

33. Cache your EJB Home interfaces, they are costly to create over and over again

34. JDBC activity inside a servlet keeps a connection out of the free pool for the length of the doPost() or doGet() method Results in short SQL query times, but long JDBS use times and possibly exhaustion of connection pool resources.

35. Development Best Practices (cont.) MVC is a good thing, use it Cleanly separate model from view.

36. JSP’s should not contain business logic!!! Limit scriptlets to presentation logic and formatting only

37. Tags are a good thing Unit 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 infrastructure To 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 concatenation String x = “Bob” + “,” + “John” + “Nate”

38. Use Stringbuffers, they cost less.. StringBuilders, even better. Use DataSources, preferably from the application server

39. Don’t spawn threads in the web or EJB container There are better ways to do this (AsyncBeans, SchedulerBeans) Don’t override the finalize() method, at all…..ever….

40. Don’t use System.out.println() as your logging mechanism

41. Development Best Practices (cont.) Use proven J2EE design patterns and stick with them Standardize on design patterns

42. Standardize on common libraries, stop mashing new things together

43. Consolidate programming frameworks Be unified in the solution approach – use the same frameworks (the tried and true) Utilize UML modeling Generating good documentation and modeling will help out when things go wrong Unify and consolidate source control systems Pick a source control method and standardize on it Helps to improve automation around building and deploying applications

44. Agenda What is a best practice?

45. Why do we care about them?

46. Best Practices Development

47. Infrastructure

48. Procedural Anti-Practices

49. Infrastructure Best Practices Automate, automate, automate Use your scripting interfaces instead of the GUIs for your changes Scripts are artifacts that can be put in change controls

50. Scripts assure that the activity is performed the same way, every time

51. Scripts help reduce repetition and tedious work Establish a naming standard for WebSphere resources Server names

52. Application names

53. Resource names Utilize shared libraries for common application libraries You still need to propagate the files out to the hosts

54. 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 else Every 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 Scale Don’t grow your own – unless you like to support it

55. Infrastructure Best Practices (cont.) Enable security on your deployment managers This should be common sense Keep Core Groups down to <=50 JVMS Lower 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 resources Just because you can setup the connection pool at 999 does not mean you should! Use hostnames on your profiles and cell configuration They rarely need to be changed, using IP addresses is bound for failure somewhere down the road. Enable verbose GC Probably the single most effective tool for diagnosing JVM heath

56. Very cheap to implement, costs some disk space (but you can rotate the files!) Make sure your box is setup to produce good system cores

57. Use InstallFactory to do new installs and maintenance Very handy tool – eliminates complexity of upgrading products

58. Infrastructure Best Practices (cont.) Utilize Type 4 (network-based) database drivers where possible Allows the greatest flexibility

59. Lowers licensing requirements (does not require DB client to be installed) Take advantage of dynamic runtime logging operations You CAN enable/disable tracing while the server is running

60. Possible through scripting and admin console access Don’t create JMX client applications that register for ALL JMX events You’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.

61. Agenda What is a best practice?

62. Why do we care about them?

63. Best Practices Development

64. Infrastructure

65. Procedural Anti-Practices

66. Procedural Best Practices Planning for infrastructure Begin with capacity plans, detail flows in-out of application Know when the load will come

67. Know where it will come from

68. Know how much load will come

69. 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)

70. Educate all parties on the technologies that will be required for a system or application

71. Procedural Best Practices (cont.) Planning for development Agree 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

72. Keeps everyone on the same page – align the vision

73. Procedural Best Practices (cont.) Planning for deployment Set 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

74. Determine application dependencies and communicate these things to the infrastructure team(s) They have to set it up – let them know!!

75. 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

76. 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

77. Agenda What is a best practice?

78. Why do we care about them?

79. Best Practices Development

80. Infrastructure

81. Procedural Anti-Practices

82. 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....

83. Anti-Practices (cont.) Using finalize() method to ensure database connections get closed Developers did not trust each other to code to standards

84. Caused impact on several applications due to sharing of the defective code base Using JDBC from a servlet Developers either did not understand EJB’s or JPA or chose not to use them/it

85. Even after connection is released, it is not returned to free pool until the doGet() or doPost() method completes (shared connections)

86. Causes database connection pool to be 100% utilized Not load testing a new application before production deployment Failure to follow testing guidelines – process was known, yet not executed

87. Anti-Practices (cont.) Failure to set retry values on MDB Listener Ports Impact is that application is up, server is up, but no work is being done, queues are filling up

88. 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 heap Impact was outage to application due to consistent heap dumps

89. Development team was told to change but no one enforced the required changes Not using indirect JNDI lookups for JNDI resources Direct JNDI lookups were deprecated starting with WebSphere 6.0

90. Using resource references assures optimal flexibility for resource behavior configuration.

91. Thanks for your time!!