The Artima Developer Community
Sponsored Link

Weblogs Forum
Thinking out loud, and in public...

9 replies on 1 page. Most recent reply: Feb 23, 2004 10:57 PM by Douglas Bass

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 9 replies on 1 page
Jim Waldo

Posts: 34
Nickname: waldo
Registered: Sep, 2002

Thinking out loud, and in public... (View in Weblogs)
Posted: Mar 23, 2003 12:43 PM
Reply to this message Reply
Summary
I'm not really used to this sort of public thinking out loud...but this could be a place to talk about how to deal with really large distributed systems.
Advertisement

Thinking out loud is something that I've generally done verbally, and in small groups. If nothing else, that allows me to ignore the mistakes later, or at least claim that I was misunderstood. But the sort of intellectual diary that a web log provides is both free-form and persistent. A different kind of experience, but one that can, I hope, generate more discussion with a larger community.

Most of what I think about these days (at least when I'm thinking about technical subjects) has to do with how we could build really large distributed systems. I'm not talking about the world-wide web, which is large but is also read-mostly; nor am I talking about business-to-business or business-to-customer web services. What I am thinking about are very large systems (thousands or millions of participants) with very few people in the loop. The kinds of systems that are going to be the outgrowth of the SETI at home work, or that will result from knitting together sensor networks with the rest of the world.

I'm pretty sure that one of the cores of such systems will involve moving objects, including code, around the network. Whether this is called mobile code, or active networks, or agents is irrelevant (the differences in these approaches has more to do with what the code does than the way the network is organized). But that is just the start; the other organizing principals are less well known. For example, how do mobile objects decide where they can actually run? What is security like in such a system (even more basic, who are the entities that are trusted in such a system)? How is scheduling done, or is there something different than what we would generally call scheduling that determines where and when objects are instantiated and executed?

That's what I'll ruminate about in this log...and I hope that others will ruminate with me.


Berco Beute

Posts: 72
Nickname: berco
Registered: Jan, 2002

Re: Thinking out loud, and in public... Posted: Mar 24, 2003 12:51 PM
Reply to this message Reply
Hi Jim,

You say, "I'm pretty sure that one of the cores of such systems will involve moving objects, including code, around the network."
I was fantasising and came up with the following question; the need for mobile code comes from the fact that it is sometimes better to do some of the work at the client-side, but what would happen if computers were orders of magnitude faster, networks were much faster and had a huge capacity? That would mean the server could do all the processing, networks could handle the potentially large amounts of communication between clients and servers, and all the client would have to do is take care of the input and output to the user. That would lessen the need to ship code around. Taken to an extreme, just shiping the input and output could in theory suffice. Of course the code for performing the input and output is needed, and there are the 7/8 falacies of network computing, but the number of occassions that require mobile code might be much lower.

In short: do you think that with the introduction of faster computers, faster networks and higher bandwiths the need for mobile code lessens?

Kind regards,
Berco Beute

Jakob Eg Larsen

Posts: 18
Nickname: jlarsen
Registered: Jan, 2002

Re: Thinking out loud, and in public... Posted: Mar 25, 2003 9:41 AM
Reply to this message Reply
I believe that your assumptions are different. Jim is assuming "very large systems (thousands or millions of participants) with very few people in the loop" (machine-machine interaction) whereas you, Berco, is talking about user-oriented systems (user-machine interaction).

In terms of interaction and coordination in such large systems I am sure that mobile code (or whatever term you want to use) may play an important role in flexibility, utility value, and ease of management of such large-scale distributed systems.

Nevertheless, it's an interesting question what level of computing you need/want for the user interface at the client side when the client is an end-user terminal. How to utilize the capacity of the system components, and how this is influenced by changes in the network infrastructure...

Jakob

Joseph Grace

Posts: 6
Nickname: occam
Registered: Mar, 2003

Re: Thinking out loud, and in public... Posted: Mar 26, 2003 11:26 AM
Reply to this message Reply
> all the client would have to do is take care
> of the input and output to the user.

In this case, the client computer will be amazingly fast as well (think 3GHz PC in the palm of your hand... or cell phone). As the computers get faster, both the servers *and* the clients get faster. The clients are probably getting faster at a higher rate than the servers at this point. My friend just got a new SonyEricsson phone, and (while I realized palm-helds would become real computers), it's mind boggling to see such a capable computer (email, sizeable screen, games, speaker audio, UI, wireless, internet) in such a small package. Now, imagine the equivalent phone two years from now!

The servers won't have to do anything! ;-)

Joseph Grace

Posts: 6
Nickname: occam
Registered: Mar, 2003

Re: Thinking out loud, and in public... Posted: Mar 26, 2003 11:28 AM
Reply to this message Reply
> a new SonyEricsson phone

I.e., the long anticipated P800 phone running java, email, browser, etc..

Thor Henning Hetland (Totto)

Posts: 4
Nickname: tottozm
Registered: Mar, 2003

Re: Thinking out loud, and in public... Posted: Mar 26, 2003 4:50 PM
Reply to this message Reply
I just wish the P800 had a real J2SE implementation (we already have webserver and dynamic DNS clients) as it would really open a new world of possibillities running active Jini clients on my phone ;) If we add some of the MIDP 2.0 API's for phone control and access to the PDA functionality.

No need to say what I feel about Personal Java... ;(

Berco Beute

Posts: 72
Nickname: berco
Registered: Jan, 2002

Re: Thinking out loud, and in public... Posted: Mar 26, 2003 6:37 PM
Reply to this message Reply
As far as 'real java on small devices' goes I can only say that it's been a waiting game for years, and since MIDP2.0 still doesn't come with object serialisation out of the box, I'm getting skeptical whether the elegant RMI of java will win from the blunt but simple XML-RPC from webservices.

Jerome Scheuring

Posts: 2
Nickname: jscheur
Registered: Mar, 2003

Re: Thinking out loud, and in public... Posted: Mar 27, 2003 1:51 PM
Reply to this message Reply
Remember that Java RMI is, in its essence, a programmer's shortcut: its goal is to avoid having to write independent clients and servers by having the system write the client for you based on the server specification.

As we've seen from Jini ERI, the underlying protocol may take many forms, while meeting this essential goal; XML-RPC may eventually be one of them, though there are obviously more efficient protocols that can be used when both endpoints are JVMs.

It's interesting to speculate on whether a JERI client running a simple TCP connection is viable on small devices.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Thinking out loud, and in public... Posted: Mar 29, 2003 10:36 PM
Reply to this message Reply
>In short: do you think that with the introduction of
> faster computers, faster networks and higher bandwiths the
> need for mobile code lessens?
>

I'd say just the opposite: Faster networks will invite more mobile code. I'd also argue with your notion that mobile code is needed in order to offload computation to a remote entity. That may be one reason to use mobile code, and perhaps the simplest one. But I like to think of mobile code as moving "capability" to some remote entity. It's a sub-specie of mobile data - data that enables the receiver to do something it couldn't do before.

For instance, we did an experimental system aimed at high "survivability." In that system, you have Java objects that are executing, going about their business. But at some point, those objects encounter exceptions. And some of those exceptions may be special, in that they are marked with an interface as "recoverable." When an object encounters such an exception, it doesn't know how to recover from the exception itself. But this recoverable exception object, when instantiated by the Java runtime, goes out on the network and discovers a "solution" to the problem at hand (using Jini, as you may have guessed). That solution comes in the form of code downloaded into the client. That code is then passed some client-side context, and is then able to execute operations on that context that allows the object to recover from the initial failure (or, at least, increases the chances that it could recover).

I don't think that scenario could be built using just mobile data (e.g., XML), because you need to download executable code in the form of those downloadable exception handlers. It's similar to an emergency service: When you call for an ambulance, they don't just hand you an emergency box and leave you with it. They come, and try to use their tools to help you out - i.e., they perform some actions at the scene.

To be very honest, I'm not sure I fully understand the implications of mobile code, even after several years of working with it. In the example I just mentioned, one implication of mobile code is that system doesn't have to be "complete" to start functioning. When you're developing such a system, for instance, you may not code up all those exception handlers up front. You may release the system, and then "inject" handlers into the network (by registering them in lookup services) at some later time. So, you have a running system that is, in some way, incomplete. It also means the exact behaviour of the system is hard (impossible) to predict, i.e., a system's performance model becomes even more probabilistic (and in more complex ways).

But that's just the tip of the iceberg...

Douglas Bass

Posts: 3
Nickname: dwbass
Registered: Feb, 2004

Re: Thinking out loud, and in public... Posted: Feb 23, 2004 10:57 PM
Reply to this message Reply
First of all, I'm glad you're thinking out loud, and in public.

John Kubiatowicz and David Anderson wrote an article in the March 2002 Scientific American called "The Worldwide Computer." It was not only saying that there would be more collaborative computing projects like SETI@Home and GIMPS, but that the data itself would be distributed, using a variation of Kubiatowicz's OceanStore system.

Right now, someone installs the SETI software on their machine, but after the software is installed, the data that gets crunched isn't under their control. Eventually, someone is going to say, "Well, why shouldn't it be that way for programs as well?"

What if the SETI people said "Our software is undergoing many rapid updates. If you install our software, you're giving us the right to automatically update it using some of the bandwidth you're letting us use." Would you have a problem with that?

Flat View: This topic has 9 replies on 1 page
Topic: Yahoo groups are enormously popular. That's probably an understatement. Previous Topic   Next Topic Topic: JSR 166, A Case Study


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us