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
• Framework for removal of redundant CMS
• Extending the framework
• Current status

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

EJB Primer
• Types of beans:
– Session beans (with or without conversational state)
– Entity beans
– Message-driven beans
• Beans contain business logic only; systemlevel 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

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)

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

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

Transaction script

Domain Model

Proposed Optimization Framework
Binding Graph Filter Optimization Coordinator optimize
Rule Engine runtime data
Monitoring isolate call graph
Application server
Call Graph Isolator generate specialized glue code
Glue Code Generator glue-code management services

Solution Domain
• Binding graphs
– 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”.

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

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

Binding Graph Example
A method1
B method1 method2
C method1
D
E
B method1
E

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

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

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

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 100 th transaction goes through)

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)

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

?&!
Q & A