Using Runtime Information for Adapting Enterprise Java Beans Application Servers

1. Using Runtime Information for Adapting Enterprise Java Beans Application Servers Mircea Trofin*, John Murphy** Performance Engineering Laboratory *DCU, **UCD

2. Overview • EJB Primer • Problem domain • Impact of redundant context management service (CMS) execution • Framework for removal of redundant CMS • Extending the framework • Current status

3. Enterprise Java Beans Primer • Component framework for building enterprise applications • Components (“beans”) have class character • Composition happens at runtime • To use a bean: • Locate its “home” using a naming service • Ask the home to produce an instance • A new one, or • An existing one

4. EJB Primer • Types of beans: • Session beans (with or without conversational state) • Entity beans • Message-driven beans • Beans contain business logic only; system-level services (concurrency control, transaction isolation, security), are all handled by the platform. • Components only specify configuration options for the above services • Components “live” on an application server

5. Problem domain • Contextual Composition Framework • Components describe runtime context requirements; usually in “deployment descriptors” • Context Management Services (CMS) • Platform services that fulfill components’ runtime context • Glue code • Platform-generated code that ties components to platform services… including CMSs • EJB is our preferred framework • Mature • Open-source implementations • Widespread practitioner reports • Our work can be extended to other contextual composition frameworks: CCM, MTS (and we’ll show how)

6. Impact of redundant CMS executions • Intuitive overview: Server-side apps: many short-lived threads… multiplexed, in the end, on few processors “classic”, client side apps, and redundancy ellimination

7. Impact of redundant CMS executions • Quantitative results • RUBiS • Compare CPU usage: session bean-only results and session + local entity • Our own tests (limited) • Currently, the only option for avoiding this overhead is to redesign the application • Not effective! The cost is typically loss of modularity

8. Transaction script

9. Domain Model

10. Proposed Optimization Framework

11. Solution Domain • Binding graphs (dynamic data) • Graph indicating, for one system transaction, how components bind • Component framework rules • A translation in a formal language (e.g. Jess) of what context configurations mean (e.g. what “transaction required” means) in terms of executing CMS and transforming the context • Application-specific facts • Information provided in the same formal language as above, pertaining to a particular system instantiation. For example: “all admin users are managers”.

12. Optimization Coordinator Implementation • Use • Component Framework Rules • Individual components’ context requirements (from deployment descriptors) • Application-specific facts • Binding graphs • …to produce an optimized configuration for the glue code of each component

13. Sample Component Framework Rule (defrule transaction_required_noCtx (transaction required ?method) (not(transactionCtx)) => (assert (transactionSvc execute ?method)) (assert (transactionCtx)) )

14. Binding Graph Example

15. Optimization Algorithm • A parsing of the binding graph • Evaluate the state of the runtime context • Decide whether CMS need run or not

16. Generating optimized glue code • (currently under analysis) • Current strategy: • Treat glue code (GC) as a document • Treat glue code configuration (GCC) as another document • Have a transformation T from GCC to GC • T is platform dependent, so is GC. GCC is not

17. Isolating call graphs • Prototype implemented under JBoss • Provide a separate naming service for each method (instead of each component) • Allow a many-to-one relation between glue code and components • Register all glue code variants in the global name space • Remap names to point to alternate glue codes

18. Overhead considerations • Training period scenario: no real overhead problems • “train” the system, then transfer it to production • Continuous monitoring: depends on the time it takes to compute a binding graph • Production system is constantly under observation • If a problem, runtime info can permeate to the optimization layer with a rate (say, every 100th transaction goes through)

19. Extending the framework • Other component frameworks can be supported by adapting the component framework rules • The targeted platform needs to support glue code management services: call graph isolator and the optimized glue code generator (in fact… for the latter, a configuration document-based glue code generation)

20. Current status • Prototype call graph isolator • Currently developing a set of component framework rules • Best case scenario: • Components involved in most or all calls have compatible context requirements • Business logic complexity in each method is low (goes hand in hand with proper modularity) • Containable overhead • Worst case scenario: • Incompatible context requirements • Low degree of modularity • Permanent overhead

21. ?&! Q & A