まず、何であるSOAアーキテクチャ
SOAアーキテクチャモデルでは、必要に応じて展開し、ネットワークを介して疎結合粗粒アプリケーションコンポーネントの組み合わせの使用を分散させることができます。サービス層であるSOAの基盤は、直接効果のソフトウェアとシステム依存ヒューマンエージェントインタラクションを制御するために呼び出さ適用することができます。
SOAは、鍵となる「サービスコンセプト」。それは、サービス指向アーキテクチャとしてあるモデルと方法論ソフトウェアアーキテクチャの設計です。ビジネスの観点から、すべて最大にするために、「サービスの出発点としての価値」、既存のソフトウェアシステム事業のSOAの使用、再統合をし、ソフトウェアアーキテクチャの新しいセットを構築します。ソフトウェアアーキテクチャは、ビジネスと企業全体のビジネス・システムに新しいソフトウェア、一般的なサービスを形成するために、いつでも既存のサービスを組み合わせるための柔軟性を変更することができます。我々は置くことができます理解するのは簡単、モジュラーコンポーネントとしてSOAを、各モジュールは独立した機能を実装することができ、かつ異なるモジュール間の結合が異なるサービスを提供することができ、モジュール間のインタフェースは、統一基準を達成することができ従ってくださいリストラや再編の低コスト。ではSOA技術フレームワークの場合、それが最大達成するために、それによって開発プロセスのエンタープライズビジネスアプリケーションシステムの柔軟性を高め、包括的かつ秩序あるシステムに巨大な混沌としたシステムを置くことができるIT資産の活用を。
、もののに存在する異なるベンダーまたは個人でSOA異なる理解を有するがために理解SOAのいくつかの重要な特性は同じである：粗粒、疎結合サービスアーキテクチャの一種、インターフェースの単純、正確な定義とサービスとの間で通信しますこれは、基礎となるプログラミング・インタフェースと通信モデルを必要としません。
それを注意することが重要であるためには、SOAは新しいものではありません。大成功したIT組織を構築し、展開し、多くの年の歴史のSOAアプリケーションを。しかし、SOAは、既製の技術ではなく、建築や組織のITインフラとビジネス機能へのアプローチ。SOAような開発方法は、より良い管理の利点を持っています。
SOAの第二に、基本的な特性
SOAの実施形態は、実質的に、いくつかの別個の特徴を有します。実装主要な目標は、SOAのエンタープライズ達成することである再利用を最大化するためにIT資産を。この目標を達成するためには、実装に必要な心の中でクマプロセスにおけるSOAの次の特性：
① 企業アクセス外部から利用可能と
高度な使用してビジネスパートナB2B協定（ebXMLのまたは互いに組み合わせのRosettaNetを）。ビジネスパートナーは、ビジネス情報ベースのビジネス上の目的を交換するときは、合格B2Bプロトコルセッションの作成を完了すること。そして、外部ユーザーによるビジネス・サービスのWebサービスを提供します。
サービス利用者がサービスを要求すると、SOAは、応答するために、サービスプロバイダの存在が必要です。ほとんどのSOA同期アプリケーションなどのポータルアプリケーションにできており、非同期B2Bアプリケーションのようなサービスを提供しています。
② 粗粒度サービス・インターフェース
粗粒度のサービスは、特定のビジネス機能を提供し、きめの細かいサービスは、技術コンポーネントのメソッドを表します。粗粒度のサービス・インターフェースを使用することの利点は、もはやユーザとサービス層、往復十分間を複数回往復しないことです。
③ 分類
粗粒度のサービスなどのサービスについての議論は設計が困難粗粒度のサービスは、特定のビジネス上の問題を解決する傾向があるので、きめの細かい差よりも再利用可能なサービスであるため、貧しい汎用性、再利用性。この論争を解決する1つの方法は、粗粒の異なるレベルでサービスを作成できるようにすることです。サービスのこのクラスはまた、粗粒、再利用性が悪いサービスを含んで、きめの細かい、高い再利用性のサービスが含まれています。
サービス種別の点で、サービスは、バックグラウンド層によって開示されているサービスシステムが（通常であることに留意すべきであるBESのAPOS）またはSOA既存のローカルサービスプラットフォーム組成物。したがって、サービス層の民間サービスの創造を可能することは非常に重要です。正しい文書の再利用のための構成管理や民間サービスIT部門が重要なのは、急速に新しい公共サービスを開発するためのSOAサービス層の能力に影響を与えています。
④ 疎結合
SOAは有する「疎結合他のほとんどのコンポーネントアーキテクチャとは異なる」コンポーネントサービスを、。この方法は、顧客サービスとどのようにサービスの利用を分離することを実現するために、サービス利用者とサービスプロバイダーを目指しています。サービスの変更は、サービス利用者に影響を与えません達成することを可能にされ、重要なサービス・インターフェースは、別のエンティティとして実装され、サービスが存在します。
ほとんどのメソッドは、疎結合メッセージングサービスベースのインターフェイスに依存しています。メッセージベースのインタフェースは、伝送モードの様々な互換性、および送信のさまざまな方法を使ってできます。疎結合と文書主導のためのWebサービスSOAサービス・インターフェースを話すが重要な基準です。
顧客がメッセージクラス呼び出すと、Webサービスを、顧客は通常、（例えば発注書など）完全なドキュメントではなく、パラメータの離散集合を送信します。Webサービスは、文書全体が処理される受け、その結果は、情報を返さない場合があります。クライアント以来とWebサービス要求応答の間には密結合が存在しない、メッセージクラスのクライアントとサーバ間でWebサービスがより多くの疎結合を提供します。
⑤ 再利用可能なサービス
再利用可能な設計サービスの原則にあれば完全に基づい、SOAは、アプリケーションがより柔軟になる可能になります。再利用可能なサービスは、開発者のために多くの時間を節約し、共通のフォーマットを使用して、重要なビジネス機能を提供します。再利用可能なサービスのデザインは、データベース設計または類似の一般的なデータモデリングで最も貴重な作品です。サービス設計が成功の鍵であるので、それゆえ、そのためSOAの実装は、サービス設計プロセス管理の適切な方法を探す必要があります。
サービスデザインサービス設計管理は、サービスの設計は、2点間の妥協を必要とし、根本的な問題です。戦術的なプロジェクトや企業がユニバーサルサービスの再利用可能な長期的な目標を構築するショートカットを取ります。
プロジェクトの短期的な目標を超えてサービス・インターフェースを開発し、評価することであるサービス・インターフェースの正確な定義に向けた重要なステップですが、また、ドキュメンテーション、サービス・インプリメンテーション文書とすべての重要な非機能機能セットの基準をインタフェースする必要があります。
大規模な組織での再利用のための前提条件は、再利用や共通性の正しさを保証するために、一般的な（設計段階）図書館サービスや開発プロセスを確立することです。また、サービスの設計と開発サービスのアカウントに文書ライブラリー・サービス・アセスメントの使用の成功の鍵となります。
要するに、サービスの再利用性を提供することを保証することはできませんルールに従って書き込みませんSOAの実装を成功さを。金融費用を生産するルールの実装の過程で、我々は、開発する必要があるとき、SOAの実装計画検討します。
⑥ サービス・インターフェースの設計管理
Webサービスは、標準化されたインタフェース（経由で機能するアプリケーションを有効に提供WSDL）、および標準化された伝送モード（に基づくことができるHTTPと標準化されたプロトコル（使用して、JMS）、SOAP）呼出しを。使用、WebサービスやXMLを作成し、それをより汎用性の高いようになりますSOAアプリケーションを、。
⑦ 標準化されたサービス・インターフェース
SOAに以下のメッセージモードがあるかもしれません。ではSOAの実装、メッセージサービスの異なるモードのミックスが頻繁に発生します。
*ノーステータスメッセージ。プロバイダにユーザーによって送信される各メッセージは、メッセージのすべての情報に必要なプロバイダのプロセスが含まれている必要があります。これは、よりスケーラブルで、ユーザの状態情報を格納せずに、そのサービスプロバイダを定義します。
*ステータスメッセージがあります。ユーザーとプロバイダは、ユーザー環境の特定の情報、メッセージプロバイダとユーザー交換に含まれる情報を共有しています。これは、プロバイダとユーザ間の通信より多くの柔軟性を定義するが、サービス・プロバイダは、ユーザごとに共有環境情報に格納されなければならないので、全体的なスケーラビリティが著しく弱体化するからです。これは、強化された結合関係サービスプロバイダーとユーザーを定義し、サービスの難易サービスプロバイダを切り替えるを向上させます。
*べき等メッセージ。繰り返しの影響を送信し、単一のメッセージのソフトウェアに同じメッセージを送信します。これは、プロバイダを有効にして、消費者は単にサービスの信頼性を向上させるために障害が発生した場合にメッセージをコピーすることができます制限しました。
⑧は 、メッセージング様々なモードをサポートしています
サービスを提供し、ユーザー定義の間の契約により提供されます。契約の条項及び最終結果は、サービスを利用するユーザが所望します。また、それができるまた、どのサービスの品質を提供します。ここで注意すべき重要な点は、サービス契約が正確に定義されなければならないということです。
第三に、あなたが使用することができます行うためにSOAを？
SOAのニーズサービスを提供する必要性から来ているITシステムは、ビジネスの変化に適応するために、より柔軟になります。関係の定義強く、まだ柔軟性の具体的な実装を可能にすることにより、ITシステムはまた、それらの間の相互作用のニーズを満たすために、将来的にいくつかの変更を行う準備ができ、既存システムの機能を利用することができますが、どちらか。
ここでは具体的な例です。衣料品小売組織が持つ500件の国際店舗を、彼らはしばしば、ファッショントレンドに追いつくために設計を変更する必要があります。これは、スタイルや色を変更する必要はないだけで意味するかもしれない、とさえ布、メーカーや製品の配信を交換する必要があるかもしれません。小売業者とメーカー間のシステムに互換性がない場合は、1つのサプライヤからの交換の他のサプライヤーにそれはソフトウェアプロセスの非常に複雑な作品かもしれません。利用することで、既存システムの現状を維持することができ、各会社の運用面でWSDLインターフェースの柔軟性を、単にマッチングあなたはそれらのソフトウェアシステムの再構築を完了していないので、WSDLインターフェースと新しいサービスレベルアグリーメントの開発を。これはつまり、彼らはパートナーを変更、サービスのレベルの変化であり、そして基本的にすべての事業活動は同じまま。ここでは、ビジネスインタフェースは、内部動作を変更する必要はありませんでしたが、ただ外部のパートナーと協力することができるようにそうしました、少し変更を行うことができます。
この変更では、組織は今ではいくつかの場所でチェーン店の小売店を小売りすることを決定した内部変更の別の形態は、店舗のお店（使用して見ることができブティック小さな店に借りstore-を店舗内の）ビジネスモデル。ここでは、ものの、同社の業務の大半は同じままですが、彼らは今、このような賃貸契約を処理するための新しい内部のソフトウェアが必要です。それは内部ソフトウェアシステムの完全なオーバーホールを買う余裕ができますが、彼らはそうしながら、既存の取引先システムとの相互作用に大きな影響を持っている必要はありませんが。この場合、内部実装が変更されながら、SOAモデルは、無傷のままです。あなたはに新しい次元を追加することもできますが、通常通り継続する責任のための新たな賃貸契約が、通常の小売管理システムを追加するSOAモデル。
内部の変化の概念を拡張するためには、IT管理者は、新しいコンフィギュレーション・ソフトウェアはまた、ローカル広告のためのレンタル貼り付けポスターとして、道の別の種類で使用することができるかもしれません。ここでは、新しい柔軟な設計で再利用による新たなビジネス提案SOAモデルを導出しました。これはからであるSOAモデルにおける新たな成果、そしてまた新しい機会であり、この新しい機会が過去に存在しない可能性があります。
垂直方向の変更は、この変更では、小売業者からの完全な変換が独占レンタル場所を通じてショップのモデル店に自分の服を販売し、可能です。垂直方向の変更が完全に下から起動した場合、それがもたらすSOAのモデル構造に大きな変化を、また一緒に新しいシステム、ソフトウェア、プロセス、および変更との関係を有することができます。この場合、SOAモデルの利点は、それが企業経営を行い、問題を検討するために、業務やプロセスの観点からではなく、アプリケーションやプログラムの観点から問題を検討することで明確なビジネスの操作に基づいているかを判断することができ、追加、変更する必要があり、または削除。ソフトウェアシステムは、ビジネスプロセスではなく、多くの既存のソフトウェア・プラットフォーム上の他の方法がしばしば見られる方法に合わせて設定することができます。
ここで、変更、および変化に適応するためのSOAシステム容量は最も重要な部分です。開発者のため、またはそのような変化は、変化があるか否かに応じて、自分の仕事の範囲外の仕事の範囲内で起こる可能性があり、それらは、インタフェースが定義されている方法の間でどのように互いに知っておく必要があるかどうか対話。違いは、開発者で、建築家の役割はに上昇を与えることであるということであるSOAモデル大きな変化。労働者のこの部門では、それは歴史の十年以上になっている、開発者はサービスのように定義された機能ユニットの作成に集中し、建築家やモデラーが適切に一緒にこれらの要素を整理する方法に焦点を当ててみましょうできるようにすることです通常、統一モデリング言語（ユニバーサルモデリング言語、UML）、及び（モデル駆動型アーキテクチャとして記述モデル駆動型アーキテクチャ、MDAの）。
ベースのアプリケーション指向の同期および非同期の要求のための分散コンピューティング/応答パターンは、SOAは革命です。アプリケーション（のビジネスロジックビジネス・ロジック）または特定の個々の機能をモジュール化し、消費者や顧客へのサービスとして提供されます。これらのサービスへの鍵は、その疎結合の特性です。例えば、インタフェースと実装サービスの独立しました。アプリケーション開発者やシステムインテグレータは、サービスの基礎となる実装を理解することなく、一つまたは複数のサービスの組み合わせを適用することによって構築することができます。例えば、サービスを使用することができます。NETまたはJ2EE達成するために、異なるプラットフォーム上ですることができ、サービスアプリケーションを使用するために、使用される言語は異なる場合があります。
第四に、SOAアーキテクチャの目的と意義
設計されたソフトウェア製品SOAのアーキテクチャと本当の目的や意味がある：元、シームレスなデータ統合ソフトウェアから残さ保全や保護ソフトウェア（データ）事業は、企業は、リピートデータ入力元投資メイクセンスを避けます。これは、ソフトウェア製品のプロモーションの実施を短縮することが可能となります。プロモーションの実施中に素早く顧客満足の最大の程度に調整することができます。クライアントアプリケーションビジネスの変化は、あなたが新しい投資、変革をしなければならない場合には、新製品には互換性があり、直接またはサードパーティ製の機器（ハードウェアおよびソフトウェア）の急速な拡大することができます。したがって、製品自体の剛性を避け、ユーザーのレガシーシステムを構成しています。SOAアーキテクチャは見ることができるB / Sモデルがある技術のXML / Webサービス後の自然な拡張。これは、エンタープライズアーキテクチャ、展開形の理解の新たなレベルのさまざまなコンポーネントの開発に立つために私たちを助けることができる、それが全体の業務システムの高速化、より信頼性が高く、多くの再利用可能な構造のエンタープライズシステムアーキテクトに役立ちます。今までよりもSOAベースのシステム、より冷静に、より適応性の劇的なビジネスの変化に直面することができます。