少し以前（2006年7月10日付け）のSearchWebService.comの記事ですが、原題は、
Analysts see Java EE dying in an SOA worldです。詳しくは原文を参照していただければよろしいかと思いますが、アナリストは、Burton GroupとZapThinkの2名で、それぞれが、Java EE（Java Platform, Enterprise Edition）のSOAへの適合性についてコメントをしています。
| 記事の概要は次のようになります。（正確には原文をご覧ください） | |
| ① | JEE5になって益々複雑さを益して、エンタープライズでの開発プラットフォームとして適合できなくなってきている。CORBAと同じ運命をたどる。ただし、Java言語自体は今後も使われていくだろう。 |
| ② | JavaEEも、これまでバージョンを重ねてきて、その度に複雑さを益し、自身の重みに耐えられなくなってきている。 |
| ③ | JavaEEは、基本的にSOA環境のために開発されたものではない。現在、SOA環境の実装の多くはJ2EEベースであるが、Javaには、オブジェクト指向、VMベースやn-Tierアーキテクチャ指向などの特徴があり、これらは理想的にはSOAプラットフォームには適さない。 |
| ④ | VMはコードのポータビリティのための仕組みであり、SOAがコントラクトによるメッセージング交換を主体としているのに対して、分散環境でのVMアーキテクチャはリモート・プロシジャー・コールを前提としている。 |
| ⑤ | JavaEEの主要な利点はプログラミングモデルの共通化であるが、コミュニケーションでデータを交換するSOAではプログラミングモデルの共通化は最重要の課題ではない。 |
| ⑥ | JavaEEは、スケーラブルなn-Tierアーキテクチャであり、プラットフォームに依存するサービスの開発には適するが、サービスを公開する抽象化Ｌａｙｅｒを必要とするエンタープライズ向けのSOAプラットフォームには適さない。 |
すべてを、そのまま受け取ることもできないのですが、私の意見としては、ひとつは、JavaEEはアプリケーションを開発するためのプラットフォームであり、エンタープライズ全体のインフラを支える基盤としては重過ぎるということと二つ目は、SOAは抽象化度を上げていくのが、アーキテクチャの目標となるべき課題であり、抽象化度を上げるためにはLayered構造になっていることが必然であるとするとMVCモデルのようなTiered構造ではアプローチとして無理があるということです。ただし、SCA（Service Component Architecture）などの動向を見極める必要はあります。
江川