On 5/09/2015 1:49 AM, Greg Trasuk wrote:
On Sep 4, 2015, at 5:26 AM, Dawid Loubser<da...@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
normalization.
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.
Regards,
Peter.
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
