Ok, now my doubt has been cleared out.

Thank you!

2017-10-24 12:09 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:

> Correct.
>
> Regards
> JB
>
> On 10/24/2017 11:19 AM, Massimo Bono wrote:
>
>> 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é <j...@nanthrax.net <mailto:
>> j...@nanthrax.net>>:
>>
>>     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é <j...@nanthrax.net
>>         <mailto:j...@nanthrax.net> <mailto:j...@nanthrax.net <mailto:
>> 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
>>         <https://github.com/apache/cxf-dosgi/tree/master/samples/rest>
>>                  <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>
>>                  <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>
>>                  <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>
>>                         <http://www.liquid-reality.de/
>> display/liquid/2013/02/13/Apache+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é
>>         jbono...@apache.org <mailto:jbono...@apache.org>
>>         <mailto:jbono...@apache.org <mailto:jbono...@apache.org>>
>>         http://blog.nanthrax.net
>>              Talend - http://www.talend.com
>>
>>
>>
>>
>>         --         *Ing. Massimo Bono*
>>
>>
>>     --     Jean-Baptiste Onofré
>>     jbono...@apache.org <mailto:jbono...@apache.org>
>>     http://blog.nanthrax.net
>>     Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>> *Ing. Massimo Bono*
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
*Ing. Massimo Bono*

Reply via email to