Plugs and the MTON engine

Important: Believe me, this file is under construction ;-).

Introduction

Object networks were primarily designed as closed systems, in which no external communication could exist at all.  Newer extensions allied with the development the Object Networks toolkit made clear the necessity of devices that allow the network have some kind of interactiveness with the external world. The first proposal, described here, is the introduction of the concept of plugs, which makes possible - with a minimum programming overhead - external software objects to push and/or pull data into a running network.

Plugs are implemented as distributed objects, via Java RMI (Remote Method Invocation) framework. This approach maximizes flexibility, because all plugs are ordinary distributed objects.

First of all it is of extreme importance the statement of the following facts:

• There are basically two types of objects in Java:
• local objects: those ones which are intended to exist solely on only one JVM. When they are passed as parameters to a remote method they are simply serialized on the caller and deserialized on the receiver as a new local object. Note that the new object has nothing else to do with its original instance, in the caller's JVM. This is the default type of object.
• remote objects: those ones which are intended to exist in a distributed computing environment, with several distinct JVMs. Remote objects preserve, independently of the JVM from which they are referenced - or instantiated, their fundamental instance uniqueness. The underlying services are transparently provided by core Java RMI classes. Remote objects need to be specifically prepared to be exported across remote JVMs.
• RMI makes possible the creation of repositories of remote objects. Each exported object instance is bound to a given name, something like \\server\bind-name. This way any authorized JVM may gain a reference to this object by a lookup on his name. The last point here is that the server host - the one with the repository - must have a running rmiregistry daemon during the lookup.

Working With Plugs

Fortunately, almost all idiosyncrasies related to RMI are automatically elided in the core MTON implementation. Thus, plugs can be incorporated in the following manner:

1. Check your requirements to see if they are satisfied by an available plug. There are several already implemented plug incorporated with the main jar file.
2. Include the plug startup code in the ON class (kernel section).
3. Include the desired plug calls in the ON class (perform section).