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 <mailto:gr...@wonderly.org>
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 <mailto:tvho...@googlemail.com>
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 <mailto:j...@zeus.net.au>
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 <j...@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.
