ObjectWeb Architecture Meeting - Day 2

June 21 is the "Fete de la musique" in France, an increasingly popular celebration of the equinox where amateur bands play music in the streets. It was pretty crowded in the streets of Grenoble last night, with really nice weather, lots of bands and packed cafés. A nice musical bridge between the two days of the Architecture Meeting!

Today Takoua Abdellatif presents the results of a research project she works on, with a prototype named "jonasALaCarte". It is an attempt to refactor JOnAS with the Fractal component model. It is implemented with Julia, a Java implementation of Fractal (that proved stable and is used in production at France Telecom). It brings the advantages of an explicit architecture, fine grained management, an on-demand distributed architecture (one instance of JOnAS can be scattered on several distributed JVMs), etc. Web container, EJB container, transation manager, etc, can be deployed on different nodes, with a much finer granularity than allowed by a monolithic JOnAS. Fractal brings nice feature, such as the possibility to upgrade a subsystem (eg Tomcat for web container), by replacing it with a more recent version for example, on the fly and without shutting down the service. jonasALaCarte also is compliant with JSR88.

Jean-Bernard Stefani proposes steps towards "JOnAS NG". He advocates for a Fractal based design for the future of JOnAS. He suggests how Fractal design can be leveraged to improve administration features in JOnAS. He gives hints at the complementary roles that AOP and OSGi can play in a Fractal based design.

Fractal is a very generic component model, as the model can be used to describe several types of components: without introspection (POJOs); with minimal introspection (COM component); with binding controller and fixed lifecycle manager (OSGi bundle); with transactional controller, content controller for POJOs with lifecycle interface (EJB). Fractal may be the basis for a micro-kernel architecture, actually what JB calls an "exo-kernel" architecture that goes beyond what a JMX based micro-kernel is. Automated system management would allow fault management: components would be the unit for fault isolation, for replication and recovery (replacement of faulty components).

So is AOP the new graal of software design? It sometimes sounds too much like a marketing gimmick. Anyways software architecture comes first, JB says, and it makes sense. Only good architecture makes it possible to put pointcuts and to apply advices at the right places. Aspect weavers can be understood as tools to program Fractal component controllers. Fractal code can be packaged as OSGi bundles. LSR Adele team developped the Froggi project which is an examplification of this possibility. JB proposes an increamental roadmap to refactor JOnAS with Fractal concepts. It'd start a coarse grain "fractalization" (eg jonasALaCarte). Then the EJB controller would be fractalized, EJB would then be made Fractal components. The interesting idea is that EJBs would then be seen as subcomponents of their container! And then fractalization would be carried on at a finer grained level... Sounds to me that this recursive peek into the internals of a webapp deployed on an application server would be pretty scary to the average system administrator!

Pedro Garcia Lopez (Univ Rovira I Virgilli) presents the SNAP P2P routing platform and the possible deployment of J2EE on SNAP. SNAP is a candidate to become an ObjectWeb project. Why P2P? Because workstations are everyday more powerfull, because the EDGE wave is coming. Eg: the Groove P2P collaborative platform has been recently bought by Microsoft. SNAP is about J2EE web application deployment in a worldwide P2P network. SNAP provides: security, persistence, load balancing, transparent failover and recovery. Companies such as Atos Origin expressed interest in SNAP. Massive deployment planned for next year. Wahoo... P2P worldwide application is another pretty cool (and scary?) vision indeed! SNAP is based on FreePastry from Rice University, a Java open-source implementation as P2P substrate. FreePastry manages an organised P2P architecture. DERMI is an RMI implementation based on P2P routing. DERMI offers sync/async invocations, a naming service, persistence, activation, invocation abstractions, basic administration features. SNAP comes with a lightweight component model (P2PCM). It proposes adaptative component activation to adapt to the network loda -- it reminds me of features implemented in ProActive. In SNAP, decentralized web app deployment is possible. Signed apps are distributed. Persistence relies on a replicated file warehouse. The closest instance is activated when a request is processed. SNAP is being tested with node scattered around the world (Pedro shows a worldmap with spots in N. America, Brazil, Europe, Asia). Pedro sees potential synergies between SNAP and Fractal, JOnAS, C-JDBC, ProActive and Jade. Hence the application to become an ObjectWeb project.

This morning session of the Architecture Meeting was a very exciting peek into the future of (open-source) middleware indeed!

Afternoon session:

Francois Exertier, JOnAS' architect, presented the directions and roadmap for JOnAS 5. I sadly missed most of his presentation. JOnAS will be compliant with J2EE 5 / EJB 3. He anticipates the availability of an alpha version by the end of 2005, a final in H1 2005.

Rafael H. Schloming talked of Red Hat goals: certified EJB3 implementation, strong community, maintainability, competitive features. A nasty aspect of EJB3 is that the spec presumes a relational backend. If you write native SQL queries, the implementation would pass the compatibility test suite, yet not being able to run on non relational backends. EJB3 is heavily modeled on Hibernate. Sebastien Chassande remarks that JDO has been around for about 6 years... so the question is who invented what? As for me, I remember of EOF, a framework in the NeXTSTEP world (ObjectiveC) that had, 10 years ago, concepts at least as advanced as those available today in the Java world! A worry is expressed by the audience that Hibernate may become the de facto reference implementation of EJB3. This would be unfair, since Hibernate is licensed under LGPL and basically controlled by one commercial entity. One would rather expect a RI to be hosted by a nonprofit.

Sebastien Chassande-Barrioz presents results of a benchmark that France Telecom R&D ran to assess performances of several OR mapping tools. Before the bench, FT used either pure JBDC, Toplink or Hibernate. Sebastien said it changed after the bench... The goal was to select the preferred persistence tool for development at FT (or at least by some teams). It is worth noticing that CMP 2 is not recommended at FT for complexity reasons. The bench has been run on Versant 3.2 (formely JDO genie), Kodo 3.2. (and other commercial JDO, but Sebastien did not the OK from the vendors to publish results) and Hibernate. Hibernate 2.1 was the only stable version available at this time.

The bench used the ObjectWeb CLIF performance testing framework. The results are pretty clear. JDO products and JDBC perform about the same. When the load increases, the performances of Hibernate drop earlier and much more that other tested solutions. The conclusions of the bench is that JDO should be prefered over Hibernate. An assessment of Speedo and JOnAS CMP2.0 is to be done. A partial benchmark (read access) between JOnAS CMP2, Hibernate, JDBC, Speedo and Versant puts Speedo & CMP2 in pole position, while Hibernate, again, is the worst performer. A remark: since CMP has a very different programmatic model than JDO or Hibernate, the result about JOnAS CMP2 should be considered with caution. The results of these bench have already been presented at the Club Java day on June 13. ObjectWeb proposes to organize a public performance contest ("Plugtest"), jointly with ETSI, in Q2 2006. Competing vendors would be provided the benchmark application ahead of time for fine tuning.