Mail Archive Home | architecture List | November 2005 Index
| <-- Date Index --> | <-- Thread Index --> |
At 3:02 -0500 3/11/05, Richard S. Hall wrote:
Jean-Bernard Stefani wrote:Just a small reaction on one bit of creeping misunderstanding. Sorry to pick on you Pierre-Yves, but there is no 'Fractal vs OSGI' issue at OW in my opinion, only people who do not understand the difference between Fractal and OSGI. Also, lying beneath this sort of remark is the implicit statement that the 'insistence' of Fractal in OW is somehow preventing OW projects to use useful technology: This is just not true since no one to my knowledge has ever been forced to use Fractal. And the JOnAS tema is sovereign in deciding where he wants to go. But let's set the record straight once and for all.OSGI is primarily a packaging technology. It only allows you to capture a small part of your software' architecture (via export and import clauses), and to deploy it locally.I agree that the two technologies are not really competitors and this has been the position of LSR since the beginning concerning OSGi and Fractal. But it is possible that some of this "competition confusion" was fostered by certain decisions and approaches taken within our community. For example, the insistence that Fractal should be on the bottom of everything else, even though OSGi's reliance on class loaders clearly puts it pretty close to the bottom (as far as Java is concerned)...we have long described OSGi as a "super" class loader.From my perspective, this belief was particularly evident in the "Fractal deployment" effort from a little while back. I would have thought that the best direction to go would have been to define a standard way to package Fractal components into OSGi bundles, but the pursued direction was not so simple and it was my understanding that this was because of the belief that Fractal should be on the bottom.To be clear, I am not saying one approach is right or wrong, but if we have failed at many opportunities to define the complementary nature of these two technologies.-> richard
Well, my reading of the "Fractal deployment effort" you mention was not in any way a means to prevent having a way to package Fractal structures in OSGI bundles, but an effort to obtain a programming-environment independent specification of loading and local deployment, much as the Fractal specification is programming language independent. For instance, we have developments taking place in Think, which can be viewed as a C implementation of Fractal. In that context, having an OSGI-based loader is not really useful, but still the loading and deployment issue exists. When working in the Java environment, I agree with you that a path of least energy (in particular in terms of mind share) is the one you suggest: using OSGI as a super class loader for Fractal deployment. But that does not apply to other environments.
Concerning the view that Fractal should be 'at the bottom of things', I can only say that that is precisely my belief, and therefore, apart from the tactical agreement with you I mentioned above (it's probably best to employ OSGI when it comes to local deployment issues because of OSGI mind share with Eclipse), we are in disagreement in that respect. I would definitely push to have Fractal at the bottom of things if one wants to build a software infrastructure with maximum flexibilty. Said otherwise, I would say that Fractal is indeed a "super" plug-in architecture, and I would argue that it (Fractal) be used as the basis of componentization in ObjectWeb middleware. As a plug-in architecture it would be in direct competition with OSGI, and there lies the perceived conflict.
But note:1/ the disagreement above is a legitimate one: the implication that there would be a kind of rampant 'Fractal imperialism' which would prevent sensible choices, as certain parts of the discussion seem to imply, is simply something I cannot bear, for nothing is further from the truth. Besides, said 'sensible choices' may not be ones that I, as a Fractal proponent, would deem that sensible architecturally. 2/ If we had failed opportunities, it was more opportunities to debate wide ranging architectural choices within OW, and in particular for the evolution of OW's application server architecture. If the debate had taken place in full, we would have considered eg the implications of having 'Fractal at the bottom' vs other, possibly standards-based, approaches.
Cheers, Jean-Bernard -- ************************************************************* Jean-Bernard STEFANI Research Director, SARDES Project INRIA Rhône-Alpes 655, avenue de l'Europe Montbonnot 38334 St Ismier Cedex France tel : +33 (0)4 76 61 52 57 fax : +33 (0)4 76 61 52 52 email : Jean-Bernard.Stefani@xxxxxxxx *************************************************************
| <-- Date Index --> | <-- Thread Index --> |
Powered by MHonArc.
Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.