You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Willem jiang <wi...@gmail.com> on 2012/10/11 15:03:44 UTC

Re: OSGI service dynamic discovery using zookeeper

It is easy to let the zookeeper know when you publish the service.
But you client need more work to know the real service address by looking up the address from the zookeeper.

CXF client has the failover feature[1] could help you do this kind of work, you just need to configure the endpoint address which you want to use.
With the fabric-cxf[2] component you can do the same thing by leverage the zookeeper which just implement the feature you need.

[1]http://cxf.apache.org/docs/featureslist.html
[2]http://fuse.fusesource.org/fabric/docs/user-guide.html#CXF_Fabric
-- 
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
          http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang





On Thursday, October 11, 2012 at 11:09 AM, Roger wrote:

> Hi everyone,
> 
> Recently, I have just started exploring on the OSGI service dynamic
> discovery using the zookeeper.
> 
> Background info
> ------------------
> I am using the eclipse osgi jars to start the bundles.
> I followed the instruction from the apache website to configure the
> zookeeper.
> Currently, I am able to publish my OSGI services to the zookeeper/osgi
> folder & also able to connect to the zookeeper using the client & retrieve
> the published service information. When I published a new service, the
> service will be reflected in the zookeeper.
> 
> Testing environment
> ----------------------
> I have two machines.
> I am running the same greeter service in two separate machines
> (connected in the same network).
> At the same time, I am running the greeter client program in one of the
> machines.
> I have also published both the services in the zookeeper (after placing
> the zookeeper.cfg in the load folder).
> 
> Verify my concept
> --------------------
> I am thinking if I stop the service which runs in the same machine as
> the greeter client program, the greeter client should be able to track the
> other remote service running in the other machine (Is my concept right?). 
> However, when I stop the service (which runs in the same machine as the
> greeter client program), the servicetracker is not able to track the remote
> service. The number of tracked services is 0. 
> 
> My questions are:
> 
> 1) Are there any other settings which needs to be done for the client to
> discover the published services in the zookeeper? Must I tell the client
> where is the zookeeper or this is done by the single-bundle?
> 2) It seems like the client is not interacting with the zookeeper to get
> the published services information. Must I do anything to the client to
> retrieve the info?
> 3) Why cant the client switch to the remote service automatically?
> 
> Thanks a lot in advance.
> 
> Roger
> 
> 
> 
> --
> View this message in context: http://cxf.547215.n5.nabble.com/OSGI-service-dynamic-discovery-using-zookeeper-tp5716356.html
> Sent from the cxf-dev mailing list archive at Nabble.com (http://Nabble.com).




Re: OSGI service dynamic discovery using zookeeper

Posted by Willem jiang <wi...@gmail.com>.
Please check out my comments in the mail.

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
          http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: willemjiang



On Monday, October 15, 2012 at 12:04 PM, Roger wrote:

> Hi,
>  
> Thanks for your reply.
> Please correct me if my understanding is wrong.
>  
> By using the fabric-cxf code, my code will need to specify the endpoints
> of the service providers right?

No, you just need to tell the zoo keeper address which could hold the reference of the service providers actual address.
The client can access the endpoint at the runtime.   
>  
> Actually, what I wanted to acheive is to retrieve a list of OSGI service
> provider information from the zookeeper and failover among the list. Will
> the fabric-cxf code helps me to retrieve the list of OSGI service provider
> information from the zookeeper at the start?

Yes, fabric-cxf does the exactly the same work as you want.
>  
> Thanks a lot.
>  
>  
>  
> --
> View this message in context: http://cxf.547215.n5.nabble.com/OSGI-service-dynamic-discovery-using-zookeeper-tp5716356p5716593.html
> Sent from the cxf-dev mailing list archive at Nabble.com (http://Nabble.com).




Re: OSGI service dynamic discovery using zookeeper

Posted by Roger <Re...@yahoo.com.sg>.
Hi,

   Thanks for your reply.
   Please correct me if my understanding is wrong.

   By using the fabric-cxf code, my code will need to specify the endpoints
of the service providers right?

   Actually, what I wanted to acheive is to retrieve a list of OSGI service
provider information from the zookeeper and failover among the list. Will
the fabric-cxf code helps me to retrieve the list of OSGI service provider
information from the zookeeper at the start?

   Thanks a lot.



--
View this message in context: http://cxf.547215.n5.nabble.com/OSGI-service-dynamic-discovery-using-zookeeper-tp5716356p5716593.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: OSGI service dynamic discovery using zookeeper

Posted by Freeman Fang <fr...@gmail.com>.
Hi,

Not really a step by step example,  just FYI, the fabric-cxf code Willem mentioned is here[1]
[1]https://github.com/fusesource/fuse/tree/master/fabric/fabric-cxf/src/main/java/org/fusesource/fabric/cxf
-------------
Freeman Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042

On 2012-10-12, at 上午10:17, Roger wrote:

> Hi Willem,
> 
>   Thanks for your reply.
> 
>   Like what you have mentioned, I would like to look up the address from
> the registry (zookeeper).
> 
>   Verify concept
>   ----------------
>    Now I understand that the OSGI framework does not automatically discover
> the remote services published in the registry. Extra work needs to be done
> on the client to look up to the registry & get the published servcies
> information.
> 
>   Questions
>   -----------
>   I have gone to look at the proposed 2 ways to achieve my objective.
> However, as I am new to OSGI & the apache cxf and hence I dont really
> understand how to implement them in my existing OSGI bundle. Therefore, may
> I ask if there are any samples which I can reference to?
> 
>   Thank you so much once again.
> 
> 
> 
> --
> View this message in context: http://cxf.547215.n5.nabble.com/OSGI-service-dynamic-discovery-using-zookeeper-tp5716356p5716444.html
> Sent from the cxf-dev mailing list archive at Nabble.com.


Re: OSGI service dynamic discovery using zookeeper

Posted by Roger <Re...@yahoo.com.sg>.
Hi Willem,

   Thanks for your reply.
   
   Like what you have mentioned, I would like to look up the address from
the registry (zookeeper).
   
   Verify concept
   ----------------
    Now I understand that the OSGI framework does not automatically discover
the remote services published in the registry. Extra work needs to be done
on the client to look up to the registry & get the published servcies
information.

   Questions
   -----------
   I have gone to look at the proposed 2 ways to achieve my objective.
However, as I am new to OSGI & the apache cxf and hence I dont really
understand how to implement them in my existing OSGI bundle. Therefore, may
I ask if there are any samples which I can reference to?

   Thank you so much once again.



--
View this message in context: http://cxf.547215.n5.nabble.com/OSGI-service-dynamic-discovery-using-zookeeper-tp5716356p5716444.html
Sent from the cxf-dev mailing list archive at Nabble.com.