Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Kura » Higher level APIs(APIs to decouple various implementations.)
Higher level APIs [message #1741796] Mon, 29 August 2016 16:41 Go to next message
Brad Johnson is currently offline Brad JohnsonFriend
Messages: 6
Registered: August 2016
Junior Member
I think the Kura project is great and will certainly be working with it.

I'm wondering if there's been any thought about higher level API abstractions. I'm thinking of things like interfaces for various sensor and actuators that use standard canonical models. The models might even be described through interfaces and not provide concrete implementations.

As an example, if I'm a manufacturer of an RFID reader/scanner my implementation may be very different from other makers. So if there was an RFIDEventSource interface that registers services that implement RFIDListeners that receive RFIDPackets, then switching from one implementation to another shouldn't change the code that uses it.

Because OSGi bundles can hide their implementations that would make versioning and export of the service interfaces quite easy. Each manufacturer or open source group would be responsible for the data conversion necessary to return an RFIDPacket. If a particular manufacturer's underlying implementation used a different connector type, the OSGi developer could be blissfully unaware of it.

If some sensors receive data is received while others have to implement polling to achieve a similar effect, again I wouldn't care from a programmatic standpoint (although the properties configuration might need tweaking (to change a pin number for example.)

At that point as users and developers we don't care about the underlying connector type or whether the data read from the device is received from the JNI stub. We just care that the implementation transforms the data and can receive listeners that it sends the appropriate data to.

This would also permit standardized certification tests. If manufacturer A creates a bundle for their RFID reader it has to accept listeners and fire events with the expected data.

Since different board might have different pin outs and the manufacturers actual C driver implementation might read different devices, the could easily provide properties for configuration with all the commonly supported boards.

As the project gains in adoption it would eventually force manufacturers to provide implementation bundles for their. After getting enough response like, "oh, you don't provide an OSGi Kura implementation for your device? Sorry but that's our standard", the manufacturers would be motivated to make that happen.
Re: Higher level APIs [message #1741824 is a reply to message #1741796] Mon, 29 August 2016 22:08 Go to previous messageGo to next message
David Woodard is currently offline David WoodardFriend
Messages: 420
Registered: July 2014
Senior Member
Hi Brad,

I commented in another post, but I will repeat here. I agree with you, having this sort of abstraction for Eclipse Kura would be great. However, as a general construct, we try and keep Kura as light of a framework as possible. There are just too many verticals in the IoT space to try and make a generic API layer like you describe. However, if you are working with RFID for example, it would be great if you could simply grab an "add on" that enabled Kura for RFID.

We have recently added Eclipse Kura to the Eclipse Marketplace. Eventually we will add all of our example projects there, but libraries like you describe may also fit well. If this is something you would like to contribute, let me know, I would be happy to work with you.

Thanks,
--Dave
Re: Higher level APIs [message #1750921 is a reply to message #1741824] Mon, 02 January 2017 01:41 Go to previous messageGo to next message
Brad Johnson is currently offline Brad JohnsonFriend
Messages: 6
Registered: August 2016
Junior Member
I'm finally in the position where I may be able to start working more with the framework and libraries. I agree that there are far too many verticals out there that might make for an explosion of possible implementations. Perhaps something outside the Kura project or even a sub-project would be appropriate. I'm really thinking of a set of API interfaces that could be used via OSGi services and not concrete implementations. Very basic API interfaces could then be extended by more specific interfaces. A simple example would be something like an LED where one might have a Toggle interface, Range interface and an Output interface extended by the LED interface. Note that none of the actual configuration details or mechanisms are exposed. But if I inject an LED OSGi service into my bundle then I'm not as concerned about the configuration values since they are abstracted away. I'm making those APIs up off the top of my head so take them with a grain of salt. The Range API might simply specify a method that takes a number from 1 to 100. In the case of the LED that might map in a configuration file to various values for each.

But when develop an application I would simply call on(), off(), toggle(). Or I might call setRange(50) to set the value to 50%. Obviously if there isn't an implementation for the OSGi service exposed that way then nothing will happen. But I don't care about the voltage or any other concrete configuration settings in my code. I can swap different components in and out and my code, via the interface, simply sets the value to 50% or toggles on/off.

Your example of the RFID is another good case in point. One really can't specify all the possible mechanisms of an RFID sensor. In this case it is likely my bundle would implement some RFID sensor listener interface that I register as an OSGi service to be picked up by the concrete implementation of the sensor/reader provided by the manufacturer. They would then send events, perhaps, based on triggered values. Perhaps there could be normalized values expected in those events that the manufacturer (or whoever implements) would have to map.

If I have a FooCorpRFIDSensor implementation bundle it may well have a lot of other methods on it. But if I have an application that registers as a listener for RFID sensor events then I should be able to switch from a BarRFIDSensor to a FooRFIDSesnor without changing my code. That would usually mean that the RFID sensor listener interface would only have a small subset of what RFID sensors might provide. In the case of a listener service, in fact, it would receive an event that implements RFIDSensorEvent that would return some basic data but might well have a lot of other data that it carries with it. While that might entail casting the RFIDSensorEvent to a specific type of RFIDSensorEvent that is a child interface or event to a FooSensorEvent in order to get the requisite data, the OSGi registration mechanics would not change.

Setting up these sorts of API bundles would also help enforce the encapsulation of the implementation classes. My FooRFIDSensorEventImpl shouldn't be exposed or importable by another bundle. The FooSensorEvent interface would be and the interface it extends would be as well.

I say these concrete implementations would be implemented by the manufacturers. That would likely come in time if the framework becomes very popular. Obviously that can have a cascade effect over time as implementations of the APIs provide springboards for other implementations.

At the basic level then one might have two standard API bundles - sensor and actuator. Those APIs interfaces would all be public. Implementations could extend interfaces from either or both while keeping implementation details nicely tucked away. That would definitely help facilitate semantic versioning of bundles as implementations are hidden and prevent developers from coupling to their code to them.
Re: Higher level APIs [message #1750935 is a reply to message #1750921] Mon, 02 January 2017 12:46 Go to previous messageGo to next message
Brad Johnson is currently offline Brad JohnsonFriend
Messages: 6
Registered: August 2016
Junior Member
As I'd imagined this the only thing in the Kura project related to the various sensor and actuator types would be the API/interface bundle(s). No implementations.

The implementations would be separate bundles accessible via Maven coordinates. There might be a reference implementation or implementations. For example, a GenericRFIDSensor bundle might exist that implements the interfaces in a rudimentary fashion.

The other thing that having the sensor/actuator APIs provides is the ability to have unit tests with mocks and stubs. I could mock the RFIDSensor and inject it into my class during unit tests and verify expected results or fire expected invocations or events.

If the project becomes a big success then individual manufacturers would take that GenericRFIDSensor implementation and use it as an example of how to implement the required elements for a bundle that supports their product.

In fact, the "reference implementations" could be nothing more than unit tests that use mocks for the service interfaces. No true implementation would exist. But if anyone wanted to contribute or if a manufacturer wanted to provide an implementation, a benchmark cum certification suite would exist to verify that their implementation met baseline standards.

Brad
Re: Higher level APIs [message #1796790 is a reply to message #1750935] Fri, 19 October 2018 01:22 Go to previous message
Hayrol Reyes is currently offline Hayrol ReyesFriend
Messages: 1
Registered: October 2018
Junior Member
Hi Brad and David... I know this is an old post, but is there any work done on this field?, or was there other way to implement RFID readers/scanners on Kura?

I am pretty interested on LLRP protocol for this field.

Regards,
Previous Topic:adding a plugin to the target definition
Next Topic:Deployment package plugins already installed
Goto Forum:
  


Current Time: Mon Dec 09 04:15:56 GMT 2024

Powered by FUDForum. Page generated in 0.03358 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top