OpenORB Enterprise Suite : An OpenSource CORBA platform

1. OpenORB Enterprise Suite : An OpenSource CORBA platform Jérôme DANIEL jdaniel@intalio.com O’Reilly Conference Santa Clara Exolab.org 2000 Alameda de las Pulgas, Suite 250 San Mateo, CA 94403

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

3. OpenORB Core OpenORB Enterprise Suite

4. The main features • Designed for large scalability • Fullywritten 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 )

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

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

7. The OpenORB Architecture Objects, Stubs and Skeletons DII DSI DynAny Interceptors … Kernel Connector OpenORB Kernel BOA OA Connector POA … Communication Protocol Connector IIOP SSLIOP …

8. Configuration & Deployment • OpenORB requires an XML configuration file. This file mainly contains two parts : • Module : an enumeration of properties • 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 )

9. OpenORB Services & Extensions OpenORB Enterprise Suite

10. The basic services • NamingService ( Interoperable Naming Service ) • Concurrency Service • Event Service • Property Service • TimeService • Trading Service

11. The complex services • Notification Service • Transaction Service • Persistent State Service

12. Several extensions • OpenORB Enterprise Suite also provides several extensions : • A Management Board • SSL • RMI over IIOP

13. The Transaction Service OpenORB Enterprise Suite

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

15. A set of objects is created for the current transaction. The Transaction Monitor begins a Two Phases Commit algorithm with all the participants. R1 Thanks to the transactional context, the participant registers a resource within the current transaction. commit Commit ok Transaction commited prepare begin ready commit Invoke business method The transactional context is now on the participant side ready transactional context header body Same thing with the second participant standard extra How is working the transaction service ? OTS R1,R2 S1 R1 C S2 R2

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

17. The Persistent State Service OpenORB Enterprise Suite

18. 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 ». ORB domain Datastore domain Objects External interface Internal interface

19. 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. API ( independent of the datastore ) : abstract model compilation API implementation : concrete model

20. 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 ); }; storagetype PersonImpl implements Person { }; Use of the default concrete model storagehome PersonHomeImpl of PersonIml implements PersonHome { };

21. 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() );

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

23. RMI over IIOP OpenORB Enterprise Suite

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

25. 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 ).

26. 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 RMI Clients RMI Objects CORBA Clients RMI over IIOP OpenORB

27. Some details about OpenEJB and OpenORB OpenORB Enterprise Suite

28. 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 )

29. OpenEJB Architecture S P I • The Service Provider Interfaces • provides connectivity to the • implementation of : • transaction management • security • persistence Container Invocation API This interface is used to invoke Home and Bean implementations.

30. The adapter purpose • To use the OpenEJB container system over CORBA • Reuse RMI over IIOP without any change • Reuse OpenEJB without any change Bean implementation ( RMI object ) OpenEJB The Adapter is responsible to rely incoming requests to the EJB container. It's also responsible for transaction and security managements. Invocation API Adapter RMI over IIOP The CORBA Object delegates the invocation to the RMI object

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

32. Conclusion OpenORB Enterprise Suite

33. OpenORB Enterprise Suite • 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