A disclaimer: I accept SecurityManager will be removed, but I feel a few
words are in order before it's passing.
A little history:
Pre-1994, Bill Joy presented a proposal to Sun Labs where he
presented three main concepts:
1) a language that would run on all platforms,
2) a virtual machine to run this language, and
3) a networked system to allow the distributed virtual machines
to work as a singular system.
In 1995, the language and virtual machine were introduced to
the market as the Java Programming language and Java Virtual
Machine. The system context, however, was kept in the Sun R&D
for continued research and development. This system context
is Jini.
Reference: http://di002.edv.uniovi.es/~falvarez/whatisjini.pdf
This fit into Sun's vision: "The network is the computer."
The components of item 3 above, have presented significant technical
challenges, progress having been made at various times during Java's
history. Only in recent years have all the pieces of the puzzle come to
together to realize the original goal.
So it appears that Java 1.17 will remain an important version for many
years to come.
There are two types of scalability, vertical and horizontal.
Various OS platforms that support different CPU and GPU architectures,
clearly the vector API is an important component as are other recent
improvements.
IPv6 enables end to end connectivity, rather than IPv4's publish
subscribe, server client model and issues with NAT. Web services are
based on the publish subscribe model, with message passing. The Web
services push API gives web applications the ability to listen to
events. https://developer.mozilla.org/en-US/docs/Web/API/Push_API But
there remain issues with cross site request forgery's.
The glue is important too (which is what Jini is).
What are the key components:
1. JVM's installed on each node.
2. Dynamic class loading, with verification and type safety.
3. Network end to end connectivity (IPv6 adoption is currently 32%)
4. Privacy, Authentication and Identity.
5. Object Serialization protocols (Java Serialization is flawed).
6. Jini Extensible Remote Invocation (RMI isn't suitable due to class
resolution issues and limited extensibility).
7. Service architecture based on Interfaces.
8. Dynamic network discovery (IPv6 global discovery only recently added
https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml).
9. Ability to "join" specific groups on the network.
10. Lookup services (multiple, it's a common misconception there is only
one), to find services, as well as listeners to be notified when
services are added, removed or changed.
11. Network Transaction Service.
12. A powerful Configuration, that uses Groovy.
Why wasn't Jini a huge success when it was released in 1998?
1. It had some initial success, but class resolution was a big problem
http://sorcersoft.org/resources/jini/smli_tr-2006-149.pdf as
ClassLoader's added complexity that wasn't originally envisioned.
To solve this problem, instead of using RMIClassLoading for class
resolution and visibility, ClassLoader's are assigned at each
Endpoint and are completely responsible for class visibility and
resolution, so it works with non-hierarchical class loading systems
like OSGi.
2. Security wasn't added until 2002, combined with IPv4, it relegated
Jini to private trusted networks, in the age of the internet,
limiting it's appeal. This is no longer the case.
3. When Security was added, it had been assumed the Java Sandbox and
Java Serialization were secure, so authentication of services was
performed after class loading and de-serialization, ouch!
4. The security model, added unnecessary complexity in the form of
ProxyTrust (This isn't used today). We just authenticate first
now, ensure the connection is private and validate the code, then
let the code validate the input, to fail atomically, and this is
handled for the user, all the user need do is configure their
services to use TLS, and ensure their services runs with the login
Subject.
5. Objects were exported remotely via their constructors allowing
"this" to escape, prior to the Java 1.5 JMM, this was changed, an
interface called Startable allows services to be started after
construction, the same thing happens with Activation (Phoenix, not
RMI), which is basically a watchdog for services.
Sun later released Jini as open source under the Apache 2.0 license in
2007 and donated it to Apache who renamed it to River.
Remaining issues have taken about 12 years to resolve, all up it's
probably had 25 years of development.
http://nighthacks.com/jag/res/Fallacies.html
https://github.com/pfirmstone/JGDMS
If JAAS continues to function in later versions of Java, we will be able
to support them as server side services, but not as clients, without
SecurityManager, so it will always depend on the last version of Java
that contains a fully functional SecurityManager. Otherwise we fail the
6th Fallacy of distributed computing.
Still have a couple of things left to do, such as support pack200 for
smaller proxy code download sizes and update it to support Java 1.17
bytecode as well as other support other object serialization protocols
using the atomic Serialization API, it will be a configuration concern.
The original vision, it was visionary, but now it works, well it's more
than that, it works really well.
--
Regards,
Peter.
