Hive[6]は移動エージェントの枠組みを利用して様々な機器の 組み合せを実現している． 複数のエージェント同士が，メッセージ交換によって お互いに協調して動作することで 機器の組み合わせを実現しており，またシャドウと呼ばれる 実際のハードウェアを抽象化し制御するためのインタフェースが 用意されている． Wappletフレームワークでは利用できるサービスプロバイダが変化した際に ミッション機構でこれを検知し，Wappletモジュールを移動して適応することが可能である． Hiveでは完全に分散したアプリケーションの構築を目的としており，このような 集中的な管理を行う機構が考慮されていない． そのため，アプリケーションがユーザの移動や環境の変化に適応して，機器を切り替える動作を 実現することは難しい．
Ninja Project[15][8]やDanse[16] では．PDAなどの 小型のクライアントがサービスプロバイダの情報を静的なドキュメントとして 取得し，これを用いて機能の組み合わせを実現する． この場合，サービスプロバイダに対しては簡単なコマンドや決められた 操作要求を送信することで，サービスプロバイダの制御を実現している． この方式では，サービスプロバイダを利用するためのインタフェースの統一化が 容易であり，またサービスプロバイダ同士の組合せも，ドキュメントの記述を適宜参照し サービスプロバイダを検索することで行う． 例えば，電灯のような家電製品の電源投入や，リモコン操作のような 作業には非常に有用である． しかし操作自体が，簡単なコマンドの送信によって実現されるため，複雑な動作 や組合せ，特にアプリケーションに依存するようなデータの交換や操作が困難になる． それに対しWappletフレームワークではメディアアクセスを実現することが目的であるため， 単純な機器の制御では充分ではない． 各機器にサービスプロバイダを配置する方式は，各機器が一定の計算能力を有することを 前提とする反面， アプリケーションが任意にその組合せや利用方法を定義することが可能であるため， 複雑な処理が可能になる．
Jini[17]では， アプリケーションが必要な機器を検索し，検索の結果として機器を利用するための インタフェースを取得することができる． Wappletフレームワークでは，機器のインタフェースは機器の種類によって抽象化されている． そのため，Jiniに比べて機器独自の機能を利用できない可能性があるが， 同じアプリケーションによって機器を代替利用する機構を持つ．