Abstraction of Transaction Demarcation in Component-Oriented Middleware

www.objectweb.org

Abstraction of Transaction Demarcation in

Component-Oriented Middleware

Romain Rouvoy - Philippe MerleJacquard INRIA Project

LIFL – USTL

{Romain.Rouvoy, Philippe.Merle}@lifl.fr

Second ObjectWeb Consortium conference,

Paris, November 28 - 29th, 2002

www.objectweb.org (JOTM) - D2 - 07/10/2002

Outline

Context

Challenges

Solution

Current experimentations

Conclusion


Context

Under sun lights of middleware for components Enterprise Java Beans (EJB) CORBA Components (CCM) Next best things as .NET, Web Services, etc.

“Container” is the key technological artifact Transparent integration of extra functionalities

Transaction, security, persistency, server scalability, etc.

Various approaches Generated interception code, Fractal component membranes, AOP,

MOP, …

Many business components require “Transaction Demarcation (TD)” as fundamental extra functionality

All/any containers should/will address TD


EJB Transaction Demarcation

EJB Container

Java Transaction Service (JTA)

6 TD policies:

- SUPPORTS- NEVER- MANDATORY- REQUIRED- NOT SUPPORTED- REQUIRES NEW

Integration already done by JOnASand any other EJB platforms


Technical Challenge n°1

EJB Platform6 TD policies

ObjectTransaction

Service (OTS)

JavaTransaction

Service(JTA)

Next BestThings

(e.g. JOTM)

Not done by JOnAS, is it? Few EJB platforms could do this!



EJB Platform6 TD policies

ObjectTransaction

Service (OTS)

JavaTransaction

Service(JTA)

Next BestThings

(e.g. JOTM)

Requires abstraction of the TM integration!



Java OpenTransaction

Manager(JOTM)

CCM / OpenCCM EJB / JOnAS Next Best Things6 TD policies 6 TD policies 6 TD policies

Who addresses this factorization?




Manager(JOTM)

Requires abstraction of the 6 TD policies!

CCM / OpenCCM EJB / JOnAS Next Best Things




Manager(JOTM)

Abstraction of the 6 TD policies


How adding new TD policies?e.g. requires new sub transaction




Manager(JOTM)

Adding new TD policiese.g. requires new sub transaction


Requires independence between TD and TM!

ObjectTransaction

Service (OTS)

Next BestThings

(e.g. JOTM)


Scientific Challenge

Abstraction of transaction demarcation in component-oriented middleware

Mastering what transaction demarcations are

Mastering what transaction managers are

Defining the Open Transaction Demarcation Framework (OTDF)


Framework Challenge


ObjectTransaction

Service (OTS)

JavaTransaction

Service(JTA)

Next BestThings

(e.g. JOTM)

Open Transaction Demarcation Framework(OTDF)


Software Challenge

Provides the Java Open Transaction Demarcation Framework (JOTDF)

Modular and extensible Aspect- and component-oriented Memory and CPU predictability No performance degradation

JOTDF should include UML diagrams Java interfaces Java classes Fractal components


What is OTDF ?E

JB P

latf

orm OTS

JTS

JOTM

OTDF

CC

M P

latf

orm ?


Technical Challenges n°1 :Transaction Manager Abstraction

EJB

Pla

tfo

rm

OTS

JTS

JOTM

OTDF

Fac

tor

Poi

ntDefine a logical factorization



EJB

Pla

tfo

rm

OTS

JTS

JOTM

OTDF

Fac

tor

Poi

ntNeed a common protocol



EJB

Pla

tfo

rm

OTS

JTS

JOTM

OTDFF

acto

r P

oint

Wrapper

Wrapper

Wrapper

Provide a TM abstraction

?

?

?

What is this abstraction ?


Technical Challenges n°2 :Transaction Demarcation Abstraction

EJB

Pla

tfo

rm

OTS

JTS

JOTM

OTDF

Extract the policies

CC

M P

latf

orm

6 T

D p

olic

ies

6 T

D p

olic

ies



Switch(td) { case Supports :

… case Required :

… case NotSupported :

… case RequiresNew :

… case Mandatory :

… case Never :

…}

<<interface>>TransactionPolicy

Supports Required

NotSupported RequiresNew

Mandatory Never

JOnAS OTDF

Command Design Pattern



EJB

Pla

tfo

rm

OTS

JTS

JOTM

OTDF

Provide interfaces

CC

M P

latf

orm

6 T

D p

olic

ies

6 T

D p

olic

ies


Required OTS

Not Supported OTS

Never OTS

Mandatory OTS

Supports OTS

Requires New OTS

Required JTS

Not Supported JTS

Never JTS

Mandatory JTS

Supports JTS

Requires New JTS

6 TD Policies :- SUPPORTS- NEVER- MANDATORY- REQUIRED- NOT SUPPORTED- REQUIRES NEW


EJB

Pla

tfo

rm

OTS

JTS

JOTM

OTDF

Technical code extraction

CC

M P

latf

orm

6 TD Policies :- SUPPORTS- NEVER- MANDATORY- REQUIRED- NOT SUPPORTED- REQUIRES NEW



EJB

Pla

tfo

rm

OTS

JTS

JOTM

OTDF


CC

M P

latf

orm

Required OTS

Not Supported OTS

Never OTS

Mandatory OTS

Supports OTS

Requires New OTS

Required JTS

Not Supported JTS

Never JTS

Mandatory JTS

Supports JTS

Requires New JTS

Not Supported JTS

Requires New JTS

Required JTS

Never JTS

Mandatory JTS

Supports JTS

Not Supported OTS

Requires New OTS

Required OTS

Never OTS

Mandatory OTS

Supports OTS



EJB

Pla

tfo

rm

OTS

JTS

JOTM

OTDF


CC

M P

latf

orm

Not Supported JTS

Requires New JTS

Required JTS

Never JTS

Mandatory JTS

Supports JTS

Not Supported OTS

Requires New OTS

Required OTS

Never OTS

Mandatory OTS

Supports OTS



EJB

Pla

tfo

rm

OTS

JTS

JOTM

OTDF


CC

M P

latf

orm

Not Supported JTS

Requires New JTS

Required JTS

Never JTS

Mandatory JTS

Supports JTS

Not Supported OTS

Requires New OTS

Required OTS

Never OTS

Mandatory OTS

Supports OTS

Requires New

Required

Mandatory

Not Supported

Never

Supports



EJB

Pla

tfo

rm

OTS

JTS

JOTMOTDF


CC

M P

latf

orm

JTS

JTS

JTS

JTS

JTS

JTS

Not Supported

Not Supported OTS

Requires New

Requires New OTS

Required

Required OTS

Never

Never OTS

Mandatory

Mandatory OTS

Supports

Supports OTS



EJB

Pla

tfo

rm

OTS

JTS

JOTMOTDFOnly demarcation code

CC

M P

latf

orm

JTS

Not Supported

Not Supported

Requires New

Requires New

Required

Required

Never

Never

Mandatory

Mandatory

Supports

SupportsOTS

Same demarcation type

?


Technical Challenges n°3 :Adding new TD policies

EJB

Pla

tfo

rm

OTS

JTS

JOTM

OTDF

CC

M P

latf

orm

JTS

Requires New

Requires New

OTS

Requires New

JOTM

Using actual demarcation type



EJB

Pla

tfo

rm

OTS

JTS

JOTM

OTDF

CC

M P

latf

orm

JTS

Requires New

Requires New

OTS

Requires New

JOTM

Using actual demarcation type

No dependance



EJB

Pla

tfo

rm

OTS

JTS

JOTM

OTDF

Defining new demarcation type

CC

M P

latf

orm

JTS

Requires New

Requires New

Supports

SupportsOTS

Requires New SubRequires New Sub



EJB

Pla

tfo

rm

OTS

JTS

JOTM

OTDF

Defining new demarcation type

CC

M P

latf

orm

JTS

Requires New

Requires New

Supports

SupportsOTS

Requires New Sub

Requires New Sub

No dependance


OTDF

Not Supported


EJB

Pla

tfo

rm

OTS

JTS

JOTM

Composing existing policies

CC

M P

latf

orm

JTSRequired

Supports

Mandatory

OTS

Co

ord

ina

tor

Required

Not Supported

Never


OTDF

Not Supported


EJB

Pla

tfo

rm

OTS

JTS

JOTM

Composing existing policies

CC

M P

latf

orm

JTSRequired

Supports

Mandatory

OTS

Co

ord

ina

tor

Required

Not Supported

Never


OTDF

Technical Challenges n°4 :Independence between TD and TM

EJB

Pla

tfo

rm

OTS

JTS

JOTM

Only demarcation code

CC

M P

latf

orm

JTS

Not Supported

Requires New

Required

Never

Mandatory

Supports

OTS

JOTM

?


OTDF


EJB

Pla

tfo

rm

OTS

JTS

JOTM

Abstraction

CC

M P

latf

orm Not Supported

Requires New

Required

Never

Mandatory

SupportsTM OTS

TM

TM

JTS

JOTM

Ind

epen

den

ce



public interface UserTransaction { public int get_status (); public void begin (); public void commit (); public void rollback (); public void set_rollback_only (); public void set_transaction_timeout (int seconds);}

public interface TransactionManager extends UserTransaction { public Transaction get_transaction (); public Transaction suspend (); public void resume (Transaction tx);}

TMOTS

<<interface>>UserTransaction

<<interface>>TransactionManager


OTDF


CC

M P

latf

orm

OTS

JTS

JOTM

Instance

EJB

Pla

tfo

rm

Not Supported

Requires New

Required

Never

Mandatory

Supports

TM OTS

TM

TM

JTS

JOTM

Not Supported

Requires New

Required

Never

Mandatory

Supports


OTDF

New Technical Challenge :Organisation of the TD

OTS

JTS

JOTM

How to structure the policies ?

Not Supported

Requires New

Required

Never

Mandatory

SupportsTM OTS

TM

TM

JTS

JOTM

Org

aniz

atio

n ?


InterruptionActivationInterrogation

New Technical Challenge :Organization of the TD

Not Supported

Required

Never

Mandatory

Supports

Requires New

No hierarchy/organization in the policies !Observing policies to define a structureMapping between policies and the structure


Domain

OTDF


OTS

JTS

JOTM

?

TM OTS

TM

TM

JTS

JOTM

Supports

Mandatory

Never

Required

Not Supported

Requires New

Interrogation

Interrogation

Activation

Interruption

Interruption

Activation



public interface DomainInterrogation extends DomainProtocol { public int get_status(RequestCallContext ctx) ;}

public interface DomainActivation extends TransactionStatus { public void begin(RequestCallContext ctx) ; public void commit(RequestCallContext ctx) ;}

public interface DomainInterruption extends TransactionStatus { public void suspend(RequestCallContext ctx) ; public void resume(RequestCallContext ctx) ; }

<<interface>>DomainInterrogation

<<interface>>DomainProtocol

<<interface>>DomainActivation

<<interface>>DomainInterruption


Domains TMTD

Domain

OTDF

New Technical Challenges :Organization of the TD

OTS

JTS

JOTM

TM OTS

TM

TM

JTS

JOTM

Interrogation

Interruption

Activation

Supports

Mandatory

Never

Required

Not Supported

Requires New


New Technical Challenges :Organization of the TD

public class RequiredPolicyImpl extends AbstractActivationPolicy implements RequiredPolicy {

public RequiredPolicyImpl(TransactionActivation ta) { super(ta); }

public void preinvoke(RequestCallContext ctx) { if (ta.get_status(ctx)==Status.STATUS_NO_TRANSACTION) ta.begin(ctx); }

public void postinvoke(RequestCallContext ctx) { ta.commit(ctx); }}

<<abstract>>ActivationPolicyImpl

ActivationPolicy

<<interface>>RequiredPolicy

RequiredPolicyImpl


The ODTF Framework

OTDF

TM OTS

TM

TM

JTS

JOTM

Domain

Not Supported

Required

Never

Mandatory

Supports

Not Supported

Required

Never

Mandatory

Required

Never

Mandatory

Requires New

Requires New

Requires New

Not Supported

Interrogation

Activation

Interruption

Domain

Interrogation

Activation

Interruption

Domain

Interrogation

Activation

Interruption

Mul

ti-pl

atef

orm

Mul

ti-T

rans

actio

n M

anag

er

Ext

ensi

ons

Org

anis

atio

n

Adaptability Configuration


Class Evaluation

Before (without ODTF)Nb Classes = Nb TD x Nb TME.g. = 6 TD x 3 TM = 18 Classes

After (with ODTF)Nb Classes = Nb TD + Nb Domaines + Nb TME.g. : 6 TD + 3 Domains + 3 TM = 12 Classes


Context of the experimentation

Specifications :Computer :

Type : DELL Optiflex GX240CPU : Intel Pentium 4 2.00GHzRAM : 1024 MoBogomips : 3971.48OS : Linux DebianKernel : 2.4.19-686

JDK : Version : 1.4.1_01

JOnAS : Version : 2.5.3 (from CVS)

JOTDF :Using Fractal : noFramework Level : 2


Context of the experimentation

Experimentation :JOnAS example : sbInvocation : method buy()Type :

1000 invocations inside a transaction1000 invocations outside a transaction

Measure :global execution timenumber :

–10 on JOnAS platform

–10 on JOnAS platform with JOTDF


The JOnAS’s JODTF Framework

JTS

Not Supported

Required

Never

Mandatory

Requires New

JOnA

S (

EJB

) P

latf

orm

JTS

Supports

Interrogation

Activation

Interruption

JOTDF


Time EvaluationBlack Box

Policies JOnAS JOnAS & JODTF Variation

None - - -

Supports 36.475 sec 37.560 sec 102.97 %

Required 53.047 sec 53.190 sec 100.27 %

Not Supported 27.994 sec 28.563 sec 102.03 %

Requires New 56.590 sec 57.563 sec 101.02 %

Mandatory 127.221 sec 127.514 sec 100.2 %

Never 109.610 sec 110.438 sec 100.8 %

Average 101.26 %


Theoric EvaluationWhite Box

Policies

(Test or Invocation)

JOnAS

(Pre) + (Post)

JOnAS & JODTF

(Pre) + (Post)

None - -

Supports 5 + 3 1 + 1

Required 5 + 5 2 + 2

Not Supported 5 + 3 2 + 2

Requires New 5 + 4 2 + 2

Mandatory 3 + 0 2 + 0

Never 2 + 0 2 + 0

Average 4.16 + 2.5 1.83 + 1.16


Conclusion

We could abstract transaction demarcation in middleware platforms for components with high added values

Modular and extensible Aspect- and component-oriented Better memory and CPU predictability No performance degradation

The framework and its code base are available UML diagrams Java interfaces and classes Fractal components

Seamless JOnAS integration done By removing transactional code in JOnAS ;-) By adding adaptation code for our framework ;-( Better integration = Think JOnAS containers as clients of our

framework


Return to The Future

Apply our approach to some other extra functionalities dealt by containers

Distributed logging? Security access control? Others?

Need for a generic and common way for integration/interposition in “containers”

Fractal and ASM bytecode generation? Java Aspect Components (JAC)? Meta Object Protocol (MOP)? Interaction service from I3S? Or other adaptation techniques?


Questions

Documents

Abstraction of Transaction Demarcation in Component-Oriented Middleware