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/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>>
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
