river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: another interesting link
Date Tue, 26 Jul 2016 11:43:14 GMT
Perhaps a script that detects the environment, asks a few questions and creates the config
files?  These can be edited for more complex configurations.

I've added a couple of default methods to ServiceRegistrar, the new lookup method doesn't
return the service proxy's, so the registrar is basically used just for search, the client
then contacts each service it's interested in.

Starting off with simple services that only use dynamic proxy's (java.lang.reflect.Proxy instances),
avoids codebases.

Reggie still requires a codebase, however if we sign it, this addresses code trust.



Sent from my Samsung device
  Include original message
---- Original message ----
From: Tom Hobbs <tvhobbs@googlemail.com>
Sent: 26/07/2016 07:50:43 pm
To: dev@river.apache.org
Subject: Re: another interesting link

I would say the comment on that blog sums everything about Jini up. 

It’s just too hard to set up and get working. 

That’s why I think simplifying reggie is possibly a first step.  Make a /small/ and simple reggie jar that just handled service registration and not proxy downloading etc.  Make it really easy to register your services without needing class loaders etc, preferably via some convention rather than configuration.  (This is what I’m trying to find the time to work on.)

I’d really like to be able to type; 

$ java -jar reggie.jar 

And have a reggie running with all the defaults ready to register my services with.  Or perhaps, as an option;

$ java -jar reggie.jar —ipv6 

Security, class loading, proxy downloading and all the rest of it could then be put back in by specifying more advanced configuration options.

My Scala service would be great if I could define it just as; 

object MyCoolService extends LazyLogging with ReggieRegistration with ReggieLookup

Or in Java with default interface methods; 

class MyCoolService implements ReggieRegistration, ReggieLookup 

And that would be it, congratulations you’ve started a reggie and registered your service and have methods available to help you find other services.

This would satisfy use cases where the network was private and/or trusted.  And security on top would, ideally, be up to configuration again or perhaps injecting some alternative implementation of some bean somewhere.  But the core premise is, make it easy to startup, demo and see if it fits what you want it for.  

> On 26 Jul 2016, at 02:58, Peter <jini@zeus.net.au> wrote: 
> Note the comment about security on the blog? 
> Steps I've taken to simplify security (that could also be adopted by river):

> 1. Deprecate proxy trust, replace with authenticate service prior to obtaining proxy.

> 2. proxy codebase jars contain a list of requested permissions to be granted to the jar signer and url (client need not know in advance).

> 3. Policy file generation, least privilege principles (need to set up command line based output for admin verification of each permission during policy generation).

> 4 Input validation for serialization. 
> 5. DownloadPermission automatically granted to authenticated registrars (to signer and url, very specific) during multicast discovery.

> Need to more work around simplification of certificate management. 
> Regards, 
> Peter. 
> Sent from my Samsung device. 
>   Include original message 
> ---- Original message ---- 
> From: Peter <jini@zeus.net.au> 
> Sent: 26/07/2016 10:27:59 am 
> To: dev@river.apache.org <dev@river.apache.org> 
> Subject: another interesting link 
> https://blogs.oracle.com/hinkmond/entry/jini_iot_edition_connecting_the 
> Sent from my Samsung device. 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message