Hi Richard,
we already had discussion with the OSGi Alliance. Christian and I asked
if it would be possible to work on specifications "outside" of our
company first, as OpenSource guys. It seems very difficult, so now, we
are discussing internally with our company.
Regards
JB
On 03/21/2016 09:53 AM, Richard Nicholson wrote:
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.
No great mystery, no crystal ball need and easily addressable.
Companies making profit out of the Karaf community (selling services wrapped
around it, or training based upon it), also companies using Karaf based
solutions in their production systems and worried about longevity, should both
join the OSGi Alliance.
Get involved, commit resources to drive forwards specifications that you want
to see. That is how the Alliance operates. DS has moved forwards precisely
because OSGi Alliance members have put the effort in to do this.
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.
- 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.
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.
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.
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
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
