For myself, the primary consideration is whether the arguments in RPC calls are
actually "downloaded classes" vs "downloaded data". In the simple sense,
"downloaded classes" are "downloaded data".
I've made a lot of arguments about how RPC at the most basic level, is a single
message, "invoke" with arguments of "the object", "the method" and "the method
arguments".
What some people seem to believe, is that "downloaded data" is much safer than
"downloaded code". Practically, "downloaded data" has to be structured in a way
to be consumable, and it can also be "manipulated" to cause the "receiving
agent" to misbehave while processing the data (the world of Internet virus and
worm manifestations). The obvious thing is how much of a problem the
misbehavior actually causes.
The most simple explanation of the problem with Java/Jini, for me, comes down to
the fact that deep inside the implementation is the act of unmarshalling the
object references associated with the parameters to the method invocation.
It is the simple fact that the "downloaded data" can "do some stuff" without
control of the "application" (the infinite loop, memory exhaustion and other
uncontrolled activities including stack overflow) that creates the problem.
The "receiving agent" is the JVM, and while it has ample control over the
content of the "downloaded data" to "execute it correctly", that is completely
orthogonal to "correct execution" of the application that the downloaded
software is now "alive" within.
As Sim says, the trust relationship is the current "idea" of how to make this a
tractable issue to deal with. As Zoltan also suggests, "downloaded data" can be
a more politically correct solution for many people because it feels (and
actually is because of the previously mentioned issues) safer.
The Jeri endpoint and invocation layer technologies still provide the
opportunity for eliminating the use of live Java objects in remote applications.
An invocation layer factory could provide the ability to convert the entire
method invocation into an XML document which is transferred via SOAP, raw HTTP,
or otherwise, for example.
We (the Jini community) have stood around and said this, but have largely not
demonstrated it publicly. We have also not thoroughly demonstrated how the
other tools in the Jini toolkit can simplify distributed applications by
building something that works in the open and is clearly not "just another
implementation of something already done".
But let me be clear, I am talking specifically about the Jini toolkit
distribution. There are things like RIO, Seven, Paremus' work and many other
more focused examples of the use of Jini for all kinds of real solutions. But,
the community at large seems to have a hard time documenting and endorsing these
things, which makes their visibility limited.
We need to work on a view of Jini that includes the whole range of problem
domains and solutions that exist now, and show how "downloaded data" that is
actually "downloaded code" can be a viable solution which in the end, simplifies
your application because you don't have a whole new layer to add to provide "the
other agent" that will use your "downloaded data" to make your application work.
Gregg Wonderly
On 9/29/2010 3:44 PM, Peter Firmstone wrote:
Sim,
Very well said.
+1. Peter.
Sim IJskes - QCG wrote:
On 29-09-10 10:26, Zoltan Juhasz wrote:
I'll think about it a bit more and come back with issues. Let's discuss
where Jini should be heading on the Internet.
I think, there is no other direction than going internet. Currently people and
organisations like to make a simple distinction. LAN is safe, internet is not.
With the proliferation of trojans, and the knowledge to writing them, the
concept of a safe LAN is impossible te keep. So instead of following the crowd
with increasing investment in firewalls, IDS technology to keep our LAN clean,
we should jump in at the other end. Expose our technology to the most
dangerous environment possible. The Internet! A jini enabled device should
survive and maintain their function, when deployed on the internet. We should
create best practices for internet deployment and work on the biggest hurdles
right now, which are:
- lack of broadcast capabilities
- firewalls
- trust relations
Gr. Sim
