river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Don't let Jini Standards become an impediment to development
Date Sun, 06 Sep 2015 11:41:16 GMT
On 5/09/2015 1:49 AM, Greg Trasuk wrote:
>> On Sep 4, 2015, at 5:26 AM, Dawid Loubser<dawid@travellinck.com>  wrote:
>> And given the vision, experience and efforts of people like Peter, it
>> would almost be criminal to not break free from an old standard, to miss
>> the potential of what may be.
> Speaking of which, I’ve always wondered, Peter, if you could tell us a little about
the Jini systems you’ve built and worked with in the past, and some of the issues you’ve
seen in production?  It would be great if we on the list could share some experiences - that
would highlight areas where the standards get in the way, and we could change them.  We are
the standards body for Jini, after all.

I can't say I've run data centres filled with Jini systems.  I haven't 
experienced difficulties writing or deploying services, although I don't 
do this on a large scale, however I've had trouble with security policy 
files and proxy trust.  I don't like using URL's for policy files, so I 
created a policy service.  I've included the service api for the policy 
service in org.apache.river.api.security.RemotePolicy

Basically when a node starts, it registers a RemotePolicy service with 
the lookup service, an automated admin client receives an event, 
contacts the service and populates it with its security policy.

The RemotePolicy service requires the policy provider to implement 
org.apache.river.api.security.RevocablePolicy.  In this case the 
implementation of the RemotePolicy service hasn't been contributed, 
however it is pretty obvious how it works.

The abstract class, org.apache.river.api.security.PermissionGrant, is an 
object version of the grant statement in a policy file.  The 
implementations of this class are package private as is the serial form 
of these classes.

Unlike PermissionCollection, PermissionGrant's are immutable, they're 
used in all River policy implementations.  The class allow 
PermissionCollection's to be created on demand, with all the latest 
dynamic and static grants, ordered optimally to eliminate unnecessary 
permission checks.

Since policy implementations are nested, another interface, 
org.apache.river.api.security.ScalableNestedPolicy allows the top level 
policy to collect all PermissionGrant's from underlying policies, before 
creating an optimally ordered PermissionCollection for policy permission 
implies checks.

These interfaces and classes make it much easier to manage security 
policies, belonging to to an administrator in a shared djinn.  Each 
administrator can idenfity their services, using an Entry, then filter 
appropriately.  The RemotePolicy service only uses a bootstrap proxy, no 
codebase is downloaded.  It is recommended to use secure endpoints.  
Calls executed on the RemotePolicy service are run with the 
administrator's subject.

For services that are Activatable, or require a thread after 
construction is completed, an interface 
org.apache.river.api.util.Startable, is provided, if a service 
implements this interface, Phoenix, or the start package will call it 
after constructing the service.  Jini was never updated to Java 5, in 
this version of Java, the JMM was updated, I think if the original Jini 
team had done so, they would have done something like this.  It's the 
simplest and safest way of exporting a service after construction, 
although the Startable interface doesn't just provide for safe 
exporting, it can be used to start threads or utilities the service uses 
after construction as well.

When an object is instantiated, the jmm guarantees a memory fence will 
occur that ensures that all threads will see the fully constructed 
object.  When an object allows a reference to itself to escape during 
construction, there is no guarantees that other threads will see the 
fully constructed object.  For synchronized access to fields, all 
accesses must be synchronized, so even if another thread uses 
synchronization, if the object wasn't safely published there's no 
guarantee that a thread will see the fully constructed object.

I've found the best place to discuss the JMM is the concurrency interest 
mail list.

The final thing I wish to discuss, is the new classes ing 
org.apache.river.api.net.* RFC3896URLClassLoader and Uri.

Uri is a RFC3986 compliant Uri, it isn't Serializable and since it is 
based on the RFC3986 standard it is also not going to change.  This 
class is relevant throughout River, from normalization of codebase 
annotations to replication of Codebase.implies functionality.  Uri, 
unlike java.net.URI (RFC2396 based) it is fully compliant with the 
standard and doesn't extend it, this is very important from a 
performance perspective, as bitshift operations can be utilised during 

RFC3986URLClassLoader, uses URL's that are parsed to be compliant with 
RFC3986, this is to avoid DNS calls in java.security.SecureClassLoader, 
this is both for performance and security reasons.

I'd like to see these classes added to the public api, anyone that uses 
URLClassLoader with network URL's should use RFC3986URLClassLoader 
instead.  Uri will have even more relevance for Java 9, since modular 
codebase annotations in Java 9 will be RFC3986 compliant.  Talking to 
the devs on OpenJDK, they've tried making java.net.URI RFC3986 
compliant, but it causes test failures for them, also because 
java.net.URI extends the previous standard, their RFC3986 version will 
probably also need to, so they'll miss out on some serious performance 
benefits provided by bitshift operations.

As for the future, once I have security sorted, I plan to make publicly 
available, a lookup service on IPv6, using the discovery announcement 
protocol over IPv6 multicast.  Here people will be able to register 
their own services and others will be able to use them.  The advantage 
that River has over web services is it's distributed, unlike its web 
service cousins that are client-server based.   For instance, the cloud 
is client server based, with resources in a data centre.   In the 
distributed model, nodes can both consume services and provide them.

As for problems with the standards, I'd suggest the proxy trust model is 
overly complex, I'd like to revise it.

Otherwise there is a lot to like and a lot of well thought out designs, 
but there are some parts that time has not been so kind to, that need 
repairing by modern standards.



> For myself, the big issue was always ease of writing and deploying services, which is
why I wrote the Harvester application container back in the day, and the River Container (which
I really must get around to thinking up a new name for) more recently.  When you get more
than a few machines involved, things get complicated to manage, although I haven’t done
a system big enough to show the kind of QOS issues that Dennis’ Rio project was designed
to address.
> Cheers,
> Greg Trasuk

View raw message