So a few months ago, I was asked to write some entries in the company blog about Skoot.  Which is a pretty broad task.  What to write?  And I fussed over it, and made a few false starts at "intro to Skoot" sorts of posts, and finally it just fell off my radar for a while, and now here we are...  Anyway, if you want to learn about what Skoot is, probably easiest to just head over to SkootIt.com and read about it there.  (The tech writers probably can express that much more clearly than I can, anyway.)  Me, I'm going to stay a little bit more conceptual, and talk about Skoot as it relates to cloud computing, a couple of articles I've seen recently, and a little bit of the Topia vision for the future.


Cloud computing, to start with, is a pretty esoteric concept.  It's right there in the name...you do something on your computer, something mysterious happens "out in the cloud" (read: where you can't see it and you don't know what's happening), and whatever is supposed to happen as a result happens.

Or, to paraphrase a cultural reference from a certain South Park episode:

1. Do something
   
2. ?
3. Magical result somewhere in the network
   
4. (maybe some profit, too)

Yet suddenly we have this buzzword, "cloud computing", that's been seized upon by both developers and media as the "next big thing", and everyone is trying to wrap their heads around what exactly can happen at the question mark stage, in the clouds.  So it seems worth looking at some of these analyses, and then talking about Skoot, and Topia in general, in that context...

The first of the articles that caught my eye is "Cloudy Judgement" from Paul Boutin at Slate.  Boutin examines software as a service (SaaS), specifically looking at online photo editing with Photoshop Express and online office productivity with Google Docs.  He ultimately concludes:

"For me, it'll be years before Photoshop Express can become powerful enough to replace my desktop version, or before Google Docs gets me to uninstall Microsoft Office. I'm not sure I want to. One of the nice things about Word and Photoshop is that once I fire them up and start working, I can forget all about the Internet for a few hours."

My big problem with this article, and ultimately his conclusion, is that his method of analyzing "cloud computing" is to analyze a bunch of browser applications that are trying to overcome some clunky browser limitations to offer a desktop-like experience.  This is fine, if course, if he's just saying "not yet", but I think his dismissal short-sells the possibility of non-browser-based applications using the cloud to enhance the user experience.  And I think Skoot, and the overall Topia vision, imagine a framework where applications are able to stand alone, but enrich the experience for the user by leveraging "the cloud" for data storage/transmission/whatever, in a way invisible to the user.  The shortcomings that Boutin claims ultimately boil down not to problems with the cloud, but problems with how applications are designed.  With Skoot, we aim to provide an application that "just works".  You create workspaces, invite others, add files, and somehow, magically, after the question mark stage, those files make it to the other members of the workspace.  And, if we've done our jobs, it was a pleasant, easy process for all parties involved.

On to the next article.  "Architecture Astronauts Take Over", by Joel Spolsky on his Joel on Software blog, hits much closer to home in that his critique is of cloud computing applications remarkably similar to Skoot.  His case study focuses on the various synchronization-on-the-web ventures of Ray Ozzie, the first of which is Groove (essentially Lotus Notes with peer-to-peer synchronization), and now the newly-released Windows Live Mesh (in his words "Groove, rewritten from scratch, one more time").  Spolsky sees no general use for these applications, terming Ozzie an "architecture astronaut": one who doesn't solve an actual problem, just attempts to solve something that, in theory, may solve a whole series of problems.

"...the fact that customers never asked for this feature and none of the earlier versions really took off as huge platforms doesn't stop him...this so called synchronization problem is just not an actual problem, it's a fun programming exercise that you're doing because it's just hard enough to be interesting but not so hard that you can't figure it out."

Now, I respect a lot of what Joel has to say about software development, but I have to call him on this one.  Granted, maybe just synchronizing some files to the web isn't a big deal, and maybe on it's own it's not the hardest problem in the world.  But at the same time, people ultimately want to have access to their files, their information, their address book, etc., everywhere they go–on their work computer, their home computer, the public terminal at the library, etc.  And guess what, that means that there needs to be some mechanism "in the cloud" (with the astronauts?) that facilitates this.  It seems to me like implicit in him saying that they're trying to do something that "isn't so hard that they can't figure it out" is the notion that a truly useful is too hard, so why try to figure it out.  People want applications that are enriched by the cloud, they just don't want to know when and how it's happening, and probably don't even want to be aware that "cloud computing" has anything to do with what they're doing.

The vision of Topia is a world in which people plug their computer into the wall, can use their applications, and everything just works.  If they have network connectivity, those applications will interact with the cloud to enhance the user experience, store data, etc.  (And if they don't have network connectivity, such as on an airplane, they can still be productive.)  But that's the core thing: network connectedness, while in some ways core to the full-functionality of the application, is invisible to the user.

Which is all very pie-in-the-sky, but that doesn't mean it isn't useful.  And if Skoot, in offering a file storage/sharing application that can operate both online and offline, is one small step on Topia's way towards realizing this vision, then I hardly see it as just a trivial "programming exercise".

When designing a mobile agent runtime, one of the first decisions that must be made is whether to support strong mobility of weak mobility.  Strong mobility gives mobile agent developers the ability to migrate agents without needing to write any supporting logic for handling state changes after a migration occurs.  For example, with strong mobility one can retrieve a directory listing on a remote machine and print it on a local machine by creating a mobile agent with code like this:

var startingHost = getHost();
var destinationHost = getParam(1);
var fileList;
moveTo(destinationHost);
fileList = exec("ls -l");
moveTo(startingHost);
print(fileList);

As the runtime executes this code, the actual location of the agent is changing and the state of the agent is automatically transferred.

With weak mobility, the agent must reinterpret its state after every move.   In essence, the agent developer has to create a state machine.  Doing so places a burden on the agent developer because he or she must figure out how to handle state rather than focus on the original problem the agent is supposed to solve.  Lets look at an example of weak migration code, doing the same thing as the strong migration code above:

class Agent
{
     const int START_STATE = 1;
     const int AT_DEST_STATE = 2;
     const int DONE_STATE;

     int state = START_STATE;
     String startingHost;
     String destinationHost;
     String fileList;


     void init(String[] params)
     {
          destinationHost = params[0];
          startingHost = getHost();
     }

     void cleanup()
     {
     }

     void run()
     {
          switch(state)
          {
               case START_STATE:
                    state = AT_DEST_STATE;
                    moveTo(destinationhost);
                    break;
   
              case AT_DEST_STATE:
                   fileList = exec("ls -l");
                   state = DONE_STATE;
                   moveTo(startingHost);
                   break;

               case DONE_STATE:
                    print(fileList);
                    break;

               default:
                      throw new Error("Unknown state!");
         }
    }
}

As you can see, the weak migration code is more complicated and harder to understand in comparison to the linear execution of the strong migration code.

The potential impact of mobile objects, like the potential impact of an ESB, on networked systems is more a matter of understanding than proof.  Once you understand MOT (mobile object technology) in general and KMOT (Kolona MOT) in particular you will be able to identify when their use would consti-tute best practices .  Where MOT is indicated, usually nothing other than MOT will pro-vide an adequate substitute due to the nature of the values MOT brings to the table and the nature of the problems that MOT solves.  

A.    MOT 101: What is the Essence of MOT?

Mobile objects move functionality.  Under usual circumstances the movement of func-tionality at one level or another (processing, business flow) is the main business of mo-bile objects although they can carry messages as well.

Standard networking involves the exchange of messages, cf. Figure 2.

 

The variety of solutions outside the MOT arena is found in how such messages are passed.  We will not go into this detail.

Network messaging, also, is contrasted with local message passing, cf. Figure 3.

 
Local messaging passing is faster than fast and not subject to the trials and tribulations of network messaging passing.  This is where MOT begins to make sense.  There are times when we should try to convert Figure 2 functionality into Figure 3 functionality.  The use of MOT seen at the most abstract level is when this circumstance is useful, cf. Figure 4.

This, however, is only part of the story.  What we have emphasized here is that function-ality, the act of messaging rather than the message is being moved rather than informa-tion.  This is important but does not differentiate MOT.  Objects, non-mobile objects, are often sent remotely and have functionality intended for local use.  The difference with mobile objects is that the movement is part of the mobile object functionality.  Mobile ob-jects are not moved so much as they request their own movement and in this sense are responsible for their own movement.  MOs usually request movement from a mobile ob-ject runtime environment (MORE).  Thus Figure 5, infra, shows the more complex back-ground MOT has in moving functionality as opposed to standard networking of objects containing functionality.  (While Figure 4 is simpler than Figure 5 the general picture in Figure 4 when expanded to include all its elements would be more complex.  The use of MORE simplifies and “standardizes” the use of mobile functionality by decoupling the mobility from the application on the target machine that will use the functionality.)



In Figure 5, the object requests movement to a remote site and upon arrival is notified of success allowing the object to initialize itself before its run method is called.  This is very different than the picture in Figure 4.  The availability of a mobile object runtime envi-ronment (MORE) is necessary to what makes a mobile object a mobile object.  Such en-vironments may allow mobile objects to request more than their movement.  For exam-ple, they might request to be stored for a given amount of time or until some event oc-curs.  The mere movement of a mobile object is a minimalist use of the mobile object.  Multi-stop trips are what make MOT so powerful. 

But, wait, we are not done.  How can the messaging relationship between the local object (Object B in Figure 5) and the mobile object (Object A in Figure 5) happen?  This is not magic.  What is the mechanism?  More is to be revealed.

B. MOT 201: MORE Management

On occasion the MOT must interface with existing applications.  How is this achieved?  The answer, first, is that the MORE must be embedded and, second, that the MORE must allow the existing application and the MO to communicate through a MO “associatable” plug-in (MOAP). 



The application registers a MOAP with the MORE and this allows the MO functionality to send and the application to receive messages from the MO functionality.  The MO reg-isters a MOAP with Kolona and the MO retrieves the MOAP via an Associatable-ServiceObject that extends the ServiceObject (SO) interface.  The application registers the references to application objects the MO functionality needs to message and the MO functionality registers the MO functionality objects the application needs to mes-sage.

C.  MOT 301 Decoupling MOT and Moving Business Logic Functionality

The question now arises as to how MOs bring functionality to a remote application.  If the functionality is already there, this is not such a feat and of little use.  If the functional-ity is not there, how is it “carried” by the mobile object?  How does it interact with the MORE, since it is new functionality?  How can a class loader load the classes if they are not here?  What if you want to change the functionality?  What do you do then?  These are all the sorts of questions intrinsic to MOT.  The maturity of the answers is coincident with the maturity of the MOT.  Does the MORE have to know about the specific MO?  Is there a way to have functionality that is intrinsic (related to mobility - MOFI) to the MO aspect of MOF separated from the functionality that is extrinsic (business logic - MOFE) separated?  The answer is “Yes!”.  KMOT makes the separation by having framework and application Java Archive (JAR) files loaded on the startup of Kolona (separate from the application) and MO JAR files loaded on the arrival of the MO.



The type of the MO, the implementation, can be contained either in the MOFI.jar or in the MOFE.jar. (MOFI.jar is placed in a Kolona directory prior to startup.  MOFE.jar is co-migrated with the MO.  MOFI functionality can always be included in MOFE.  “MOFI” and “MOFE” are not required names and are used here for convenience only.)  What a node (machine) in a network contains can differ along with what functionality is involved with a MO. 

    C.1.    Node Functionality

The node can contain various combinations of (1) MORE; (2) MOFI.jar; and (3) Applica-tion with MOAP.  Any of these combinations are possible, understanding that MORE is an absolute requirement.  No MORE?  No MO!  MOFI JARs can be any functionality one might want.  However, since MOFI functionality is presumably not functionality specifically associated the application (otherwise it would be in the application), MOFI would be functionality associated with MOT, such as a MO framework not unlike Struts is a framework in a multi-tiered. Web server.  (KMOT includes a framework called “Strategies” that abstracts and makes transparent to the application programmer MOT, allowing the programmer using KMOT to concern him or herself with business logic alone.)

    C.2.    MO Functionality

A KMO must have a MOFE.jar, but the JAR can be null.  The MOFE.jar can include the type (implementation) of the MO or that type can be included in a MOFI.jar.  Either the application, the MOFE JAR or the MOFI JAR must include the MO implementation class.  If one uses a mobile object framework, such as Strategies, then the MOFI JAR will contain all the MOs and SOs needed.  If not, then the MOFE JAR is likely to contain these entities.

D.    KMOT 202: Creating a Kolona MO (KMO)

How does all this get started?  Where did a MO come from?  Who wrote the “book of MO”?  There are MOs that are created initially by non-MO functionality and there are MOs created by MO functionality. 

MO plug-ins (MOPs), a Kolona object, and MOs themselves create KMOs.  Each will be considered separately.  All mobile objects are created with a createMobileObject method that takes String, Object array and (depending on the creator) File objects as parameters.  The String parameter is the name of the fully qualified type of the MobileObject implementation.  The Object array parameter is the set of objects used to initialize the MobileObject.  And the File parameter is the location of the MOFE.jar JAR file.  (This location can be null for MOP or Kolona, if no application level external classes are needed.)

    D.1.  MOP

The MOP class is accessed remotely.  Kolona MOPs (KMOPs) have access to MobileObjectRuntime, which can create MOs with a createMobileObject method.  

    D.2.  Kolona

Kolona is accessed locally by the application that embedded Kolona.  The Kolona class itself has a createMobileObject method. 

    D.3.  MO

The KMO is accessed internally.  An MO can clone itself or create a mobile object with its MobileObjectServices object (set by Kolona’s Spring container in Kolona with inversion of control, IoC, dependency injection, DI) a slightly different create-MobileObject method, viz. one that does not take a File parameter.

        D.3.1.  Cloning

If a MobileObject clones itself, no createMobileObject method is required: clone is called.

        D.3.2.  Creating New Type

If a MobileObject creates another type of MobileObject, that new type of Mo-bileObject must use the MOFE.jar that the creating MobileObject had.  Accord-ingly, such a KMO does not have a File parameter in the creation method.

Next, in Part 3, we will look at MOT in illustrative system wide scenarios.
 

Lately I've been researching on how to utilize mobile object technology into an existing software system.  Although it would be nice to sprinkle magic mobile object fairy dust onto a system and make it twice is good (somehow), that is not reality.  Mobile objects are fascinating but they do not solve every problem, nor should one attempt to use them to do so.  However, there are some areas where mobile agents really do show a heck of a lot of potential.  The are that interests me is using them as agents; pieces of autonomous mobile code that performs tasks for you with as little intervention as possible.
For the research I spoke about I've been leaning towards augmenting the capabilities of an already existing and technologically successful system by opening the door for mobile agents to interact with said system on the behalf of individuals (groups of individuals may also be a possibility).
I won't go into details about the system but lets say that this system provides services that are accessible over the Internet.  These services do neat things but have the limitation that they are only accessible when the user of these services has a connection to the Internet.  Mobile agents can be used to provide a presence for the user that can make decisions on his behalf at any time.
Going down this road a little further, why limit the interaction of these agents to just this set of services?  If these agents can interact with each other as well as the services then it may be possible for the agents to do more helpful  and clever tasks for the user(s).  Going to the extreme, what may end up happening after years of research is that we all eventually have agents that represent us and make decisions on our behalf.  Considering that a major reason we use computers is to make our lives and work easier by off-loading mundane tasks it makes since that we should spend time figuring out what the next possibilities in this arena are.  Agents are already here, just look at your email client's junk or spam filtering capability.  The problem is that they don't exists outside of a particular program or computer, they cannot decide to travel somewhere else and represent you there.  Nor can they travel to a "meeting place" and interact with other people's agents to perform a sort of commerce for the benefit of more than one party.  That's the future folks.

Different technologies map differently onto and relate differently to large scale architectural requirements in net-centric systems.  Two important features of technologies that might be useful are (1) how obvious their usefulness to such systems is and (2) how easy it is to illustrate their place in such architectures. [fn. 1]

Mobile object technology (MOT) in general and Kolona MOT (KMOT) in particular can be shown to be clearly useful in meeting large scale architectural requirements but difficult to illustrate.  There is no plain illustration for the applicability of MOT to such architectures like there is, e.g., for an enterprise service bus: no sweeping graphic, no simple statement.  MOT, like JDBC and IoC/DI, needs to be addressed in detail in order to properly illustrate its usefulness.  The bugaboo of MOT is a lack of systemic understanding in the relevant technological communities of what MOT is and the use of MOT is. 

Further, the “evident” nature of MOT potential contributions in general or in relation to architectural requirements in particular cannot be realized without first elucidating and understanding the essential features of MOT.  There is certain knowledge of MOT that is required before these things are “evident”.  The fact that mobile objects move tells us virtually nothing.  Of course they do!  So what?  Without explicit and clear explanations of what MOT is, we are left to guess at applicability.  Consequently, even the “evident” nature of the positive impact of MOT relating in meeting large scale architectural and operational requirements is not clear until the essential high level values in MOT in general and KMOT in particular are well understood.  What is evident is evident only af-ter MOT and KMOT are well understood.  Without this base for understanding, MOT discussions are no more than idle conjectures.

------------------------------ footnotes

[Fn. 1]

“Not evident” in the graphic means not directly useful but that does not mean there is no use in the big picture.  Legacy CORBA or EAI functionality, for example, might plug into an ESB.  “Evident” means something that large scale architectures and systems should incorporate where indicated.  Enterprise Service Bus (ESB): decouples and distributes integration logic.  Extensible Markup Language (XML): provides for interoper-able exchanges between networked hosts.  Java Message Service (JMS): a specification for loosely coupled, event-based, synchronous and asynchronous messaging.  Inversion of Control (IoC): a lightweight dependency injection that assists in the efficiency and cost of development.  Java Database Connectivity (JDBC): a database abstraction that allows multiple implementations to serve an application.  MOT (MOT): an event-based, technology for moving functionality in order to convert remote messaging to local messag-ing.  Enterprise Application Integration (EAI): decouples network integration from applications and pro-vides centralized control of the integration.  Common Request Broker Architecture (CORBA): a standard that enables software components writing in multiple computer languages and running on multiple comput-ers to work together.  C++: a general purpose programming language built as an enhancement of the C lan-guage, adding classes, virtual functions, operator overloading, multiple inheritance, templates and exception handling.  Flash: a multimedia and application player.

Here is the reality: Kolona is as safe as Java and Java is as safe as it gets.  The logic is inescapable: Kolona is as safe as it gets.  This does not mean that there is any perfect security.  Security is always a question of a balance between the price for the security and the price to break the security.

 

Java security and, hence, Kolona security is based on the Java policy file.  Policy files in Java applications describe what objects can do what.  A particular Java process allows users to describe for themselves in their policy file what specific objects can do.  This is not related to whether or not the objects in question are mobile objects.  Mobile objects cannot sneak around users policy files.  The mobility does not require special measures.

Java is a practical language, not an academic language.  The language was meant to solve, not cause problems.  Java more specifically was meant to solve networking problems.  And, security is one of the network problems Java was and is meant to solve. 

Kolona from a security point of view should simply be seen as a set of Java classes.  There is nothing, nothing, I repeat, nothing about Kolona mobile objects that makes them more "iffy" security wise than other Java objects.  So, to understand Kolona security in this sense is to understand how security works with Java objects.  The policy file is the key.  If the user in the Java policy file does not allow a Java object to do what the object wants to do, the object cannot do it in that process. 

A caveat: "security" is concept covering a wide field and like "consumption" or "delinquency" includes matters which are incidentally but not logically or otherwise related.  There is, for example, the issue of cryptology in security.  Hamlet was a nuisance to Claudius, King of Norway, so Claudius sent him with Claudius's trusted agents, Rosencrantz and Guilderstern, bearing a note requesting that Hamlet be murdered on arrival in England.  When they arrived in England, the note was produced, saying that the trusted civil-servants should be dispatched and escaped in an unlikely plot twist involving pirates.  Hamlet the hacker had broken the code.  This, however, is not akin to the security issues that must be discussed with Kolona mobile objects.   The issue with objects is whether or not there is an invitation to the ball.

The Rhodopis story (generally known to us as Cinderella) is more apt.  The question in the case of Java classes security is whether or not the glass slipper fits.  There are no fairy godmothers with weird pumpkins to mutate objects into forms that do have invitations in Java.  But, Oh Joy, if there were, it would not matter.  If the policy file invites the object to do something, everything is going to be alright ever after.

We will discuss the details later and there are volumes in the literature.  But the bottom line is that Kolona mobile object technology is not a special case involving security.  Whatever networking solution one chooses, you can have less but not more security solutions than Kolona mobile object technology.  Kolona mobile objects are not executable files.  They are Java objects.

In the Tenth Book, the final book, of Plato's Republic, we find the final expression of Socrate's long reductio ad absurdum of utopian theories of social systems to a group of Athenians ironically hiding in Cephalus' house to avoid mingling with foreigners. Young Socrates voices his ultimate wisdom in the desire to be "a plain man who minds his own business".  Here at Topia (place), the opposite of utopia (no place), we too have our feet firmly planted on solid ground, eschewing elixirs, panaceas, cure-alls and magic bullets.  There is a lot you could do with mobile objects that you should not do.  Our can do does not blind us to what one should and should not do.  How can we assess where mobility is indicated as the best or better solution?  We too want to be and are plain individuals who mind our business, which is mobile object technology (MOT) and, more specifically, Kolona MOT.  This is the first part of a multi-part discussion of this question.

THERE IS that wonderful song ("What do the simple folk do?") in Camelot (the movie) where Arthur and Guenevere are wondering what simple folk do to turn tears to mirth.  Several conjectures are presented: they whistle, they sing, they dance, and they wonder what Arthur and Guenevere do.  What do mobile objects do that is not done otherwise to brighten up our day, to give us the needed glow?  Do you know?  The simplest recipe for mobile object oomph follows.

Local objects communicate, as a rule, by using references: they call and message one another on the same machine.  Distributed (remote) objects communicate in various ways but most usually through remote method invocation (remore procedural calls) and message passing via sockets and other networking devices on different machines. 

Distributed objects differ from local objects in several particulars:

• Life cycle: The creation, migration and deletion of the objects differ.
• Reference: Remote references are much more complex than simple pointers to memory addresses in the same process.
• Request latency: A distributed request is orders of magnitude slower than local invocations.
• Object activation: Distributed objects might not always be available.
• Parallelism: Distributed objects can be executed in parallel.
• Communication: There are different communication primitives available for distributed objects requests.
• Failure: Distributed objects have more points of failure.
• Security: There are vulnerabilities specific to the distribution of the objects.

Examples of distributed objects are:

• Objective C using the Cocoa API with the NSConnection class and support.
• Java RMI
• CORBA allows distributed mixed object systems.
• DCOM is a framework for distributed objects on the Microsoft platform.
• DDObjects is a framework for using distributed objects on Borland Delphi.
• JavaSpaces is a Sun Microsystems specification for distributed, shared memory.
• Pyre is a framework for distributed objects with Python.
• Distributed Ruby (DRb) is a framework for distributed objects using Ruby.

The following graphics indicate visually local versus distributed objects at the simplest level.  Local object communication is on the same machine.

Distributed object communication is on different machines.

Mobile objects provide a combination/merger of the virtues of each of these object communication paradigms.  Mobile object communication is both on different machines and on the same machine.

Lately I've been spending quite a bit of time thinking and researching how Mobile Objects (MOs) can be applied to the distributed computing space.  Apart from the complexity of transforming serial algorithms into distributed ones itself there is the problem of distributing the actual code in a manner that is easy to deploy and administer.  If, for example, one has a cluster of 100 computers dedicated to performing a distributed operation then one has to ensure that each of those 100 computers has the ability to execute the needed code.  Obviously, doing this manually for each of the 100 machines is not practical.  What one needs is the ability to easily make the code locatable to each machine in the cluster.

One way to do this is use MOs.  In effect, what this would involve is making each computer in the cluster a "blank slate" with no application specific code on them.  Installing an operating system and our MO runtime, Kolona, on each computer would enable new code to be dispatched to any (or all) of the machines as needed.  Because each machine can perform any computation at any time, the cluster can be used for a variety or purposes as needed.  One could even have many types of calculations occurring on the cluster at the same time by moving different type of MOs to different machines in the cluster.  So, one day the cluster can be doing graphic rendering and the next day something else...without having to change any of the machines' installed code.

This usage of MOs for distributed computing is not limited to calculations but can be used for data processing.  One could use a privileged MO to install a special type of Kolona component called a Service Object (SO).  SO's provide services to MOs via an application specific interface.   For this example I'm going to install a SO that provides block-based storage.  The nodes of the cluster will have this generic ability for MOs to store and retrieve blocks of data.  The actual contents of the blocks are not defined by this block-storage SO.  Rather, MOs are able to use the block-storage service in any way they see fit.  For example, one could use a swarm of MOs to migrate to each node of a cluster and search for some piece of data in parallel, as if the blocks represented a large database.   Simply using different mobile objects can change the capabilities of the cluster’s storage service.

I'll be talking more about the use of MOs for distributed computing more in the future because this topic is fascinating to me.  The future of computing is parallelism.  This is not true just for super-computer like clusters but is also becoming evident for desktop machines.  At present, four-core machines are readily available for purchase at Best Buy for $1000.  Anyhow, I believe MOs are a valuable addition to the world of distributed computing.  More next week!