Sascha Vogt and Johannes Utzig started a discussion on karaf dev to find
a way to implement a light weight DOSGi implemention (using RMI).
See:
http://karaf.922171.n3.nabble.com/Proposal-Lightweight-standalone-remote-OSGi-implementation-for-karaf-cellar-td4045343.html
After looking into the possible places to put this we found that the
CXF-DOSGi code might provide a good starting point for it. As the code
is coupled to CXF it needs some work of course.
The discovery and topology manager parts are already nicely separated
from CXF. Only the dsw-cxf module is tightly coupled to CXF.
Unfortunately this part contains a big part of the
remote services reference impl. So the idea is to split this module in
the impl of RemoteServiceAdmin and into one or more modules for the CXF
providers (WSDL, pojo, rest).
I already started this to make sure it is possible. In the current
master I refactored the code inside the module to decouple CXF and the
spec parts.
These packages implement the RemoteServiceAdmin spec part while the
other packages implement the CXF providers.
https://github.com/apache/cxf-dosgi/tree/master/dsw/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/api
https://github.com/apache/cxf-dosgi/tree/master/dsw/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/service
The idea is to use an API like this for providers:
public interface ConfigurationTypeHandler {
ExportResult createServer(ServiceReference<?> serviceReference,
BundleContext dswContext,
BundleContext callingContext,
Map<String, Object> sd,
Class<?> iClass,
Object serviceBean);
Object createProxy(ServiceReference<?> serviceReference,
BundleContext dswContext,
BundleContext callingContext,
Class<?> iClass,
}
So a provide needs to be able to expose a service to the outside world
and create a local proxy for a remote service. An API like this will
make it a lot easier to write additional transports /serializations that
are not related to CXF. Providers would then provide a OSGi service of
the above interface and be responsible for one remote service
configuration type each.
So one point of discussion is if we want to create such an API for the
public and how it should look like.
The other point is that the CXF independent parts then would not have
any dependency on CXF. So I think they would be better placed in Aries
as they implement an OSGi spec.
The CXF implementations for Soap and Rest providers would of course stay
in CXF but might then be moved into the CXF main project to follow the
changes and releases in CXF more closely.
We should also discuss with Eclipse ECF if the API above (or similar)
could be supported by both so providers could run in both
implementations. Johannes even proposed that such an API could be part
of a future remote services spec.
What do you think?
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
