Agents - The "Home" Cloud

Agents

Agent Smith, was it?

To control a device, to run things on it or just to ask something of it, it must run an "agent". Agents are normally the unit of distribution. Any device that can, would run an agent and thus be a full member of the cloud.

The different coulds are made of agents.

Agent functionality:

Agents can have "services" derived from AgentService
Agents are normally combined with a server and listen on a socket
Agents are thus uniquely identified by their host/port combination (url)
You can upgrade an agent remotely
Embedded presentation and control
Each agent can track the status of the clouds it knows and maintain the cloud state (i.e. who's up who's down, who's where…)

services and plugins

The unit of deployment is a "plugin", which is a bundle placed in the aptly named "plugins" folder, consisting of at least a plugin*.xml file. These are scanned and loaded by the local agent upon startup. Plugins normally register either services or assets or both.

The unit of modularity in the agent is a "service". A service has lifecycle management (onStart, onShutdown) as well as API services: it can bind methods to a protocol. If you bind to http for instance it acts much like a servlet. Read more on the LightSoa framework.

There are a few out-of-the-box services:

AgentHttpService - the basic socket server that the agent is tied to
AgentFileService - wip
AgentControlService - control of the agent: upgrade, shutdown, status, restart etc
AssetService - basic asset management
MetaService - meta information about the assets managed and services offered by this agent
AgentNetworkService - cloud management
AgentUpnpService - upnp bindings.

Developing with agents

Since this is primarily a developer-oriented framework, to test out distributed algorithms and stuff, there are a lot of developer-friendly features.

Remote upgrades

You can upgrade a remote agent easily from any other agent. Say you're developing on machine1 and have a remote agent on machine2:4444:

#1. prepare the new jar files from the code (eclipse project)
machine1> cd ~/razmutant
machine1> ./mprepare.sh
machine1> ./mutant.sh
- the local, updated mutant starts and now you switch to the web ui, find the remote agent and click "update to".
- the local agent will send to the remote agent all its files and then ask the remote to restart.

Running multiple agents in the same process

You can easily create and run multiple agents in the same process. In fact, the unit tests for the agents frequently start a few agents in the same test, to see if they can find eachother for instance.

Example:

    // two agents in the same JVM, see if they connect to each-other without UPNP
    def testConnectingAgents() = {
        val agents = razie.SimpleAgent.localCloud ("4446", "4447").toArray
        agents.foreach(_.onInit())
 
        agents(0) inContext {
           // not actively maintaining cloud state
           agents(0).register(new TempAgentNetworkService(false));
        }
 
        agents(1) inContext {
           // this will actively search and maintain the network too
           agents(1).register(new TempAgentNetworkService(true));
        }
 
        try {
            Thread.sleep(1000);
 
            // all agents in the group are up...?
            for (h <- razie.RJS.apply(Agents.homeCloud().agents().values()))
                junit.framework.Assert.assertTrue("must be up..." + h, h.status.equals(AgentHandle.DeviceStatus.UP));
        } finally {
            agents.foreach(_.onShutdown())
        }
        Thread.sleep(1000);
    }

Thread contexts

Surely everyone is familiar with the thread context. In J2EE it gets a litle more complicated. Same here. Each agent instance has its own context. The agent is intimately tied to its web/http/socket server, because its context is automatically set whenever the server is processing a request.