Exolab.org OpenORB Enterprise Suite : An OpenSource CORBA platform Jérôme DANIEL...

Exolab.org www.exolab.orgwww.openorb.org

OpenORB Enterprise Suite : An OpenSource CORBA platform

Jérôme DANIEL [email protected]’Reilly Conference Santa Clara

Exolab.org2000 Alameda de las

Pulgas, Suite 250San Mateo, CA 94403


What is the OpenORB Enterprise Suite ?

• A CORBA ORB for Java

– compliant to the latest specification 2.4.2

– includes POA & BOA

– supports Object By Value

• A set of very valuable services

– includes 10 CORBA Services

– some very interesting services :

• Transaction

• Persistence

• Notification

• Some powerful extensions

– RMI over IIOP

– SSL An OpenSource project sponsored by Exolab.org


OpenORB Core

OpenORB Enterprise Suite


The main features

• Designed for large scalability

• Fully written in Java ( compliant with JDK 1.2 & JDK 1.3 )

• Mapping 2.4.2

• Two object adapters : BOA & POA

• Object By Value supported

• IIOP 1.2 and Bidirectional IIOP

• Portable Interceptors

• Dynamic API ( DII, DSI, DynAny )

• Reusable IDL compiler ( IDL reflection )

• Some utilities ( IDL to HTML, IDL to RTF )


CORBA Feedback

• From developers :

– complex to configure

– complex to deploy and maintain an application

• From managers :

– Too heavy for the needs

– Does not contain the specific features for our IT logic

– Too expensive


OpenORB : an Open ORB

• OpenORB is not a monolithic ORB : it’s a truly modular ORB

• OpenORB can be customized to fit an application requirements :

– The user can specify the features to use

• Within a configuration file, the user describes what he wants :

– He only includes the required parts,

– He takes advantage of a better distributed environment : lighter, faster

• Some parts can also be replaced by some others. For example, the communication protocol ( by default IIOP ) could be replaced by another one ( developed for example by the user ) : OpenORB is an Open ORB.


The OpenORB Architecture

OpenORB Kernel

Kernel Connector

Communication Protocol Connector

OA

Connect

or

Objects, Stubs and Skeletons

DII DSI DynAny

BOA

POA

IIOP SSLIOP …

Interceptors …

…


Configuration & Deployment

• OpenORB requires an XML configuration file. This file mainly contains two parts :1. Module : an enumeration of properties2. Profile : a set of modules

• A Profile is a full configuration that can be used to start the ORB.

• A default configuration file is delivered with OpenORB as an embedded configuration directly located within the Jar file.

• A user can define its own configuration file to customize the OpenORB behavior

:

– Specify the ORB features to use

– Customize the ORB behavior

– Customize all other OpenORB services and extensions

• Then, this configuration can be included in its own Jar file ( for its application ).

– easy deployment ( no configuration required for the CORBA part when deploying )


OpenORB Services & Extensions



The basic services

• Naming Service ( Interoperable Naming Service )

• Concurrency Service

• Event Service

• Property Service

• Time Service

• Trading Service


The complex services

• Notification Service

• Transaction Service

• Persistent State Service


Several extensions

• OpenORB Enterprise Suite also provides several extensions :

– A Management Board

– SSL

– RMI over IIOP


The Transaction Service



What is the Transaction Service ?

• The OTS ( Object Transaction Service ) provides :

– Distributed transactions management

– Recovery management

– Flat transactions and sub transactions ( close model )

– Initiator and subordinate models are supported

– does not provide any API for XA and OSI/TP interoperability

• A set of objects are managed by the OTS

– The transaction factory

– The control object

– The coordinator and terminator objects


How is working the transaction service ?

C

S1 R1

S2 R2

OTS

begin

transactional context

Invoke business method

The transactional context is now on the participant side

A set of objects is createdfor the current transaction.

bodyheader

standard extra

Thanks to the transactional context,the participant registers a resource withinthe current transaction.

R1R1,R2

Same thing with thesecond participant

commit

The Transaction Monitor begins aTwo Phases Commit algorithmwith all the participants.

prepareready

ready

commit

Commit okTransaction commited


The OpenORB OTS

• A fully compliant implementation of the OMG OTS specification

• Some extensions

– JTA interfaces

– XA management

– Administration interface

• The Exolab also sponsors another Transaction Monitor

implementation : Tyrex ( www.tyrex.org )

– A complete Transaction Monitor

– An OTS version


The Persistent State Service



What is the PSS ?

• The Persistent State Service ( PSS ) provides several CORBA friendly APIs to store/restore CORBA data types within datastores.

• The PSS provides a link between the « ORB domain » and the « Datastore domain ».

External interface Internal interface

Objects

ORB domain Datastore domain


The PSDL

• To describe persistent data, a new description language is used : PSDL ( Persistent State Description Language ) which is a super set of IDL.

• A PSDL description is divided into two parts :– The abstract model which describes the persistent data types.

– The concrete model which implements the abstract model.

• A PSDL description is compiled and generates a set of APIs which are independent of the datastore.

compilation

API ( independent of the datastore ) : abstract model

API implementation :concrete model


A simple example

• Description of persistent data : « abstract storage type »

• Description of set of persistent data : « abstract storage home »

– Includes finder and factory

abstract storagetype Person{

state string firstname;state string lastname;state long age;

};

abstract storagehome PersonHome of Person{

key name( firstname, lastname );key firstname;factory create( firstname, lastname, age );

};

Use of the default concrete model

storagetype PersonImpl implements Person { };

storagehome PersonHomeImpl of PersonIml implements PersonHome{ };


How to use a storage type ?

• No need to invoke a store/restore operation

• The PSS implementation automatically stores the object if it has been modified.

• To get or create a new storage type, we only use the storage home.

– A storage home is retrieved thanks to a connector that implements the link between the

concrete implementation and the the data store.

PersonHome home = …

Person joe = home.create("Joe","Smith",31);

joe.age( 32 ); // Happy birthday !

System.out.println("My name is " : joe.firstname() );


OpenORB PSS Implementation

• Full implementation of the PSS implementation

– PSDL compiler

– 3 connectors :

• Database, File and Memory

– 3 session types per connector :

• Basic, transactional, session

• Several extensions

– Extended API

– Iterator

– Multiple connectors with the same application implementation


RMI over IIOP



Overview

• RMI over IIOP is a way to run RMI applications over CORBA !

– It means that an ORB is used

– It’s completely transparent from the user point of view

• A RMI client uses RMI over IIOP to invoke RMI objects

• A CORBA client directly uses the standard CORBA invocation model

– An IDL description is required for a RMI object

• With RMI over IIOP, it’s not possible :

– To invoke a standard CORBA object from a RMI client


Some details about RMI over IIOP

• RMI/IDL is a set of rules that define how to describe a RMI object in

IDL.

• A RMI/IDL tool is provided to automatically generate :

– The RMI object IDL description

– The RMI object stub and skeleton ( also called « Tie Object » )

• To invoke a RMI object from a CORBA client :

– The IDL description must be compiled to generate the CORBA stub

– The ORB used on client side must provide Object By Value

– Most of complex data types must be re-implemented on the client side ( as

for instance the Vector type ).


OpenORB RMI over IIOP

• OpenORB Enterprise Suite provides a complete implementation of the

RMI over IIOP specification :

– A tool to generate a IDL description, stubs and skeletons

– A JNDI implementation to bind RMI objects within the CORBA naming

service

– It takes advantage of the OpenORB platform ( Scalability, Interoperability )

– It’s possible to use several extensions at the same time

• Combine for instance RMI over IIOP and SSL

OpenORB

CORBAClients RMI over IIOP

RMI Clients RMI Objects


Some details about OpenEJB and OpenORB



OpenEJB

• OpenEJB is a fully compliant implementation of the EJB 1.1

specification.

– OpenEJB is also an OpenSource project sponsored by Exolab.org (

www.openejb.org)

– It’s not an EJB Server

– It’s a EJB container system ( it means that OpenEJB provides

several containers to deploy and execute session and entity

beans )


OpenEJB Architecture

Invocation API

SPIContainer

The Service Provider Interfacesprovides connectivity to theimplementation of :

- transaction management- security- persistence

This interface is used to invoke Home andBean implementations.


The adapter purpose

• To use the OpenEJB container system over CORBA

– Reuse RMI over IIOP without any change

– Reuse OpenEJB without any change

OpenEJB

RMI over IIOP

Bean implementation ( RMI object )

The CORBA Object delegates the invocation to the RMI object

The Adapter is responsibleto rely incoming requests tothe EJB container. It's alsoresponsible for transactionand security managements.

Invocation API

Adapter


OpenEJB/OpenORB Adapter

• The OpenEJB/OpenORB Adapter will be available in several

weeks :

– Provides a complete application server over CORBA

• EJB components ( session, entity )

• Transaction, Persistence and Security Management

– Takes advantages of the OpenORB Enterprise Suite Platform

• OpenORB Scalability

• Secured communication

• Distributed transaction management


Conclusion




• A complete CORBA Framework

– An ORB 2.4.2 ( scalability, interoperability, portability )

– 10 services ( Transaction, Persistence, Notification, … )

– 3 extensions ( RMI over IIOP, SSL )

– Several kinds of application ( CORBA application, RMI application, EJB

component )

• An Open Source project sponsored by Exolab.org

– Team : Jerome DANIEL, Marina DANIEL, Olivier MODICA, Chris WOOD

– Contributors

Exolab.org OpenORB Enterprise Suite : An OpenSource CORBA platform Jérôme DANIEL...

Documents

Transcript of Exolab.org OpenORB Enterprise Suite : An OpenSource CORBA platform Jérôme DANIEL...