It's clear for me too now, I can choose the right solution :) Thanks !
Le 24/10/2017 à 18:47, Jean-Baptiste Onofré a écrit : > You are welcome ;) > > Happy to help. Let me know if you need any more details. > > Regards > JB > > On 10/24/2017 04:17 PM, Massimo Bono wrote: >> Ok, now my doubt has been cleared out. >> >> Thank you! >> >> 2017-10-24 12:09 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net >> <mailto: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> <mailto: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>> >> <mailto: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>> >> >> <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>> >> >> <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>> >> <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/Apache+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/Apache+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/Apache+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/Apache+Karaf+Tutorial+Part+8+-+Distributed+OSGi >> >> <http://www.liquid-reality.de/display/liquid/2013/02/13/Apache+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>> >> <mailto: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> >> <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* >
