Proposal to move core of CXF DOSGi to Aries as protocol neutral Remote Service Admin Spec impl

[Christian Schneider <ch...@die-schneider.net>]

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:
https://github.com/apache/cxf-dosgi/blob/master/dsw/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/api/DistributionProvider.java

So a provider needs to be able to expose a service to the outside world 
and create a local proxy for a remote service.
The main advantage of such an API compared to the RemoteServiceAdmin 
interface is that it is stateless. The provider just needs to create the 
endpoints and clients/proxies. It does not have to manage them. So it 
should be a lot easier to write new transports for the Remote Service 
Admin spec.

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.

I have also started to discuss with Scott Lewis(Eclipse ECF) and Peter 
Kriens. They are quite positive about the API.
Ideally it could be supported by Aries and ECF 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

Re: Proposal to move core of CXF DOSGi to Aries as protocol neutral Remote Service Admin Spec impl

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Christian,

+1 for that.

In that case, I would like something with API/Interface where I could 
donate/merge what I did in Cellar DOSGi. Then, I will remove the code 
from Cellar to use a feature from Aries.

Regards
JB

On 03/04/2016 05:16 PM, Christian Schneider wrote:
> 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:
> https://github.com/apache/cxf-dosgi/blob/master/dsw/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/api/DistributionProvider.java
>
>
> So a provider needs to be able to expose a service to the outside world
> and create a local proxy for a remote service.
> The main advantage of such an API compared to the RemoteServiceAdmin
> interface is that it is stateless. The provider just needs to create the
> endpoints and clients/proxies. It does not have to manage them. So it
> should be a lot easier to write new transports for the Remote Service
> Admin spec.
>
> 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.
>
> I have also started to discuss with Scott Lewis(Eclipse ECF) and Peter
> Kriens. They are quite positive about the API.
> Ideally it could be supported by Aries and ECF 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
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com