Optimizing J2EE Applications

1. Optimizing J2EE Applications A Comparison of J2EE Design Idioms and their Performance Presented by Maciej Zawadzki mbz@urbancode.com

2. Outline • Introduction to EJBs • EJB Performance Benchmark • Beyond Performance: Code that is Simple and Easy to Maintain

3. Introduction to EJBs • Introduction to EJBs • Three Tiered Architecture • Stateless Session EJBs • Stateful Session EJBs • Entity EJBs • Distributed Objects • Client View of EJBs • EJB Performance Benchmark • Beyond Performance: Code that is Simple and Easy to Maintain

4. Three Tiered Architectures • Middle Tier houses system level services such as: • Remote access between clients and data sources • Session and transaction management • Security management • Resource access management (dbs. connection pooling)

5. J2EE Three Tiered Architecture • The EJB container and Web container make up the J2EE middle tier.

6. Stateless Session EJBs • Not tied to any client • No data kept between method invocations • Do not survive beyond the lifetime of the J2EE server • Can access other resources available through the J2EE server

7. Stateful Session EJBs • Tied to a single client • Can keep session data that survives between method invocations • Do not survive beyond the lifetime of the J2EE server • Can access other resources available through the J2EE server

8. Entity EJBs • Provide an object oriented representation of a row of data in a database • Not tied to any client and can execute on behalf of multiple clients • Built in protocol for data persistence via ejbLoad() and ejbStore() methods

9. Distributed Objects • Typical distributed object systems rely on Stub object on the client side to provide a proxy for the server side object. • Method calls on the proxy are communicated to the server using a wire protocol. • Arguments and return values are marshaled to and from the network data streams.

10. Client View of EJBs • Home interface provides remote access to a factory object • Remote interface declares the business methods available on the EJB

11. EJB Performance Benchmark • Introduction to EJBs • EJB Performance Benchmark • Five Design Idioms • Four Tests (measuring relative performance of each idiom) • Benchmark Results • Explanation of Results • Strategy for Optimized Performance • Beyond Performance: Code that is Simple and Easy to Maintain

12. Benchmark Scenario • Benchmark is a section of a J2EE application. • Each inventory item consisted of: number, name, description, price, weight, weight unit of measure, manufacturer name. • A database containing 1,000 records representing fictional inventory items was created.

13. Five Design Idioms • Fine Grained Entity Bean (FGE) – often used by beginners to Enterprise Java Beans • Coarse Grained Entity Bean (CGE) – the best performing Entity Bean idiom typically used in practice • Optimized Entity Bean (OE) – the best performing contender that still uses Entity Beans • Session over Entity Bean (SE) – typically advanced as a “best practice” in trade media • Coarse Grained Session Beans (CGS) – the proposed best performer

14. Fine Grained Entity Bean Design Idiom • The client calls accessor methods on an entity bean to read the value of every individual data member

15. Coarse Grained Entity Bean Design Idiom • The client uses an entity bean to retrieve a state object populated with database data

16. Optimized Entity Bean Design Idiom • The client uses an entity bean to retrieve a state object populated with database data. The entity bean does not update the data store unless the state has been changed.

17. Session Over Entity Bean Design Idiom • The client uses a session bean to retrieve a state object populated with database data, but the session bean populates the state object based on its conversation with a fine grained entity bean

18. Coarse Grained Stateless Session Bean Design Idiom • The client uses a stateless session bean to retrieve a state object populated with database data

19. Four Tests • Test 1 – designed to measure the relative performance when accessing a single instance of data • Test 2 – designed to measure the relative performance when accessing small (up to 100 element) collections of data instances • Test 3 – designed to measure the relative performance when accessing large (up to 1,000 element) collections of data instances • Test 4 – a load test. Designed to measure relative performance when accessing a collection of 50 data instances by a varying number of clients concurrently.

20. Benchmark Setup • App. Server – JBoss 2.0 with bundled Tomcat 3.2 • Database – Hypersonic (bundled with JBoss) • Hardware – PIII 600Mhz (mobile) 392Mb RAM • Operating System – Windows 2000

21. Results of Test 1(Single Instance Access)

22. Results of Test 2

23. Results of Test 2 (cont.)(Regression Analysis) • The CGS idiom is 121 times faster than the FGE idiom.

24. Results of Test 3

25. Results of Test 3 (cont.) (Regression Analysis) • The CGS idiom is 86 times faster than the FGE idiom.

26. Results of Test 4

27. Results of Test 4 (cont.)(Regression Analysis) • The CGE idiom scales 8.67 times better than the OE idiom.

28. Explanation of Results • Single instance access – EJB containers call ejbLoad() and ejbStore() methods automatically during transactions. If a method call requires a Transaction, then at least ejbStore() will be called before the Transaction associated with the method call completes, even if there has been no change to the state. • Collection access – Entity beans know how to load (restore) only a single instance at a time. No optimizations for bulk access are possible when using Entity beans.

29. Strategy for Optimized Performance • Practice Coarse Grained Access - State objects pattern (aka. Memento, Value Objects). • Eliminate superfluous calls to ejbLoad() and ejbStore() – use Session Beans instead of Entity Beans • Optimize bulk access – use a single conversation with the database when accessing multiple instances

30. Beyond Performance: Code that is Simple and Easy to Maintain • Introduction to EJBs • EJB Performance Benchmark • Beyond Performance: Code that is Simple and Easy to Maintain • Remaining problems • Domain Façade as a solution • Introduction • UML diagram • Automatic Primary Key Dereferencing • Class = data + behavior • Layered and Columnar Architecture • Real World Implementation

31. Remaining Problems • EJBs do not provide an elegant solution to automatic primary key dereferencing and object navigation. • Coarse grained access patterns do not adhere to Object Oriented Programming principles: • class = data + behavior

32. Introduction to the Domain Façade Idiom • Builds on top of the Coarse Grained Session Bean idiom, thus maintains the performance advantage • Adds the concepts of Domain Class and Domain Helper: • Domain Class – classes whose instances wrap State object instances • Domain Helper – utility classes that carry on conversations with EJBs

33. Domain Façade Class Diagram

34. Automatic Primary Key Dereferencing Example • EJBs do not have object references to other EJBs, rather they hold the Primary Keys of referenced instances. • Domain Classes provide object references.

35. “Class = data + behavior” Example • When using Domain Facades, the developer has complete control over which accessor and mutator methods should be available to the client. • The developer can also add business methods that express behaviors.

36. Layered and Columnar Architecture of Domain Facade

37. Business Logic Settles Close to the Client and Close to the Data Store

38. A Detailed View of the Layers • Each layer knows only about the layer behind it • The loose coupling promotes: • code reuse • ease of maintenance • parallel development

39. Alamo MPOWERENT Project • Online rental management system • Available via extranet to insurance company partners • Fully integrated with legacy rental system • In production since August 2000 • Over 8,000 business users • App. server on two clustered HP servers running WebLogic 5.1 • Average app. server CPU load is under 5%

40. Further Issues • Treatment of dependent objects within the Domain Façade idiom • Automatic state validation • Non data intense domain classes that do not require the save() method

41. Summary • EJB Performance • EJB Performance Benchmark • Lessons Learned / Strategy for Optimized Performance • Turning Strategy into a Design • Beyond Performance: Code that is Simple and Easy to Maintain • Remaining Problems – Absence of OOP • Domain Façade as a Solution

42. Thank you! Maciej Zawadzki mbz@urbancode.com

43. Benefits of Domain Façades • Performance – built on top of best performing idiom • Maintenance – layered architecture allows updates to any one layer to be isolated from all above layers. Columnar architecture makes updates to any one Domain column easy as all Domain related concepts (Domain Class and Helper, EJB, DAO) are isolated from any other Domain columns. • Ease of Development • Automatic Primary Key dereferencing makes code more readable and bug free. • Ability to combine logic with data in adherence with OOP brings in all advantages of OOP.

44. EJB Broker Pattern

45. Persistence Services EJB Pattern

46. Domain Classes in Detail • Private reference to a corresponding state object • Constructor – accepts a state object • Called either for a restored instance, or • When a new instance is created • Wrapping simple fields • Accessor calls are delegated to the state object • Mutator calls are delegated to the state object

47. Domain Classes in Detail (cont.) • Wrapping reference fields • Accessor calls are intercepted. The PK of the referenced object is obtained from the state object. The PK is then converted into a Domain Class reference by calling a lookup method on the associated Helper. The Domain Class reference may be cached for later usage. • Mutator calls are intercepted. The PK of the Domain Class parameter is obtained and set on the state object. The Domain Class reference may be cached for later usage. • The save() method • Calls the serviceState(…) method on the associated Helper with the state object as a parameter. The method returns an updated state object which then becomes the new state.