Thanks for your response Peter. I really appreciate it. I follow your logic above, it makes complete sense.
However, I'd like to argue that this process has a limit of scale. Take for instance the Websphere migration to OSGi (I'm extrapolating from Graham Charters talk at Eclipse/OSGiCon). I don't think it could ever have included the PojoSR step. Nor could it have succeeded, I believe, without an early access to the real OSGi framework (in order for the engineers to learn and immediately benefit from it). If I'm wrong, I'm hoping he'll correct me. My point is that I'm not really convinced (excluding the services first step of course) that migrating a truly complex application can suffer the process above. In our case, taking that approach would literally mean years for us to get to OSGi. We'd be mired in the gap between services first (which in our case we luckily already have) and an actual set of bundles running in osgi for an eternity and I'm sure misery would quickly set in among our team members. I think our project fits more with the Websphere case than with any project that could conceivably be re-architected in more or less a single development cycle. We have several criteria: 1) we have to retain backward compatibility for our own plugin APIs and lifecycle (which uses the host app server's webapp support) 2) we can't repackage our app as a pure OSGi runtime with a set of bundles (it's a web app, and has to run in app servers) without losing significant extensibility feature set we currently support. 3) "super bundle" approach is out of the question (it would break literally thousands of features) 4) we can't assume an osgi runtime exists outside one we bootstrap ourselves (we run in websphere, weblogic - jetty, tomcat (everything in between) 5) it will likely take 4-5 years to fully migrate our application to OSGi 5.1) we cannot have dual development streams supporting both the legacy and the new architecture 5.2) we must release new versions of our product in that time I have spoken to many of the esteemed OSGi experts who came to OSGiCon, however I have sensed trepidation when discussing our situation and approach. Perhaps few have considered the position such as the one we're in (except again Websphere) because of the types of recommendations I have been given (except by the odd few). I'm hoping for some measure of validation that taking the approach of starting with an embedded framework container with the goal of evolving our application in small bits gradually over time is not a completely bone-headed plan. In fact, I've started a small project, which I am hoping to leverage, which will allow parts of our application which are spring based (but outside osgi) to leverage OSGi services without actually being aware that they are doing so (akin to PojoSR, except backed by a real OSGi framework). I'm currently also considering taking a similar approach for other "component"-like frameworks in order to allow those to consume OSGi services without actually being aware of it, like struts. The project is called Arkadiko (https://github.com/rotty3000/arkadiko/blob/master/README.md)<https://github.com/rotty3000/arkadiko/blob/master/README.md>and it actually talks about the above concerns. It's a work in progress. I'd be quite pleased if the experts here could comment more on our approach. Sincerely, - Ray On Mon, Apr 1, 2013 at 4:48 AM, Peter Kriens <[email protected]> wrote: > A very good way to get started with OSGi is services first. Start with > PojoSR and then move your code to services. Since PojoSR == OSGi - > classloader isolation it will not break your code and is completely > unintrusive. Once you're there, you can test the app, move something to a > bundle with services, test, repeat ad. hopefully not infinitum. Notice that > bundles work, DS works, Config Admin works, etc. Limits are no class loader > isolation, so no dynamic install/uninstall/update and side by side > versioning. Start/stop, resource loading, etc. all work. > > Once the application is broken in bundles that way you can try to run it > with isolation. Since you do not need class loader hacks for the > intermodule communication (services fulfill that role) remaining problems > should be manageable. > > That said, the greatest problem is that there are too few enterprise > libraries that are really modular, uncoupled, and highly cohesive. Many > popular libraries drag in the kitchen sink. > > Kind regards, > > Peter Kriens > > > > On 29 mrt. 2013, at 16:56, Raymond Auge wrote: > > [This was going to be a response to the DS vs Blueprint thread.. but got > too long] > > Re: DS vs Blueprint? > > What about complex concerns like providing aop on thousands of services? > > Speaking to David Bosschaert briefly about this at osgi con, he suggested > two options, service interception (via service listener I believe) and/or > asm/weaving/etc (David correct me if I'm wrong here). > > Which of DS or Blueprint lends itself better with these concerns? > > It would seem to me that DS lends itself better when development is on > "new" components while Blueprint seems more "integrate-able" with already > established, non-osgi, components. > > This brings me to my main topic and a comment I have after all the > fantastic talks from the convention is that the vast majority of > application of osgi (except of course for Graham's talk exploring the > history of Websphere's evolution to osgi) seems focused on new development. > Meanwhile it's evident that a key osgi value for many ( again demonstrated > by both the websphere and eclipse cases) is in taking a complex system and > migrating it to a modular architecture and osgi. > > I think this is where a lot of developers hit a wall. We can't just start > from scratch. Secondly, by nature of having arrived at the osgi > "conclusion", the issue was quite obviously that complexity already existed. > > At the OSGi BoF, it was asked "what could the osgi community do to help > make it easier for new developers". > > It would be extremely valuable to have several demonstrations of taking > some non-osgi application containing at least some degree of complexity and > transforming that to an osgi-ified one with insight into the decisions and > best practices. > > i.e. o(sgi)petstore is fine and dandy, there are plenty of those (Tim Ward > demonstrated ~120) but what I really would benefit from is a jpetstore -> > opetstore migration. > > In an effort to make some of that experience available to the general > public, David also suggested that it would be great for Liferay to publish > it's experience, and so I think I may do just that. The caveat being of > course that as "new" osgi-ers we will likely show that we made some wrong > decisions. However, I feel emboldened by Graham's admittance of IBM having > made mistakes along the road. If IBM can do that, surely we can do that too. > > It was a great pleasure meeting many of you. > > Sincerely, > Ray > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> --- 24-25 October 2012 |* Liferay **Spain Symposium* | liferay.com/spain2012<http://www.liferay.com/spain2012> 16 November 2012 |* Liferay **Italy Symposium* | liferay.com/italy2012<http://www.liferay.com/italy2012>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
