RE: [architecture] Re: Two JBI implementations in ObjectWeb - open discussion

[Gaël Blondelle - EBM WebSourcing <gael.blondelle@xxxxxxxxxxxxxxxxxx>]

Hi all,

That's our turn to tell you the Petals history, status and proposal for
synergies.

1) A little bit of history and facts,

Petals was submitted jointly by FossilEC and EBM WebSourcing in the
framework of the ESBi on July 2005 with the following objectives:
        - build a distributed JBI container
        - leverage ObjectWeb architecture (Fractal) and projects

During the summer, we, at EBM WebSourcing, uploaded the first Petals code
base (namely petals-0.2 on the forge) which implements a distributed NMR
(the messaging part in JBI), the component LifeCycle, but lacks Component
installation and deployment and was not based on Fractal component model.
When Rafael from FossilEC started effectively to work on the project, he
started working on these holes in the implementation but he decided to
recode from scratch, while moving from our simple ant building system to
maven 1, and to put all our code in a frozen part of the repository. 

During the last months of 2005, at the time when Rafael started to work on
the project, we were incited by OW instances to study some synergies with
other JBI providers. Unfortunately, these discussions failed, and during
this time, we made the error of not making our dev advance a lot. But since
January, we have several full time developers working on Petals (raising up
to 5 people this month), and this kind of "stop and wait" situation will not
occur anymore. 

Since late January, Rafael informed us that he had to leave the project
without proposing any way of collaboration at this time. 

2) The status

Petals is alive, and the Petals community becomes larger.
Since January, as leader of the project, we work hard on the code base to
produce a significant milestone that will go out next week. Project roadmap
until the end of the year will go online at the same time.
People from Jones project have selected Petals as the focal point for their
contributions in term of architecture and packaging (downloadable packages
including the Binding Components and Service Engines produces by the
project) and use cases.

3) Synergy opportunities

We welcome any contributions, and especially from people who already know
JBI and want to work on it.
Those contributions must respect some elements:
        - Petals architecture is Fractal, and this fractalization is going
deeper in the code, according to the ObjectWeb architecture model, period.
        - Petals licence is LGPL as recommanded by ObjectWeb.
        - Petals is moving to Maven 2 as other OW projects did, but it has
to be done in continuity with the current code base.
        - Petals project must provide standard based, monitoring and
management tools, and that's certainly the point in which eXo contribution
can be the greatest.

Best regards,
Gaël Blondelle.

> -----Message d'origine-----
> De : Benjamin Mestrallet [mailto:benjamin.mestrallet@xxxxxxxxxxxxxxx]
> Envoyé : lundi 10 avril 2006 18:03
> À : Francois Letellier
> Cc : architecture@xxxxxxxxxxxxx; esb@xxxxxxxxxxxxx; jean-
> pierre.laisne@xxxxxxxxxxxxx; College Objectweb
> Objet : [architecture] Re: Two JBI implementations in ObjectWeb - open
> discussion
> 
> Hi
> 
> So let me summarize the current status and the suggestion I would
> have to find synergies between the JBI.
> 
> eXo Platform has grown from a portal framework to an Application
> Platform Suite (APS) including Enterprise Portal Solution (EPS) and
> Enterprise Content Management (ECM) one. In each case implementing
> the default JCR standards (JSR 168, 170), each time with quite some
> success.
> 
> In both cases we mainly focus on the integration of all those
> products to build a comprehensive stack but also allowing them to run
> independently. We mainly focus on providing portlet monitoring tools
> thanks to a native integration of the - in JVM - eXo service/
> component stack.
> 
> We are also adding some layers of the APS by integration with other
> OW projects like SpagoBI (for portal monitoring and then BAM) and
> XWiki. Tools like Lomboz are also now natively supporting eXo
> portlets deployment which strengthen the ObjectWeb ecosystem.
> 
> In january 2006, eXo decided to complete that stack by providing a
> JBI container based on our eXo in JVM component stack to dynamically
> monitor (and manage) JBI components in our JMX portlet, to leverage
> the existing services like caching or security one and to finally use
> the advanced building mechanism we built on top of Maven2.
> 
> Therefore, we purchased the Brazilian company FossilEC which was, at
> that time, the only contributor - in term of code - to PETALS
> project. Our goal was to accelerate the implementation of a JBI
> container in ObjectWeb to avoid to see other OW projects and members
> forced to use JBI implementations like ServiceMix. We also convinced
> some partners to at least test their JBI components on our
> implementation too.
> 
> Last Thursday, we have released our first JBI implementation (wrongly
> marketed as an ESB in the announcement...sorry for that) which
> created some FUD and noise here and there and mainly in the college
> mailing list. It is not the first time there exist 2 projects with
> some overlaps in OW, it is the case with Bonita and Shark as well as
> Byline and eXo that were even accepted at the same time!
> 
> Now while the code contributed to PETALS were mainly FossilEC one,
> the other contributor just got resources to accelerate its
> contribution and tries to fill the missing holes that we would also
> need.
> 
> So here is my suggestion to try to find new synergies:
> 
> - eXo backport its enhancements to PETALS code which means that the
> exo-platform in JVM service container is used as the basis for the
> new JBI works (note that the code of the core platform of eXo is
> licensed as LGP which would not break the current licensing of petals).
> - eXo replaces FossilEC as co lead of PETALS with Rafael Marins as
> project admin
> - eXo will provide its APS-EAI layer based on PETALS and code like
> monitoring/managing portlets will remain in eXo SVN
> - eXo continues to push OW members/projects to use in priority or at
> least test on the OW JBI container
> 
> We would like this issue to be resolved quickly as I have not asked
> my team to stop the developments during what we can call a
> "negotiation" :), hence the more we wait the more the merge will be
> complex.
> 
> Hope you will all find that proposal reasonable
> 
> Cheers
> 
> Benjamin Mestrallet