[kura-dev] namespaces and remote services

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Kura devs,

I just watched with interest a video from recent EclipseCon on 'Advanced 
MQTT and Kura: Best Practices for Topic Namespaces in M2M Applications" 
[1].  I enjoyed the talk.

One thing that I thought I would point out that may be useful to the 
Kura team...since you are apparently using OSGi/OSGi services...and MQTT 
for inter-process communication.

OSGi remote services (chap 100 in enterprise R4.3+ spec) provides a 
means to make arbitrary OSGi services available remotely.  Like all OSGi 
services, these remote services are semantically described by java 
interfaces and the classes they reference...e.g:

public interface MyActuatorConfigurator {

    public IStatus getStatus();
    public IStatus executeCommand(String commandId);

(I'm obviously making these up...but this is just meant to be 
representative)

}

The OSGi remote services spec specifies the behavior of a distribution 
provider...which...using some unspecified/implementation specific means 
of inter-process communication...makes instances of 
MyActuatorConfigurator (or any other service) available to 
remotes...which can...using all the normal means of acquiring OSGi 
services (e.g. ServiceReference, ServiceTracker, DS, blueprint, etc) get 
a proxy constructed by the distribution system...and then use that proxy 
at the application level (i.e. call the getStatus() and/or 
executeCommand methods). Particularly because of the dynamic nature of 
OSGi services, this works very nicely with remote services...which are 
inherently more dynamic (e.g. because they can become unavailable due to 
network failure).  Note that all of the association between serviceIds, 
bundleIds, endpoint/remote service ids and the actual implementation of 
MyActuatorConfigurator is managed by the distribution provider...making 
it very easy for consumers to get/track/release the service instances 
they want without having to have a lot of information.

Three other things that are particularly nice about OSGi Remote Services 
(IMHO) is that it a) takes into account/allows for versioning of the 
service interface...along with multiple versions of a single service 
type;  b) it's very easy to use existing OSGi classes to represent 
network failure (i.e. ServiceException) and; c) has very flexible 
service-level security (e.g. package and/or service ServicePermissions).

Anyway...the above is specified via OSGi Remote Services/RSA.  None of 
what's described above is implementation-specific.   We/ECF have a full 
compatibility-test-suite-compliant impl of these specifications [2].    
There are other impls as well:  one is Apache CXF...and there are others.

One thing that I believe distinguishes ECF's impl, however, is that we 
have an open, extensible, community-hardened APIs that allow new 
distribution providers to be easily created...either by extending 
existing providers, or by creating completely new ones.  There's a brief 
tutorial doing this...by creating a REST/http-based+json provider...here 
[3].   There are a number of these providers that we have already 
created (ECF generic, r-osgi/http, REST-based provider, XML-RPC, JMS, 
JavaGroups, Restlet/JAX-RS, etc)...but the one that is probably most 
interesting/useful in the m2m context is our relatively new MQTT 
provider (uses Paho 0.5.0 to implement) [4].

One reason I bring this up is that while watching this talk, it occurred 
to me that it would be very easy to 'wrap' what you have done (associate 
a MQTT topic with a remote service semantics) by defining some new OSGi 
remote services with desired semantics, and simply extending the ECF 
MQTT provider with new Namespaces (ecf's core APIS include extensible 
IDs/Namespaces).   Like all ECF APIs and their impls/providers, it is 
open/open source and so may be extended if desired.

One advantage such 'wrapping' would have is that your existing 
transport/wire protocol wouldn't have to change at all...and existing 
non-OSGi devices would simply use MQTT as they are now...alongside OSGi 
clients...that would have access to remote services (and yet would use 
the same underlying topics, namespaces, messages, as well as the MQTT 
protocol).

In any event I thought the above information...about OSGi Remote 
Services...and ECF's impl...might prove useful to Kura...since you are 
obviously using both OSGi (and therefore OSGi services), and MQTT...and 
ECF's open provider architecture does allow easy and standards compliant 
creation/customization of distribution providers...allowing you to 
easily expose your existing MQTT-based communications as 
standards-compliant OSGi Remote Services.

Thanks,

Scott

[1] https://www.youtube.com/watch?v=EA5j7c2SgqQ
[2] http://wiki.eclipse.org/ECF#OSGi_Remote_Services
[3] 
http://wiki.eclipse.org/Tutorial:_Creating_a_RESTful_Remote_Service_Provider
[4] http://www.eclipse.org/ecf/NewAndNoteworthy.html