river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: another interesting link
Date Tue, 26 Jul 2016 16:13:56 GMT
Also maven has been used as part of this solution too.  Maven lookup by package instead of
interface seems like adding another layer or a redirection in lookup mechanisms.

Gregg

Sent from my iPhone

> On Jul 26, 2016, at 8:41 AM, Michał Kłeczek (XPro Sp. z o. o.) <michal.kleczek@xpro.biz>
wrote:
> 
> I am well aware of StartNow since that is the first Jini "support library" I have used.
Indeed - it is really easy to use.
> But it is only one side of the issue - the API and some support support code that is
supposed to be linked statically with the service implementation.
> 
> What I am talking about is actually "externalizing" most aspects of a service implementation
so that:
> - you do not have to package any (for some meaning of "any" :) ) libraries statically
(since all code can be downloaded dynamically)
> - you do not have to provide any (for some meaning of "any" :) ) static configuration
(ie. configuration files) - a service should simply use other services and "reconfigure" itself
when those change
> It would go towards some kind of an "agent architecture", with movable objects (ie "services")
being "hosted" by well... other movable objects :). The idea is less appealing today when
we have all the cloud infrastructure, virtualization, software defined networking etc. Nevertheless
still interesting IMHO.
> 
> Thanks,
> Michal
>> Gregg Wonderly July 26, 2016 at 1:28 PM
>> My StartNow project on Java.net aimed directly at this mode of operation a decade
ago. I wanted conventions that provided use of configuration with defaults.
>> 
>> You just extend PersistantJiniService and call start(serviceName). Subclasses could
override default implementation for how the conventions in the APIs created implementation
objects through code or configuration.
>> 
>> The intent was to create THE API to provide the conventions of service creation.
>> 
>> We have a Window/JWindow class and don't have to do all the decorating ourselves.

>> 
>> Jini service construction should work the same way!
>> 
>> Gregg
>> 
>> Sent from my iPhone
>> 
>> 
>> Tom Hobbs July 26, 2016 at 11:50 AM
>> 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. 
>> 
>> 
>> 
>> 
>> Peter July 26, 2016 at 3:58 AM
>> 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.
> 

Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message