Yes .. this is correct. Actually exporting and importing or services is
completely decoupled in Remote Service Admin.

When you offer a suitable OSGi service it will be exported as a REST
service. The properties of the service are then also sent to the Discovery
implementation. If you just want to export the service then
you simply do not use that discovery information.

On the client side the Discovery information can be used to create a proxy
that is offered as an OSGi service and that forms a REST client. Again this
is completely decoupled from your REST service.

You can even feed the Discovery information into the system if there is no
DOSGi REST service on the other side. This can be used to create a CXF
DOSGi proxy to a service that is outside of OSGi.

Christian

2017-10-24 9:24 GMT+02:00 Massimo Bono <massimobo...@gmail.com>:

> So, it's like saying:
>
> We know DOSGI implements RPC with REST-ful services, so we exploit that in
> order to create some rest webservices. Then, instead of query them from
> another OSGi container, we directly query them from the browser.
>
> Is my understanding correct?
>
> 2017-10-24 6:29 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
>
>> Hi,
>>
>> CXF DOSGi implementation is based on CXF and exposes OSGi services as
>> REST service.
>>
>> That's an approach for DOSGi, but it's not the only one.
>>
>> In Cellar, you have another DOSGi implementation based on NIO/Hazelcast.
>> Another one is Eclipse RemoteService.
>>
>> Each has pros/cons.
>>
>> Anyway, the purpose of DOSGi is to provide remote service invocation. So,
>> a service is exposed on a node and used remotely on another one. It should
>> be transparent for your code (the only minor change is that the service
>> that has to be exposed for remote call should contain
>> exported.service.interface property).
>>
>> Regards
>> JB
>>
>> On 10/23/2017 10:13 PM, Massimo Bono wrote:
>>
>>> Hello,
>>>
>>> I'm trying to grasp my mind on DOSGi; I want to have a general idea on
>>> the main concepts before start coding.
>>>
>>> A while ago I tried (with success) to replicate the awesome tutorial
>>> Christian provided (available https://github.com/apache/cxf-
>>> dosgi/tree/master/samples/rest).
>>>
>>> Now, before continuing coding, I want to understand why DOSGi is useful
>>> in my use case.
>>>
>>> Briefly, I want to code with Declarative Services with Karaf because i
>>> feel it's a more OSGi oriented way to define and bind services.
>>> Furthermore, I want my OSGi framework to recreate a web page the user
>>> can interact with: CXF can easily be deployed in Karaf, so I felt like it
>>> was a good choice over the other alternatives (like jetty). I used RESTful
>>> services as well, just to have something well structured.
>>> In a previous question, Christian suggested me to use DOSGi to fullly
>>> implement this scenario.
>>> After the successful attempt, I read the following resources on the
>>> topic.
>>>
>>> 1) http://cxf.apache.org/distributed-osgi-reference.html;
>>> 2) https://github.com/apache/cxf-dosgi;
>>> http://www.liquid-reality.de/display/liquid/2013/02/13/Apach
>>> e+Karaf+Tutorial+Part+8+-+Distributed+OSGi;
>>>
>>> Especially from the last one: It seems that DOSGi is used to let an OSGi
>>> framework B access to services located on a OSGi framework A. This is all
>>> good and dandy but in my scenario (Karaf + CXF exposing a REST service)
>>> where are the 2 OSGI containers? I can see only one, namely the one on my
>>> laptop in localhost!
>>>
>>> I'm sure I'm missing something, probably for my inexperience.
>>> Can someone solves this question of mine?
>>>
>>> Thanks!
>>>
>>> --
>>> *Ing. Massimo Bono*
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> *Ing. Massimo Bono*
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>

Computer Scientist
http://www.adobe.com

Reply via email to