Hi Sascha,
On 2/12/2016 7:42 AM, Sascha Vogt wrote:
Hi all,
we (a colleague of mine and myself) started searching for a
high-performance / lightweight remote OSGi implementation. We have a
requirement that the implementation has to /also/ (in addition to Karaf)
run on a heavily customized JBoss 7.1.1 as well, so the lightweight part
was kinda important ;)
We stumbled accross http://moi.vonos.net/java/dosgi-fabric/ which talks
about using the "old" dosgi implementation from Fabric8 (former Fuse
ESB). We had a look and we really liked it. Performance wise it comes
really close to RMI with about 30% overhead at 10k invocations of a
service sending back and forth a simple string on the same host. Using
different hosts the times were identical. Yes I know, that's not a
"real" use case, but it made us confident in taking a deeper look. It
also only has two external dependencies (hawtdispatch and hawtbuf, both
ASL-2 licensed).
So now the proposal: Resurrect the old Fabric8 implementation, directly
at the karaf-cellar subproject. As the copyright of the original code
belongs to RedHat, Guillaume could you ask internally if the following
resources could be donated to the Karaf project?
https://github.com/fabric8io/fabric8/tree/4d878d1f47226a2c3fb77aeee76814419f5edce0
Paths
/fabric/fabric-dosgi
/fabric/fabric-api/src/main/java/io/fabric8/api/ManagedCuratorFrameworkAvailable.java
/fabric/fabric-api/src/main/java/io/fabric8/api/scr/Configurer.java
/fabric/fabric-api/src/main/java/io/fabric8/api/scr/ValidatingReference.java
/fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/utils/ZooKeeperUtils.java
/fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/curator/Constants.java
/fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/curator/CuratorConfig.java
/fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/curator/CuratorFrameworkLocator.java
/fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/curator/ManagedCuratorFramework.java
Test-Dependecies paths
/fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/bootstrap/BootstrapConfiguration.java
/fabric/fabric-api/src/main/java/io/fabric8/api/Container.java
/fabric/fabric-api/src/main/java/io/fabric8/api/ContainerOptions.java
/fabric/fabric-api/src/main/java/io/fabric8/api/HasId.java
/fabric/fabric-api/src/main/java/io/fabric8/api/ZkDefs.java
/fabric/fabric-api/src/main/java/io/fabric8/api/RuntimeProperties.java
/fabric/fabric-api/src/main/java/io/fabric8/api/DataStore.java
/fabric/fabric-api/src/main/java/io/fabric8/api/DataStoreTemplate.java
/fabric/fabric-zookeeper-spring/src/main/java/io/fabric8/zookeeper/spring/ZKServerFactoryBean.java
The test dependencies could probably be done without, if they provide
too big of a hassle, though it's better to start with running tests ;)
They would also go into fabric-dosgi/src/test/java/...
Given that RedHat would be willing to donate the code, we (mainly
Johannes and me, both working for SEEBURGER AG) would work on it with
the following roadmap in mind:
1. Make the implementation remote OSGi compatible (implement the defined
interfaces, etc.)
2. Make the discovery exchangeable (so Zookeeper becomes an optional
dependency). We need that part, as we have our own database based
discovery, not really usable for the rest of the world. This would also
allow to replace the currently available remote OSGi impl in Karaf and
using the Cellar internals for discovery.
3. That is a bigger step / work and needs to be discussed further. There
are at least two possible options
3. a) Inline the needed parts of hawt* as they seem to be an abandoned
project too.
3. b) Make the transport exchangeable so the dependency to hawtbuf /
hawtdispatch becomes optional and provide our own implementation
Regarding hawt and option 3.a) inlining it: Guillaume do you know who
owns the copyright to that? I assume also RedHat? Maybe those could also
be donated?
@all: What are your thoughts on that?
I would suggest simply creating a new distribution provider for ECF's
remote services/RSA implementation (fully spec compliant and
CT-tested). In terms of the spec/standards, what was called
'distributed osgi' is now called 'remote services/remote service admin'.
Background: In addition to a fully compliant implementation, ECF has
pluggable distribution and discovery providers [1]. This has allowed
us and others to create a growing set of providers that are based upon
various transports (e.g. distribution: CXF, Jersey, r-OSGi,
ActiveMQ/JMS, Hazelcast, MQTT, custom REST, generic, others; discovery:
Zookeeper, etcd, SLP, DNSSD, zeroconf, EDEF, others) [2]. These are the
ones we know about...there can/could be others that we are not aware
of. It would be great to have additional providers, both for discovery
(Cellar?), and others either in open source or not.
One major advantage: There's no need for new providers (discovery or
distribution) to consult the spec to create RS/RSA-compliant
implementations. All of that is done, CT-tested, open (source), and
maintained/supported to be spec compliant. This makes it much easier
to create, and test compliant implementations. Also...if desired and
at all possible, the ECF team will happily assist in creating and
testing providers [3].
We've discussed on this list the possibility of using Cellar to create
providers in the past...I would very much like to see this, and offer to
contribute to such an effort.
Thanks,
Scott
[1] http://wiki.eclipse.org/OSGi_Remote_Services_and_ECF
[2] http://wiki.eclipse.org/Distribution_Providers
[3] https://www.eclipse.org/ecf/NewAndNoteworthy_3.12.1.html
