Slide 1: J2EE Pitfalls and Best Practices Rachel Shen e-business University rshen@ca.ibm.com Centre for e-Business Innovation ::Vancouver IBM Pacific Development Centre
Slide 2: Approach • Java 2 Enterprise Edition (J2EE) and WebSphere Application Server (WAS) are quite powerful • But you can mis-use, under-use or over-use their capabilities quite easily, much to the detriment of your applications AND of your customers • Perspectives • Project & Team Issues • Architecture Issues • Design & Implementation Issues
Slide 3: Java 2 Enterprise Edition • A set of related specifications applications • Single standard for implementing and deploying enterprise • WebSphere Application Server 4.0 supports J2EE 1.2 • WebSphere Application Server 5.0 supports J2EE 1.3 • J2EE 1.4 focuses on Web Services. Key JSRs started in • Servlet 2.3 / JSP 1.2 / EJB 2.0 … October/November, 2001 J2EE 1.3 maintains backward compatibility with J2EE 1.2 • J2EE specification level • Servlet 2.2 / JSP 1.1 / EJB 1.1 … • • J2EE is a proven platform for building flexible, scalable, reliable, maintainable enterprise applications
Slide 4: Project and Team Issues • Before you even get to building you can get yourself into trouble…
Slide 5: Not Understanding the Technology • As with any new technology • • If you don’t understand it and have experience, you will likely mis-use it, and risk project failure One bad experience early on can ruin you for good • Java and J2EE are not silver bullets • You can build bad applications in Java different ways • As you can with ANY language; they’ll just be ‘bad’ in • You can easily build horrendously slow J2EE applications • Particularly if you don’t understand distributed computing
Slide 6: How Do You Understand a Technology? • What you and your team need: • Training • Courses, books, web sites • Both in general technologies and in your chosen tools • Experience • Do prototypes of increasing complexity • Shadow other projects • How much do your customers know? • This is perhaps even more important • They’ll be taking it over – are they capable of it?
Slide 7: Development and Test Environments • Should be same as production • Same hardware • If not same scale, then at least same topology • Same software, same versions • Same data (mangled as little as possible) • It’s a risk, otherwise • Don’t assume! • For example, at the PDC we have successfully done our development on WAS on NT and simply copied files to WAS on AIX in production • But we had to test it, first
Slide 8: Architectural Issues • You’ve decided to use J2EE… • How much of it are you going to use? • And how?
Slide 9: “Model-View-Controller” (MVC) • Separates the presentation from the business logic Controller View Model databases • View – the presentation; displays output and takes in data (could be HTML, could be a Windows app) • Model – the business logic and databases; performs calculations or other actions based on input and defined business processes • Controller – coordinates the view and the model, and translates data passed between them
Slide 10: MVC Model Can Be Servlet-based • Implicit J2EE implementation of MVC JSPs HTML servlets databases • View consists of JSPs and static HTML pages • Servlets are both controllers and model • Access the databases directly
Slide 11: Two Choices for Controller • Does control have to go in the servlets? • JSP-centric – all requests are sent directly to the next JSP for processing and output • Servlet-centric – all requests are sent to servlets for processing, and they in turn output JSPs
Slide 12: Make Applications servlet-centric • Use servlet-centric in all but trivial cases • JSP-centric might work for apps of 2-3 pages • But typically have way too much Java code in them • Better to have servlets decide which JSP to use after doing the business processing messy • Redirecting from JSPs can be done, but it gets
Slide 13: Take Business Logic Out of Servlets • Classes that extend HttpServlet should only do • servlet housekeeping work • Manage request and response objects, and HttpSession Write business logic into plain old Java classes • Pass them only normal Java constructs, not servlet-related • • classes like requests, responses or sessions Fewer or no problems with shared class variables Easier to develop, to test and to re-use classes than servlets servlets JSPs objects databases
Slide 14: MVC Model Can Be EJB-based • Another typical J2EE approach servlets JSPs EJBs databases • View consists of JSPs and static HTML pages • Controllers are servlets • Model is EJBs • Looks very similar to having model in plain old Java objects – except these are run remotely
Slide 15: J2EE - Web Application Architecture JDBC Servlets HTML Javascript Database Legacy Systems Interaction Control Business Logic Page Construction JSPs - Java classes - beans - EJBs C o n n e c t o r s 3rd party systems
Slide 16: Types of EJBs • Two types of Enterprise JavaBeans: • Entity Beans • Represent data • Will continue to exist after server restarts • Persisted to a database, either by the EJB container (“CMP”) or the programmer (“BMP”) • Session Beans • • Perform actions • Equivalent to a ‘normal’ Java object, only accessed remotely Can be stateless (to perform atomic actions), or stateful (to perform a series of actions in one context)
Slide 17: Do You NEED EJBs??? • EJBs are currently cool and trendy, but… • Questions to ask yourself (1) • • • • • Do you need to access multiple data sources with transactional support? Do you need to distribute your business logic? Do you need to support multiple client types? Do you need method-level security on your objects? Do you need a standards-based architecture? • “Nice to have” != “need” • If at least one real “yes”, then consider EJBs • Last two are not good enough on their own
Slide 18: “To EJB or Not to EJB?”(5) • Seriously ask what EJBs will contribute to a proposed solution • Is that contribution measurable? • any servlet-based app can be converted to use EJBs… • There are definitely good places to use EJBs • For instance, a bank with servers across the country which needs both Windows-based and web-based access to the same applications • Just remember: EJBs usually add considerable complexity and expense (both in $ and in execution time) to a web-based application
Slide 19: Okay, So How Do You Use EJBs? • Most people’s first instinct is to take existing DB tables, make an entity bean for each and go to town…  • This approach can have its place in certain situations, but in general it’s not the way to go • It’s a short-term gain for the programmers, but…
Slide 20: Entity Beans Are Expen$ive! • When accessing an entity bean from a client… • Every call is remote • Even getters/setters are remote calls • Remote calls far more expensive than local • By default, every call is a database transaction • Even for getters/setters • If not careful, getting 20 fields from a table row could cost you • 20+ database transactions! Can set some methods to be read-only to partially avoid this • Transaction isolation slows down the system • Exclusive access to a database row is nice, but it holds up anyone else needing access to that row
Slide 21: Entity Beans == Bad Design? • Sometimes, but certainly not always • Very useful when transactions are truly important • E.g. transferring money between two bank accounts, or when making a series of changes to a user profile record • Useful for persistence of objects • Design the object first, THEN map it to the database • Using entity beans as direct mappings of tables doesn’t provide a useful abstraction • You’re still tied directly to the data, so why not use JDBC or a databean and avoid the EJB overhead?
Slide 22: Try Using Session Beans Instead • If client apps access entity beans directly, then maybe they have too much business logic? • Think about what the system DOES for you, not about what the database tables need to look like • Instead, call a session bean method which does the business logic work and returns a plain old object or databean containing the results • One remote call -> one transaction • Returned data is disposable
Slide 23: For Example… • Kyle Brown reports a case study(1) where the customer assumed every object in the system was an entity bean • Had over 200 entity EJBs • Took several hours for the server to startup • He applied the technique of session beans returning simple Java objects • Reduced to less than two dozen entity beans • Startup time of less than one minute
Slide 24: Again, Take the Logic Out… • Session beans themselves should do only EJB housekeeping work • Put the actual business logic into plain old Java classes that can be developed and tested independent of the EJB container • Just like as was suggested for servlets • Could access entity beans from these classes, or the session bean, with higher performance • Local calls within the container, so faster than remote • All calls to entity bean can be within one transaction! • That is, use session beans as façades…
Slide 25: Session Bean Façade Diagram occasionally… EJB Container legacy systems client data objects session beans business objects entity beans databases plain old Java objects EJBs other resources
Slide 26: Façade Benefits • Much easier to develop business logic classes outside of the EJB environment than within • Much much easier to test, too • Business classes can be re-used for/from other applications that access the same back-end resources • Not restricted to EJB only • E.g. classes to handle legacy-system access (4) • Granularity reduces cost of remote calls • • Business object methods are fine-grained and do small amounts of work; since they are called locally, they are cheap Façade session bean methods are coarse-grained and do large amounts of work; they are called remotely, but are called less often, so cost less overall
Slide 27: EJB’s Summary • Consider carefully whether EJBs provide a benefit to your solution • Entity beans are easy to over-use • Use them judiciously! • Use session beans as façades • Put the business logic in plain old Java objects • Use plain old Java objects to return data from database tables (via session beans)
Slide 28: Design and Implementation Issues • We’re down to the fun part, writing the code! • As always, there are better ways of doing some things…
Slide 29: Use a Framework • Most J2EE applications share a number of tasks: • Logging, database access, data validation, properties management, exception handling, HTML generation… • Don’t write these from scratch on every project! • Don’t do these different ways in the same project! • A “framework” specifies common ways to do these tasks (and more) by re-using existing code (and skills!) • Could be in-house (taken from previous projects) • Could be external (e.g. JADE)
Slide 30: Cache Everything You Can • Some things can be cached and shared by all clients • InitialContext object • And just about anything else retrieved from JNDI, for that matter • EJB Home interfaces • They are the same for all clients • Some things are cached by individual clients • Database resultsets • For example, cache search results when you are only displaying • a few at a time Could cache in the servlet, could cache in session bean
Slide 31: Tips for Servlets • Put as much as possible in init() • It’s only executed once, at startup • Synchronize as little as possible • For sure don’t synchronize on whole class • They are shared by all active users • It’s thread-safe, but really kills performance… • Servlets use HttpSession instead • Don’t use any instance variables • Don’t use SingleThreadModel • For the non-Java crowd: don’t store data in cookies
Slide 32: Tips for JSPs • Keep the amount of Java code to a minimum • Java inside of JSPs is hard to maintain and to test • Should be absolutely no business logic in a JSP • Write helper classes to generate HTML from data • One of the few times putting hardcoding HTML in Java is ‘okay’ • Ideally use only “<%= ... %>” tags… • Pass each JSP only a very simple object containing only the data to be displayed • Sometimes called a “view bean”, but doesn’t have to be a real JavaBean Restricts the JSP to doing display work only, and removes temptation to write business logic •
Slide 33: Still More JSP Tips • If you have shared components or sections in your pages, use some form of includes • E.g. for menus, title bars, footers, etc • Can use HTML or JSP include commands • Can include static HTML, or another JSP • Don’t forget a try/catch for the entire JSP • Annoyingly, if an exception is thrown within the JSP, it can’t • be caught by the servlet Alternately, put all the contentious code in a block at the top, and wrap that section in a try/catch block
Slide 34: Tips for EJBs… • Try to keep your session beans stateless • EJB container will pool them • Explicitly destroy stateful session beans as soon as possible to reduce unnecessary passivation • On client side, don’t access your EJBs directly • Wrap them in a plain old Java class to abstract out the code dealing with contexts, home and remote interfaces, etc • Basically an adapter… an adapter for a proxy! • Alternately, VAJ has wizards to create “access beans” • Similar idea, “makes an EJB look like a JavaBean”
Slide 35: Tips for JDBC and Databases • Use a connection pool • Create a number database connections,and share them • Release/return any resources as soon as you’re done with them • E.g. Statements, Connections, ResultSets… • Having raw SQL in your code is slow, since it has to be recompiled each time it is used • Use JDBC’s PreparedStatement instead of Statement • Even faster – though much less portable – is to use stored procedures in the database
Slide 36: Tips for HttpSession Objects • Make sure everything you put in the session implements Serializable (or Externalizable) • Not required, but a good practice in case your app becomes distributed across multiple servers • Avoid storing large objects in the session • Invalidate the session manually • Can only do this if application has explicit ‘log out’ function • If session is not needed by JSP, disable its creation <%page session=“false”%>
Slide 37: Tips for JavaScript • Put as little JavaScript in HTML pages as possible • • • • Use separate JavaScript files and refer to them from HTML Will be cached by the browser Makes HTML files smaller Can be shared, and are easier to maintain • Stick to ECMA standard for JavaScript • Defines a JavaScript core that all major browsers support • Should reduce or eliminate differences between browsers • http://www.ecma.ch/ecma1/STAND/ECMA-262.HTM • http://www.jsworld.com/ecmascript/
Slide 38: Tips for Java • Watch for memory leaks and garbage creation • Reduce synchronization • • E.g. use StringBuffer instead of String • Destroy references as soon as you’re done with them • Particularly important when many instances of a class can be running in parallel Avoid heavy use classes like Vector and Hashtable • Implement Externalizable instead of Serializable • More work for programmer, but faster at run-time • Particularly important for EJBs and RMI
Slide 39: Tips for XML • Don’t overuse it • All that parsing and message creation can get expensive and tedious (DOM trees aren’t so fun) • By all means, use XML for messages between systems… • But don’t need to use it within a system • Just use data objects! • De-XMLify as soon as possible • Convert the data from XML into a plain old Java class • Can use tools for this (e.g. GenX) • XML is for transmission, not for processing!
Slide 40: Final Note: Optimization… • Repeat after me: • • • • • • • • You can’t tune a bad application. You can’t tune a bad application. You can’t tune a bad application. You can’t tune a bad application. You can’t tune a bad application. You can’t tune a bad application. You can’t tune a bad application. You can’t tune a bad application.
Slide 41: Bibliography The following were pilfered in the making of this presentation… :-) (Specific references were highlighted throughout with superscripts.) • • • • • Kyle Brown, IBM, “EJB Best Practices: Architecture (Why EJB’s?)” D25WKGP4/25/A/IBM, galambos\techni1.nsf, "EBU - EJB Best Practices“ Brian Waterworth, IBM, “eBusiness Java/WebSphere practitioner best practices” Harvey Gunther, IBM, “WebSphere Application Server Development Best Practices for Performance and Scalability” (includes statistics!) http://www-4.ibm.com/software/webservers/appserv/ws_bestpractices.pdf Daniel Steinberg, Review of conference talk by Martin Fowler http://www-106.ibm.com/developerworks/library/j-con3.html Humphrey Sheil, “J2EE Project Dangers!”, JavaWorld http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html
Slide 42: References The following sites are considerable sources for ‘best-practice’ material: • WebSphere World An IBM-internal site from Kyle Brown, one of the biggest WebSphere and J2EE gurus in IBM. Lots of presentations and white papers, with considerable emphasis on bestpractices. http://websphereworld.raleigh.ibm.com/KylesWorld • WebSphere Performance and Technology Team http://wasperf.rchland.ibm.com An IBM-internal site from a team that specializes in making WebSphere sing and dance. Lots of articles, presentations and papers. • WebSphere White Papers A public IBM site with several years of white papers related to WebSphere. Not as extensive, since not all good papers are released publicly… http://www-4.ibm.com/software/webservers/appserv/whitepapers.html • Internal WebSphere Developer Domain Overall a great source of training and marketing materials. http://submit.boulder.ibm.com/wsdd/