Ok. Given this approach, it sounds like reaching out to the IoT community would be a good step. Identify some of the more popular device protocols, coordinate with the communities for those devices/protocols, introduce discovery for those devices/protocols in river, and do some outreach in those communities with some IoT examples.
One of the projects that we (Systap, LLC) support on the blazegraph (graph database) platform is the wiki data query service. There might be an opportunity for an interesting mashup of IoT and knowledge graphs. Thanks, Bryan On Aug 31, 2015 4:06 AM, "Peter" <j...@zeus.net.au> wrote: > On 30/08/2015 9:50 PM, Bryan Thompson wrote: > >> Peter, >> >> I like the solution. I have two questions. One related to the radmap. The >> other related to river and IoT. >> >> First, this a 3.1 release road map issue? >> > > Yes. > > > It would be nice to be able to >> move to a 3.0 now and have a development road map for 3.1. >> >> Second, there are a lot of devices and protocols propagating in the IoT >> space. Do you have a sense of what percentages of these devices any of >> these are running embedded java? >> > > I don't think there are many. > > I have been playing with IoT mainly >> through microcontrollers. At least hobby end of that market the devices >> are >> running C, squirrel, etc. So one question I have about making river >> relevant to IoT (which would be a killer use case) is how to manage >> communication with devices running other languages. Could this be done in >> the language binding or would there be protocol translation services >> hosted >> in the river fabric. >> > > River has RMI IIOP endpoints for multi language interop, however these > still use compiled stubs. Glassfish uses dynamic RMI IIOP proxy's that > don't require codebase downloads, we'd probably also want to investigate > TSL. > > However I think that surrogate services designed for protocols, such as > MQTT, MQTT-S and CoAP, may be more appropriate. So we could use a > surrogate service, that automatically discovers such devices, and registers > them with the lookup service. > > Where the service proxy is the bridge or adaptor. > > Regards, > > Peter. > > Right now IoT has device silos. Different kinds of devices can not directly >> commnicate. A variety of services exist to allow data logging and >> centralize event triggers and the like, but they are not open >> architectures, at least not that I have found. If river can offer cross >> device relevance and an open architecture for IoT that would be a very >> interesting capability. >> >> Thanks, >> Bryan >> On Aug 30, 2015 7:09 AM, "Peter"<j...@zeus.net.au> wrote: >> >> I finally had the chance to look through the org.apache.river name change >>> work Dennis Reedy has done, it all looks very impressive, he's even taken >>> the time to tidy up the qa suite. I haven't had time to run any tests or >>> look at the jtreg test suite, I promise I'll make some time in the near >>> future. Before we release this code there is an opportunity to tidy up >>> the >>> org.apache.river name space even further. In the Jini days, >>> com.sun.jini.* >>> was implementation code, it wasn't part of the Jini public API, should we >>> now use org.apache.river.* for this purpose? There is some new public >>> api, >>> in org.apache.river.api.* and at the time new implementation code was >>> being >>> placed into org.apache.river.impl.* and now the com.sun.jini.* namespace >>> has been moved to org.apache.river.*. Should we consider placing the new >>> api in the net.jini.* namespace? It's worth looking at the javadoc as >>> most >>> of the new classes are package private. There are also discovery >>> constraints in the implementation namespace that should be moved into the >>> public api in my opinion, thoughts? >>> >>> IPv6, for River, this is big, IPv6 has auto network configuration, >>> powerful multicast abilities, IPSec and no need for NAT. IPv6 is going to >>> allow our existing discovery protocols to work over the internet. >>> >>> The examples project looks promising, I like how Greg Trasuk has >>> structured the examples into api, server and clients, Greg has done a lot >>> of work to tidy this up. Our existing example code is relatively old, I >>> did >>> notice some bad practices by current standards as a consequence. If we >>> want >>> to reduce our support burden, we should encourage new users to use best >>> practise. >>> >>> The issue that stuck out the most was letting 'this' escape during >>> construction. All River service implementations now implement the Starter >>> interface to avoid letting 'this' escape during construction, however >>> since >>> there are a number of downstream “Container” projects and there was >>> controversy surrounding the start method; if someone wants to propose >>> something less controversial for user examples, please do so, hopefully >>> it >>> won't upset anybody still clinging to unsafe publication. >>> >>> On the topic of “Letting 'this' escape”, because readObject methods >>> behave >>> like constructors, the jvm performs a final freeze after the readObject >>> method completes, however there are a number of places where River lets >>> 'this' escape during deserialization, I did have some solution options >>> for >>> this, including a better way to deserialize... >>> >>> I try not to discuss River security after another developer raised >>> concerns it was scaring off new developers. I'm going to take the liberty >>> to discuss security and performance briefly. >>> >>> Some points: >>> >>> * >>> >>> IPv6 will enable River to traverse the internet, easily. >>> >>> * >>> >>> IPv6 is plug and play – autoconfiguration of network devices. >>> >>> * >>> >>> River is well positioned for the internet of things, but needs >>> IPv6. >>> >>> * >>> >>> IPv4 NAT is pretty much what killed the Jini iot tech 20 years >>> ago, as Jini was distributed, not centralised, web services have >>> grown up around this centralised model. >>> >>> * >>> >>> River security isn't ready, our crypto protocols need updating and >>> proxy trust is currently flawed. >>> >>> >>> The issue with proxy trust: >>> >>> * >>> >>> We can discover a lookup service securely. >>> >>> * >>> >>> We can't connect to services securely, service proxy's are >>> downloaded and deserialized before trust is established. >>> >>> >>> Don't despair, the security issues are easily fixed. >>> >>> Back in the early days, Jini used RMI and RMI used skeletons and stubs. >>> The stubs had to be downloaded, so you always had codebase downloads. >>> Now, >>> codebase downloads aren't always required, but the lookup service >>> implementation, is still designed around codebase downloads. >>> >>> When security was enhanced in Jini 2.0, we were given the concept of a >>> bootstrap proxy, which is just a reflective proxy that doesn't require a >>> codebase download. So what does River do, it downloads a codebase, >>> deserializes a service proxy and then requests a bootstrap proxy from it. >>> At this point in time the river client authenticates the service, then >>> River asks the bootstrap proxy for a TrustVerifier instance to check the >>> service proxy, permissions are dynamically granted (but how do we know >>> what >>> permissions are required?) and method constraints are applied. This is >>> called proxy preparation and it's a configuration concern, as are the >>> exporters. Yep this is a complex processs. >>> >>> How could this flaw be fixed without impacting the client? >>> >>> Easy, the lookup service shouldn't contain the service proxy, only the >>> bootstrap proxy. Guess what, big performance increase, just like delayed >>> codebase downloads, thank you Gregg Wonderly, for identifying and >>> trailblazing that path at least a decade ago. >>> >>> During proxy preparation (a process determined by configuration), instead >>> of asking the service proxy for a bootstrap proxy, the lookup service >>> should only contain the bootstrap proxy and clients obtain the service >>> proxy from it, after authentication, constraints are applied, permissions >>> granted to the proxy and the process is complete. This is much simpler >>> than >>> our current proxy trust establishment. Less serialization overhead, less >>> network traffic, more performance. A configuration flag could restore the >>> old behaviour of course. >>> >>> The client is none the wiser, it still receives a fully prepared and >>> constrained proxy. All River services already implement >>> ServiceProxyAccessor, although part of the start package, it's an >>> interface >>> that provides access to the service proxy. >>> >>> We only need a new Exporter (easy) that creates the bootstrap proxy and >>> ensures it doesn't implement any interfaces that would require a codebase >>> download. >>> >>> Then when a service is registered with a lookup service, Reggie obtains >>> the bootstrap proxy from the exported service proxy in the client jvm. >>> >>> It also means the entire process is simpler, developers no longer need to >>> learn the complex TrustVerifier process as it becomes an Endpoint and >>> system concern. >>> >>> Thoughts? >>> >>> Regards, >>> >>> Peter. >>> >>> >>> >>> >
