All this extra (meta) information about the different implementations is actually really appreciated from my end, so feel free to continue :D
2015-06-02 11:16 GMT+02:00 Simon Kitching <si...@vonos.net>: > 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 > >
