Hi Scott,
Maybe I shouldn't hijack a thread on the Felix list to ask about ECF,
but we are already talking about remote-services implementations, and
you are here so I'll do it :-)
Link [1] has instructions on using ECF's remote services on Karaf which
lead to this karaf features file:
http://download.eclipse.org/rt/ecf/3.8.0/site.p2/karaf-features.xml.
That file appears to indicate that 49 bundles are needed (the majority
from eclipse.org). Plus bundles to support whatever discovery provider
is desired. That doesn't seem reasonable; other remote-services
implementations have 1-3 bundles. Have I understood correctly?
The ECF sourcecode appears to be here (not on github, which appears to
be for addons and experiments):
http://git.eclipse.org/c/ecf/org.eclipse.ecf.git
with the remote services-related code here:
http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/osgi/bundles
Looking at the commit-log for the osgi code, I see that you are the only
committer since at least the start of 2014. Is this correct? If so, then
while I appreciate your hard work, having a single developer would be a
significant issue to consider when using this code in production. Not
critical, as the code is open, but nevertheless important to know.
Actually, it appears that you are the author of 95% of commits to the
entire (very large) ECF project. Is this right?
Regarding building from source : I see no Maven, Ant, Groovy or bnd
buildfiles in the sourcecode - just eclipse project files. Could you
point me to instructions on how to build artifacts from the source-code
(ideally outside of the Eclipse IDE)? And is there any easy way of
seeing what the dependencies of the projects under osgi/bundles are (the
kind of info visible in a maven pom-file)?
Is there a list of the implemented "distribution providers" (network
protocols for the actual remote method invocation) available, with
details on the features and performance of each choice? I couldn't find
one. In particular, I needed a high-performance protocol - one that (a)
keeps network sockets open rather than opening a new connection for each
call, and (b) uses a high-performance serialization mechanism, ie not
xml. I couldn't find any page with that kind of information in it. The
closest I found was:
*
https://wiki.eclipse.org/Discovery_and_Distribution_Provider_Configuration_Options
*
https://wiki.eclipse.org/Comparison_of_Discovery_and_Distribution_Providers
but neither of those pages are very useful. In particular, "r-osgi" and
"ecf generic" are not described in any way.
Thanks,
Simon
On 06/01/2015 06:42 PM, Scott Lewis wrote:
Since people are commenting on RSA implementations, I think it's
appropriate to provide for this community some resources for ECF's RSA
implementation.
Documentation [1]
Maintenance and Release History [2]
This implementation is OSGi CT-tested and fully implements the RS/RSA
1.1 (OSGi R6) specifications. It runs on any OSGi R5+ compliant
framework. Our 3.10/Mars release is occurring in ~3 weeks [2].
ECF's modular, layered, open provider architecture [3] uniquely allows
new transports to be introduced (by us or others) that meet specific
security, performance, and/or other concerns. In 3.10 we have
introduced several new distribution and discovery providers (e.g.
MQTT, websockets, etcd) in addition to those already present (e.g.
JMS, r-OSGi, tcp) [4]. There is also now a tutorial on how to create
your own provider [5], if that's the path that makes the most sense
for your app and/or deployment needs.
Resources are available for custom development (app and/or provider),
consultation, and support. Since we are a volunteer-run project,
these resources are most easily accessed via communication on our
public mailing list [6] or in direct communication with me (project
lead). We welcome...and as quickly-as-possible will respond to...bug
reports and/or enhancement requests [7].
Scott
[1] https://wiki.eclipse.org/ECF#OSGi_Remote_Services
https://www.eclipse.org/ecf/
https://www.eclipse.org/ecf/NewAndNoteworthy_3.10.0.html
https://projects.eclipse.org/projects/rt.ecf
[2] https://projects.eclipse.org/projects/rt.ecf
[3] https://wiki.eclipse.org/OSGi_Remote_Services_and_ECF
[4] https://github.com/ECF
[5]
https://wiki.eclipse.org/Tutorial:_Creating_a_RESTful_Remote_Service_Provider
[6] https://dev.eclipse.org/mailman/listinfo/ecf-dev
[7] https://bugs.eclipse.org/bugs/enter_bug.cgi?product=ECF
On 6/1/2015 6:53 AM, Simon Kitching wrote:
Hi Sebastiaan,
Regarding "management of large distributed systems" : the OSGi spec
itself mainly deals with multiple libraries running in a single JVM.
Some of the central features of OSGi can help in building a
distributed system, but they aren't part of the OSGi spec itself. And
Apache Felix doesn't have any subprojects that address distrubuted
systems (AFAIK). You might want to look at Ace (ace.apache.org) or
jboss fuse (though fuse is currently undergoing a radical rewrite,
with the previous version effectively abandonware, so is difficult to
base anything on at the moment).
Regarding osgi remote services: the spec is pretty elegant, and
invoking a remote service is much like invoking a local one. However
the existing implementations are mainly intended for integration with
other systems, and not for performance. I recently needed a
high-performance remote-services impl for communication between OSGi
containers, and had great difficulty finding one. The reference impl
from cxf.apache.org is based on xml and opens a new network
connection for each call. The impl from Amdatu is based on json, and
also opens a new network connection per call. The impl from eclipse
ECF seems poorly maintained and poorly documented - at least I didn't
feel comfortable integrating it into a production system. In short :
if you want to occasionally make calls to external systems via SOAP
or allow external systems to occasionally call in, then remote
services with the default impls are ok. Building a cluster with it is
not currently so easy.
One other issue with remote services : deserialization can cause
problems. In particular, the code deserializing a stream needs to
somehow locate the appropriate classes which is not so hard with a
traditional java classpath, but more difficult under OSGi for obvious
reasons.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
