SearchSOAのJack Vaughn氏の報告によれ(リンク)ば、先日行われたGartner AADI SummitでYefim Natis氏が「SOAは統合」と主張したそうだ。公正を期して言うなら、Natis氏はSOAと統合の同一視を意味したわけではない。
［SOAが］可能なのは、制御のきくドメイン部分のみです。多数の企業がSOAを実施していますが、それにはIT全体を網羅した独自のアーキテクチャ的青写真を伴っていません。中には、組織全体に及ぶ同意済みの相互運用プロトコルとトランスポートに基づいて、「ドメインSOA」の連合の試みを始めている人もいます。
従って、「統合」という言葉を使ってはいるが、Natis氏は実質的には「連合した」SOAについて話していたのであり、そうしたSOAでは、企業内の異なるグループや部門が複数のSOA実装を自由に開始でき、そして後にその実装を統合・連合して、結合したひとつの統一体にできる。それでも、Natis氏のコメントを受けて、Yahoo!のSOAディスカッションリストではすぐさま議論(リンク)が始まった！ 議論はMichael Poulin氏の次の質問から始まった。
そうした統合SOAの狂気が広まる速度を落とすには何ができるでしょうか。
Steve Jones氏はPoulin氏の質問を退け、Natis氏が説明したアプローチはBSB（ビジネスサービスバス）／DSB （ドメインサービスバス）(リンク)に類似していると主張した(リンク)。
- 私が長いこと話してきたBSB/DSBモデルは、まさしく連合したSOAモデルのことです。
- モデルが重要であり、技術が統合させます。
それとは別に、Anne Thomas Manes氏の返答(リンク)はSOAと統合の相違に集中した。
多くの組織がSOAは統合戦略であると誤認しています。SOAは統合戦略ではありません。SOAの目的はアーキテクチャです。SOAの達成には、システムの再構築が必要です。不要なものを取り除かなくてはなりません。いかなる組織にも物 — 不要になったアプリケーションやデータソース — が多すぎます。SOAの目的は家の掃除です。不要になったものを減らすまで、環境の単純化や、経費削減、アジャイルの獲得は不可能です…。統合とアーキテクチャ的な活動（構築活動）の区別が重要であると私は考えます。サービス指向のミドルウェアを利用して統合プロジェクトを実行するのは構いませんが、その際、あなたの期待を再調整する必要があります…。サービス指向アーキテクチャは大変な仕事です。破壊的です。政治的な地雷原です。アプリケーションポートフォリオを最初から最後まで検討し、廃止の上、単一のサービスで置き換え可能な不要アプリケーションを識別することです。ところが、そのような難題のフタを開けたがる人などいないのです。「壊れなければ、直すな」ということわざに従って行動する人がたくさんいます。他にすべきことが、たくさんありすぎるのです。
Rob Eamon氏は次のような意見をもって議論に参加している(リンク)。
「SOAは統合である」とは言いませんが、統合はSOアプローチの中核的な価値の１つであるという意見はもっています。サービスには１つ、あるいはそれ以上のインターフェースがあります。サービスとの相互作用を媒介するのはそうしたインターフェース（だけ）です。サービス（ならびにサービスクライアントなどの他の構成要素）は、独立した所有権ドメインに存在します。こうした特性は統合の心臓部です。SOでは、統合をあとからの思い付きで検討するというより、事前に検討する必要があります。
Miko Matsumura氏はSoftware AGでの経験を次のように話してくれた(リンク)。
ある意味、古い統合の世界の原因を作ったともいえるSoftware AG/webMethodsで働いているので、真の連合に対する要求を日々目にしていますが、それはインターフェースの一次元全体にわたるものではありません。統合から連合への確かな移行は、システムの調和から部門組織の調和に移行することです。我が社の戦略的な顧客は、コスト、複雑性、異種性、サイロ主義 、部門主義、コンサルタント主義、ベンダー主義を管理する方法を探し求めています。しかし、ビジネスプロセスやスキーマ、インターフェース、契約、ポリシー、プロフィール、資産、インフラ、VMなどの各方面で探しているのです。局地的な権力が（アジャイルという名の下に）バリエーションを急速に作り出すという自然な傾向であり、さらに、局地的な権力の中の可能な範囲内で（また時にはその範囲を越えて）、中央の権力が地位を固め、正常化し、統治し、さもなければ統制するという自然な傾向なのです。
Michael Poulin氏は次のように(リンク)議論に追加している。
統合と相互作用の相違は何でしょうか。恐らくこれが、SOAの目的が統合であるか否かをようやく判断できる方法でしょう。サービスを集めて組織化したプロセスにする際、それは統合でしょうか、それとも相互作用でしょうか。前述の質問に対する答えがわかった後なら、「統合戦略は企業レベルにおいてSOの原則を適用した副作用である」という意見に同意するでしょう。
Anne Thomas Manes氏は統合とSOAの相違を説明することにより、議論を続けている(リンク)。
統合を駆動するのは個々のプロジェクトであり、すなわち、多数の小さなステップをとりますが、わざわざ「大きな」局面を「考える」ことはありません。SOIをアプリケーションポートフォリオの強硬な管理と同時に行うなら、相違を心配する必要などないと思います。特定のプロジェクトの実行には違いがない傾向にあります。
Rob Eamon氏はコメントで(リンク)、SOAへの企業的なアプローチが重要であると再度強調している。
焦点を合わせる点については同感です。所定の状況において適切なレベルに焦点を合わせることです。アプリケーションの結合ではなく、構築もしくは公開される適切なサービスに焦点を合わせることです。しかし、統合がSOAの核心部分であるか否かは、それによって変わるとは思いません。SOの原則の目的は、サービスと、サービスの「外部」世界とのインターフェースを定義することです。再度申しますが、統合は焦点をあてるべき「対象」物ではありませんが、統合はSOAのひとつの事柄、というのが私の意見です。
SOAのアーキテクチャ的懸案事項と実装の懸案事項の区別を試みることにより、Steve Johns氏が議論に新次元を加えている(リンク)。
…どちらかといえば、統合とは何かについて議論しているように思われ、たとえば、プロセスとコレオグラフィは統合と考えられるか否か、より動的な相互作用モデルは統合と考えられるか否か、といった具合です。このディスカッションリストのほとんどの人たちが、SOAは主にガバナンス／組織的／ビジネス／思考の事柄ではあっても、実装と直接的な関係があるSOA技術が存在する、ということには同意すると思います。このグループで継続中の課題のひとつが、SOAに存在する２つの異なる世界なのです。
Anne Thomas Manes氏は統合とSOAの相違を説明することにより、議論を続けている(リンク)。
統合を駆動するのは個々のプロジェクトであり、すなわち、多数の小さなステップをとりますが、わざわざ「大きな」局面を「考える」ことはありません。SOIをアプリケーションポートフォリオの強硬な管理と同時に行うなら、相違を心配する必要などないと思います。特定のプロジェクトの実行には違いがない傾向にあります。
Mike Nibeck氏はZapthinkを引用し(リンク)、統合とSOAの違いを説明している。
ZapthinkではSOAと統合について非常に明確な解釈をしています。次のように述べています。主な要点を述べると、SOアーキテクチャにおいては、統合は組み立ての単なる１ステップもしくは一部分であり、プロセスや技術の独特かつ別個のセットとみなされることはもはやない、ということです。ほとんどの場合、統合の取り組みは２つ以上の異なるシステムをどうにかして「結合する」ことを目的としています。ところが、相互作用点が高レベルのビジネスサービス契約とすると、個々の統合点の関連性は低くなります。遠隔システムとの相互作用は常に必要であり、低レベルの詳細はいまだ伝統的な統合の取り組みに酷似しているでしょうが、こうした取り組みは、サービスモデルがうまくすれば個々の統合の取り組みから直接影響を受けないような、より大きなコンテキストで存在することになります。
- SOAのひとつの目標 − サービスを組み立てる副産物としての統合。
- レガシー統合の目標 − この目標を支援するためのサービスの構築であり、特定のビジネスニーズに対処するためにシステムを接続することでありません。
Loraine Lawson氏はYahooのグループディスカッションではなく、自身のブログでこの問題を扱っている(リンク)。
定期的にチェックしていない方のために申し上げると、これ［SOAと統合の関係］はSOAでは重要問題です。SOAはアーキテクチャであり、物事を結合する以上のことを目的にしている…という議論です。しかし、事実はこうです。ほとんどの企業は完全な再建を目的にSOAを始めているわけではありません。統合を単純化する上でSOAが非常に役立つという理由で、たいていの企業がSOAをデプロイします…。David Linthicumといった人たちは、アジリティがSOAのROIと信じているようですが、多数の企業が統合を通じてSOAのROIを実現しており…、SOA関係者の多数がSOAを行う真の理由として統合を否定すれば、それは自分たちやSOAに害を加えていることになります。ほら、SOAは統合に役立っているのですよ。なぜそれを喜んで認めないのでしょう…。ですから、「違います、 SOAは統合ではありません」と言った後で完全なオーバーホールを推奨する代わりに、SOA専門家は次のように試してみることができるのではないでしょうか。「もちろん、それで結構です！ 統合のためにSOAをデプロイしてください」、そして半年後に戻ってきてください。そうすれば、このアプローチを使って他に何が達成できるかについて話ができるでしょう。
それでは、SOAと統合の関係は本当のところどうなっているのか。アーキテクチャ的見地からいうと、エンタープライズ・アプリケーション・インテグレーション（EAI）は、
…ビジネスプロセスの単純化と自動化を可能な限り行うために、単一組織内のアプリケーションを相互にリンクしながら、それと同時に、既存のアプリケーションやデータ構造を全面的に変更する必要がないようにするプロセスです。
一方SOA(リンク)は、
…企業のビジネスソリューションの設計、構築、組み立ての基本ユニットとして、ビジネスに合わせた企業サービスの概念を奨励するアーキテクチャ様式です。
SOAの定義では、既存のITシステムにオーバーホールが必要とは述べていない。それどころか、成功を収めたSOA 実装の大多数は、既存アプリケーションの（統合を介した）再利用を基礎としており、その基礎の上に（サービス）合理化のかなり薄いレイヤを導入している(リンク)。統合とSOAの基本的な相違は(リンク)、
EAIとSOA両方の目標は似ている（既存のアプリケーションポートフォリオを使って企業のビジネスプロセスをサポート）ことが多いのですが、その達成方法は根本的に異なります。EAIは統合サービスを通じてアプリケーションの機能を公開することに焦点をあて、企業ビジネスモデルとして既存のアプリケーションポートフォリオを効果的に公開します。SOAは対照的に、既存のアプリケーションを隠し、その代わりにアプリケーションに依存しないビジネスサービス一式を公開することに焦点をあて、既存のアプリケーションポートフォリオの上に企業ビジネスモデルを計画します。
実装の観点からすると、Webサービスがトランスポートソリューションを提供する技術として現在進歩しているので、標準ベースの統合ソリューションと見なされることがたびたびある。これによりWebサービスは、EAI実装に代わる非常に魅力的な（そしてベンダーに依存しない）選択肢となる。エンタープライズサービスバス（ESB）製品の導入により、Webサービスベースかつ標準ベースの統合ソリューションがいっそう人気を博すことになる。