1 / 21

Using Runtime Information for Adapting Enterprise Java Beans Application Servers

Using Runtime Information for Adapting Enterprise Java Beans Application Servers. Mircea Trofin * , John Murphy ** Performance Engineering Laboratory * DCU, ** UCD. Overview. EJB Primer Problem domain Impact of redundant context management service (CMS) execution

kyla-guzman
Download Presentation

Using Runtime Information for Adapting Enterprise Java Beans Application Servers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related