I think one of the primary focuses, that would be well received and have a lot of traction, would be a JSON based message structure without any object serialization and use an HTTP or HTTPS based/restful endpoint. The basic fact is that this would allow “Jini” to interoperate with lots of things.
For the “internet of things” marketplace, there should also be MQTT messaging support. Yes, this can start to eliminate the whole mobile code mechanisms over serialization, but in the end, we have more and more indication that OSGI, Maven and many other “versioning/distribution” mechanisms can make code available dynamically without having to “wire” that up ones self. Gregg Wonderly On Feb 15, 2014, at 12:45 PM, Greg Trasuk <tras...@stratuscom.com> wrote: > > (cc’d to user@ for discussion) > > Not sure about a research branch - I’d like to focus on making it easier for > developers to use River in real applications, so I’m hesitant to do anything > that diverts attention from that. On the other hand, we should perhaps try > out some things. On yet another hand, I’m not sure if easier deployment is > necessarily backwards-incompatible. I’d love to hear more opinions. > > I wonder if we can just discuss the idea of removing activation and JRMP > support from trunk? > > For me, JRMP is a no-brainer - the functionality is much better covered by > JERI. I think JRMP was only there for backwards compatibility to Jini 1.2 > services. > > Activation is a little more difficult question. Personally I’ve never used > it, and I suspect the rationale for it (maintaining service availability in > restricted environments) is not so strong these days. We generally seem to > be OK with leaving services running all the time - that’s the deployment > model for XML- and REST-based SOA. > > So I’d be fine with just dropping support for JRMP and activation, but we > should hear more opinions. > > Something I would like to see is a messaging-based channel for JERI. > Something like JERI-over AMQP (i.e. using a QPID server). AMQP is gaining > traction in the financial industry (it originally started out at JP Morgan > Chase), but the challenge as with any messaging protocol is how to structure > the messages. I’ve seen Google Protocol Buffers used, but that seems > over-architected to me (and much like XML/SOAP, incurs a large development > overhead to get platform neutrality that is seldom actually used). I think > allowing for Jini would give the advantages of low configuration overhead, > but still give the low latency that AMQP promises. That also seems to fit in > well with a space-based architecture for load-balancing. > > Anyone else have thoughts on dropping JRMP and Activation, or on adding AMQP > endpoints? > > Cheers, > > Greg Trasuk. > > On Feb 14, 2014, at 10:52 PM, Peter <j...@zeus.net.au> wrote: > >> Any takers for a research branch to exlpore recent ideas? >> >> Was thinking about a subset of Jini, just the essentials, no activation, no >> JRMP support, forgetting backward compatibility to allow experimentation >> with new ideas and considering all possibilities. >> >> Regards, >> >> Peter. >
