J2EE Project Dangers Siddhesh


Published on

Preventing disaster in your J2EE project

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

J2EE Project Dangers Siddhesh

  1. 1. J2EE Project Dangers Pitfalls to avoid for ensuring success of your project Siddhesh Bhobe (based on articles in JavaWorld)
  2. 2. Project Phases <ul><li>Vendor Selection: Picking the best possible mix of tools -- from the app server right down to your brand of coffee </li></ul><ul><li>Design: You know exactly what you are building and how you will build it. Coding is OK! </li></ul><ul><li>Development </li></ul><ul><li>Stabilization/Load Testing: Impose a feature freeze and focus on build quality, as well as ensure that the system's vital statistics can be met </li></ul><ul><li>Live: Date set in stone </li></ul><ul><li>We will consider the effect in context to the project phases </li></ul>
  3. 3. Danger 1: Not understanding Java, EJB, J2EE <ul><li>Project phase: Design, Development </li></ul><ul><li>Project phase(s) affected: Design, Development, Stabilization, Live </li></ul><ul><li>System characteristics affected: Maintainability, scalability, performance </li></ul>
  4. 4. Danger 1: Symptoms <ul><li>Not knowing what the following are and what they do: </li></ul><ul><ul><li>When objects can be garbage collected -- dangling references </li></ul></ul><ul><ul><li>Inheritance mechanisms used in Java </li></ul></ul><ul><ul><li>Method over-riding and over-loading </li></ul></ul><ul><ul><li>Why java.lang.String proves bad for performance </li></ul></ul><ul><ul><li>Pass-by reference semantics of Java (versus pass-by value semantics in EJB) </li></ul></ul><ul><ul><li>Using == versus implementing the equals() method </li></ul></ul><ul><ul><li>Hotspot (and why old tuning techniques negate Hotspot optimizations) </li></ul></ul><ul><ul><li>The JIT and when good JITs go bad (unset JAVA_COMPILER and your code runs just fine, etc.) </li></ul></ul><ul><ul><li>The Collections API </li></ul></ul>
  5. 5. Danger 1: Symptoms <ul><li>EJBs that work when they are first called but never thereafter </li></ul><ul><ul><li>Ex: stateless session beans that are returned to the ready pool </li></ul></ul><ul><li>Not knowing for what the developer is responsible, compared with what the container provides </li></ul><ul><ul><li>Manual transaction management </li></ul></ul><ul><ul><li>Custom security implementations </li></ul></ul><ul><li>EJBs that do not correspond to the specification </li></ul><ul><ul><li>fire threads </li></ul></ul><ul><ul><li>load native libraries </li></ul></ul><ul><ul><li>attempt to perform I/O </li></ul></ul><ul><ul><li>Do NOT look at EJBs from your vendors eyes! </li></ul></ul>
  6. 6. Danger 2: Over-Engineering <ul><li>Project phase: Design </li></ul><ul><li>Project phase(s) affected: Development </li></ul><ul><li>System characteristics affected: Maintenance, scalability, performance </li></ul>
  7. 7. Danger 2: Symptoms <ul><li>Oversized EJBs </li></ul><ul><li>Role and relationships between EJBs not clear to developers </li></ul><ul><li>Nonreusable EJBs, components, or services </li></ul><ul><li>EJBs starting new transactions when an existing transaction will do </li></ul><ul><li>Data isolation levels set too high in an attempt to be safe </li></ul><ul><ul><li>Serializable, Repeatable Read, Read Committed, Read Uncommitted </li></ul></ul>
  8. 8. Avoiding Over-Engineering <ul><li>Design and implementation should strictly be driven by the requirements, nothing more </li></ul><ul><li>Don't try to second-guess what the system will need to look like in the future </li></ul><ul><ul><li>That doesn’t mean you ignore performance and scalability requirements! </li></ul></ul><ul><li>Leave scalability and fail over for the application server infrastructure to handle for you </li></ul><ul><li>Employ Design Patterns </li></ul>
  9. 9. Danger 3: Not separating Presentation from Business logic <ul><li>Project phase: Design </li></ul><ul><li>Project phase(s) affected: Development </li></ul><ul><li>System characteristics affected: Maintainability, extensibility, performance </li></ul>
  10. 10. Danger 3: Symptoms <ul><li>Large and unwieldy JSPs </li></ul><ul><li>You find yourself editing JSPs when business logic changes </li></ul><ul><li>A change in display requirements forces you to edit and redeploy EJBs and other backend components </li></ul>
  11. 11. Separating presentation from business logic <ul><li>Reuse GUI frameworks like taglibs, rather than trying to build your own </li></ul><ul><li>Use the Model 2 Architecture </li></ul>
  12. 12. Danger 4: Not deploying where you develop <ul><li>Project phase: Development </li></ul><ul><li>Project phase(s) affected: Stabilization, Parallel, Live </li></ul><ul><li>System characteristics affected: Your sanity </li></ul>
  13. 13. Danger 4: Symptoms <ul><li>Multiday or weeklong transitions to live systems </li></ul><ul><li>Major risk involved in going live, with many unknowns and major usage scenarios not tested </li></ul><ul><li>Data in live systems not the same as data in development or stabilization setups </li></ul><ul><li>Inability to run builds on developer machines </li></ul><ul><li>Application behavior is not the same in the development, stabilization, and production environments </li></ul><ul><ul><li>Duplicate environments completely and faithfully! </li></ul></ul><ul><ul><li>Example: XAT </li></ul></ul>
  14. 14. Danger 5: Choosing the wrong vendors <ul><li>Project phase: Vendor Selection </li></ul><ul><li>Project phase(s) affected: Design, Development, Stabilization/Load Testing, Live </li></ul><ul><li>System characteristics affected: Scalability, performance, maintainability, stability </li></ul>
  15. 15. Danger 5: Symptoms <ul><li>Tools not utilized properly </li></ul><ul><li>Significant system redesign required in order to work around known or unknown bugs in the implementation </li></ul><ul><li>Poor integration between different tools (application servers and IDEs, IDEs and debuggers, source control and build tools, etc) </li></ul><ul><li>For IDEs, debuggers, etc., developers simply forsaking them in favor of their own favorite tools </li></ul>
  16. 16. Choosing vendors correctly… <ul><li>The only way to evaluate is use! </li></ul><ul><li>The only way to evaluate a J2EE implementation is to build a proof of concept that touches the features you are betting your architecture on. </li></ul><ul><li>Continually evaluate the market. </li></ul>
  17. 17. Danger 6: Not knowing your vendor <ul><li>Project phase: Vendor Selection </li></ul><ul><li>Project phase(s) affected: Design, Development, Stabilization/Load Testing, Live </li></ul><ul><li>System characteristics affected: Maintainability, scalability, performance </li></ul>
  18. 18. Danger 6: Symptoms <ul><li>Development takes much longer than the worst estimate </li></ul><ul><li>Developers reinvent the wheel when the vendor or implementation provides the required functionality out of the box </li></ul>
  19. 19. How to understand your vendor better! <ul><li>Subscribe to all the vendor-supplied support resources you can find </li></ul><ul><ul><li>email lists </li></ul></ul><ul><ul><li>news groups </li></ul></ul><ul><ul><li>release notes (especially those with a list of bug fixes) </li></ul></ul><ul><li>Invest in training as soon as possible </li></ul><ul><li>Build a quick proof of concept to break the team in gently </li></ul><ul><li>Figure out the build process as early as possible </li></ul><ul><li>Your schedule doesn't give you the time to not do it! </li></ul>
  20. 20. Danger 7: Not designing for scalability or performance <ul><li>Project phase: Design </li></ul><ul><li>Project phase(s) affected: Development, Load Testing, Live </li></ul><ul><li>System characteristics affected: Scalability, performance, maintainability </li></ul>
  21. 21. Danger 7: Symptoms <ul><li>Unacceptably slow systems </li></ul><ul><li>Systems that make heavy use of server-side state and cannot take full advantage of vendor clustering technology </li></ul><ul><li>Test for performance in exactly the same environment </li></ul><ul><li>Example cases: Tradec, XAT </li></ul>
  22. 22. Danger 8: Antiquated development processes <ul><li>Project phase: Development </li></ul><ul><li>Project phase(s) affected: Stabilization, Live </li></ul><ul><li>System characteristics affected: Maintenance, code quality </li></ul>
  23. 23. Danger 8: Symptoms <ul><li>Using the waterfall method. </li></ul><ul><li>Builds are a nightmare, because there is no build process </li></ul><ul><li>Build days equal lost development days because nothing else gets done. </li></ul><ul><li>Components are not adequately tested before integration. Integration testing involves taking two unstable components, strapping them together, then looking at the stack traces. </li></ul><ul><ul><li>Using JUnit and ANT! </li></ul></ul><ul><ul><li>http://www. javaworld .com/ jw -10-2000/ jw -1020-ant.html </li></ul></ul>
  24. 24. Danger 9: Failure to employ frameworks <ul><li>Project phase: Development </li></ul><ul><li>Project phase(s) affected: Development, Stabilization, Live </li></ul><ul><li>System characteristics affected: Maintenance, extensibility, code quality </li></ul>
  25. 25. Danger 9: Symptoms <ul><li>Bugs in core libraries that are used multiple times in code. </li></ul><ul><li>No set logging standards </li></ul><ul><ul><li>system output is impossible to read or parse with scripts. </li></ul></ul><ul><li>Bad and inconsistent exception handling </li></ul><ul><ul><li>sending back a SQLException stack trace when a user tries to check out their shopping cart. </li></ul></ul>
  26. 26. Frameworks should address the following: <ul><li>Logging </li></ul><ul><li>Exception handling </li></ul><ul><li>Getting a connection to resources like databases </li></ul><ul><li>Building JSP pages </li></ul><ul><li>Data validation </li></ul><ul><li>Related article: </li></ul><ul><li>http://www.javaworld.com/jw-09-2000/jw-0929-ejbframe.html </li></ul>
  27. 27. Danger 10: Basing project plans and designs on marketing blurb <ul><li>Project phase: All phases; Vendor Selection particularly influenced </li></ul><ul><li>Project phase(s) affected: All phases are affected </li></ul><ul><li>System characteristics affected: Maintenance, extensibility, design quality, code quality </li></ul>
  28. 28. Danger 10: Symptoms <ul><li>Technical decisions taken lightly because EJBs are “designed to be portable” </li></ul><ul><li>Vendor selection performed without a &quot;hands-on&quot; trial of the product </li></ul><ul><li>Needing to switch tools during a project lifecycle </li></ul>
  29. 29. Suggestions <ul><li>Don’t believe vendors </li></ul><ul><li>Don’t believe whitepapers paid for by vendors </li></ul><ul><li>Download the tool you want to evaluate, roll up your sleeves, and prototype with it </li></ul>
  30. 30. MTV Top Ten <ul><li>Not understanding Java, not understanding EJB, not understanding J2EE </li></ul><ul><li>Over-engineering </li></ul><ul><li>Not separating presentation logic from business logic </li></ul><ul><li>Not deploying where you develop </li></ul><ul><li>Choosing the wrong vendor(s) </li></ul><ul><li>Not knowing your vendor(s) </li></ul><ul><li>Not designing for scalability or performance </li></ul><ul><li>Antiquated development processes </li></ul><ul><li>Not using frameworks </li></ul><ul><li>Basing project plans and designs on marketing blurb, not technical fact </li></ul>
  31. 31. To EJB, or not to EJB? <ul><li>To EJB, or not to EJB: that is the question. Whether 'tis nobler in the mind, to suffer The slings and arrows of outrageous licensing ; Or to take arms against a sea of potential overheads and features , And by opposing end them? To roll your own: to reinvent the wheel ; No more; and by reinvent, to say, we continue The heart-ache of low-level systems maintained in-house , and the thousand natural shocks That flesh is heir to; 'tis a consummation Devoutly to be avoided. </li></ul>
  32. 32. EJB Advantages <ul><li>The underpinning EJB specification </li></ul><ul><li>Integration with the J2EE platform: servlets, JMS, JCA, JSP, JDBC and so on </li></ul><ul><li>Almost transparent scalability </li></ul><ul><li>Free access and usage of complex resources: transaction and security management, resource pooling, JNDI, component lifecycle management </li></ul><ul><li>Strong and vibrant industry community </li></ul>
  33. 33. EJB Disadvantages <ul><li>Large, complicated specification </li></ul><ul><li>Increased development time </li></ul><ul><li>Added complexity compared to straight Java classes </li></ul><ul><li>Potential to produce a more complex and costly solution than is necessary </li></ul><ul><li>Continual specification revisions </li></ul>
  34. 34. Alternative Approaches <ul><li>Avoid EJB completely, yet still employ a Java solution </li></ul><ul><ul><li>Explicitly handle (or ignore) issues such as multithreading, scalability, and transaction management yourself. </li></ul></ul><ul><ul><li>If they do, you will end up seeing methods like getConnection() and closeConnection(), plus a couple of XXXManagers: can quickly mushroom into a mini-container! </li></ul></ul>
  35. 35. Alternative Approaches <ul><li>Adopt an EJB-friendly design </li></ul><ul><ul><li>Adopt design patterns, usually Model 2 Architecture </li></ul></ul><ul><ul><li>Allows for more robust middle tier later </li></ul></ul><ul><li>Related Article: </li></ul><ul><li>http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/index.html </li></ul>
  36. 36. Alternative Approaches <ul><li>Move to a completely different technology </li></ul><ul><ul><li>CORBA </li></ul></ul><ul><ul><li>.NET </li></ul></ul><ul><ul><li>Jini/JavaSpaces (for non-commercial applications only!) </li></ul></ul>
  37. 37. Rules for choosing EJB <ul><li>Choose EJB when you know your application will need to scale beyond initial low usage levels and support multiple, concurrent users. </li></ul><ul><li>Choose EJB if you need transaction management. </li></ul><ul><ul><li>For online catalogues or read-only systems with low user numbers, you probably don't need EJB. </li></ul></ul><ul><ul><li>For financial systems or any system where you must preserve the ACID properties, EJBs are a must. </li></ul></ul><ul><li>Choose EJB if you need a comprehensive security model. </li></ul>
  38. 38. Rules for not choosing EJB <ul><li>Do not use EJB when you find no need for scalability, transaction management, or security and anticipate low numbers of read-only users. </li></ul><ul><li>Don't choose EJB if you don't need platform independence and don't mind being locked into one particular vendor. </li></ul><ul><ul><li>Intranet Applications, for example! </li></ul></ul><ul><li>Do not choose EJB if your team possesses no EJB experience </li></ul><ul><li>Do not use EJB just because your company got a free set of licenses from vendor X. </li></ul>
  39. 39. EJB Folklore <ul><li>You don't need developers to understand SQL if you are using container managed entity beans: Myth! </li></ul><ul><li>EJBs are portable between vendors: Half-myth </li></ul><ul><ul><li>CMP entity beans are difficult to port. Session beans and BMP entity beans usually port quite easily. </li></ul></ul><ul><ul><li>Applications that rely on a clustering implementation take longer to port. </li></ul></ul><ul><ul><li>Administration and configuration tools are vendor-specific </li></ul></ul><ul><ul><li>Startup and shutdown scripts and build scripts are vendor-specific too, unless vendor uses ANT  </li></ul></ul>
  40. 40. EJB Folklore <ul><li>Security is free with EJB: Misunderstanding </li></ul><ul><ul><li>Provides just a model, you need to set up your users and roles yourself -- and potentially tie in to an existing authentication source, such as a database or LDAP server. </li></ul></ul><ul><li>EJB solutions are expensive: Mostly-true </li></ul><ul><ul><li>Should soon change to a myth. Open source and low-cost alternatives are offering real competition to the entrenched market leaders </li></ul></ul><ul><li>CMP is faster than BMP or BMP is faster than CMP: Misunderstanding </li></ul><ul><ul><li>Depends on the quality of the vendor's CMP engine </li></ul></ul><ul><ul><li>The more proprietary an application server is, the more features it can add to its CMP engine, like batch updates, smart updates, and more. </li></ul></ul>
  41. 41. EJB Folklore <ul><li>Entity beans are slow. True </li></ul><ul><ul><li>Entity beans are often too slow and need to be worked around by a combination of session beans and value objects. </li></ul></ul><ul><ul><li>Most noticeable in cases where a finder method returns thousands of rows. </li></ul></ul><ul><ul><li>In some cases, application servers try to be smart about loading data (lazy-loading), but such efforts often prove insufficient. </li></ul></ul><ul><li>Stateful session beans are bad and should be avoided. Myth </li></ul><ul><ul><li>Prove valuable in certain situations </li></ul></ul><ul><ul><li>However, they should be used sparingly as server-side state always adversely affects scalability </li></ul></ul>
  42. 42. From a Gartner Report… <ul><li>J2EE and Enterprise JavaBeans (EJB) are not the same </li></ul><ul><ul><li>Most Java projects use Java Server Pages/servlet capabilities and not EJB </li></ul></ul><ul><li>The more costly application servers are designed for EJBs, yet are using JSP/servlet capabilities instead </li></ul><ul><li>Gartner estimates that by 2003, at least 70% of the new applications will be deployed on high-end application servers but 60% of all new J2EE application code will remain JSP/servlet-only </li></ul>
  43. 43. How to make the right decision? <ul><li>Step 1: Identify and Quantify critical system requirements </li></ul><ul><ul><li>Load factors (Max concurrent users, peak usage) </li></ul></ul><ul><ul><li>Security (SSL, Roles and Groups) </li></ul></ul><ul><ul><li>Transaction Management </li></ul></ul><ul><li>Step 2: Qualify technologies as per your requirements </li></ul><ul><ul><li>Rule out technologies that are an overkill! </li></ul></ul><ul><li>Step 3: Evaluate </li></ul><ul><ul><li>Proof of concept using the technology of your choice is a must </li></ul></ul><ul><li>Step 4: Decide and put support structure in place </li></ul><ul><ul><li>Training and Mentoring </li></ul></ul><ul><ul><li>Right toolset </li></ul></ul>
  44. 44. <ul><li>There is no substitute for experience and planning! </li></ul><ul><li>Get experience </li></ul><ul><li>Don’t bet on on-the-go training </li></ul><ul><li>Proactively source training before the project starts, ideally before the design phase </li></ul>Conclusion
  45. 45. References <ul><li>Local copies of most of the articles referred here, we well as other interesting, related links can be found at http://reismagos/Papers/JavaAndJDBC/index.html in the Java Design Techniques section </li></ul><ul><li>This presentation was based on articles from JavaWorld </li></ul><ul><li>J2EE Design Patterns http://java.sun.com/blueprints/patterns/catalog.html </li></ul>