On migrating from Python & Zope to Java with EJB 3 & JBoss SEAM

Posted by Floyd Marinescu on Sep 26, 2006

Community

Java

Topics

Change ,

Scripting ,

Portal/CMS

Tags

Python ,

Nuxeo ,

EJB ,

JBoss Seam ,

JBoss ,

Java EE

Nuxeo SAS has announced that the next generation of its enterprise content management platform, due to November 2006, will be based on open source Java technologies, specifically JBoss SEAM, EJB 3, and JBoss Application server.  The move is interesting as previously they were mainly a Python shop using the ZOPE application server, and they claimed to be "the biggest Zope-focused company in the world." Last week InfoQ spoke to Nuxeo's engineering team to find the why and how of their move.

The company initially chose ZOPE as it's primary platform back in 2000 when there were no open source Java alternatives.

But now our company has grown a lot, and we are now addressing $M+ projects that have strong requirements in terms of performance, availability and integration into our clients’ information systems.

Over the past 6 years, we have worked hard trying to push Zope past its natural limits to meet the needs of our customers. We had to work on all levels, including many infrastructure components (object database, document model, index engine, workflow engine, programming tools…), while seeing more and more compelling components appearing in the open source Java world (Jackrabbit, Lucene, jBPM, Eclipse…).

We also had worked on rich client tools, through the Apogee project we initiated and that has recently been approved by the Eclipse Foundation. We found the Eclipse model of extensible components, based on OSGi, to be both compelling and in some ways similar to the “Zope component architecture” we were familiar with.

After working on an hybrid combination of Zope front-end and Jackrabbit+Lucene backend, we finally decided that the time was ripe for a full rewrite, that would take advantage of both our ECM and Java experience.

On the pros/cons analysis of the move, the team found the following:

Pros:

• It is easier to hire and train staff, both for us and our partners
• There is a strong ecosystem of open source libraries, the most relevant for ECM applications being: Jackrabbit, Lucene, jBPM, JBoss Rules, etc.
• We have a choice of applications servers
• Our main customers and partners ask us for it
• There are a lot of tools to help developers be productive
• It will be easier to integrate with the customers information systems
• Java is now “Agile” thanks to JUnit, refactoring support in mdern IDEs, the OSGi component model, AOP, upcoming JVM scripting support (JSR-223)…
• The overall dynamism of the open source Java community (thanks to the Apache, JBoss, Eclipse, ObjectWeb, etc. groups or projects) is compelling

Cons:

• We have to rewrite the whole application from scratch (but the other option was to manage a transition from Zope 2 to Zope 3, which would have been less dramatic, but still a lot of work, maybe more than the Java rewrite)
• We’re losing our status as the biggest Zope-focussed company in the World (but we intend to claim the title of biggest open source ECM company, with more focus on business (ECM) and less on technology)
• We’re leaving the Python community, which was full of smart and knowledgeable people (but we know the Open Source Java community is cool too
  

The company is believes it will take 5 (mythical) man-years to reach a functional scope similar to what they had in previous versions, with a sounder and more scalable overall architecture. They have already been working on the port for 6 months, and are on schedule to meet the milestones in the current roadmap.

On why they chose OSGI:

OSGi is the model used by Eclipse. We are targeting Eclipse RCP with Nuxeo RCP, the rich client side of our project, in the sense that we want the same core components to be usable both on a Java EE application server and on Eclipse. Hence we had to use OSGi.  Besides, OSGi has several useful features: 

• it is probably the most complete mainstream Java packaging and service model
• it allows dynamic activation and hot deployment
• it manages dependencies between bundles

Of course these functionalities are probably available on other platforms, but by using OSGi, which is a POJO component model, we can easily adapt it to other target platforms. We have also observed that several Java EE application servers already support, or plan to support OSGi in the future: Geronimo, JBoss AS 5, JOnAS. That made our choice even clearer. What we have added to OSGi is the extension points mechanism, inspired by Eclipse, which gives a lot of freedom in configuring and extending applications. We also plan to make this mechanism compatible with the OSGi descriptive services. 

The company decided to adopt JBoss SEAM as their web application framework, due to the 'highly conversational' nature of the apps they need to host. In addition they chose to use JBoss application server as a full Java EE environment in order to get the benefits of EJB and a 'real' application server:

Performances: Nuxeo 5 targets high document volume with high level of concurrent transactions, and we believe the pooling and state replication services of an EJB container will allow us to reach these goals.

• Integrity and security: Nuxeo 5 leverages the transaction and security model of EJB3. As we have a very modular system, having a simple way to waranty transaction and security propagation to all components on all JVMs is important.

• Clear separation of Presentation and Business logic: All processing and services of Nuxeo 5 are implemented using EJB3. This clear separation gives us several advantages :

  • you can choose to deploy presentation and logic on differents JVM
  • we can easily split the business components on several machines to externalise the services that have intensive needs of ressources
  • the development model for business and presentation are differents, as they should be

• Remote access to the business layer: Because Nuxeo 5 can be used both via a thin client and via a rich client, EJB3 gives us the opportunity to expose a remote business API. This remote API can be accessed via SOAP (as this would be possible in Tomcat) but also via RMI and IIOP.

The emphasis on JBoss is tactical: we want to get a working product out of the door ASAP (in November 2006 to be precise) and we believe the best way to achieve this is to focus on one target platform. JBoss is production-ready, Java EE 5 / EJB 3 compliant, and professionally supported. Last, we have chosen to use three products from JBoss (Seam, jBPM and JBoss Rules) as primary building blocks for our platform. We know they can also be used on top of other servers than JBoss, but it’s more convenient for us to work with the same partner for both the application servers and these additionnal components.

But in the long run, we will target other application servers, including Glassfish, JOnAS and Geronimo. We have specifically designed the Nuxeo Runtime layer of Nuxeo 5 to be able to do this, by pluging in new adapters for each new platform we (or third-party contributors to the project) will want to target.

There is a roadmap on the website. First server platform release is scheduled for November 2006, while several core components will be released sooner. Participation to the project is encouraged. The project is licensed under the LGPL.

1. Back to top

   Nuxeo Runtime 1.0 has been released

   Sep 28, 2006 5:41 AM by Stefane Fermigier

   We have released version 1.0 of Nuxeo Runtime yesterday.
   
   There is a narrative or Eric’s blog.
   
   Nuxeo Runtime is the component technology we use to plug in functionalities into the application. (In a way similar to what we used with the Zope CMF tools / Zope 3 component architecture).
   
   Besides its use in Nuxeo Core, which will be released early next month BTW, Nuxeo Runtime should also be useful to Java / Java EE developers working on any kind of project where extensibility is key.

   Reply

2. Back to top

   Split deployment in a seam application

   Nov 1, 2007 6:57 AM by Jim Wormold

   Very interesting article. You mention that you can choose to deploy presentation and logic on different JVMs. Would an example of this be splitting the ear so that the war is deployed on a separate tomcat instance from the ear, which is deployed on jboss?
   
   If so, would you be able to provide some more details of how this can be set up ie how the remote calls work?
   
   It would appear to be a slight oversight on the seam developers part if this were not an easy thing to do, or is it now considered better practice not to split the ear across servers (against defense-in-depth reasons).
   
   Many thanks,
   
   Jim

   Reply

• Older >