Re: REST - Declarative Services

[Scott Lewis <sl...@composent.com>]

On 5/30/2018 2:17 AM, Tim Ward wrote:
> Almost certainly the simplest option has already been suggested. The 
> OSGi JAX-RS whiteboard provides a simple, standard mechanism for 
> registering JAX-RS applications, resources, and extensions using the 
> OSGi service registry. The Aries JAX-RS whiteboard is the Reference 
> Implementation of this spec, and is in the process of being released 
> (it should be available within the next three weeks). Using the JAX-RS 
> whiteboard gives you more control over your resources, gives you 
> access to more of the JAX-RS specification, and is more portable than 
> using RSA.

It's debatable to say that the JAX-RS whiteboard spec is more portable 
than using RSA.   Portability can mean multiple things...e.g. across 
impls (e.g. CXF or Jersey), or service contracts across transports (http 
vs. mqtt).   Further, RSA does have things that JAXRS currently 
lacks...e.g. proxys, mgmt agent, topology mgr, discovery/edef.

But I don't wish to debate.   I'll just point to an example running on 
Karaf that uses Jersey, CXF, JAX-RS, OSGi R7 RSA: 
https://wiki.eclipse.org/Tutorial:_JaxRS_Remote_Services_on_Karaf

Scott

>
> There’s a simple set of tutorials using the R7 specifications provided 
> by OSGi enRoute:
>
> https://enroute.osgi.org/Tutorial/
>
> The quickstart application should provide you with everything you need.
>
> Best Regards,
>
> Tim
>
>> On 29 May 2018, at 17:03, Scott Lewis <slewis@composent.com 
>> <ma...@composent.com>> wrote:
>>
>> On 5/28/2018 10:40 AM, Guenther Schmidt wrote:
>>> Hello All,
>>>
>>> I’ve been developing services using Declarative Services for 
>>> dependency injection and it was a breeze so far. Now I want to 
>>> expose some of the functionality via a REST API and I’m stuck. So 
>>> far I’ve deployed my bundles through bundle:install -s man: …. all 
>>> very easy. But what should be simple, exposing this through REST is 
>>> becoming difficult. There are tips out there suggesting to use 
>>> Blueprint, which I don’t want, others seem to suggest that I need to 
>>> create a “feature” package.
>>>
>>> Then there’s also the requirements to “feature” install cxf. That’s 
>>> OK btw, I only have to do that once. But is there really no simple 
>>> way to create a simple REST service using merely DS?
>>>
>>> Guenther
>>>
>>>
>> Hi Guenther,
>>
>> Another option would be ECF Remote Services [1]. It's a full 
>> implementation of the OSGi Remote Services and Remote Service Admin 
>> (R7/latest) specifications [2].   These specifications standardize 
>> the remoting of OSGi services (meta-data and dynamics), so it works 
>> seemlessly with DS and other frameworks that use the OSGi service 
>> registry.
>>
>> ECF has a provider architecture so allows the use of a variety of 
>> distribution providers [3], including CXF [4].
>>
>> We have features defined for Karaf [5] and we also now have support 
>> for bndtools-based development [6] (workspace and project templates).
>>
>> Caveat:   ECF is in the middle of 'release season' for the Eclipse 
>> simultaneous release (late June), so the transition to ECF 3.14.0 is 
>> not yet complete.  For example, the Karaf features don't yet point to 
>> 3.14.0 at maven central only because we have to wait for the SR  
>> process before deployment of the release to maven central.   However, 
>> I'm happy to provide needed support via [7].
>>
>> Scott
>>
>> [1] https://wiki.eclipse.org/Eclipse_Communication_Framework_Project
>>
>> [2] 
>> https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.html
>>
>> [3] https://wiki.eclipse.org/Distribution_Providers
>>
>> [4] https://github.com/ECF/JaxRSProviders
>>
>> [5] https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf
>>
>> [6] 
>> https://wiki.eclipse.org/Bndtools_Support_for_Remote_Services_Development
>>
>> [7] https://accounts.eclipse.org/mailing-list/ecf-dev
>>
>> [8] http://eclipseecf.blogspot.com/
>>
>