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

[Benjamin Mestrallet <benjamin.mestrallet@xxxxxxx>]

Hi all

After listening to the people opinions and position of ObjectWeb  
college and board, we have decided not to continue our efforts to  
implement a JBI container and to focus our activity in the JBI/ESB  
monitoring space thanks to portal advanced functionalities to  
leverage both our Portal and JBI expertise.

We will now develop only portlets in our exo-esb/ module in exo SVN  
source code and will leverage existing JBI containers as well as ESB.  
We will test those on several implementations like Petals and  
ServiceMix. We will continue the development of those portlet based  
on our current JBI container implementation until we have reached the  
limit of it from a monitoring perspective. We will then move to  
another implementation hoping that at that time Petals will be ready.

Kind regards

Benjamin Mestrallet


On Apr 12, 2006, at 4:50 PM, Gaël Blondelle - EBM WebSourcing wrote:

> 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
>
>
>
>
>
> --
> You receive this message as a subscriber of the  
> college@xxxxxxxxxxxxx mailing list.
> To unsubscribe: mailto:college-unsubscribe@xxxxxxxxxxxxx
> For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/ 
> wws