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
On 05/31/2015 06:22 PM, Sebastiaan la Fleur wrote:
Remote Services and Remote Service Admin were indeed the terms I was
looking for. Thanks Neil!
2015-05-30 13:55 GMT+02:00 Sebastiaan la Fleur <
sebastiaan.la.fl...@gmail.com>:
Thanks for your reply! Yeah, I was thinking about that when I was in
the
shower just now haha. Sorry about that.
To rephrase: Is there a connection handler component in the Felix
framework that already handles accepting and losing socket connections
which can also be used to send or are we stuck using our own
implementation
on top of java sockets? Does that component already use some form of
application layer protocol to abstract from the streams into
information
packets?
I want to be able to talk between different nodes (send textual and
video
data). Of course I can write my own connection managing software, but I
would expect something like that to already be in Felix. I saw Felix
contains a subproject to handle HTTP servlets, but the client server
architecture of HTTP is not entirely suitable in my case. Both
clients need
to be able to start a connection to each other and both clients need
to be
able to start the conversation on the established connection.
Hopefully this is a lot clearer to what I am searching for!
2015-05-30 13:19 GMT+02:00 Neil Bartlett <njbartl...@gmail.com>:
That's a really wide-open question... "information exchange over a
network" could mean so many things! Can you be more specific about
your
requirements?
In the meantime, take a look at the Remote Services and Remote Service
Admin specs as they may be relevant.
--
Neil Bartlett
Sent from a phone
On Saturday, 30 May 2015 at 11:36, Sebastiaan la Fleur wrote:
Hi everyone!
As of yesterday I am trying to get into Apache Felix for a project. I
am still trying to get a basic grip on the framework. So far, if I am
understanding correctly the framework allows for remote install,
update
etc. of bundles(highly modulerized code) on different devices which
allows
for the management of large distributed systems. I have been
looking for a
way to let these devices communicate using the framework but so far
I was
not able to find any subproject or piece in the OSGi specification
that
allows for this. Probable is that I missed it though(quite a bit of
info
:P). Does Felix have a subproject/implementation to handle basic
information exchange over a network between OSGi capable devices?
If so,
could you direct me to the place where the documentation of this is
stored?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
