## 5 Implementation Details
### The Key Components of Middleware and Their Relations
In the presence of SOMM, services are kept in code repositories and therefore the maximum number of services in SOMM is bounded to the available memory in code repository nodes which are rich nodes regarding to available memory. Nodes can download codes of services based on their needs and service registry nodes help the clients to find the appropriate node which can provide their needed services. ### Comparing with Other Middlewares

In this section, we compared SOMM with previously mentioned middlewares by concentrating on how well they meet the design criteria. Table 1 shows the main features of these middlewares beside the level that each middleware satisfies each of design criterions and in the follow, these features have been described in more detail. \begin{table}
\begin{tabular}{|c|c|c|c|c|c|c|c|} \hline
**Middleware** & **Key features** & **Scalability** & **Power awareness** & **Modifiability** & **Heterogeneity** & **Ease of use** & **General purpose** \\ \hline \multirow{3}{*}{Mate [7, 8]} & Virtual machine, small size applications, per-module reprogramming & Medium & Medium & Medium & Medium & Low & High \\ \hline \multirow{3}{*}{Cougar [12]} & Virtual relational database, Abstract & & & & & & \\  & DataTypes, SQL Like Language, In-network & & & & & & \\  & query processing & & & & & & \\ \hline \multirow{3}{*}{MiLAN [11]} & Macro-programming with high level concerns, QoS & & & & & & \\  & based efficient execution planning, Network & & & & & & \\  & protocol stack & & & & & & \\ \hline \multirow{3}{*}{Middleware} & Key features & Scalability & Power awareness & Modifiability & Heterogeneity & Ease of use & General purpose \\ \hline \multirow{3}{*}{TinyDB [4]} & Virtual relational database, Acquisitional & & & & & & \\  & query processing, & & & & & & \\  & Semantic routing tree, & & & & & & \\  & Power aware query & & & & & & \\  & optimization & & & & & \\ \hline \multirow{3}{*}{Agilla [3, 10]} & Virtual machine, & & & & & & \\  & Autonomous mobile & & & & & & \\  & agents, Tuple space, & & & & & & \\  & supporting self-adaptive & & & & & & \\  & applications & & & & & & \\ \hline \multirow{3}{*}{Kairos [13]} & Macro-programming, & & & & & & \\  & Caching with eventual & & & & & & \\ \cline{1-1}  & consistency, Language & & & & & & \\ \cline{1-1}  & independent & & & & & & \\ \hline \end{tabular}
\end{table} 
Table 1: Comparing SOMM with other middlewares. #### 6.2.1 Scalability

Mate supports scalability by using active messages [30] to update the network protocols and parameters by injecting new capsules. It facilitates the addition of new nodes to the network but the number of concurrent applications in Mate is very limited because of maintaining all applications in all nodes of network. Cougar and TinyDB use a centralized optimizer to maintain a global knowledge of the network and since the dynamic nature of large-scale sensor networks poses a problem for this centralized approach, these middlewares do not support scalability. MiLAN tackles the scalability challenge by providing application driven network management. Agilla and Impala provide application adaptation at runtime and therefore scalability using mobile agents and a suitable architecture model. Kairos is not scalable because it does not provide the ability for applications to fully control the underlying runtime resources. TinySOA provides a highly scalable framework by using service oriented architecture. Also as we mentioned in previous sub-section, SOMM provides highly scalable platform by using SOA and the concepts of code repositories and service registries and also the ability to automatically detect and register capabilities of nodes. #### 6.2.2 Power Awareness

Mate and Agilla are not efficient in term of power awareness. Their virtual machine and instruction interpreter increases the energy consumption of network.