In that case the user wouldn't interact with the browser, but with a client
embedded inside the OSGi application itself, correct?

2017-10-24 9:44 GMT+02:00 Jean-Baptiste Onofré <[email protected]>:

> Or a remote instance can "ship" a client interacting with a remote REST
> service exposed from an OSGi service.
>
> Regards
> JB
>
> On 10/24/2017 09:24 AM, Massimo Bono wrote:
>
>> 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é <[email protected] <mailto:
>> [email protected]>>:
>>
>>     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
>>         <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
>>         <http://cxf.apache.org/distributed-osgi-reference.html>;
>>         2) https://github.com/apache/cxf-dosgi
>>         <https://github.com/apache/cxf-dosgi>;
>>         http://www.liquid-reality.de/display/liquid/2013/02/13/Apach
>> e+Karaf+Tutorial+Part+8+-+Distributed+OSGi
>>         <http://www.liquid-reality.de/display/liquid/2013/02/13/Apac
>> he+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é
>>     [email protected] <mailto:[email protected]>
>>     http://blog.nanthrax.net
>>     Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>> *Ing. Massimo Bono*
>>
>
> --
> Jean-Baptiste Onofré
> [email protected]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
*Ing. Massimo Bono*

Reply via email to