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 <[email protected]> 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
