Hi Tim,
FYI, Guillaume was involved in the Blueprint specification (and he's
OSGi Alliance member via RedHat if I remember well).
Regards
JB
On 03/21/2016 09:48 AM, Timothy Ward wrote:
Hi Christian,
On 21 Mar 2016, at 08:27, Christian Schneider <[email protected]
<mailto:[email protected]>> 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, and questions on the OSGi
mailing lists get pretty comprehensive answers
(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)
- 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
<http://nabble.com>.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
