river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Towards Internet Jini Services (why)
Date Wed, 29 Sep 2010 21:45:30 GMT
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 

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

View raw message