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; 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

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

Application server

Monitoring Glue Code GeneratorCall Graph Isolator

Optimization CoordinatorBinding Graph Filter

Rule Engine

runtime data

optimize

isolate call graph generate specialized glue code

glue-code management services

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”.

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

method1 method2

B

method1

C

DE

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 100th 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