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 well 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))
• gt
• (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