January 2008 Archives

Part One: The Myth of Ur and Mobile Object Solutions

By MG on January 23, 2008 11:39 AM | Permalink | Comments (0) | TrackBacks (0)

Introduction

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.

Nothing could be more injurious to the future of mobile object technology than to try to force it to do what it is not meant to do well. Mobile objects will never replace the fundamental Internet browser technology. A static request with a response is just what the doctor ordered for HTTP and the World Wide Web (www). Yet the Web would be fairly useless and dull without JavaScript, Flash, Applets, DCOM, Ajax, and the like, most of which are mobile code (however, not mobile objects). The need to have a distributed connection between the browser user and websites is clear enough. The need to supplant this connection with hidden, transparent, technologies invoking the assistance of browser plugins in the static HTML or DHTML is also clear. Eye popping dynamism jumps out off those static Web pages.

Mobile object solutions are like mobile code solutions on the Web. They are background solutions that are invisible or in the background yet the source of evident pizzaz.

Let's remember our discussion of the core, the kernel, the essence, of mobile object technology in the earlier blog "Camelot: What Do Simple Objects Do?". Mobile objects are an amalgam of local and distributed object communications. Where neither distributed nor local communications alone can solve a problem, mobile object technology is helpful. And, let's remember our discussion of the advantages of mobile object technology in the earlier blog "Mobile Code: Excitement on a Barren Internet Landscape".

1. Mobile objects reduce network traffic by transforming network conversations to local conversations making ongoing connections and data transfers unnecessary (reducing chatter).

2. Mobile objects reduce network load by going to where the data is rather than sending the data to where the processing is (reducing throughput).

3. Data exchange in distributed systems involves protocols that evolve. Mobile code can provide evolving adapters that handle legacy protocol channels without disturbing the network system.

4. Mobile devices rely on fragile networks. Mobile objects operate asynchronously and autonomously. Loss of connections does not affect the viability of mobile object code.

5. Mobile objects can sense their execution environment and react autonomously to changes. Multiple mobile objects, for example, can configure themselves in a network to optimally provide a solution.

6. Since mobile objects are computer and transport independent (they live within the mobile object runtime environment), they provide for seamless system integration.

7. Mobile objects ability to react dynamically to unfavorable situations make it easier to build robust and fault-tolerant systems.

8. There are no “killer mobile object applications” but merely applications that use mobile objects, or mobility, to their advantage. Mobility is a facet, not a defining feature, of applications that use mobility as a solution. The addition of a mobile object runtime environment brings potential to a distributed system not otherwise present.

9. Mobile objects are well suited to eCommerce because they (and no other distributed functionality) give real-time access to remote resources.

10. Mobile objects make excellent network assistants on behalf of their creators. For example, six mobile object representatives of six businessmen can meet at some common host and agree upon a time to meet.

11. If there are collaborators that do not trust one another, the mobile objects can so with a secure, trusted, third party host for collaborative purposes.

12. You can dispatch mobile objects to large volumes of data to create search indexes over time periods when the original machine may be down.

13. In large-scale networks requiring reconfiguration and user customization, mobile objects are useful as glue keeping the system together.

14. As workflow items, mobile objects embody the information and behavior they need to move through an organization independent of any particular application.

15. A mobile object can monitor a host without a need to stay in contact with its origins.

16. Mobile objects life spans can exceed that of their creator processes, e.g., for monitoring hosts.

17. Mobile objects incorporate a push model of communication and can be used to disseminate information (new, software updates). This is done independent of the originating process.

18. Mobile objects can clone themselves for purposes of parallel computing jobs.

How can we break down what mobile objects do to see what makes these uses the advantages of mobile object technology rather than just uses that could be perhaps better done with other technologies. There is a hint, if we remember prior blogs:

Atomic Capability One: mobile object technology can move code to cooperate with local code on a target system.
Atomic Capability Two: mobile object technology allows a remote source to monitor, control, etc. what is happening on a target system or target systems.

This is but a beginning. In Part Two we will look into and discuss the details of these two interactive capabilities and how they can illuminate deciding where and when to use mobile objects in distributed solutions.

Camelot: What Do SImple Mobile Objects Do?

By MG on January 22, 2008 11:10 AM | Permalink | Comments (0) | TrackBacks (0)

The Mobile Object Pattern: Live Globally, Act Locally

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.

When you have distributed (global) communication that is problematic because of its nature and need local communication, try the mobile objects.

Conversely, when you have local communication that is problematic because you need remote (global) configuration or management, try mobile objects.

The preceding is the simplest measure of when you should be using mobile objects. Think of the mobile object runtime environment (MORE) as a locally existent template for global configuration of object communications. Very often you might find yourself in a quandary about how to solve a simple network problem that is easily resolved by the Mobile Object Pattern.

Distributed Computing with Mobile Objects

By Chad Hardin on January 17, 2008 1:33 PM | Permalink | Comments (0) | TrackBacks (0)

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!

Mobile Code: Excitement on a Barren Internet Landscape

By MG on January 15, 2008 9:39 AM | Permalink | Comments (0) | TrackBacks (0)

Mobile code is software transferred across a network, downloaded and executed on the target local system by some pre-existing plugin, framework, etc. Scripts (JavaScript, VBScript), Java Applets, ActiveX controls, Flash animations (and Extras) and macros embedded in Microsoft Office documents are some examples of the ubiquitous presence of mobile code on the Internet and intranets. Mobile code is also downloaded and run via email.

The Internet as we know it would be a barren landscape without mobile code. Yet, in most situations mobile code goes about its business quietly, efficiently and invisibly. So there is not a lot of awareness about the actual existence of mobile code except on the part of software engineers and such.

Mobile code has major technological paradigms.

(1) Code on demand,

(2) Remote evaluation, and

(3) Mobile agents.

Internet browsers are an example of code on demand. You have used a browser: Internet Explorer, Firefox, Netscape, Safari, etc. You are using a browser right now. Your browser has various plugins and modules that allow it to enrich beyond simple presentations of words with markup. WIthout mobile code, a browser reads HTML (hypertext markup language) and is text bound. The Internet without mobile code would be like Prometheus without fire.

Grid computing is an example of remote evaluation. The Human Genome Project is an example of grid computing doing what otherwise would have been a somewhat intractable problem. All of you who let your home computers be used for this or other projects did so as remote evaluators for your part of the huge task. Thanks from all of us to all of you. And, thanks to mobile code.

Mobile agents, nonetheless, are the paradigm that makes mobile code not only ubiquitous and helpful but immensely exciting. We will have many blogs on this technology.

Topia Technology's mobile objects technology (K-MOT) includes the Kolona mobile object runtime environment (K-MORE) and is an example of the mobile agent technological paradigm for mobile code. Topia talks about mobile objects rather than mobile agents because Topia focuses on the movement rather than the intelligence of the agents. (K-MORE is like the plugin on your browser that allows you to run JavaScript. The browser reads a tag in the HTML that says that some JavaScript must be sent off to a plugin to process the scripted mobile code. When a Kolona mobile object arrives at a destination, K-MORE does the same thing as the JavaScript plugin.)

Mobile objects have diverse uses.[1] Here is a partial list of uses: