OpenSOAイニシアティブが「Power Combination, SCA, OSGi and Spring(source)」（OSGi、SCA、Springの強力な組合せ）という表題のホワイトペーパーを発表して以来、これら3技術の組合せは話題を呼んできた。インフラの商用実装(source)でさえ存在する。Spring Dynamic Module(source)はすでにSpringとOGSiを結合しており、他方、Spring BeanはSCAコンポーネントの実装(source)として使える。最近、TuscanyのJava実装がApacheのOSGiフレームワークFelix上(source)に構築された。
William Vambenepeがこの新種のインフラを認める用意がある(source)なら、次のようになるだろう。
「柔軟性」（OSGiのおかげ）
「テスト容易性」（Springのおかげ）
「再使用可能性」（SCAのおかげ）
Vambenepeは以下の点で、ホワイトペーパーの著者に同意するのをややためらっている。
「簡潔性」 ...3つすべてと関わりのある少数派に属さない限り、該当しないでしょう。
「管理容易性」は「管理容易潜在性」と呼んで、親しい付き合いを続けましょう。
管理容易性はSOAの重要側面である。シアトルに本拠を置く大手保険会社でBusiness Architecture部長を務めるBrian Cowan氏は、私信で次のように指摘している。
SOAはマネージメントとオペレーションにモノリシック・アプリケーションモデルの複雑性を押しつけているように思われます。独立したソリューションの実装やデプロイ、スケール、確保を手に入れる能力に対する代償です。
Williamは過去の投稿(source)ですでに、管理容易性に対するSCAの影響について意見を述べている。
SCAにもう1つ利点があります。アプリケーション管理とサービス管理で役立つ粒度レベルで、コンポジット・アプリケーションのロジックが機械で読み込み可能な記述になっていることです。
[同様に］ SCAのように、BPELは管理容易性を目的に設計されたわけではありません。生産性、ポータビリティ、柔軟性の向上を意図していました。［中略］アプリケーション管理に非常に有用なメタデータも提供します。アプリケーション・フローをハイライトすること（アクティビティを通して）と、依存性と関連ポリシーを明白にすること（パートナーリンクを通して）の両方の点から見て、です。
SCA、OGSi、Springはそのギャップを埋めるのにも役立ちます。アプリケーションメタデータをさらに提供し、アプリケーション管理ツールがそのメタデータを活用して、管理タスクにさらに多くのアプリケーションコンテキストを提供できます。
OSGiを広く紹介している(PDF・英語)このホワイトペーパーで、著者は次のように書いている。
OSGiサービスプラットフォームは、無人状態、もしくはプラットフォームオペレーターの管理下で稼働可能な装置向けに特に設計されています。リモート管理を必要とする装置です。
装置のリモート管理にはプロトコルが必要です。SNMP、CMISE、CIM、OMA DMなど、多数の選択肢があるため、適切なプロトコルの選択は難しいのです。
OSGi Allianceは、1つのプロトコルが全ケースに適合することはないという理由から、他より好ましい管理プロトコルは存在しえないと決定しました。そのためOSGi Allianceはアーキテクチャを選択しましたが、このアーキテクチャが認定バンドルによって使用される管理APIを提供します。この認定バンドルは次に、管理バンドル役を務めることができ、API呼び出しへのプロトコルをこのバンドルがマップするのです。
事実、スペインのマドリード工科大学(サイト・英語)（UPM）情報通信工学部(サイト・英語)（DIT）は、OSGiサービスプラットフォーム向けのJMXベースの管理エージェントを開発した。その名をJMood(サイト・英語)という。
Williamは警告で締めくくっている。
すべて胸躍るような出来事ですが、こうした規格をがんじがらめに結合してしまう危険を冒すには、あまりに時期尚早ではないかと訝しむ自分も存在します。「開発途中の規格をひとまとめにしたものが、一体となって正確に動作し、世界の全ニーズに対応する」というような、「標準フレームワーク」的性質を謳うPowerPointのスライドを、これまで余りにもたくさん見てきましたから。
原文はこちらです：http://www.infoq.com/news/2008/02/manageability-oss