Hi Tim,
On 21.03.2016 09:48, 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.
The OSGi community is more than the OSGi alliance. For example we at
Talend are also part of the OSGi community but as we unfortunately do
not get backing for an alliance membership none of our efforts will go
into a RFC. On the other hand I agree with you that DS gains more
traction at the moment. Guillaumes effort on the spring namespace
support for blueprint is a great development
on the blueprint side but there are not many other such examples.
- 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.
I would like to see a lot more of these other implementations.
Unfortunately there is not much information on how to use them
especially on apache karaf. I think a major enabler is to find the
bundles on maven central. Another big part is the documentation and of
course the license.
So from the license side the Amdatu implementation would be interesting.
Maybe someone can do a tutorial for it?
Not sure about the others. Are they are all closed source?
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.
Yes. The way to specify this is configuration or more specific service
properties and additional properties. What I am refering to is that I
introduced an extension interface in Aries RSA that allows
to customize what the TopologyManager adds in form of additional
properties. See
https://github.com/apache/aries-rsa/blob/master/spi/src/main/java/org/apache/aries/rsa/spi/ExportPolicy.java
Probably other Remote Service Admin impls have similar ways to do this.
The other part of the solution of course is to then apply these
configurations in the provider for the RemoteServiceAdmin. CXF is just
an example here of course but it is the most widely used JAXWS and JAXRS
impl today and people do quite some fancy configs in blueprint today. So
to replicate this we have to make sure we can do the same using Remote
Service Admin. CXF DOSGi supports intents implemented by Features but I
think no one has tried to implement some of the more advanced security
setups with this.
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.
That is also what I thought when starting the migration :-)
Unfortunately the codebase I had to deal with was not modular at all.
They simply used annotations to declare and consume beans all over the
application in a tightly coupled fashion. Most of these beans did not
even have an interface.
It was not possible for me to split this into modules that offer and
consume services without doing a big refactoring. At the start I tried
to propose some refactorings but they were rejected by the team
responsible to ship the business features as they feared that any
instability or delay would possibly cancel the whole project.
So what I did was to replicate the beans they used using blueprint beans
out of annotations and define blueprint contexts that also contained
some beans of dependency bundles. This was of course not a nice OSGi
like module system but it was able to reflect the actual code base.
Then after the initial OSGi migration was done and the production system
was on OSGi they peace by peace now do the modularization to nice OSGi
bundles with services but this effort is still not finished.
So yes .. you can do the OSGi migration in a bundle by bundle fashion if
the code base is well designed but I would not bet on this being the
case in any spring project.
Best regards
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
