Nuxeo, a vendor of an open-source enterprise content management platform, has developed a modular software architecture using OSGi and an extension point model to enhance flexibility and customization. The Nuxeo Enterprise Platform consists of over 186 bundles and 215 extension points and aims to integrate with Java EE while overcoming challenges related to class loaders and configuration. Nuxeo plans to contribute the core of its platform to the Eclipse ECR project, promoting a community-driven approach to creating an OSGi-based ECM platform.

1. Creating Large-Scale Software
Platforms with OSGi and
an Extension Point Model
Introducing Eclipse Content Repository
Bogdan Stefanescu, Lead Architect at Nuxeo
2011-03-23
1

2. Nuxeo, Who Are We?
●
Vendor of an open source software platform in the
feld of Enterprise Content Management
●
Love to create great software, fond of modularity,
started to use OSGi 4 years ago to create server-side
enterprise software
●
10 years old, 500+ customers, 5000+ installations
●
Sells support & maintenance subscription and
added value software provided as a service
●
Dual HQ Paris & Boston, offces in San Francisco
●
http://www.nuxeo.com
2

3. Nuxeo Enterprise Platform
●
The software we develop is an Open Source ECM
platform known as Nuxeo Enterprise Platform (EP)
●
A platform because you can use Nuxeo EP to develop
your own customized ECM application
●
We also provide turn-key pre-built applications based
on Nuxeo EP already customized for different scopes:
– Document Management (DM)
– Digital Asset Management (DAM)
– Case Management Framework (CMF)
– or simply Content Application Platform (CAP) for developers
3

4. 4

5. Why Are We Here Today?
●
To share our experience in building an enterprise
application using OSGi and an extension point
model
●
To discuss and participate into spreading
Equinox on the server side as well
●
To grab your feedback and ideas!
●
And, why not... to do some marketing too ;-)
5

6. What Have We Achieved For Now?
●
A complex software platform made of
●
186+ bundles, 215+ extension points
●
Very fexible thanks to extension points
●
Easy to contribute new services
●
Easy to customize the default application (including UI
and business logic)
●
Running virtually everywhere
●
JBoss AS - as an EAR application
●
Tomcat - as a WAR application
●
Equinox - as an OSGi application (and Virgo very soon)
6

7. A Bit of History...
●
We have been developing this ECM platform for 8
years
●
We started in Python
●
5 years ago we switched to Java
●
We needed a great model suitable for
●
Modularity – split functionality in modules
●
Flexibility – be able to easily confgure the application
●
Constraints (requested by customers)
●
Must deploy as an EAR or WAR application
7

8. Choosing the Framework
●
What were the choices?
●
Java SE – nothing proposed
– No bundle life cycle, no modularity, no extension system
●
Java EE – not modular at all
– All is packaged as one big application (EAR or WAR)
– To update or add a feature you need to recompile the entire
application
●
OSGi – great specifcation – love at frst sight
– But not compatible with J2EE
– No real OSGi enterprise framework implementations at that
moment
8

9. Let's Give OSGi a Try...
●
OSGi was best suited for our dreams… but...
●
How to achieve fexibility?
●
Eclipse already had the answer: extension points
– Thanks Eclipse!
●
How to integrate with J2EE Application Servers?
●
J2EE applications are monolithic – there is no notion
of modularity inside an application; the application is
the unit
●
But our application is supposed to be a platform
made from tens or hundreds of units!
9

10. An Extension Point Model ...
●
So Eclipse already provided an extension point
model – which is very good but ...
●
It is based on EXSD descriptors
●
Diffcult to manage EXSD fles outside PDE IDE
●
PDE is very related to Eclipse plugin development
●
PDE was not friendly with server side development
– Remember we are in 2006
●
PDE was not friendly with other build systems
– We were using Maven as our build system
10

11. Nuxeo Extension Point Model
●
So we decided to achieve something similar but
in a more fexible way:
●
No intermediate object model between services and
contributed extensions
●
Write your extension class and map it to XML using
Java annotations
●
Very easy to write for developers
●
No specifc IDE needed to code extension points.
●
Write a Java class, put the right annotations and the
extension XML will be correctly injected into the Java
object
11

12. Extension Example
XML Extension Extension Class
12

13. J2EE Integration
●
Main problem: different ClassLoader model
●
In J2EE an EAR application is the deployment unit
and use a fat ClassLoader
●
In OSGi an application is made of multiple units (i.e.
bundles) each one with its own ClassLoader
●
Second problem: static confguration
●
In J2EE the application is confgured as a single block
using an application.xml and web.xml fle
●
In OSGi we can have fragments that can dynamically
add confguration
13

14. Class Loading Problems
●
Running as an EAR application:
●
Using a home-made OSGi Adapter to load bundles
when the EAR application starts
●
Bundles life cycle is preserved
●
A fat class loader model is used
– All classes are visible to all bundles
●
Running as an OSGi application:
●
Main problem caused by third party libraries using
Class.forName and the Thread Context ClassLoader
– Using Eclipse-BuddyPolicy when no other solution is
possible
14

15. Confguration Fragments – 1
●
On J2EE confguration is monolithic
●
To declare servlets you should know in advance what
are the servlets provided by different bundles
●
Using templates for J2EE confguration fles
●
Dynamically generate these fles at application startup
from the confguration contributed by bundles
●
Able to package EAR applications that can adapt
themselves to the confguration provided by
application bundles
●
No need of having different product packagings for
different confgurations
15

16. Confguration Fragments – 2
conf guration fragment
i web.xml template. ID: web
16

17. J2EE Features Added to OSGi
●
Full OSGi integration of JAAS – for the
authentication system
●
Full JTA (transactions) support through Apache
Geronimo
●
Full JCA (resource adapters and pooling) support
through Apache Geronimo
●
In-memory JNDI server
●
Future plans to integrate the work done in the
Gemini project (and also support Virgo)
17

18. Where Are We Going?
●
Contribute the core of Nuxeo EP to Eclipse
●
ECR (Enterprise Content Repository) project is
in the proposal phase
●
https://github.com/nuxeo/org.eclipse.ecr
●
Port all major Nuxeo EP services as ECR plugins
●
For now only the core functionality is included
in ECR
●
Help us provide the frst OSGi-based ECM
platform based on the ECR project!
18

19. Questions?
Start Hacking ECR:
https://github.com/nuxeo/org.eclipse.ecr
Get Involved:
ECR Proposal Forum
Read more:
Eclipse ECR Proposal
Nuxeo EP Reference Documentation
Contact me/us:
Bogdan Stefanescu - bstefanescu@nuxeo.com
http://www.nuxeo.com
19