This is one of those places where Jini's power, using mobile code, creates more
"necessary" overhead, than people familiar with other forms of "marshalling"
start to wonder "why would you do that then?" I think it's important to look at
what "external mechanisms" Jini is using now, and start looking at providing
other forms of "marshalling" at the InvocationLayerFactory level.
Simple, "document transfer", is what it seems many people feel is "tenable" for
them in enterprise level systems. I've long argued, that the Jeri ILF is
actually just like a "document transfer", in that the method arguments are sent,
in a package, to the server, whose "invoke" action is passed this "document."
The remote server then processes the document and returns it, potentially with a
"hyper link", in the form of a remote reference or just the resultant "value."
The type information available from the result, is the "complete, self
documenting" description. It tells you what you have and what you can do with it.
It's this simple view of the "Jini transport", that would enable a lot of
different possible mechanisms to be used at the ILF layer. Because I've never
really had the need for anything else, I don't have anything in production
different than the standard Jeri ILF. But, I did, at one point, create an ILF
that did do MODBUS-over-TCP as an exploration of what it would mean to move
something, which I could do at the "service layer" via a "delegation model",
into a lower level interface.
What I found, was that there wasn't a "distinct" advantage, so I threw that
stuff away and just kept it at the service implementation level. This is one
of the things that I found important to understand about Jini. It works well as
a layer of communications and unification of interface, that enables features
that are not what the "service" is about, but rather what "distributed systems"
are about. So, as a tool set, it works well for that specific task.
Things like Rio, JavaEE integration, Realtime systems monitoring etc, are the
"domain" targeting mechanisms that enable specific types of system
"construction" which in turn can enable specific kinds of "features". Rio lets
you build lots of "small" or "large" services and get all the dynamic, built-in,
life-cycle management features that a large enterprise environment needs. The
Harvester and other such systems, provide ways to use Jini features inside of a
JavaEE environment to take advantage of "both" tool sets together. The
dedicated solutions world, which has plagued the Jini platform with no
"demonstrable" users, is what we've always held up and waved around, saying,
"people feel it's so valuable to them, that they don't want their competition to
"see" or "know" how they are using it.
So, there is the whole other side of the internet, on untrusted networks, where
people are constantly using the "Web" for their transactional, data transport
systems/models. I'm not sure where Jini fits in that world, without some very
specific, dedicated systems that do stuff that the web can't do. Looking for
some of that "lone" fruit to pick, is what I'm not sure about.
What kind of transactional, leased or other data services could you imagine Jini
being a key part of on the Internet?
Gregg Wonderly
On 1/27/2012 7:04 PM, Peter Firmstone wrote:
I've been thinking about the practicalities of a djinn running in untrusted
networks (internet), the first thing that springs to mind is, security is much
simpler if people can get away with only "dumb" or reflective proxies.
I'd like to the see the default security setup requiring DownloadPermission.
I we sign our download jars (a number of developers could do this, requiring
at least this group of signers), a standard policy file template could include
a certificate grant for DownloadPermission, allowing anyone to load classes
from a standard River download proxy.
This gets our smart proxy's out of the way.
Then all developers need to worry about are Principals and MethodConstraints,
allowing people to get started using River with reflective proxy's over the
internet.
Later if people want to get into smart proxy's that power's still there, this
change prevents unauthorised class loading.
Cheers,
Peter.
