I’ve now built 2 different systems based on OSGi at scale (over 1M end devices) where the endpoints needed to communicate together. In both cases, it has required some ‘server’ infrastructure to help with message passing between endpoints, but that could be a side effect of the infrastructure we had to use. However, these server components were again based on OSGi.
The http question (I.e. using the HTTP service) is actually a bit of a red herring: there is nothing stopping each endpoint implementing an http service and also being a client of other endpoints to pass messages. My suggestion would be to use this approach, as it has so many side benefits, including: * good availability of tools such as Jackson for message serialisation * open protocols that will allow for different endpoint implementations in future * (by and large) avoiding problems that custom socket protocols will run into with firewall tunnelling etc …the list here is pretty long. On 02/06/2015 16:08, "Scott Lewis" <sle...@composent.com> wrote: >On 6/2/2015 2:16 AM, Simon Kitching wrote: >> 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? > >For the latest the correct URL is: >http://download.eclipse.org/rt/ecf/latest/site.p2/karaf-features.xml > >ECF's implementation is quite modular, and so is made up of more >bundles, generally much smaller and finer-grained. > >> >> <stuff deleted> >> >> 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? > >I have done the majority of the commits from the start of 2014, but am >not the only committer. The source code history is not a very good >indicator of overall contributions for a project in this point in it's >life-cycle. Also, much of the recent coding work on ECF (by myself and >others) has taken place on our github repos[4]. > >> <stuff deleted> > >> 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)? > >We currently use Eclipse + buckminster to build, and are part of the >Eclipse Simultaneous Release (which also uses buckminster). There are >contributors from Red Hat that are working adding to use Tycho to >build. FWIW, we also produce a maven repos as part of our build [A]. > >> 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)? > > From Eclipse, certainly. When Red Hat's contribution is in place you >will be able to do with maven-pom file as well. > >> >> 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? > >No, regrettably we don't have that. I've opened an enhancement request >to that effect [B]. There was some performance analysis work >contributed some time ago, but unfortunately I think it's likely pretty >obsolete by now. > >> 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. > >For the details about everything there's always 'use the source'. :-) > >I can tell you that r-osgi, ecf generic, JMS, MQTT distribution >providers all > >1) keep network sockets open as you describe; >2) use java object serialization as the default > >I can also tell you that all of those providers, and the distribution >API that they implement (known to us as the 'remote services api'), are >customizable/extensible for both 1 and 2...meaning that if you wish, you >can replace both the serialization as well as the socket-level transport >with something more suitable for your use case without having to >implement a distribution provider from scratch. As a an example, that >is how websockets support was added in the 3.10 release cycle. > >I propose moving this to ecf-dev or direct correspondence if you want >more details. > >Scott > >[A] http://build.ecf-project.org/maven/ >[B] https://bugs.eclipse.org/bugs/show_bug.cgi?id=469155 > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >For additional commands, e-mail: users-h...@felix.apache.org > *** DISCLAIMER *** This message, including attachments, is intended solely for the addressee indicated in this message and is strictly confidential or otherwise privileged. If you are not the intended recipient (or responsible for delivery of the message to such person) : - (1) please immediately (i) notify the sender by reply email and (ii) delete this message and attachments, - (2) any use, copy or dissemination of this transmission is strictly prohibited. If you or your employer does not consent to Internet email messages of this kind, please advise Myriad Group AG by reply e-mail immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by Myriad Group AG unless otherwise indicated by an authorized representative independent of this message.
