You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dubbo.apache.org by Scott Lewis <sl...@composent.com> on 2019/08/30 22:05:31 UTC
Dubbo as OSGi Remote Service Distribution
Hi,
I'm the project lead for the Eclipse Communication Framework [1].
Among other things, ECF provides an implementation of the OSGi R7 Remote
Services/Remote Service Admin specifications [2].
ECF supports pluggable 'distribution providers', responsible for the
rpc, serialization/marshalling, and wire protocol. We have upwards of
10 distribution providers [3] created by us and others.
I've recently learned about Apache Dubbo, and decided to use it to
create a new ECF Remote Service Distribution Provider [4]. What this
means is that Apache Dubbo can now be used as a distribution impl for
any OSGi remote service. This also makes it quite possible to have
Other Runtimes -> OSGi and OSGi->Other runtimes and retain all the OSGi
service dynamics, injection through declarative services, etc.
If the Dubbo dev community is interested, I could easily describe how
Dubbo extensibility could be exposed via the OSGi service
registry/remote services. This would make it possible for Dubbo to be
easily extended using the OSGi service registry.
If Dubbo folks wanted to expose Dubbo modules as OSGi bundles, I believe
this could also be easily done and would be happy to contribute it back
to Dubbo.
One technical question: With Dubbo, is it possible to listen for
asynchronous events (such as disconnection/failed reconnect requests)
and respond to them? If so are there docs or examples of how to do
this? (java API best).
Thanks.
Scott
[1] http://www.eclipse.org/ecf https://wiki.eclipse.org/ECF
[2]
https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.html
[3] https://wiki.eclipse.org/Distribution_Providers
[4] https://github.com/ECF/DubboProvider
Re: Dubbo as OSGi Remote Service Distribution
Posted by Jun Liu <li...@apache.org>.
Thanks Scott. Thanks for the detailed explanation, it really helps me and I think also the community a lot.
Sorry for coming back late, but I am really busy with some other things on hand recently. I personally think OSGIRegistry can be a good choice to enrich the Dubbo ecosystem. I would recommend the extension exists as an independent project in Apache[1] first, just like dubbo-spring-boot-project[2]. The community can help to transfer the project to apache organization once it’s done and you decide to donate.
As for OSGI bundle I am not sure if Dubbo needs that kind of deployment or distribution form, we need further discussion in the mailing-list.
What do others think, especially those familiar with OSGI?
1. http://github.com/apache
2. https://github.com/apache/dubbo-spring-boot-project
Jun
> On Sep 3, 2019, at 7:58 AM, Scott Lewis <sl...@composent.com> wrote:
>
> Hi Jun,
>
> On 9/1/2019 10:29 PM, Scott Lewis wrote:
>> <stuff delected>
>
>> Yes both of these use cases are supported. As an example of 1: during testing of the DubboProvider I exported a DemoService instances as an OSGi Remote Service. Since it was exported with the Dubbo protocol, it can/could be accessed by either an OSGi-based client (as per the examples in the DubboProvider...i.e. 2) AND I tested access to it via a Java-only client (from dubbo-demo-api-consumer). What this means is that such a service can be accessed by any consumer (OSGi or not) that uses the dubbo protocol (both 1 and 2).
>
> To provide an example of this, I created this java project [1]. It's a DemoService consumer that is Java-only (similar to your own dubbo-demo-api-consumer except for how the dubbo url is discovered), but it can use/call the DemoService exported by the OSGi RS impl [2].
>
> Scott
>
> [1] https://github.com/ECF/DubboProvider/tree/master/examples/ecf.example.demo.consumer
>
> [2] https://github.com/ECF/DubboProvider/tree/master/examples/org.eclipse.ecf.examples.provider.dubbo.demo.impl
>
>
>
Re: Dubbo as OSGi Remote Service Distribution
Posted by Ian Luo <ia...@gmail.com>.
Hi community, is there anyone who's familiar with OSGI or interested in
this?
Thanks,
-Ian.
On Tue, Sep 3, 2019 at 7:58 AM Scott Lewis <sl...@composent.com> wrote:
> Hi Jun,
>
> On 9/1/2019 10:29 PM, Scott Lewis wrote:
> > <stuff delected>
>
> > Yes both of these use cases are supported. As an example of 1: during
> > testing of the DubboProvider I exported a DemoService instances as an
> > OSGi Remote Service. Since it was exported with the Dubbo protocol,
> > it can/could be accessed by either an OSGi-based client (as per the
> > examples in the DubboProvider...i.e. 2) AND I tested access to it via
> > a Java-only client (from dubbo-demo-api-consumer). What this means
> > is that such a service can be accessed by any consumer (OSGi or not)
> > that uses the dubbo protocol (both 1 and 2).
>
> To provide an example of this, I created this java project [1]. It's a
> DemoService consumer that is Java-only (similar to your own
> dubbo-demo-api-consumer except for how the dubbo url is discovered), but
> it can use/call the DemoService exported by the OSGi RS impl [2].
>
> Scott
>
> [1]
>
> https://github.com/ECF/DubboProvider/tree/master/examples/ecf.example.demo.consumer
>
> [2]
>
> https://github.com/ECF/DubboProvider/tree/master/examples/org.eclipse.ecf.examples.provider.dubbo.demo.impl
>
>
>
>
Re: Dubbo as OSGi Remote Service Distribution
Posted by Scott Lewis <sl...@composent.com>.
Hi Jun,
On 9/1/2019 10:29 PM, Scott Lewis wrote:
> <stuff delected>
> Yes both of these use cases are supported. As an example of 1: during
> testing of the DubboProvider I exported a DemoService instances as an
> OSGi Remote Service. Since it was exported with the Dubbo protocol,
> it can/could be accessed by either an OSGi-based client (as per the
> examples in the DubboProvider...i.e. 2) AND I tested access to it via
> a Java-only client (from dubbo-demo-api-consumer). What this means
> is that such a service can be accessed by any consumer (OSGi or not)
> that uses the dubbo protocol (both 1 and 2).
To provide an example of this, I created this java project [1]. It's a
DemoService consumer that is Java-only (similar to your own
dubbo-demo-api-consumer except for how the dubbo url is discovered), but
it can use/call the DemoService exported by the OSGi RS impl [2].
Scott
[1]
https://github.com/ECF/DubboProvider/tree/master/examples/ecf.example.demo.consumer
[2]
https://github.com/ECF/DubboProvider/tree/master/examples/org.eclipse.ecf.examples.provider.dubbo.demo.impl
Re: Dubbo as OSGi Remote Service Distribution
Posted by Scott Lewis <sl...@composent.com>.
Hi Jun,
On 9/1/2019 9:13 PM, Jun Liu wrote:
> Hi, Scott
>
> Welcome!
>
> Thanks for all the works you’ve done trying to integrating Dubbo with ECF. I personally don’t very familiar with OSGI, here’s some of my opinions and questions.
>
>> If the Dubbo dev community is interested, I could easily describe how Dubbo extensibility could be exposed via the OSGi service registry/remote services. This would make it possible for Dubbo to be easily extended using the OSGi service registry.
> With Dubbo distribution provider
> 1. It would be able for existing Dubbo services to community with OSGI based services using Dubbo protocol, or vice versa.
> 2. Dubbo offers as another option of transport protocol for SOGI remote service.
>
> Am I right for the above benefits of Dubbo distribution provider?
Yes both of these use cases are supported. As an example of 1: during
testing of the DubboProvider I exported a DemoService instances as an
OSGi Remote Service. Since it was exported with the Dubbo protocol, it
can/could be accessed by either an OSGi-based client (as per the
examples in the DubboProvider...i.e. 2) AND I tested access to it via a
Java-only client (from dubbo-demo-api-consumer). What this means is
that such a service can be accessed by any consumer (OSGi or not) that
uses the dubbo protocol (both 1 and 2).
> And is the integration work available now, as being displayed in this link https://github.com/ECF/DubboProvide?
Yes. The example that is given in the DubboProvider/examples is an
example of 2...i.e. exporting as an OSGi remote service, and
discovery/import/usage via an OSGi consumer. As for 1...I have not
written a Java-only client for the DemoService (which has a new package
name), but it would be very easy to do...and look almost exactly like
the dubbo-demo-api-consumer.
One other use case is also possible. It would be possible for an OSGi
consumer to access a Java-only Dubbo service. Again because the dubbo
protocol is used underneath this use case would also be easily supported.
>
>> If Dubbo folks wanted to expose Dubbo modules as OSGi bundles, I believe this could also be easily done and would be happy to contribute it back to Dubbo.
> Will this require many changes on the existing Dubbo code to meet some OSGI bundle exposing requirements? Or few extra configurations would be enough?
I'm not completely certain, yet, but I think that adding configurations
would be enough. OTOH, I think it might be desirable (if not
necessary) to expose different parts of the dubbo api (e.g. common,
config, rpc, etc) as separate OSGi bundles (jars+osgi metadata) when in
an OSGi environment. I do not think this would require many changes to
the Dubbo java code, but it might require some changes because of the
assumptions about classloading (and so resource loading) in OSGI, where
every bundle has it's own classloader.
But I do not expect large code changes would be required. There are
many significant libraries already available as both OSGi bundles and
'plain 'ol java jars'.
>
>> One technical question: With Dubbo, is it possible to listen for asynchronous events (such as disconnection/failed reconnect requests) and respond to them? If so are there docs or examples of how to do this? (java API best).
> Currently, Dubbo don’t have an asynchronous events mechanism. Would you please describe the scenarios that these features would be useful when working with OSGI?
The immediate need for this would be to detect network disconnection
(e.g. a service host gets disconnected). Since OSGi Services (and
remote services) are fully dynamic (can come and go at runtime), such
disconnect events can be translated to remote service proxy 'going
away/becoming unavialble' at runtime.
Scott
>
> Jun
>
>> On Aug 31, 2019, at 6:05 AM, Scott Lewis <sl...@composent.com> wrote:
>>
>> Hi,
>>
>> I'm the project lead for the Eclipse Communication Framework [1]. Among other things, ECF provides an implementation of the OSGi R7 Remote Services/Remote Service Admin specifications [2].
>>
>> ECF supports pluggable 'distribution providers', responsible for the rpc, serialization/marshalling, and wire protocol. We have upwards of 10 distribution providers [3] created by us and others.
>>
>> I've recently learned about Apache Dubbo, and decided to use it to create a new ECF Remote Service Distribution Provider [4]. What this means is that Apache Dubbo can now be used as a distribution impl for any OSGi remote service. This also makes it quite possible to have Other Runtimes -> OSGi and OSGi->Other runtimes and retain all the OSGi service dynamics, injection through declarative services, etc.
>>
>> If the Dubbo dev community is interested, I could easily describe how Dubbo extensibility could be exposed via the OSGi service registry/remote services. This would make it possible for Dubbo to be easily extended using the OSGi service registry.
>>
>> If Dubbo folks wanted to expose Dubbo modules as OSGi bundles, I believe this could also be easily done and would be happy to contribute it back to Dubbo.
>>
>> One technical question: With Dubbo, is it possible to listen for asynchronous events (such as disconnection/failed reconnect requests) and respond to them? If so are there docs or examples of how to do this? (java API best).
>>
>> Thanks.
>>
>> Scott
>>
>> [1] http://www.eclipse.org/ecf https://wiki.eclipse.org/ECF
>>
>> [2] https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.html
>>
>> [3] https://wiki.eclipse.org/Distribution_Providers
>>
>> [4] https://github.com/ECF/DubboProvider
>>
>
Re: Dubbo as OSGi Remote Service Distribution
Posted by Jun Liu <li...@apache.org>.
Hi, Scott
Welcome!
Thanks for all the works you’ve done trying to integrating Dubbo with ECF. I personally don’t very familiar with OSGI, here’s some of my opinions and questions.
> If the Dubbo dev community is interested, I could easily describe how Dubbo extensibility could be exposed via the OSGi service registry/remote services. This would make it possible for Dubbo to be easily extended using the OSGi service registry.
With Dubbo distribution provider
1. It would be able for existing Dubbo services to community with OSGI based services using Dubbo protocol, or vice versa.
2. Dubbo offers as another option of transport protocol for SOGI remote service.
Am I right for the above benefits of Dubbo distribution provider?
And is the integration work available now, as being displayed in this link https://github.com/ECF/DubboProvide?
> If Dubbo folks wanted to expose Dubbo modules as OSGi bundles, I believe this could also be easily done and would be happy to contribute it back to Dubbo.
Will this require many changes on the existing Dubbo code to meet some OSGI bundle exposing requirements? Or few extra configurations would be enough?
> One technical question: With Dubbo, is it possible to listen for asynchronous events (such as disconnection/failed reconnect requests) and respond to them? If so are there docs or examples of how to do this? (java API best).
Currently, Dubbo don’t have an asynchronous events mechanism. Would you please describe the scenarios that these features would be useful when working with OSGI?
Jun
> On Aug 31, 2019, at 6:05 AM, Scott Lewis <sl...@composent.com> wrote:
>
> Hi,
>
> I'm the project lead for the Eclipse Communication Framework [1]. Among other things, ECF provides an implementation of the OSGi R7 Remote Services/Remote Service Admin specifications [2].
>
> ECF supports pluggable 'distribution providers', responsible for the rpc, serialization/marshalling, and wire protocol. We have upwards of 10 distribution providers [3] created by us and others.
>
> I've recently learned about Apache Dubbo, and decided to use it to create a new ECF Remote Service Distribution Provider [4]. What this means is that Apache Dubbo can now be used as a distribution impl for any OSGi remote service. This also makes it quite possible to have Other Runtimes -> OSGi and OSGi->Other runtimes and retain all the OSGi service dynamics, injection through declarative services, etc.
>
> If the Dubbo dev community is interested, I could easily describe how Dubbo extensibility could be exposed via the OSGi service registry/remote services. This would make it possible for Dubbo to be easily extended using the OSGi service registry.
>
> If Dubbo folks wanted to expose Dubbo modules as OSGi bundles, I believe this could also be easily done and would be happy to contribute it back to Dubbo.
>
> One technical question: With Dubbo, is it possible to listen for asynchronous events (such as disconnection/failed reconnect requests) and respond to them? If so are there docs or examples of how to do this? (java API best).
>
> Thanks.
>
> Scott
>
> [1] http://www.eclipse.org/ecf https://wiki.eclipse.org/ECF
>
> [2] https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.html
>
> [3] https://wiki.eclipse.org/Distribution_Providers
>
> [4] https://github.com/ECF/DubboProvider
>
Re: Dubbo as OSGi Remote Service Distribution
Posted by Scott Lewis <sl...@composent.com>.
Hi KimmKing,
On 9/1/2019 6:24 PM, KimmKing wrote:
> Thanks, Scott,
>
> Integration with other popular frameworks is always in Dubbo Ecosystem Principles.
> I am familiar with OSGi, and can you guide me how to implement this Dubbo extensibility.
I've noticed that Dubbo uses the java ServiceLoader for extensibility.
I believe one good way to leverage the OSGi Service registry would be to
use the ServiceLoader to load (e.g.) an OSGiRegistryFactory, and then
have the impl of the OSGiRegistryFactory use the OSGi service registry
to dynamically use or create instances of (e.g.) Registry instances.
There is more to it than this, obviously, but the general point is that
the OSGi Service Registry is sufficiently dynamic that it can support
both load/start time extensibility (as ServiceLoader does) as well as
runtime extensibility (bundles and services being added and removed from
a running system).
> Asynchronous events for disconnection or failure to reconnect is not supported now, should we complete this feature first for ECF?
It would be a nice feature to have for ECF's usage of Dubbo. The main
reason is that it would allow disconnection events (and/or reconnect
failure) to be detected by clients...with the result in OSGi of
automatic unregistration of proxy service instances. This is something
that some remote services users value...i.e. the ability to detect
network failure, resulting in proxy unregistration.
Thanks,
Scott
>
>
> At 2019-08-31 06:05:31, "Scott Lewis" <sl...@composent.com> wrote: >Hi, > >I'm the project lead for the Eclipse Communication Framework [1]. >Among other things, ECF provides an implementation of the OSGi R7 Remote >Services/Remote Service Admin specifications [2]. > >ECF supports pluggable 'distribution providers', responsible for the >rpc, serialization/marshalling, and wire protocol. We have upwards of >10 distribution providers [3] created by us and others. > >I've recently learned about Apache Dubbo, and decided to use it to >create a new ECF Remote Service Distribution Provider [4]. What this >means is that Apache Dubbo can now be used as a distribution impl for >any OSGi remote service. This also makes it quite possible to have >Other Runtimes -> OSGi and OSGi->Other runtimes and retain all the OSGi >service dynamics, injection through declarative services, etc. > >If the Dubbo dev community is interested, I could easily describe how >Dubbo extensibility could be exposed via the OSGi service >registry/remote services. This would make it possible for Dubbo to be >easily extended using the OSGi service registry. > >If Dubbo folks wanted to expose Dubbo modules as OSGi bundles, I believe >this could also be easily done and would be happy to contribute it back >to Dubbo. > >One technical question: With Dubbo, is it possible to listen for >asynchronous events (such as disconnection/failed reconnect requests) >and respond to them? If so are there docs or examples of how to do >this? (java API best). > >Thanks. > >Scott > >[1] http://www.eclipse.org/ecf https://wiki.eclipse.org/ECF > >[2] >https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.html > >[3] https://wiki.eclipse.org/Distribution_Providers > >[4] https://github.com/ECF/DubboProvider
Re:Dubbo as OSGi Remote Service Distribution
Posted by KimmKing <ki...@apache.org>.
Thanks, Scott,
Integration with other popular frameworks is always in Dubbo Ecosystem Principles.
I am familiar with OSGi, and can you guide me how to implement this Dubbo extensibility.
Asynchronous events for disconnection or failure to reconnect is not supported now, should we complete this feature first for ECF?
At 2019-08-31 06:05:31, "Scott Lewis" <sl...@composent.com> wrote: >Hi, > >I'm the project lead for the Eclipse Communication Framework [1]. >Among other things, ECF provides an implementation of the OSGi R7 Remote >Services/Remote Service Admin specifications [2]. > >ECF supports pluggable 'distribution providers', responsible for the >rpc, serialization/marshalling, and wire protocol. We have upwards of >10 distribution providers [3] created by us and others. > >I've recently learned about Apache Dubbo, and decided to use it to >create a new ECF Remote Service Distribution Provider [4]. What this >means is that Apache Dubbo can now be used as a distribution impl for >any OSGi remote service. This also makes it quite possible to have >Other Runtimes -> OSGi and OSGi->Other runtimes and retain all the OSGi >service dynamics, injection through declarative services, etc. > >If the Dubbo dev community is interested, I could easily describe how >Dubbo extensibility could be exposed via the OSGi service >registry/remote services. This would make it possible for Dubbo to be >easily extended using the OSGi service registry. > >If Dubbo folks wanted to expose Dubbo modules as OSGi bundles, I believe >this could also be easily done and would be happy to contribute it back >to Dubbo. > >One technical question: With Dubbo, is it possible to listen for >asynchronous events (such as disconnection/failed reconnect requests) >and respond to them? If so are there docs or examples of how to do >this? (java API best). > >Thanks. > >Scott > >[1] http://www.eclipse.org/ecf https://wiki.eclipse.org/ECF > >[2] >https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.html > >[3] https://wiki.eclipse.org/Distribution_Providers > >[4] https://github.com/ECF/DubboProvider