Hi Christian,
> On 21 Mar 2016, at 08:27, Christian Schneider <ch...@die-schneider.net> wrote: > > Indeed it is difficult to predict where the OSGi community will go in the > future. I’m not sure that I agree with this. OSGi RFPs and RFCs are publicly available at https://github.com/osgi/design <https://github.com/osgi/design>, and questions on the OSGi mailing lists get pretty comprehensive answers (https://www.osgi.org/community/mail-lists/ <https://www.osgi.org/community/mail-lists/>). In this specific case, there are no OSGi members driving the Blueprint RFCs (RFCs 155, 156, 164 and 166) which is why they have had no activity since 2011 or so. > > For DS the situation is hopefully a little better today than at the time I > did the comparison. > - JPA can be solved today by using the Aries JPA and JPATemplate but it is > not standardized. The upcoming spec hopefully will improve this. Specifically RFC 221 (https://github.com/osgi/design/tree/master/rfcs/rfc0221 <https://github.com/osgi/design/tree/master/rfcs/rfc0221>) > - Services and Remoting can be solved by Remote Service Admin. With ECF and > Aries rsa (CXF-DOSGi) there are now two stacks available on karaf that can > help with this. There are also a lot of other RSA implementations which can be deployed in any OSGi framework. > Still it can be a little rough if you want to use some special CXF features. > We will have to prove using some good examples / pocs that Remote Services > can fully replace the blueprint CXF namespaces. > > Btw. I have some plans for Aries RSA to support application wide policies. > The idea is to define some common aspects of your services centrally and > apply them to all exported OSGi services. So for example you could define in > one central point that all your services with JAXRS annotations should be > auto exported and have single sign on authentication using STS, SSL > encryption and logging. This is configuration for the RSA distribution provider and should be possible to define at a central point for any RSA implementation, not just when using Karaf’s preferred CXF provider. > > The migration though is still a big issue. > > Some time ago I did the migration of a medium sized production system from > servlet container + spring to karaf + blueprint. The big problem there was > that we had to do the transition > while the main team was going full steam and doing releases. It was the > start of the blueprint-maven-plugin as this was the only way to do migration > without a big bang. So if you > have to do this then the annotation based approach + the plugin above can > help a lot. If someone wants to try this I can help with some good advices. > If there is some interest I can also blog about > how to do such a transition in practice. > > A migration to DS will pretty much be a big bang as it is too different from > spring to do a smooth transition. I think it is possible to do a full > business application in DS but the migration step is bigger. This is also incorrect - OSGi is a modular environment, and the whole point is that modules can be changed individually. Both DS and Blueprint communicate between bundles using OSGi services so there is no problem at all with having one bundle using DS while the other uses Blueprint. The migration from blueprint to DS can occur one bundle at a time, and does not have to be a big bang across the whole codebase. Regards, Tim > > Christian > > On 21.03.2016 02:24, Tim Jones wrote: >> Andreas you are crossing or about to cross a bridge we are crossing at the >> moment. We also have a SpringDM based application. It is 3+ years in >> production and so a change as large as moving away from SpringDM is very >> disruptive. For the most part we considered only Aries Blueprint vs DS. >> However as you can see from this post there are other alternatives, some >> fairly recent such as support for Spring namespaces in Aries Blueprint. >> >> For us the most significant points to consider were >> >> 1) Will there still be good support in 5-10 years (having been burnt once we >> don't want face the same issue again) >> >> 2) Where is the general OSGi community heading? Blueprint/DS/other. The >> first sentence of Tim Ward's post is something we thought significant. >> Something that has concerned me over the last couple of years is sometimes >> an alternative is suggested by needs some jiggery pokery to make it work, it >> doesn't have wide support, little documentation, often has bugs which led to >> a churn of releases. While it may be a cool, clever solution we aren't going >> to bet our production system on cool and clever only. >> >> 3) We are by and large glue coders and don't have the ability nor want to >> spend the time/resource building our own custom solutions, this is where I >> think Spring has suited us well until now. We tried to identify what >> offerings were available for the bits we needed e.g. JPA, JDBC, >> transactional control, Camel JMS, CXF. It is an opinion only, but from what >> I could see Blueprint offered the broadest support (see Christian's >> ecosystems-compared >> http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider). >> >> The big one for us was lack of JPA/JDBC/transactional control for DS, while >> there were some solutions we wanted something with a 'spec behind it'. This >> is currently been worked on at the moment >> (https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a >> significant piece of work that will make DS a much more attractive >> proposition in the enterprise/applications space. Admittedly there is a risk >> in being new adopter however we think the risk is worth it in this case. >> Camel has a recent DS offering camel-scr (although I think there are some >> issues with it). Hopefully in time more libraries will offer DS support out >> of the box. >> >> 4) We are not yet sure we will be able to fully realise the pros of the >> service dynamics that DS offers vs Blueprint as although one of our goals is >> to be able to 'hot swap' bundles into a running system this may be harder to >> achieve than we had hoped. We currently do some limited hot swapping with >> our SpringDM system. >> >> 5) Perhaps counter intuitively of less importance to us was the actual ease >> of transition, Blueprint would almost certainly be easier to migrate to from >> SpringDM but we think that this is a one off cost that will be outweighed in >> the long term. >> >> Tim >> >> >> >> >> >> -- >> View this message in context: >> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html >> Sent from the Karaf - User mailing list archive at Nabble.com. > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
