## 5 Implementation Details
### The Key Components of Middleware and Their Relations  
The key components of SOMM and their relationships are depicted in Figure 9. SOMM supports having multiple agents in the network and also in a node at the same time. However the locking mechanism provided by SOMM allows the programmer to prevent the node from providing multiple  
Figure 7: Key interfaces in SOMM (**a**) tuple space interface; (**b**) agent transmitter interface; (**c**) instruction interface; and (**d**) interpreter interface. services at the same time, having multiple agents in a node is necessary. Because some situations may exist in which a node should provide multiple low quality services which do not need locking mechanism. Also since two types of agents exist in the SOMM (proxy agent and service agent), SOMM should provide facilities for simultaneous execution of these agents in a node. When multiple agents exist in a node, it is important to share the CPU time between them. In SOMM, it is the agent manager component that performs this job. The agent manager executes agents using Round Robin policy. Scheduling in virtual machine based middlewares such as Agilla [3] and Mate [7] is at instruction level; which means that each time an executable entity (e.g., process, agent or capsule) grabs the CPU, the scheduler executes a fixed number of its instructions and then allocates the CPU to the next entity. For example, Agilla executes four instructions of an agent in each turn by default. SOMM also performs the similar way; which means that the agent manager that is responsible for executing agents, executes four instructions of the active agent in each turn. As shown in Figure 9, agent manager uses the interpreter component to execute agents. To execute each instruction, agent manager calls the interpreter and the interpreter uses the corresponding Opcode component to execute the instruction. Figure 8: Key interfaces of SOMM (**a**) service manager interface; (**b**) QoS aware routing interface; (**c**) message dispatcher interface; and (**d**) agent manager interface. interface IQosRouter{ //sendsamesagestosinkoraspecifiednode commandresult_tsend(message_tmessage,uint_tnodeID); //sendsamesagestonodeneighborsandinformsthemthat //thisnodeisbusy commandresult_tdisServices(); //sendsamesagestonodeneighborsandinformsthemthat //thisnodeisfree commandresult_tenServices(); //updatestheneighborstableandmarkaspecifiednodeasa //busynode commandresult_tsetBusy(uint_tnodeID); //updatestheneighborstableandmarkaspecifiednodeasa //freenode commandresult_tsetFree(uint_tnodeID); //obtainsneighborsinformation commandresult_tgetNeighboursInf(); //notifywhethermessagesuccessfullysentornot eventvoidSendDone(uint8_tstatus); //notifythatanagestisarrived eventvoidmessageArrived(message_t*message); } ```
interface IMessageDispatcher{ //invokesanappropriatecomponentbasedonmessageType commandresult_tdispMessage(message_tmessage); }
```

interface IAgentManager{ //marshalsanagentandsendsittodestinationnode commandresult_tmigrateAgent(AgentContext*agent,uint_t nodeID); //un-marshalsanagentandrunsit commandresult_tunmarshalAgent(marshaledAgent*agent); //blocksanagentthatexecutedablockinginstruction commandresult_tblockAgent(AgentContext*agent); } ```

To better understand the behavior of SOMM components, Figure 10 shows the sequence diagram for registering services scenario at the startup a node. As it is shown, agent manager calls the _detDownServices_ command of service manager; service manager detects the connected sensors using underlying operating system and service manager calls the _dwnAgent_ command of agent transmitter to download the proxy agent for each sensor. Agent transmitter then downloads the appropriate proxy agent from code repository by sending and receiving messages to the code repository using QoS aware

Figure 8: _Cont._

router component. When an agent transmitter downloads the agent, it delivers the agent to the agent manager and the agent manager executes the agent after un-marshaling it.