Dynamic Deployment of IIOP-Enabled Components in the JBoss Server

(1)

1 CD 2004 – Edinburgh, UK – May 2004 Francisco Reverbel, Bill Burke, Marc Fleury

Dynamic Deployment of IIOP-Enabled Components in the JBoss Server

Francisco Reverbel

CS Department, University of São Paulo

Bill Burke

JBoss, Inc.

Marc Fleury

JBoss, Inc.

Outline

Introduction

JBoss Background

JMX, Service Components, Meta-Level Architecture

The IIOP Module

Proxy Factories

IIOP Invoker and IOR Factory Internals

Related Work

Concluding Remarks

(2)

Introduction

• Introduction

• JBoss Background

• The IIOP Module

• Proxy Factories

• IIOP Invoker and IOR Factory Internals

• Related Work

• Concluding Remarks

Software Components in the JBoss Server

Application components

Server-side parts of distributed applications

Middleware components

Provide middleware (system-level) services to application components

Both kinds of components can be dynamically deployed into a running server

(3)

Component Models

Application components follow J2EE standards

EJB model: for business components (“enterprise beans”) whose methods can be invoked either by remote clients or by local clients

Servlet/JSP model: for “web components”

Middleware components employ an extension of the JMX model

This extension is JBoss-specific

IIOP-Enabled EJB Components

IIOP support is mandatory for EJB compliance

IIOP support is a feature that can by dynamically added to a running server

IIOP-enabled EJBs are dynamically deployable components themselves

No extra compilation steps for IIOP stub/skeleton generation

JBoss uses reflective techniques instead

JBoss supports IIOP in a dynamic way:

(4)

Hot Deployment

Users can deploy IIOP-enabled EJBs into a running server simply by dropping deployment units (such as EJB-JAR files) in the server’s deployment directory

These deployment units contain no IIOP stubs and no IIOP skeletons

They contain no JBoss-specific classes (such as EJB container or CORBA servant classes)

A change to a JBoss-specific deployment descriptor is all that is needed to convert a non-IIOP-enabled deployment unit into an IIOP-enabled one

JBoss Background

• Introduction

• The IIOP Module

• Proxy Factories

• Related Work

(5)

JMX Architecture

Java Virtual Machine Agent Level Instrumentation

Level

Mgmt Client

Browser

Distributed Services Level

Connector

Protocol Adapter

Agent Services (as MBeans)

Managed Resources (as MBeans)

MBean Server

The JMX component model

The instrumentation and agent levels define an in-process component model

The MBean server provides a registry for JMX components (MBeans)

Each MBean is assigned an object name that is unique in the context of the MBean server Clients use object names to refer to MBeans MBean operation invocations always go through the MBean server

(6)

Method invocation on a dynamic MBean

Java Virtual Machine

Client

!!"#"# $$%%&')(*

&')(*++$,-($,-(..&&//

012

01233457698457698 :;<);:;<);==?>> @@

ABC

ABCDDEF7G9HJIDFEEF7G9HJIDFEKKBLMC)NBLMC)NOO

MBean Registry MBean Server

MBean

DEPQRN DEPQRNSSTABCABCDDEF

EF

QQUUNC)KBNC)KBDDQEVK

QEVKWWNN XX

YZ[

YZ[NN\B7G9H\B7G9H UKC)K

UKC)KWW?II

XX

ABC

ABCDDEF7G9HJIDFE

EF7G9HJIDFEKKBLMC)NBLMC)NOO

] The client holds no direct Java references to the MBean

] It does not need to know the MBean’s Java class/interfaces

] This very simple arrangement favors adaptation

Issues not covered by JMX

^ Dependencies between MBeans

^ Service lifecycle

^ Packaging and deployment of MBeans

JBoss addresses these issues with the notions of service MBean and deployable MBean

(7)

The JBoss model for middleware components

Service MBeans:

MBeans whose management interfaces include service lifecycle operations

Also called service components

Deployable MBeans:

Service MBeans packaged according to EJB-like conventions, in deployment units called service archives (SARs)

A SAR includes a service descriptor, an XML file that conveys information needed at deployment time

Also called deployable services

They are a JBoss- specific extension to JMX

Meta-level architecture for EJB:

the case of a non-IIOP client

Server Virtual Machine

Container MBean

Server-Side Interceptors

EJB Component Client Virtual Machine

Client-Side Interceptors

Invocation Handler

Dynamic Proxy

EJB Client

Invoker Proxy

EJB Container Invoker

MBean Client-Side

Proxy

Meta Level Base Level

(8)

Reified method invocations

No interface along the reified invocation path depends on base-level application types

FO

D

V , Q YR FD W L ^

2

E

M HF

R

EM H F W1^"! DP^#$ H ^%

M

& D^' Y

(

D^'*) O⁺ D^' Q^, J^-*) U^. H^/ IO⁰⁺ HF^/1 W² ⁾ 0

3

HW^/42 K⁵ R

6

G

7 P

8

H^/ W² KR⁵

6

G

7*9

2

:

E

; M^< HF^=> W^? >^@BA

C

D^D U^E J^F V^G ^H ,

I Q^J Y

K

RF

L"M D^N W^O L^P RQ^LJ &

Q

R

L QW^J4O H[^RTS W^O L^P QY^J

K

R

L F^M D^N WL^O"P R^L Q^J &R

Q L QW^JTO H^R [^S W^O ^U

^V ^VWV

`^X

Remote invocation architecture for non-IIOP clients

(1 of 2)

Y EJB containers expose a type-independent

L^Z Q^[ Y

\

R

]

NH^{^*_} operation

` Protocol-specific invoker MBeans make this operation accessible to remote clients through various protocols (JRMP, HTTP, SOAP)

` Client-side stubs are dynamic proxy instances

` They convert calls to the typed interfaces seen by clients into

L^Z Q^[ Y

\

R

]

NH^{^*_} calls on remote invokers

Server VM

Container MBean Invoker

MBean

(9)

Remote invocation architecture for non-IIOP clients

(2 of 2)

Each client-side proxy has an invocation handler that performs remote calls on a given invoker, over the protocol

supported by the invoker Client side proxies and their invocation handlers are instantiated by the server and dynamically sent out to clients as serialized objects

Client Virtual Machine

Invocation Handler Dynamic Proxy

EJB Client

Invoker MBean Client-Side

Proxy

JBoss invokers

Deployable MBeans that act as protocol-specific gateways to multiple EJB containers

Interface exposed by the JRMP invoker:

Other non-IIOP invokers implement either this interface or very similar ones

!!#""$$&%%''(""*))++%%,,--++

..

//002114335566

778899;::88<<>==?88<<4@@AA?BBC99DDEEFF88

GGIHHKJJ

LLMMNNOOPPQQ

RRSSUTTVV?WW OO XX4YY

SSCTTVV PPZZQQ

RRVV;SS

RRSSUTTVV PPZZQQ

RRCVVSS[[]\\

^^

(10)

Invoker proxies

A client-side proxy (or, more precisely, its invocation

handler) must

“know a remote invoker”

This knowledge is protocol-specific It is encapsulated within an invoker proxy

Client Virtual Machine

Invocation Handler

Dynamic Proxy

EJB Client

Invoker MBean Client-Side

Proxy

The IIOP Module

• Introduction

• The IIOP Module

• Proxy Factories

• Related Work

(11)

The IIOP module consists of...

… three deployable MBeans:

&

2

5 % $

2

U E 6 HU YL

FH

Thin wrapper around a third-party IIOP engine

JacORB is the default IIOP engine in the JBoss distribution

&

R

U E D 1 D P

L

Q J 6HU Y L F H

In-process CORBA naming service

Reuses (through inheritance) code from the JacORB naming service

, , 2

3 , Q Y R N H U

The IIOP invoker

! Unlike all other invokers, it does not follow the JBoss “invoker pattern”

! IIOP is treated as an special case

"

Reason: interoperability with CORBA clients written in other languages

"

The “invoker pattern” leads to an IIOP invoker that expects IIOP requests with the verb ^LQYRNH in their operation fields

# But IDL-generated stubs send out IIOP requests whose operation fields contain application-specific verbs

(12)

Meta-level architecture for EJB:

the case of an IIOP client

Server Virtual Machine

EJB Component Client Virtual Machine

EJB Container IIOP Invoker

MBean

CORBA Servant

POA

EJB Client

IIOP Stub

Server-Side ORB Client-Side

ORB calls to base-level interfaces calls to ORB-specific interfs.

IIOP request

call to OMG-defined interface flow of reified invocations

Proxy Factories

• Introduction

• The IIOP Module

• Proxy Factories

• Related Work

(13)

EJB references

An EJB reference is either a reference to an

(

- % 2

E M H F Wor a reference to an (-% + R

P

H

EJB containers have the responsibility of creating such references, which in various situations they pass to EJB clients or to EJB implementations

JBoss supports two general kinds of EJB references:

Java references to dynamic proxy instances, which are sent out to other VMs as serialized Java objects

CORBA references, passed across process boundaries in the standard IOR format

The proxy factory interface

SX E O L F L Q W HUI^! D"$#&%& (^' -⁽ %⁾ 3^* UR^+-, [^. \^/ )⁰ DF¹³² W⁴ R^, U\⁺ ^/ H

5 [W

. 4 H⁵ Q⁶ G⁷ V⁸ &

9

R

, QW^6:4 DL^1<; Q⁶ H⁵ U⁺ 3O^*>= X^? J^@ L^; Q⁶ ^^A ^B ^BB

2

C

E^D M^E HF^5&2GF4 J^@ HW^5:4 (^' -⁽ %+^)H RP^,:I H⁵ ^J ^K ^L 2

M

E^N M^O HF^P&QGR

S

J

T HW^P

S

6

U W

S

DW

V S

HO

P3W H^P V^X V^X 6H^U:P V^X V^X L^Y RQ^ZG[ (^\ -^] %2^{^}

M

EM

N_O H^P F^Q W

S

^J`KaL

2

M

E^N M^O HF^P&QGR

S

J

T HW^P

S

6

U W

S

DW

V S

HI

Pb X^c O^W 6^U HV^P3X V^X L^Y R^Z Q(^[3\ -^] %^{^} 2E

M N MH^OP F^Q W

S

^J 2

M

E^N MH^OP F^QdR

S

V

X HV^P3X V^X L^Y R^Z Q,^[e G^f ^KaL

2

M

E^N M^O HF^P&QGR

S

J

T HW^P

S

(^\ Q^[ WL

S Y W\

S>g

(^\ -^] %^{^} 2E

M N M^O H^P F^Q W

S

^J 2

M

E^N MH^OP F^QdR

S

h UL^ikj P

l

D

m Uⁱ \.

ndo

H

p \

n

^q ^r

&

s

R

t O^u OH^u_p F^v W^w L^j RQ^tGx J^y HW^p&w (Q^z_x W^w L^j W^w \&ⁿ

s

R

t O^u O^u HF^p&v W^w L^j RQ^tdx ^{

&

s

RO

tGu O^u H^p F^v WL^w<j R^t Q^x S^h UL^ikj P

l

D

m Uⁱ \.

ndo

H

p \

n

V^| ^qar

`

(14)

Implementations of the EJBProxyFactory interface

3

U R

[

\

) D F WR

U\

Instances of this class create dynamic stubs that talk to remote invokers over various protocols

3

U R

[

\

) D F WR

U \+

$

Instances of this class create dynamic stubs used in clustered JBoss environments

The “HA” suffix stands for “high availability”

, 2

5 ) D F WR U\

Instances of this class create CORBA references

Relationship between invokers, proxy factories and containers

Server Virtual Machine MBean Server

EJB Component

EJB Container IIOP Invoker

MBean

CORBA Servant

POA

Server-Side ORB HTTP Invoker MBean JRMP Invoker MBean

ProxyFactory ProxyFactory

IORFactory

(15)

Proxy factory configurations

EJB deployer MBean

Handles the deployment of EJB components

Reads container configurations from XML files and creates containers

Container configuration

Has all the information the EJB deployer needs to create a container MBean, its plug-ins and its interceptors

Includes information on the container’s proxy factories

One proxy factory configuration per protocol

Information in a proxy factory configuration

The proxy factory class (a Java class) The invoker MBean (the protocol!)

Additional parameters, depending on the proxy factory class

In the case of non-IIOP access, XML elements in the proxy factory configuration fully specify the chain of client-side interceptors

No similar elements exist in the configuration of a proxy factory for IIOP access (,

2

5 ) DFWR

U \

)

Interceptors instantiated at the server side would not make sense for non- Java clients

(16)

Global configuration file

Default container configurations for standard kinds of EJBs:

Stateless session beans

Stateful session beans

Entity beans

Message-driven beans

These configurations support RMI over JRMP

Alternative container configurations:

IIOP support

clustering

...

Local configuration file

JBoss-specific deployment descriptor

Optionally included with a given EJB

May refer to an alternative container configuration by its name

Perhaps to specify other protocol, such as IIOP

May fully define a new container configuration May use a predefined configuration and

enhance it with aditional proxy factory configurations, also taken from the global configuration file

EJB accessible via multiple protocols

(17)

IIOP Invoker and IOR Factory Internals

• Introduction

• The IIOP Module

• Proxy Factories

• Related Work

CORBA servants

Two CORBA servants per IIOP-enabled EJB

home servant and bean servant

They must implement IDL interfaces not known in advance!

Our servants use the stream-based ORB API

Each servant knows the object name of the target container MBean

Each servant has marshalling knowledge specific to the IDL interface it implements

Map from IDL operation names to objects

(18)

POA usage

Our choice of lifetimes for CORBA references:

Session bean instances :transient references

Entity bean instances :persistent references

EJB homes :persistent references

In terms of POAs:

Session bean servants are registered with POAs with the TRANSIENT lifespan policy

Entity bean and home servants are registered with POAs with the PERSISTENT lifespan policy

These POAs may be per-servant or shared

Default: per- servant POAs created at deployment time

Lazy generation of

RMI/IIOP stub classes (1 of 3)

An ,2

5 )D F W R U \

can be optionally associated with a web class loader that generates

RMI/IIOP stub classes in a lazy way

:

HE

&/

is a subclass of URLClassLoader

It has a method ^"!! #%$'&)(+*#%$'&)(,*&&$%-/.10

$-2.10)3354)-6-4)-6- 78'9768'9 ::

; When a :

<

HE^=> &

?

/^@ is asked to load )^A R

B

RB

BC

6^D WX^EF E^G , it

H performs Java introspection on interface ^IIKJJJJ

L applies the Java to IDL mapping on ^IIMJJ'JJ

L uses code generation techniques to create a byte code array with the class file for ^NMO6OPNMOO,P/QQ5RSR%STT

U keeps this array in a hash map, to be returned by ^VVXWZYWZY5[[]\\+YYXWW+^^

_ creates a ^``a'b)c^adb)c6cc instance from the byte code array

(19)

An in-process web server allows remote clients to download classes via HTTP

A client downloads a class file by issuing an HTTP request to a resource name that includes

the id of a :

H

E &

/ instance that can load the class

the full name of the class file

When the web server receives such a request, it uses the :HE& / given by the resource name

to create a &

OD V V object

to retrieve the corresponding class file

Default ,25 ) D FW R U \ configuration:

Every , 25 ) D F W R U\

has its :HE&/

instance

An ,2 5 ) D F W R U \ includes information on its web class loader in each IOR it generates

The IOR has a tagged component that specifies a codebase URL for stub downloading

The path component in this URL identifies the web class loader of the ,^! 2

"

5)^#%$ D F^& W^' RU^(*) \

+ that created the IOR

(20)

Related Work

• Introduction

• The IIOP Module

• Proxy Factories

• Related Work

Some related middleware systems

Flexinet (Hayton et al)

Flexible remote invocation paths

Dynamic stubs

OpenCOM (Clarke et al)

Lightweight component model

Based on a subset of COM

Dependence management, reconfiguration, method call interception

Hadas (Ben-Shaul et al)

Fractal component model (Bruneton et al)

(21)

Commercial J2EE servers

Most use compilation-based approaches IONA’s ART framework

relies on the chain of responsibility pattern

basis for various middleware products, including a J2EE server

Nearly all commercial offerings require vendor- specific EJB container or CORBA servant classes to be generated as part of the deployment process

In the case of IIOP-enabled EJBs, all other servers require extra compilation steps for stub and skeleton generation

Concluding Remarks

• Introduction

• The IIOP Module

• Proxy Factories

• Related Work

(22)

JBoss/IIOP...

Supports IIOP-enabled components without sacrificing the levels of flexibility, developer friendliness and ease of use that JBoss had already reached in the non-IIOP case

Strong reliance on reflection to make EJB deployment easy

Dynamic deployment issues...

Instantiation of CORBA servants for IDL interfaces not known in advance

Creation of POAs at deployment time Lazy generation of RMI/IIOP stubs

We believe that our techniques are equally applicable to CCM servers

and to other highly dynamic component environments.

(23)

Thank you for your attention!

Q & A ...

Francisco Reverbel

reverbel@ime.usp.br

Bill Burke Marc Fleury

bill@jboss.org marc@jboss.org

http://www.jboss.org

Backup Slides

(24)

Dynamic proxy usage

A dynamic proxy is an object adapter that converts the type-independent interface of its invocation handler into a list of interfaces specified at runtime

Dynamic proxies bridge the gap between the interfaces that are application-specific and those exposed by middleware components

The dynamic stub idiom

In Java RMI:

Serializable types are normally passed by value

Remote types are normally passed by reference

What about a remote object that is also serializable?

If it has not been exported through the RMI system, then it will be passed by value (in serialized form)

This allows the creation of custom stubs, which interact over a custom protocol with the remote objects they represent

JBoss uses dynamic proxies as custom stubs

The dynamic proxy implements application interfaces

Its customized part is the invocation handler

(25)

Generalized EJB containers

A container MBean is created when an EJB is deployed

It provides middleware services to its EJB

(instance pooling, instance caching, persistence, security, transactions...)

… by merely aggregating aspects that do the real work

Container configurations (XML files)

For standard kinds of EJBs

For JBoss-specific extensions

Customized containers for generalized EJBs

JBoss...

Demonstrates that application servers can be built out of dynamically deployed components that provide middleware services to application components

Brings reflective middleware to the world of mainstream computing