karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Red Hat" <bradj...@redhat.com>
Subject RE: Karaf IoT
Date Wed, 04 Jan 2017 20:02:43 GMT
Not yet…I’m trying to find out if there are existing projects that might be interested
or already working on either Karaf or appropriate OSGi services for boards, sensors and actuators.
 It certainly is a project I’ll set up if there isn’t any interest elsewhere.  Kura might
not be the place for it and while Karaf/Felix is important to me, it can leverage the existing
Kura bundles without necessarily being a part of that project. So I’ll definitely be involved
in some Karaf deployment/implementation mechanism.


I did post on the Kura forum today asking about interest.  Part of what drives this is going
to be their mission statement and interest. At the very least, for the project to be useful,
the board level device concerns and configurations have to be abstracted behind service and
service factory interfaces for the supported boards and their devices. The sample code on
the Kura project shows some abstraction levels that would be appropriate for creating sensor/actuator
bundles but it needs to hew to OSGi idioms more. That obviously isn’t a Karaf specific concern
but is an OSGi library concern that we all share. I really want to make sure I’m not coming
off as busting on the Kura project here.  It is based on Pi4j which has support for a lot
of different boards.


This code sample appears to have the sort of abstraction I’d expect a sensor/actuator driver
bundle to use. A developer or manufacturer interested in providing an implementation bundle
for a specific sensor or actuator can inject the DS ModBus service and bind to it. It is still
showing pin and register level access though which binds it to a specific board implementation
as far as I can tell.



By contrast this sample is calling across classloaders to a device manager and explicitly
setting pin configuration instead of configuring it at a board level, exporting as a service,
and injecting it into a consumer bundle. That configuration is board specific and should be
tucked away, done solely via configuration and exported.  



Those board level bundles should be exporting services and service factories that are purely
set up via configuration.  That permits the intermediary bundles for sensors and actuators
to bind to them without configuring them.  The configuration of the pins/services should be
associate with the board level bundles.  Moving from one board to another should be a simple
matter of changing board level configuration without requiring modifications to sensor/actuator
bundles and especially without changes to application level bundles that use sensor/actuator
service interfaces.  (Yeah, life is never that simple but it’s a good goal I think).


The injection of services like GpioPin might use LDAP filtering for export and import (or
other mechanism so that pin numbers and configuration are not exposed.) Moving from board
to board then is matter of configuring the board level exports to set up pins and expose them
as services with via a given name.


And Karaf 4 is a spectacular way to zip an application and all its dependencies for deployment.
 Once some service interfaces for sensors and actuators are developed, then simulators for
those could be created permitting easy development of applications on the desktop.  Perhaps
those would also provide reference implementations for developing tests suites against that
driver manufacturers could use to determine if their sensor or actuator bundle actually complies
with the standard.







From: Jason Pratt [mailto:jpratt3000@gmail.com] 
Sent: Wednesday, January 4, 2017 12:05 PM
To: user@karaf.apache.org
Subject: Re: Karaf IoT


scott/brad do you guys have a repo setup for this project?


On Wed, Jan 4, 2017 at 9:39 AM, Brad Red Hat <bradjohn@redhat.com <mailto:bradjohn@redhat.com>
> wrote:

I'll certainly look at that a bit more. My concerns about Kura project have
as much to do with the project's level of abstraction and I can bring it up
there.   I did ask about their intentions with service interfaces.  As I've
dug into it deeper and thought about "the vision thing", to quote a US
president, I laid out some of those thoughts.


Because it is an Eclipse project I wasn't sure that they'd be interested in
Karaf/Felix but can check. I've heard that they have, in fact, opened a Jira
ticket about it. So they may be interested.

It isn't just about a Karaf implementation although it is certainly about
that as well. I'm also concerned about the intermediary libraries/services
that abstract developers away from low level details of pin outs in order to
make application code portable.

Obviously the intermediate level concerns really don't belong with Kura or
Karaf so I won't discuss those here.  Suffice it to say I'd like to see that
intermediate set of libraries become a "sticky" place where developers and
sensor/actuator manufacturers go to add new high level device specific
bundles for use in applications.


-----Original Message-----
From: Scott Lewis [mailto:slewis@composent.com <mailto:slewis@composent.com> ]
Sent: Tuesday, January 3, 2017 9:33 PM
To: user@karaf.apache.org <mailto:user@karaf.apache.org> 
Subject: Re: Karaf IoT

On 1/2/2017 11:35 AM, Brad Red Hat wrote:
> I certainly understand the "short of time" problem. It just happens
> that I have a bit of a window right now and would like to get into it a
bit deeper.
> Whether a Karaf/PAX/Felix implementation is more appropriate under the
> aegis of Kura or as a separate project that leverages the Kura driver
> bundles is hard to say.  I guess that would depend on a couple of things.
> 1. How amenable they are to a more top down approach that starts with
> OSGi service mechanics and drives down to meet the driver bundles?
> 2. Does an Eclipse foundation project have any interest in an Karaf
> branch project?

The ECF project would be interested in such an effort [1].  We have been/are
distributing our impl of the OSGi Remote Services/RSA specs [2] as Karaf
features [3] and have recently been exploring using remote services for
Karaf management [4].

Also, in my interaction with some of the Kura committers it's become clear
that they are doing some prototyping of running Kura services on
Karaf [5].   I don't know whether they have release plans around that
work, but I know that it has been going on.   It might be useful to
convey to them directly what your desires/criticisms are, and perhaps
contribute to that work.


[1] http://www.eclipse.org/ecf
[3] https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf
[4] https://wiki.eclipse.org/Karaf_Remote_Management_with_Eclipse
[5] https://dev.eclipse.org/mhonarc/lists/kura-dev/


View raw message