You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Sebastiaan la Fleur <se...@gmail.com> on 2015/05/30 12:36:00 UTC
Newbie question related to device communication
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?
I did come across something called SIP but it seemed fairly comprehensive for my goals.
Thanks in advance!
Sincere Regards,
Sebastian
Re: Newbie question related to device communication
Posted by Simon Kitching <si...@vonos.net>.
On 06/02/2015 12:57 PM, Sebastiaan la Fleur wrote:
> All this extra (meta) information about the different implementations is
> actually really appreciated from my end, so feel free to continue :D
I wrote up my experiences with searching for an osgi remote-services
implementation; you might find it useful:
http://moi.vonos.net/java/dosgi-fabric/
I've just added a link from that article back to this thread for future
reference.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Newbie question related to device communication
Posted by Sebastiaan la Fleur <se...@gmail.com>.
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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Newbie question related to device communication
Posted by Scott Lewis <sc...@gmail.com>.
Hi Folks,
Update: ECF has recently completed initial documentation for 9
distribution providers [1]. We've also recently had our 3.11.0 release
[2], which includes a new API for registering custom distribution
providers via the whiteboard pattern.
Scott
[1]
http://eclipseecf.blogspot.com/2015/10/ecf-remote-services-distribution.html
[2]
http://eclipseecf.blogspot.com/2015/09/ecf-3110-custom-remote-services.html
On 6/3/2015 10:03 AM, Scott Lewis wrote:
> On 6/3/2015 2:25 AM, Bruce Jackson wrote:
>> 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.
>
> I would like to discuss the Remote Service specification before
> returning to discussing protocols and RS implementations.
>
> The specification explicitly allows the runtime selection of a
> distribution provider to be used to export a remote service, via a
> standardized service property called the 'config type' (property
> name: service.exported.configs). As an example, the
> 'ecf.generic.server' distribution provider is the config type used in
> this tutorial [1].
>
> I feel that one of the most useful aspects of the config type and the
> underlying distribution system is that it abstracts away the
> implementation specifics, i.e. the transport protocol (e.g. http, jms,
> tcp, mqtt, private, etc), as well as the serialization
> mechanism/format (json, binary, xml, etc). It does this for both the
> remote service creator/implementer and for the remote service consumer.
>
> IMHO, there are there are many advantages of doing this. A big one
> is modularity and reuse. Why should it be necessary for every remote
> service author to implement a brand new protocol and serialization, in
> order to remote their micro service? Another one is flexibility:
> any given reasonably sophisticated app has changing requirements over
> time, and sometimes these changing requirements require flexibility in
> the underlying libraries. Another big advantage is getting access to
> all the simplicity, dynamics, versioning, and other capabilities of
> OSGi services provided by the OSGi service registry and libs built on
> top of it (e.g. DS, etc). There are of course many others.
>
> Of course, there are disadvantages in reusing distribution systems or
> any set of libraries: Perhaps the protocol or serialization
> mechanism that's widely implemented and popular today doesn't meet
> your application's performance needs. Perhaps there are more
> appropriate or new protocols, or improved implementations. Perhaps you
> have unique security requirements. Perhaps you have timing or
> reliability requirements that are difficult to address. There are lots
> of application-specific reasons for favoring or disfavoring
> non-functional requirements like performance, ease of deployment and
> management, security (e.g. firewalls), network reliability/failure
> handling, etc.
>
> But in my view, the Remote Services specification adopts a nice
> balance here, by allowing potentially many distribution providers,
> down to the level of the individual service instance set at *service
> instance registration time*. Even if one needs to create a new,
> entire distribution system, there are still many advantages of using
> OSGI Remote Services...e.g. the service registry's graceful handling
> of dynamics inherent in a network-based service, versioning,
> discovery, and the ability for service creators and perhaps more
> importantly service consumers to ignore some of the subtle and
> difficult aspects of distribution (e.g. partial failure, timing,
> etc). I do think that standardizing these advantages and having many
> implementations will over time make it easier to build, use,
> understand, and manage distributed applications.
>
> Returning to RS implementations: The approach ECF has taken (since
> well before the Distributed OSGi rfc and RS/RSA standardization) has
> been protocol neutral. As such we have gone to the trouble of
> creating extensible APIs for various types of network communication:
> e.g. filetransfer, instant messaging, group messaging, voice over ip,
> network service discovery, and remote services distribution (of
> course). For each of these types, we have multiple protocol
> implementations, some created by us (in open source), some created by
> others (in open source or not). This is true, of course, for our
> OSGi Remote Services implementation, and it's distribution and
> discovery subsystems...as I've said we have a number of providers that
> are based upon tcp and we have providers that are based upon http and
> REST. But more importantly (I think), we are trying to support the
> creation of hopefully many other/new providers, created by
> others...possibly extending those that already exist...that meet their
> needs for app-specific non-functional requirements, new/popular
> application areas (like IoT) for distributed applications.
>
> The way that we do this with a multi-provider/multi-protocol approach
> is to:
>
> 0) Fully implement the latest specs an test for compliance
> 1) Define stable, extensible, open APIs for distribution and discovery
> (e.g. 'remote services api' -> distribution, 'discovery api' ->
> discovery), and maintain/enhance these APIs.
> 2) Re-use existing work to create stable, extensible, open provider
> implementations for these types (e.g. ecf generic, http/REST, r-osgi,
> jms, mqtt, etc)
> 3) Do what we can in open cooperation with the community to document
> and provide examples for both 1 and 2, as well as document how to
> create new providers [2], and analyze the runtime characteristics of
> existing providers.
> 4) Engage the community (commercial and open source) to drive 0-3
> forword in the directions that are most needed, and get support for
> these efforts via new committers, contributors, collaborators, and
> supporters [3].
> 5) Provide the support for the community in doing all of the above
>
> Are we resource-limited? Yes, unless you consider the community. Is
> there more to do? (particularly around documenting individual
> providers)? Yes. My comment is that in today's software world I
> don't think these answers are particularly uncommon ;-). [4]
>
> Scott
>
> [1]
> https://wiki.eclipse.org/Tutorial:_Building_your_first_OSGi_Remote_Service
> See section: Service Host: Register and Export the Service
> [2]
> https://wiki.eclipse.org/Tutorial:_Creating_a_RESTful_Remote_Service_Provider
> [3] https://projects.eclipse.org/projects/rt.ecf/who
> [4] https://www.eclipse.org/ecf/NewAndNoteworthy_3.10.0.html
>
>
>
>>
>>
>>
>> On 02/06/2015 16:08, "Scott Lewis" <sl...@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-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@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.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Newbie question related to device communication
Posted by Scott Lewis <sl...@composent.com>.
ECF 3.10.1 has been released [1].
A part of this release was the simplification and refactoring of the
Karaf features [2] available to install OSGi Remote Services, along with
required distribution and discovery providers.
Scott
[1] http://eclipseecf.blogspot.com/
[2] https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Newbie question related to device communication
Posted by sl...@composent.com.
Update: ECF has recently completed initial documentation for 9
distribution providers [1]. We've also recently had our 3.11.0 release
[2], which includes a small new API for registering custom distribution
providers via the whiteboard pattern.
Scott
[1]
http://eclipseecf.blogspot.com/2015/10/ecf-remote-services-distribution.html
[2]
http://eclipseecf.blogspot.com/2015/09/ecf-3110-custom-remote-services.html
On 6/3/2015 10:03 AM, Scott Lewis wrote:
> On 6/3/2015 2:25 AM, Bruce Jackson wrote:
>> Ive 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.
>
> I would like to discuss the Remote Service specification before
returning to discussing protocols and RS implementations.
>
> The specification explicitly allows the runtime selection of a
distribution provider to be used to export a remote service, via a
standardized service property called the 'config type' (property name:
service.exported.configs). As an example, the 'ecf.generic.server'
distribution provider is the config type used in this tutorial [1].
>
> I feel that one of the most useful aspects of the config type and the
underlying distribution system is that it abstracts away the
implementation specifics, i.e. the transport protocol (e.g. http, jms,
tcp, mqtt, private, etc), as well as the serialization mechanism/format
(json, binary, xml, etc). It does this for both the remote service
creator/implementer and for the remote service consumer.
>
> IMHO, there are there are many advantages of doing this. A big one is
modularity and reuse. Why should it be necessary for every remote
service author to implement a brand new protocol and serialization, in
order to remote their micro service? Another one is flexibility: any
given reasonably sophisticated app has changing requirements over time,
and sometimes these changing requirements require flexibility in the
underlying libraries. Another big advantage is getting access to all the
simplicity, dynamics, versioning, and other capabilities of OSGi
services provided by the OSGi service registry and libs built on top of
it (e.g. DS, etc). There are of course many others.
>
> Of course, there are disadvantages in reusing distribution systems or
any set of libraries: Perhaps the protocol or serialization mechanism
that's widely implemented and popular today doesn't meet your
application's performance needs. Perhaps there are more appropriate or
new protocols, or improved implementations. Perhaps you have unique
security requirements. Perhaps you have timing or reliability
requirements that are difficult to address. There are lots of
application-specific reasons for favoring or disfavoring non-functional
requirements like performance, ease of deployment and management,
security (e.g. firewalls), network reliability/failure handling, etc.
>
> But in my view, the Remote Services specification adopts a nice balance
here, by allowing potentially many distribution providers, down to the
level of the individual service instance set at *service instance
registration time*. Even if one needs to create a new, entire
distribution system, there are still many advantages of using OSGI
Remote Services...e.g. the service registry's graceful handling of
dynamics inherent in a network-based service, versioning, discovery, and
the ability for service creators and perhaps more importantly service
consumers to ignore some of the subtle and difficult aspects of
distribution (e.g. partial failure, timing, etc). I do think that
standardizing these advantages and having many implementations will over
time make it easier to build, use, understand, and manage distributed
applications.
>
> Returning to RS implementations: The approach ECF has taken (since
well before the Distributed OSGi rfc and RS/RSA standardization) has
been protocol neutral. As such we have gone to the trouble of creating
extensible APIs for various types of network communication: e.g.
filetransfer, instant messaging, group messaging, voice over ip, network
service discovery, and remote services distribution (of course). For
each of these types, we have multiple protocol implementations, some
created by us (in open source), some created by others (in open source
or not). This is true, of course, for our OSGi Remote Services
implementation, and it's distribution and discovery subsystems...as I've
said we have a number of providers that are based upon tcp and we have
providers that are based upon http and REST. But more importantly (I
think), we are trying to support the creation of hopefully many
other/new providers, created by others...possibly extending those that
already exist...that meet their needs for app-specific non-functional
requirements, new/popular application areas (like IoT) for distributed
applications.
>
> The way that we do this with a multi-provider/multi-protocol approach is
to:
>
> 0) Fully implement the latest specs an test for compliance
> 1) Define stable, extensible, open APIs for distribution and discovery
(e.g. 'remote services api' -> distribution, 'discovery api' ->
discovery), and maintain/enhance these APIs.
> 2) Re-use existing work to create stable, extensible, open provider
implementations for these types (e.g. ecf generic, http/REST, r-osgi,
jms, mqtt, etc)
> 3) Do what we can in open cooperation with the community to document and
provide examples for both 1 and 2, as well as document how to create new
providers [2], and analyze the runtime characteristics of existing
providers.
> 4) Engage the community (commercial and open source) to drive 0-3
forword in the directions that are most needed, and get support for
these efforts via new committers, contributors, collaborators, and
supporters [3].
> 5) Provide the support for the community in doing all of the above
>
> Are we resource-limited? Yes, unless you consider the community. Is
there more to do? (particularly around documenting individual
providers)? Yes. My comment is that in today's software world I don't
think these answers are particularly uncommon . [4]
>
> Scott
>
> [1]
https://wiki.eclipse.org/Tutorial:_Building_your_first_OSGi_Remote_Service
> See section: Service Host: Register and Export the Service
> [2]
https://wiki.eclipse.org/Tutorial:_Creating_a_RESTful_Remote_Service_Provider
> [3] https://projects.eclipse.org/projects/rt.ecf/who
> [4] https://www.eclipse.org/ecf/NewAndNoteworthy_3.10.0.html
>
>
>
>>
>>
>>
>> On 02/06/2015 16:08, "Scott Lewis" <sl...@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-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@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.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Newbie question related to device communication
Posted by Scott Lewis <sl...@composent.com>.
On 6/3/2015 2:25 AM, Bruce Jackson wrote:
> 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.
I would like to discuss the Remote Service specification before
returning to discussing protocols and RS implementations.
The specification explicitly allows the runtime selection of a
distribution provider to be used to export a remote service, via a
standardized service property called the 'config type' (property name:
service.exported.configs). As an example, the 'ecf.generic.server'
distribution provider is the config type used in this tutorial [1].
I feel that one of the most useful aspects of the config type and the
underlying distribution system is that it abstracts away the
implementation specifics, i.e. the transport protocol (e.g. http, jms,
tcp, mqtt, private, etc), as well as the serialization mechanism/format
(json, binary, xml, etc). It does this for both the remote service
creator/implementer and for the remote service consumer.
IMHO, there are there are many advantages of doing this. A big one is
modularity and reuse. Why should it be necessary for every remote
service author to implement a brand new protocol and serialization, in
order to remote their micro service? Another one is flexibility: any
given reasonably sophisticated app has changing requirements over time,
and sometimes these changing requirements require flexibility in the
underlying libraries. Another big advantage is getting access to all
the simplicity, dynamics, versioning, and other capabilities of OSGi
services provided by the OSGi service registry and libs built on top of
it (e.g. DS, etc). There are of course many others.
Of course, there are disadvantages in reusing distribution systems or
any set of libraries: Perhaps the protocol or serialization mechanism
that's widely implemented and popular today doesn't meet your
application's performance needs. Perhaps there are more appropriate or
new protocols, or improved implementations. Perhaps you have unique
security requirements. Perhaps you have timing or reliability
requirements that are difficult to address. There are lots of
application-specific reasons for favoring or disfavoring non-functional
requirements like performance, ease of deployment and management,
security (e.g. firewalls), network reliability/failure handling, etc.
But in my view, the Remote Services specification adopts a nice balance
here, by allowing potentially many distribution providers, down to the
level of the individual service instance set at *service instance
registration time*. Even if one needs to create a new, entire
distribution system, there are still many advantages of using OSGI
Remote Services...e.g. the service registry's graceful handling of
dynamics inherent in a network-based service, versioning, discovery, and
the ability for service creators and perhaps more importantly service
consumers to ignore some of the subtle and difficult aspects of
distribution (e.g. partial failure, timing, etc). I do think that
standardizing these advantages and having many implementations will over
time make it easier to build, use, understand, and manage distributed
applications.
Returning to RS implementations: The approach ECF has taken (since
well before the Distributed OSGi rfc and RS/RSA standardization) has
been protocol neutral. As such we have gone to the trouble of creating
extensible APIs for various types of network communication: e.g.
filetransfer, instant messaging, group messaging, voice over ip, network
service discovery, and remote services distribution (of course). For
each of these types, we have multiple protocol implementations, some
created by us (in open source), some created by others (in open source
or not). This is true, of course, for our OSGi Remote Services
implementation, and it's distribution and discovery subsystems...as I've
said we have a number of providers that are based upon tcp and we have
providers that are based upon http and REST. But more importantly (I
think), we are trying to support the creation of hopefully many
other/new providers, created by others...possibly extending those that
already exist...that meet their needs for app-specific non-functional
requirements, new/popular application areas (like IoT) for distributed
applications.
The way that we do this with a multi-provider/multi-protocol approach is to:
0) Fully implement the latest specs an test for compliance
1) Define stable, extensible, open APIs for distribution and discovery
(e.g. 'remote services api' -> distribution, 'discovery api' ->
discovery), and maintain/enhance these APIs.
2) Re-use existing work to create stable, extensible, open provider
implementations for these types (e.g. ecf generic, http/REST, r-osgi,
jms, mqtt, etc)
3) Do what we can in open cooperation with the community to document and
provide examples for both 1 and 2, as well as document how to create new
providers [2], and analyze the runtime characteristics of existing
providers.
4) Engage the community (commercial and open source) to drive 0-3
forword in the directions that are most needed, and get support for
these efforts via new committers, contributors, collaborators, and
supporters [3].
5) Provide the support for the community in doing all of the above
Are we resource-limited? Yes, unless you consider the community. Is
there more to do? (particularly around documenting individual
providers)? Yes. My comment is that in today's software world I don't
think these answers are particularly uncommon ;-). [4]
Scott
[1]
https://wiki.eclipse.org/Tutorial:_Building_your_first_OSGi_Remote_Service
See section: Service Host: Register and Export the Service
[2]
https://wiki.eclipse.org/Tutorial:_Creating_a_RESTful_Remote_Service_Provider
[3] https://projects.eclipse.org/projects/rt.ecf/who
[4] https://www.eclipse.org/ecf/NewAndNoteworthy_3.10.0.html
>
>
>
> On 02/06/2015 16:08, "Scott Lewis" <sl...@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-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Newbie question related to device communication
Posted by Bruce Jackson <Br...@myriadgroup.com>.
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" <sl...@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-unsubscribe@felix.apache.org
>For additional commands, e-mail: users-help@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.
Re: Newbie question related to device communication
Posted by Scott Lewis <sl...@composent.com>.
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Newbie question related to device communication
Posted by 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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Newbie question related to device communication
Posted by Scott Lewis <sl...@composent.com>.
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.fleur@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 <nj...@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Newbie question related to device communication
Posted by Simon Kitching <si...@vonos.net>.
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.fleur@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 <nj...@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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Newbie question related to device communication
Posted by Sebastiaan la Fleur <se...@gmail.com>.
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.fleur@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 <nj...@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?
>> >
>> > I did come across something called SIP but it seemed fairly
>> comprehensive for my goals.
>> >
>> > Thanks in advance!
>> >
>> >
>> > Sincere Regards,
>> >
>> > Sebastian
>>
>>
>
Re: Newbie question related to device communication
Posted by Sebastiaan la Fleur <se...@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 <nj...@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?
> >
> > I did come across something called SIP but it seemed fairly
> comprehensive for my goals.
> >
> > Thanks in advance!
> >
> >
> > Sincere Regards,
> >
> > Sebastian
>
>
Re: Newbie question related to device communication
Posted by Neil Bartlett <nj...@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?
>
> I did come across something called SIP but it seemed fairly comprehensive for my goals.
>
> Thanks in advance!
>
>
> Sincere Regards,
>
> Sebastian