ブログの投稿で、David Chappell氏（Chappell & AssociatesのDavid Chappell氏です。Sonic/OracleのDavid Chappellと間違えないで下さい）は、JavaOneで彼がモデレータとなったService Component Architecture (SCA)のセッションでの所感を書いている。David氏は、SCAが2つのもの(プログラミングモデルとアセンブリモデル)で構成されているということを強調している。即ち、次のとおりである。
[...]SCAは、Java(若しくはC++)で、サービス指向コンポーネントを作成するための新しいプログラミングモデルであり、コンポーネントをコンポジットと呼ばれるかたまりにアセンブリするための方法について書かれたものです。コンポジットは、SCAの新しいプログラミングモデルを利用して構築されたコンポーネントを含めることができますが、SpringやBPELといった、その他の技術を利用して構築されたコンポーネントを含めることもできます。SCAは、これらその他の技術のための新しいプログラミングモデルを定義しているのではありません。それらを使用して構築されたコンポーネントを、コンポジットの一部とするための方法についてだけ定義しているのです。
SCAとJBI(Javaによるビジネス統合技術)の相対的価値は、以前に、InfoQで議論された。それらの関係については、現在は、オフィシャルな状態になった。以前の投稿では、Chappell氏は、SCAはJava EEに対する脅威になると主張していた。J2EEとJava EEへの投資を深刻な問題としていない、IBMとBEAは、共にSCAの主要サポータである。しかし、David Chappell氏が指摘するように、これは違ったことを意味している。
これに関してもう少し言うと、あるベンダーが、SCAをサポートすると言うとき、あなたが実際に尋ねてみるまでは、それが何を意味するのかを知ることはできません。Oracleがそれを言うと、それはアセンブリ構造の側面における技術のサポートを意味しているように見えるでしょう。BEAがそれを言うと、アセンブリ構造の側面とJavaコンポーネントはサポートするが、C++のコンポーネントは不要であるように見えるでしょう。IBMがそれを言うと、現在のバージョン1.0の仕様のほぼ全てをサポートするように見えるでしょう。Sunがそれを言うと・・・、いや、残念ながら、本当に意味するところを私はお話することができません。
GoogleのGregor Hohpe氏は、自身の所感を次のように書いている。
そのプログラミングモデルは、MicrosoftのWCFにそっくりで、全ての分散システムとやり取りするための統合されたAPIを提供しています。Microsoftにとっては、当然のことながら大きな出来事のはずです。しかし、ベンダーがサポートするSCAのプログラミングモデルは、あまり熱のこもっているものとは言えず、少し驚きでした。数多くある"公式な"ドキュメントでさえ、仕様面を軽視したものになっているように感じられます。IBMとBEAだけが、真の意味で両方(プログラミングモデルとアセンブリモデル)をサポートしていますが、他のベンダーは、プログラミングモデルは興味の中心には無いと、はっきり言っています。
Gregor Hohpe氏は、SCAは、本当にSOAとして何かするのかということについても質問した。
以前のSCAは、その仕様が、コンポジットを単一のベンダー環境で実行しなければならないものに思えたので、完全に私の興味が薄れていきました。この制約は、SCAが、SOAとの関係が比較的少ないものであるということを意味しているように私には思えました。しかし、それらは本来、単一のベンダーによってコントロールされていない異なる環境で処理されるべきものです。
実際、SCAは、一般的にハイレベルなSOAの側面とは異なるものを解決しているように思える。それは、実現不可能な技術ではないように思えるので、SOA周りの標準とごくふつうの関係であることが本当に適切であるかどうかに関わらず、問題を解決してくれるものであると強く期待してしまうのだ。
（原文は2007年5月17日にリリースされました）