SOA（サービス指向アーキテクチャ）とは何ですか？
必要に応じて私をトロールと呼んでください。しかし、私は真剣です：新しいSOAトレンドは、15年前に構築していたクライアントサービスアーキテクチャとどのように違うのですか？私は聞き続けていますSOAしかし、私たちがいつもやってきたこととどう違うのかわかりません。
10年前、私の会社には同じサービスと通信する複数のクライアント（複数の言語）がありました。これはXMLではなく（Microsoft DCOMと呼ばれるバイナリプロトコルでした）、WSDLによる自動検出はありませんでしたが、ドキュメントを読むのも同じくらい簡単だったので問題ありません。私たちのシステムは、サードパーティが私たちのサービスと話すことができるように十分に文書化したという意味で「オープン」でさえありました。私たちはパイオニアではありませんでした-10年前に私が知っていた他のすべての会社が同じことをしていました。
当時と現在の唯一の違いは、インターネット上で利用できるサービスが1つしかないのに対し、10年前は、各顧客が独自のサービスインスタンスをホストしていたことです。しかし、それはアーキテクチャの問題ではありません。サービスが物理的に存在する場所は、サービスを使用するすべての人に対して透過的です。
では、SOAこれは私たちが何年もやってきたこととは違うのですか？SOAは、実際に一般的になったベストプラクティスを表す単なるマーケティング用語ですか？ずっと昔ですか？それとも、SOAこれまでずっとやってきたこととは違う、微妙に欠けているのでしょうか？
XMLを忘れてください。 WSDLを忘れてください。 SOAは購入できるテクノロジーではありませんが、そのように販売されることがよくあります。
SOAの本当のポイントはすべてITについてです組織。SOAのポイントは、大量の「アプリケーション」を持たないようにすることです。 「データプールが分離されていて、相互に通信しない（したがって、データが重複することが多い）か、アダプタ層またはEAIシステムを介して非効率的でバグのある方法でしか通信しない。
大企業にとって、これは深刻な問題です。文字通り何百もの個別のアプリが十分に統合されていません。どこにでも重複した一貫性のないデータがあり、その結果、請求部門がキャンセルされた注文の請求書を送信し続け、注文追跡でキャンセルされたために顧客サービス担当者が注文を見つけることができないため、顧客は腹を立て、実際のお金が失われますシステムですが、課金システムではありません。
SOAは、他のアプリがデータにアクセスでき、データを複製する必要がないように、標準化されたクロスプラットフォーム方式でサービスを公開するようにすべてのアプリをゼロから設計することでこれを解決することになっています。
ビジネスの観点から、これは非常に望ましいことです。流行語の誇大宣伝と頭字語のスープは、IT企業がその望ましさを利用しようとする試みにすぎません。残念ながら、これにより、CEOを含む多くの人々が、SOAは購入できる製品であり、これが次の場合にのみ発生することに気付かずに、魔法のようにITをより効率的にするだろうと信じ込ませています。また、IT全体（および場合によってはビジネスユニットも）をSOA互換になるように再編成します。
Integration Hellの有名な鞭打ち少年：Telcoを使用させてください。
90年代にさかのぼると、私の近所では携帯電話会社が多忙で、90年代半ばの通信規制緩和によって可能になった長距離再販業者とほぼ同じくらい豊富でした。さて、時が経ち、ベルアトランティックはベライゾンである大国になり、会社を次々と飲み込みます（そして少なくとも1つのベイビーベル）。これらの企業はすべて、タワー、スイッチング機器、課金システムなど、互いに完全に互換性のないテクノロジーを導入しています。
それで会社は立ち去り、ビジネスのやり方についてこれらのモデルがあります。WSDL/ SOAP/XSDの形ですべてのテクノロジーに友好的で一貫した顔を向けましょう-今日私たちが持っているすべての言語とシステムはこれに接続してください！ゆっくりと、しかし確実に、同社はすべてのシステムを機能について報告し、負荷と請求の目的で調査し、将来の先見者がまだ説明されていない方法で悪用できるようにしています。
誰でもSOAクライアントを構築できます。wgetとテキストエディタを持っている人なら誰でも。そして誰でも結果（XML）を解析できます。
これが、過去のクライアント/サーバーアーキテクチャとは根本的に異なる点です。先日、CobolベースのシステムとSmalltalkベースのシステムをSOAアーキテクチャに接続することについて誰かと話していました。これは簡単に解決できる問題です。DCOMシステムについても、同じことが言えます。
SOAは設計の方法に他なりませんであり、モジュールは「サービス」を介して相互に通信します。それだけです。次の質問は、正確に「サービス」とは何であり、通常の「メソッド」との違いは何ですか？
サービスは、単一のアトミックなビジネス操作を実行する操作です。この原子性により、多くのモジュールから非常に再利用可能になります。その場合、複雑な事業運営は、これらのサービスの多くを特定の順序で呼び出すためのオーケストレーションにすぎません。
SOAは特定のテクノロジーとは何の関係もなく、特定の設計方法にすぎません。
シュトゥットガルト大学の Frank Leymann 教授は、 [〜＃〜] soa [〜＃〜] を彼の サービス指向コンピューティング（SOC）の重要な概念として取り上げています。彼がSOAについて話すときの研究作業 。彼はSOAの定義について尋ねられているようで、その後の会話は良い読み物になるでしょう。
ロードマップは「サービス指向コンピューティング（SoC）」、つまりサービス指向の背後にあるコンピューティングパラダイムに関するものであることに注意してください。サービス指向アーキテクチャー（SOA）は、このコンピューティングパラダイムのアーキテクチャーによる実現です。これを、パラダイムとしての「クライアント/サーバーコンピューティング」、およびこのパラダイムの2つの（他のさまざまな）アーキテクチャ上の実現としての「ブラウザ/ Webサーバー」または「DBクライアント/ストアドプロシージャ」と比較できます。
.。
SOAは完全に新しいものではありません。 SOAのいくつかの個別の側面は、実際には長い間使用されています。たとえば、「疎結合」を見てください。企業は、アプリケーションを統合するために、つまり疎結合のために、信頼できるメッセージングテクノロジーを数十年にわたって使用しています。誤解しないでください。SOAには新しい概念があります。たとえば、SOAにまとめられた概念の組み合わせから生じる概念、つまり出現から生じる概念です。
Webサービスの仕様により、対応するテクノロジーがクロスプラットフォームで利用できるようになります。つまり対応する仕様は、根本的に新しい概念を発明するものではありませんが、これらの概念と対応する実装が異種環境でどのように機能するかを定義します。結果として得られる相互運用性は画期的であり、SOAを現実のものにします。
要約すると、SOAは、成熟したものと新しいものが混在しています。
2006年4月付けの SoCペーパーリファレンス もあります。
Neal Fordは、SOAに関して多くの強い意見を持っています。彼の視点が面白いと思うかもしれません。
SOAはマーケティング用語であり、既存のソリューションを統合したものであり、ソフトウェアやマシン全体を販売するのではなく、サービスを販売するという考えです。
私にとって、サービス指向アーキテクチャーは、企業が、共通のドメインに関係するさまざまなアプリケーションの選択を、単一のデータソースに対して動作する相互運用可能なサービスのセットに統合したいときに生まれます。
ソフトウェアのアイテム/ソフトウェアのスイートのアイデアを持っている新しいスタートアップ企業の場合、企業がサービス指向アーキテクチャを最初から始める方法がわかりません。最初に、各ソリューション（相互運用可能になる可能性のあるサービスに進化する可能性があります）は、問題領域を分離して解決しようとする必要があります。
おそらく、ソリューションが完成してサービスに入るときに、各ソリューションのエンタープライズ機能またはスイートが相互運用可能なサービスになるためのロードマップに含まれるでしょう。このため、おそらく開発チームは、ソリューションをサービス指向アーキテクチャーにサービスとして含めることを容易にするために、ソリューション（最終的なサービス）を構築するためのモジュラー/コンポーネント指向のアプローチに着手します。
ソフトウェアの既存のアイランドがサービス指向アーキテクチャで相互運用可能なサービスになる場合、このアプローチにより、ソフトウェアアイテム（配布され、異なる言語で記述される場合があります）が公開されたAPIや共通プロトコルを介して通信できるようになります。 （たとえば、Webサービスのフレーバー）および一般的なデータ形式（たとえば、XML）。
SOAはアプローチまたはアイデアです。フレームワークやツールではありません。 WDSLとEJBの名前が削除されると、これは忘れられることがよくあります... SOAの概念はまったく新しいものではありません。
実際、SOAは、クライアントサービスアーキテクチャも利用しています。さらに、SOAは、ソフトウェアを設計する方法です。アプリケーションが単純なものになり、本の検索、新しい本の追加、ユーザーの好みに応じた本の推奨などの独立したタスク。各タスクのサービス（API）を検討する場合、実際にはSOAを使用しています。このアーキテクチャの利点はWebアプリやモバイルアプリを構築している場合でも、必要なのは前述の開発済みサービス（API）のみです。
サービス指向アーキテクチャ（SOA）は、ソフトウェアがビルディングブロックとして設計されているアーキテクチャパターンです。つまり、モジュラー開発。これにより、自由に組み立てることができます。ゼロから始めるのではなく、新しいプロジェクトを開始したい場合は、サービスを再利用できます。新しいサービスが必要な場合は、既存のサービスと簡単に統合して新しいプロジェクトを作成できます。そのため、時間とお金を大幅に節約できます。サービス指向アーキテクチャの基本原則は、ベンダー、製品、テクノロジーに依存しません。
アナロジー：おもちゃはレゴのビルディングブロックを使用して構築されます。
実際には、SOAは明確に定義されたサービスのコレクションです。基本的にSOAは疎結合サービスを使用して、目的の結果を簡単に取得します。サービスの実装の詳細はクライアント/コンシューマーから隠されているため、実装の変更は、それらの間の契約が変更されるまでサービスに影響しません。サービスプロバイダーは、事前に定義された入力と出力に基づいていくつかのビジネスロジックを実行し、SOA実装を通じてこの機能を公開するコンポーネントです。これにより、SOAに基づくシステムは、ビジネスに対してより迅速かつコスト効率よく対応できます。コンポーネントとSOAの主な違いは、SOAは、プログラミング言語やプラットフォームに固有ではないオープンスタンダードメッセージを提供することです。その結果、プラットフォームやテクノロジー間で高度な疎結合と相互運用性を実現できます。従来のクライアントサーバーの世界では、プロバイダーがサーバーになり、コンシューマーがクライアントになります。SOAの詳細については、こちらをご覧ください： サービス指向アーキテクチャー（SOA）
ここでの回答のほとんどは、SOA (Service Oriented architecture)が標準化された方法でアプリケーションを構築し、他のアプリケーションがプラットフォームに依存しない方法でアプリケーションと対話できるようにすることを伝えているようです。
それ以来、意味が変わったかどうかはわかりませんが、SOAスイートを提供している会社と仕事をする機会がありました。以下は、それについての私の考えです。
もちろん、アプリケーションを設計するときに、クロスプラットフォームに準拠することを保証することはできません。例として_stock Trading systems_を取り上げます。彼らは_Fix protocol_を使用してメッセージを転送します。 SOA準拠）と呼ばれるように、XML形式でデータを返すことを期待していますか？絶対にそうではありません！SOAは、役立つアーキテクチャアプローチです。あなたは_decouple your application/services_し、それらを相互作用させます。SOAのバックボーンは、あるサービスから別のサービスにデータを転送するために使用されるESB (Enterprise Service Bus)です。SOAアーキテクチャはフォーマット変換を処理する必要があります。たとえば、-
_FIX(Service 1) -> (XML ---ESB---> XML) -> JSON (Service 2)
_これらの変換モジュールは一般にadaptersと呼ばれ、通常SOAスイートの一部です。もう少し詳しくは、別の回答を参照してください-
SOAとESB の違い
確かにSOAは、マーケティング目的で誇大宣伝されているWordです。技術的に言えば、データの逆シリアル化とシリアル化と同じくらい簡単なので、サービスを分離してプラットフォームに依存しませんが、その背後にある考え方は具体的です。
同じことについては Wikiページ も参照してください。