You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2016/02/29 11:45:01 UTC

[Discuss] Provider API for DOSGi and move core of CXF-DOSGi to Aries

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

Re: [Discuss] Provider API for DOSGi and move core of CXF-DOSGi to Aries

Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Sergey,

just saw that my paste was incomplete.
The createServer method already contains a map and the createProxy 
method contains the EndpointDescription which also has a map inside.
So I think we should already be able to push additional data through the 
Maps.
Sorry for the error.

Btw. One thing I hope to be able to remove is the dswContext. I think it 
should be internal to the provider.

Christian

https://github.com/apache/cxf-dosgi/blob/master/dsw/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/api/ConfigurationTypeHandler.java

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,
EndpointDescription endpoint) throws IntentUnsatisfiedException;
}

EndpointDescription endpoint) throws IntentUnsatisfiedException;

On 29.02.2016 12:01, Sergey Beryozkin wrote:
> Hi Christian
>
> I think it is a good idea to make some of CXF-DSW code re-usable.
> It may help to give more 'energy' to CXF DOSGI itself (as well to 
> DOSGi in general), and also indeed make for yet another connection 
> between CXF and Aries.
>
> As far as ConfigurationTypeHandler is concerned, what happens if in 
> some future one extra parameter needs to be passed along. If it were 
> in CXF DSW then it would be only a quick internal update. Might be 
> worth adding an extra parameter such as Map<String, Object>, so that 
> the extra objects can be passed if needed without breaking the 
> implementations. May be that interface will never change :-) or may be 
> a better idea can be realized...
>
> Cheers, Sergey

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [Discuss] Provider API for DOSGi and move core of CXF-DOSGi to Aries

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Christian

I think it is a good idea to make some of CXF-DSW code re-usable.
It may help to give more 'energy' to CXF DOSGI itself (as well to DOSGi 
in general), and also indeed make for yet another connection between CXF 
and Aries.

As far as ConfigurationTypeHandler is concerned, what happens if in some 
future one extra parameter needs to be passed along. If it were in CXF 
DSW then it would be only a quick internal update. Might be worth adding 
an extra parameter such as Map<String, Object>, so that the extra 
objects can be passed if needed without breaking the implementations. 
May be that interface will never change :-) or may be a better idea can 
be realized...

Cheers, Sergey
On 29/02/16 10:45, 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:
>
> 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
>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/