Charles, It was the evolution of Spring *outside* the EJB specifications that gave EJB the required impetus to improve. Likewise the existence of other component models outside of Blueprint and DS is useful to allow them to experiment with new ideas and potentially discover new approaches.
In contrast to Spring, iPOJO arises from academic research into component models and has some very interesting and advanced features that cannot be implemented in Spring (but on the other hand it has some practical features which I dislike). Different applications need to make different trade offs and there is no sense forcing early standardisation of a still rapidly evolving area. The risk of multiple approaches is, of course, fragmentation. This is why the interoperability through OSGi services is so great -- we no longer need to choose between Spring or Guice or iPOJO etc and commit ourselves to that model exclusively until the end of time. In fact it becomes a per-bundle implementation detail. Far from fragmenting the space for components, OSGi services unify it. Neil On Thu, Jul 2, 2009 at 12:51 PM, Charles Moulliard<[email protected]> wrote: > Neil, > > Thanks for the clarification. The idea that I promote behind my reply is not > at all to debate which approach is better than the other but instead to make > aware the opensource community that too much frameworks kill our > goals/intents. The merit of EJB specification has been to become a standard > used by all the actors (developer, architect, manufacturer of application > server, ...) even if, from a technical point of view, EJB 1 and 2 have > increased development life cycle. This is why Spring has taken the lead by > promoting an easiest way to design enterprise solutions. > > For the future of the OSGI development based on SOA architecture or Service > Component, we need to have strong/federating standards who will simplify our > way to design/develop enterprise solutions. From my point of view, Blueprint > is one of them and it should be interesting that existing frameworks align > with this specification (like Spring DM will do soon). > > Regards, > > Charles Moulliard > Senior Enterprise Architect > Apache Camel Committer > > ***************************** > blog : http://cmoulliard.blogspot.com > > > On Thu, Jul 2, 2009 at 1:21 PM, Neil Bartlett <[email protected]> wrote: > >> Charles, >> >> Of course iPOJO and Blueprint are compatible! >> >> Services exported by a bundle using iPOJO can be imported by a bundle >> using Blueprint, and vice versa. All of these component models -- >> iPOJO, Blueprint, DS, Spring-DM, Peaberry etc -- interoperate >> perfectly at the level of OSGi services. Of course they are all >> implemented in different ways internally, but there is absolutely no >> need to force every component model to implement Blueprint. >> >> Regards >> Neil >> >> On Thu, Jul 2, 2009 at 12:12 PM, Charles Moulliard<[email protected]> >> wrote: >> > If iPojo and Blueprint are not compatible. What can we do ! >> > This kind of situation is always frustrating for developers/designers and >> > architects because choice must be done between competitors (Spring DM, >> > Blueprint, iPojo, SCA, ...). >> > Our time is precious. This is why having standards in OSG is really >> > important like it is in Java World for J2EE specifications. I'm pretty >> sure >> > that this kind of situation will not help to promote OSGI as alternative >> to >> > classical development done on J2EE application servers like Websphere, >> ... >> > >> > Regards, >> > >> > Charles Moulliard >> > Senior Enterprise Architect >> > Apache Camel Committer >> > >> > ***************************** >> > blog : http://cmoulliard.blogspot.com >> > >> > >> > On Thu, Jul 2, 2009 at 11:59 AM, Guillaume Nodet <[email protected]> >> wrote: >> > >> >> When I first started the blueprint implementation, the idea was to use >> >> iPojo and implement blueprint on top of it. >> >> Unfortunately, iPojo and blueprint have very different ways of solving >> >> the same problems, and it seems quite impossible to easily reconcile >> >> those. >> >> So, I don't think there will be any relationship between iPojo and >> >> blueprint. >> >> >> >> On Thu, Jul 2, 2009 at 11:19, Charles Moulliard<[email protected]> >> >> wrote: >> >> > Hi, >> >> > >> >> > What are the future plans of iPojo regarding to OSGI specification (= >> RFC >> >> > 124 ) called Blueprint ? Will iPojo be migrated to be used as >> blueprint >> >> > services or iPojo will continue to live without integration with >> >> blueprint ? >> >> > >> >> > Regards, >> >> > >> >> > >> >> > Charles Moulliard >> >> > Senior Enterprise Architect >> >> > Apache Camel Committer >> >> > >> >> > ***************************** >> >> > blog : http://cmoulliard.blogspot.com >> >> > >> >> >> >> >> >> >> >> -- >> >> Cheers, >> >> Guillaume Nodet >> >> ------------------------ >> >> Blog: http://gnodet.blogspot.com/ >> >> ------------------------ >> >> Open Source SOA >> >> http://fusesource.com >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
