Mailing-List: contact users-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@felix.apache.org
Message-ID: <556C8B5F.7080804@composent.com>
Date: Mon, 01 Jun 2015 09:42:07 -0700
From: Scott Lewis <slewis@composent.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: users@felix.apache.org
Subject: Re: Newbie question related to device communication
References: <5569928e.e15eb40a.431f.ffff9bcd@mx.google.com>
	<05F3DA0FF13D4429B43E207CC0E3E754@gmail.com>
	<CAD0paNUWnqKr4_U4vepNgcA6A1tbTDXR63kYU6s8DnZds2FVQA@mail.gmail.com>
 <CAD0paNXSvBN4GzvXEb_cTQ+Th6LCyEo_-Lp+uPxDfbE=P3GJUA@mail.gmail.com>
 <556C63E4.4060506@vonos.net>
In-Reply-To: <556C63E4.4060506@vonos.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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 <njbartlett@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