サービス指向アーキテクチャ(SOA)の構築方法)
©.com|Bakhtiar Zein
この記事では、サービス指向アーキテクチャ(SOA)のトピックに焦点を当てます。 私たちは、1)SOA:説明について深く掘り下げ、次に2)サービス指向アーキテクチャの構築について議論することから始めます。
サービス指向アーキテクチャ：説明
SOAとは何ですか？
SOAまたはサービス指向アーキテクチャは、異なるタイプのサービスが独立して相互に対話できる方法です。 サービスは機能の自己完結型の部分であり、いくつかのサービスを組み合わせて、ソフトウェアアプリケーションの使用と機能を大規模に提供できます。 SOAが行うことは、ネットワークに接続されているPc上のソフトウェア部品が相互作用して協力することをより簡単にするということです。 SOAの設計パターンは、it内のアプリケーションコンポーネントが主にネットワークを介して他のそのようなコンポーネ それぞれのコンピュータシステムは、人間の助けなしにネットワーク内の他の異なるサービスと情報を交換するために構築された任意の数のサービスを
ビジネス用語では、SOAはビジネス企業の目標とプロセスに対処するビジネスに合わせたITサービスのセットです。 SOAの構造設計は、ビジネスの要件だけでなく、同じの技術的なソリューションとの整合があることを確認します。
SOAの主要な要素
SOAの主要な要素は次のとおりです:
- SOAドライバ–SOAドライバまたはエンタープライズ-ビジネス-ドライバには、競争、戦略、規制力、市場力などが含まれます。 これらすべては、ビジネスアーキテクチャを推進し、ビジネス全体のパフォーマンス管理
- SOAイネーブラーに形を与えるために一緒に来ています-五つの主なSOAイネーブラーは、エンタープライズビジネスモデル、ビジネスパフォーマンスの最適化、ポートフォリオ合理化、エンタープライズセマンティクスの定義と主要なパフォーマンス指標です。 ビジネスモデルを持つことは、ビジネスの目的と目標とサービスを正しく整列させるために重要です。 セマンティック情報モデルは，与えられた企業のための共通および一般的なビジネス関連情報を与える。 主要業績評価指標またはKpiは、SOAの影響の評価を可能にし、ビジネスプロセスの測定を容易にします。 一方、ポートフォリオの合理化は、アプリケーション、データ、インフラストラクチャの統合と簡素化を可能にします。
- SOAの実装–実装に関する限り、ビジネスサービスとプロセスが主な側面です。 ビジネスプロセスは主に業務のビジネス目標と目的に関連していますが、一方で、ビジネスサービスは適切に整列され、柔軟で成功したSOA実装には重 SOAの実装に関連する他の側面のいくつかは、エンタープライズコンテンツリポジトリ、セマンティックメッセージング、統合サービスです。 この情報は会社のデータリソースを表し、このデータは、サービスとプロセスの間に一種の意味論的メッセージを提供する文書の形で渡されます。
- SOAサポート–既存のアプリケーションやシステムのすべての機能と要素は、新しいサービスインターフェイスを介して既存の機能からカバーを外すいくつかの統
SOAの主な原則
以下はSOAの主な原則のリストです:
- サービスアーキテクチャ–サービスによって使用されたすべてのリソースを上回る個々のサービスの物理的なレイアウトまたは設計。
- サービス構成アーキテクチャ–サービス指向の設計手法を使用して開発されたすべてのサービスは、構成中心であり、これが主な特徴です。 したがって、このアーキテクチャは、さまざまなサービスの個々のアーキテクチャの構成です。
- Service inventory architecture–このアーキテクチャは、service inventory blueprintから形成され、service inventoryは企業の手順を自動化するサービスで構成されています。
- サービス指向エンタープライズアーキテクチャ-このタイプは、構成、サービス、インベントリアーキテクチャを構成します。
SOAコンセプトの進化
- モノリシック設計–この設計は、比較的非構造化手続き型コーディングに関連していました
- オブジェクトと構造指向設計–これは、機能性に基づくプログラムユニットを含む設計です。
- クライアント-サーバー設計(二層設計)-これは分散設計の概念であり、機能を二層にバンドルすることに関連しています。
- 分散オブジェクト設計(multitier design)–この設計には、異種環境でのオブジェクトの相互作用と分散オブジェクト設計が含まれます。
- コンポーネントオブジェクトモデルアーキテクチャ–これは、厳密な型だけでなく、明確に定義されたインターフェイスを持つロジックベースの部分に項目
- Service oriented architecture–これは、柔軟な相互運用のための標準インターフェイスとの粗いサービス間の相互作用と通信を含む設計です。
SOAとJAVA
多くの開発者は、SOAとwebサービスは互いに同義であると考えていますが、これは真実ではありません。 彼らはまた、webサービスを使用せずにSOAを構築することはできないと信じるかもしれませんが、実際にはSOAは設計原則ですが、webサービスは一種の実装技術 つまり、ある種の実装技術を利用することなく、実際にSOAを構築することができるということです。 しかし、Javaは、サービス指向アーキテクチャを開発または構築するために使用できる伝統的な技術の別の種類です。
SOAの主な目的は、モジュール間の疎結合を開発することであり、モジュールがあまりにも緊密に結合されていないアプリケーションを構築することがで この種の構造は、JAVAの助けを借りて構築または形成することができます。
SOAの特徴は何ですか？
- 接続の緩み–SOAのサービスは、1つの接続を形成するために緩くリンクされています。 これは、各サービス間の相互依存の少量を前提としています。 主なアイデアは、互換性がまだ維持されているレベルに相互依存を減らすことです。
- 標準化されたサービスインタフェース–SOAの基本的な要件の一つは、インタフェースの標準化と詳細の必要性です。 詳細には、必要なデータ、サービスの使用方法、およびルールの適用方法を含める必要があります。
- 再利用性–SOAでは、サービスの再利用性は他の当事者によってもプロセスチェーンの下でも可能であり、他のタイプの目的のためにも可能である。
- サービスの見つけやすさ–もう一つの特徴は、サービスを使用するためにはサービスを簡単に見つけなければならないということです。 すべての消費者にとって、サービスレポジトリは利用可能になり、そのようなリポジトリはサービスのインターフェイスと実装方法で構成されます。
- サービスの自律性–すべてのサービスは、独立して動作し、機能することができなければなりません。 この用語は、自給自足であり、リソース、ロジック、および環境を独自に管理できるサービスを指します。
- Capacity for service orchestration–これは、個々のサービスが他のサービスと組み合わされて、より大きなビジネスプロセスまたはユニットになるプロセスです。 これは、SOAのさらなる特性または要件です。
- サービスのステートレス–サービスのパフォーマンスは、定義されたサービスがレンダリングされるという概念に基づいています。 これは、要件が特に指定または要求されている場合にのみ、データの保持を考慮に入れます。
SOAの利点と利点
- より良い投資収益率–SOAの最大の利点の一つは、優れた投資収益率を提供することです。 このプロセスには堅牢なレイヤーの作成が含まれているため、これらの各サービスレイヤーは、ソフトウェアを作成するために行われた投資に対するよ
- コードモビリティ–これはSOAのもう一つの重要な利点であり、サービス指向アーキテクチャには場所の透明性があるため可能です。 ほとんどのクライアントは、動的バインディングとサービスへの参照があるため、サービスがどこにあるかを気にしません。 つまり、SOAを使用している企業は、サービスを別のマシンに移動したり、外部のサービスプロバイダーに移動したりできます。
- 再利用性–SOAのもう一つの利点は、さまざまなコードとサービスを何度も何度も使用できることです。 実行時サービスの再利用の利便性があり、ディレクトリ内のサービスを見つけてバインドするのと同じくらい簡単です。 開発者は、プラットフォームやその他の非互換性について心配する必要はありません。
- さまざまなクライアントタイプのサポート–どの企業でも、複数のクライアントタイプと複数のクライアントを使用してSOAのサービスにアクセ これは、このような構造または概念では、層がサービスに分割されており、クライアント層およびさまざまなクライアントタイプを実装する方が簡
- より高いレベルの可用性–SOAが場所の透過性をサポートしているため、複数のサーバーがそれらを使用するサービスのいくつかのケースを持っています。 これは、全体的な可用性が非常に高いことを意味します。 たとえば、マシンやネットワークの一部が動作を停止したり、問題が発生したりした場合、クライアントがそれを知ったり、それに悩まされたりすることなく、要求を他のサービスにリダイレクトすることができます。
- 欠陥が少ない–これはSOAの主な利点です。 欠陥の確率ははるかに低く、全体的なテストは、簡単にテストできるサービスの公開されたインターフェイスのためにはるかに優れています。 より多くのテストは正確さおよび少数の欠陥のより大きいレベルに翻訳する。
SOAの課題
- テストスペースの欠如–SOAにおける最大の課題の一つは、テストスペースの欠如です。 典型的なアーキテクチャでは、メッセージやデータベースサービスなどのヘッドレスサービスをテストするための整形式や高度なツールや方法はありません。 SOAの主な目的は、企業や企業に俊敏性を提供することです。 しかし、水平方向の信頼の欠如のために、挑戦を容易にするテストフレームワークに投資する必要があります。
- サービスメタデータの管理–これはSOAの一般的で非常に明白な課題です。 サービスメタデータの管理は難しいだけでなく、多くの場合非常に複雑です。 サービスベースの建築空間は、メッセージを交換することによって相互に相互作用するサービスを含む。 このようなシナリオでは、単一のサービスに何百万ものメッセージが生成されることがあります。 これらの多くのサービスを管理することは、特にサービスが会社内の異なる企業や部門によって提供される場合、非常に困難になる可能性があります。 これは多くの信頼の問題を作成します。
- 適切なレベルのセキュリティを提供する–SOAのもう一つの課題は、適切なレベルのセキュリティを提供することです。 アプリケーションに設計されたセキュリティモデルでは、アプリケーションが他のユーザーに自分自身を表示するときには十分ではないため、アプリケーシ
- 相互運用性–これはSOA実装の重要な側面になります。 多くの場合、サービスの相互依存性を減らしたり減らしたりするためには、それらの間の互換性が低下する可能性がありますが、依存性は互換性を維持
- ベンダーの誇大広告–SOAに関連するベンダーの誇大広告があり、これは一定のレベルの過度の期待を作成します。 SOAには多くの利点がありますが、いくつかの欠点もあります。 たとえば、SOAはITコストの削減を保証するものではなく、システムの俊敏性の向上を約束するものでもありません。 したがって、誇大宣伝と現実の間に明確な区別があった方が良いでしょう。
サービス指向アーキテクチャの構築
SOAフレームワーク
SOAがどのように構築されているかを理解するには、まずそのフレームワークが何であるかを理解す
は、5つの異なる水平層として表示されます。:
- コンシューマーインターフェースレイヤー-これらは、サービスまたはアプリのインターフェイスにアクセスするアプリです。
- ビジネスプロセスレイヤー-これは、アプリケーションに関するビジネスユースケースを表すサービスであるレイヤーです。
- サービス–多くのサービスは、企業全体を作成するために一緒にクラブされています。
- サービスコンポーネント–技術インタフェースや技術ライブラリなどのサービスを構築するために使用されるコンポーネントまたは部品です。
- 運用システム–技術パターン、データモデル、データリポジトリなどを含むレイヤーです。
以下は、SOAフレームワークの垂直層であり、水平層に適用され、サポートされています:
- 統合層-この層は、プロトコルのサポートまたはプラットフォームの統合、データ統合、アプリケーションおよびサービスの統合などで構成されます。
- サービスの質–サービスの質を構成する要因には、可用性、セキュリティ、パフォーマンスなどが含まれます。
- 情報–この層は主にビジネス関連の情報を提供する仕事をします。
- ガバナンス–この層またはIT戦略層は、必要に応じて能力と運用モデルに到達するために水平層によって支配されます。
SOA Implementation Framework(SOAIF)
SOAの実装には、ランタイムインフラストラクチャのソフトウェアとツールが必要であり、必要です。 これを総称して、サービス指向アーキテクチャ実装フレームワークまたはSOAIFと呼ぶことができます。 この概念は、ビジネスがSOAを構築するだけでなく、実行するために必要なあらゆる種類の技術を提供する包括的なフレームワークを目指しています。 SOAIFは、実行時と設計時の両方の機能で構成され、含まれています。 また、企業がSOAを実行し、サービス指向を含むSOAを構築するために必要なソフトウェア機能も含まれています。:
- モデリング
- 統合
- ツール
- 管理
- セキュリティ
- プロセス
SOAへのアプローチ
ビジネスにおけるクラブ情報、異種、システムには、三つの主要なタイプ さまざまなサービスプロバイダーや企業が顧客や消費者にソリューションを提供することに向かって競争するにつれて、これらのアプローチは、粗粒、緩くクラブ
1. Enterprise Service Bus
最適なSOAを構築して実装するのに役立つ最初のアプローチは、enterprise service busまたはESBです。 このアプローチは、ネットワーク上の分散サービスの形式であるさまざまな要素を調整して配置するのに役立ちます。 このアプローチでは、システムは、非同期のメッセージ指向インフラストラクチャを介して相互に接続する離散的で分散されたサービスであると考 この種のメッセージ指向のインフラストラクチャは、独立したサービスまたはモジュール間で疎結合接続を可能にします。
2. ビジネスプロセス管理
多くの企業は、長年にわたり、ビジネスプロセス管理アプローチの実装によってビジネスプロセスの問題を解決しようとして このアプローチでは、IT資産とシステムを、適切に同期され、適切に調整されたビジネス手順に参加する活動またはタスクとして考慮します。 BPMツールは、統合目標に達することができるプロセスを構築するために使用するのではなく、主にモデリングおよび設計手順の時に使用されます。 これがBPMの主な課題です。 Bpmソリューションは、疎結合モジュールに必要なランタイム環境で構成されていないため、SOA要件を満たすのに十分です。
3. サービス指向の統合
SOAを適切に実装するための第三の最後のアプローチは、サービス指向の統合アプローチです。 この特定のアプローチは、企業が動的に結合し、刻々と変化し、進化する要件を満たすことができる優れたレベルのプロセスを作成することができ、サービ このアプローチは、サービスの消費者と生産者を区別することによって、緊密に結合された脆いモジュールを過ぎて移動します。 したがって、ビジネス要件を満たすためにSOAを適切に実装するために必要な疎結合の側面を課します。 このアプローチ自体でさえ、サービス間の長時間の実行の相互作用を保証するには十分ではありません。
SOAを構築するためのベストプラクティス
SOAを構築する際には、最良かつ最も利点のあるプラクティスのいくつかに従わなければなりません。 これらの慣行は、次のように与えられています:
- 実装技術は非常に宣伝されており、その人気のためにそれらにジャンプしないことを覚えておく必要があります。 Webサービスがその要件と必要性に対してより理にかなっているかどうかを慎重に検討する必要があります。 Rmiのような技術を利用してサービス指向のアプリケーションを構築する方が、webサービスよりもビジネスのケースに適している可能性があることを覚えて
- 非常に緊密にリンクされたモジュールや結合されたモジュールを作成したり構築したりしないことを覚えておく必要があります。
- 相互運用性を維持することが重要であり、これらのためにはWS-Iのベストプラクティスに従わなければなりません。
- webサービスの使用に意味がない場合は、選択できる他の多くの代替オプションもあります。
