aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré>
Subject Re: Proposal to move core of CXF DOSGi to Aries as protocol neutral Remote Service Admin Spec impl
Date Fri, 04 Mar 2016 16:42:37 GMT
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.


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:
> 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.
> The idea is to use an API like this for providers:
> 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é
Talend -

View raw message