Software-architecture-design-distributed-architecture
分散アーキテクチャ
分散アーキテクチャでは、コンポーネントは異なるプラットフォーム上に提示され、特定の目的または目標を達成するために、いくつかのコンポーネントが通信ネットワークを介して相互に連携できます。
- このアーキテクチャでは、情報処理は単一のマシンに限定されず、複数の独立したコンピューターに分散されます。
- 分散システムは、多層アーキテクチャのベースとなるクライアント/サーバーアーキテクチャによって実証できます。代替手段は、CORBAなどのブローカーアーキテクチャ、およびサービス指向アーキテクチャ（SOA）です。
- .NET、J2EE、CORBA、.NET Webサービス、AXIS Java Webサービス、Globus Gridサービスなど、分散アーキテクチャをサポートするいくつかのテクノロジーフレームワークがあります。
- ミドルウェアは、分散アプリケーションの開発と実行を適切にサポートするインフラストラクチャです。 アプリケーションとネットワークの間にバッファを提供します。 *システムの中央に位置し、分散システムのさまざまなコンポーネントを管理またはサポートします。 例としては、トランザクション処理モニター、データコンバーター、通信コントローラーなどがあります。
分散システムのインフラストラクチャとしてのミドルウェア
Concepts Distributed Architecture
分散アーキテクチャの基本は、その透明性、信頼性、および可用性です。
次の表は、分散システムにおける透過性のさまざまな形式を示しています-
| Sr.No. | Transparency & Description |
|---|---|
| 1 |
リソースへのアクセス方法とデータプラットフォームの違いを隠します。 |
| 2 |
Location リソースが配置されている場所を非表示にします。 |
| 3 |
Technology プログラミング言語やOSなどのさまざまなテクノロジーをユーザーから隠します。 |
| 4 |
Migration/Relocation 使用中の別の場所に移動される可能性のあるリソースを非表示にします。 |
| 5 |
Replication 複数の場所でコピーされる可能性のあるリソースを非表示にします。 |
| 6 |
Concurrency 他のユーザーと共有される可能性のあるリソースを非表示にします。 |
| 7 |
Failure ユーザーのリソースの障害と回復を隠します。 |
| 8 |
Persistence リソース（ソフトウェア）がメモリまたはディスクにあるかどうかを非表示にします。 |
利点
- リソース共有-ハードウェアおよびソフトウェアリソースの共有。
- オープン性-さまざまなベンダーのハードウェアとソフトウェアを使用する柔軟性。
- 並行性-パフォーマンスを向上させるための並行処理。
- スケーラビリティ-新しいリソースを追加することでスループットが向上しました。
- フォールトトレランス-フォールトが発生した後も動作を継続する機能。
デメリット
- 複雑さ-集中システムよりも複雑です。
- セキュリティ-外部からの攻撃を受けやすくなります。
- 管理性-システム管理により多くの労力が必要です。
- 予測不能-システム構成とネットワーク負荷に応じた予測不能な応答。
集中システムvs. 分散システム
| Criteria | Centralized system | Distributed System |
|---|---|---|
| Economics | Low | High |
| Availability | Low | High |
| Complexity | Low | High |
| Consistency | Simple | High |
| Scalability | Poor | Good |
| Technology | Homogeneous | Heterogeneous |
| Security | High | Low |
クライアントサーバーアーキテクチャ
クライアントサーバーアーキテクチャは、システムを2つの主要なサブシステムまたは論理プロセスに分解する最も一般的な分散システムアーキテクチャです-
- クライアント-これは、2番目のプロセスにリクエストを発行する最初のプロセスです。 サーバー。
- サーバー-これは、要求を受信して実行し、クライアントに応答を送信する2番目のプロセスです。
このアーキテクチャでは、アプリケーションは、サーバーによって提供される一連のサービスと、これらのサービスを使用する一連のクライアントとしてモデル化されます。 サーバーはクライアントについて知る必要はありませんが、クライアントはサーバーのIDを知っている必要があり、プロセッサーとプロセスのマッピングは必ずしも1対1ではありません。
クライアントサーバーアーキテクチャは、クライアントの機能に基づいて2つのモデルに分類することができます-
シンクライアントモデル
シンクライアントモデルでは、すべてのアプリケーションの処理とデータ管理はサーバーによって行われます。 クライアントは、プレゼンテーションソフトウェアを実行するだけです。
- レガシーシステムがクライアントサーバーアーキテクチャに移行されるときに使用されます。レガシーシステムは、クライアントに実装されたグラフィカルインターフェイスを備えた独自のサーバーとして機能します。
- 主な欠点は、サーバーとネットワークの両方に高い処理負荷がかかることです。
シック/ファットクライアントモデル
シッククライアントモデルでは、サーバーはデータ管理のみを担当します。 クライアント上のソフトウェアは、アプリケーションロジックとシステムユーザーとの対話を実装します。
- クライアントシステムの機能が事前にわかっている新しいC/Sシステムに最適
- 特に管理用のシンクライアントモデルよりも複雑です。 アプリケーションの新しいバージョンをすべてのクライアントにインストールする必要があります。
利点
- ユーザーインターフェイスの表示やビジネスロジックの処理などの責任の分離。
- サーバーコンポーネントの再利用性と同時実行の可能性
- 分散アプリケーションの設計と開発を簡素化します
- 既存のアプリケーションを分散環境に簡単に移行または統合できます。
- また、多数のクライアントが高性能サーバーにアクセスしているときにリソースを効果的に使用します。
デメリット
- 要件の変更に対処するための異種インフラストラクチャの欠如。
- セキュリティの複雑さ。
- サーバーの可用性と信頼性の制限。
- 限られたテスト容易性とスケーラビリティ。
- プレゼンテーションとビジネスロジックを併せ持つ太ったクライアント。
多層アーキテクチャ（n層アーキテクチャ）
多層アーキテクチャは、プレゼンテーション、アプリケーション処理、データ管理などの機能が物理的に分離されているクライアント/サーバーアーキテクチャです。 アプリケーションを層に分けることにより、開発者はアプリケーション全体を作り直す代わりに、特定のレイヤーを変更または追加するオプションを取得します。 開発者が柔軟で再利用可能なアプリケーションを作成できるモデルを提供します。
多層アーキテクチャの最も一般的な使用法は、3層アーキテクチャです。 3層アーキテクチャは通常、プレゼンテーション層、アプリケーション層、およびデータストレージ層で構成され、個別のプロセッサで実行できます。
プレゼンテーション層
プレゼンテーションレイヤーは、WebページやオペレーティングシステムGUI（グラフィカルユーザーインターフェイス）など、ユーザーが直接アクセスできるアプリケーションの最上位レベルです。 このレイヤーの主な機能は、タスクと結果をユーザーが理解できるものに変換することです。 他の層と通信して、結果をブラウザ/クライアント層およびネットワーク内の他のすべての層に配置します。
アプリケーション層（ビジネスロジック、ロジック層、または中間層）
アプリケーション層は、アプリケーションを調整し、コマンドを処理し、論理的な決定を下し、評価し、計算を実行します。 詳細な処理を実行することにより、アプリケーションの機能を制御します。 また、周囲の2つのレイヤー間でデータを移動および処理します。
データ層
このレイヤーでは、データベースまたはファイルシステムから情報が保存および取得されます。 次に、情報は処理のために戻され、ユーザーに戻されます。 データ永続化メカニズム（データベースサーバー、ファイル共有など）が含まれ、保存されたデータを管理する方法を提供するAPI（アプリケーションプログラミングインターフェイス）をアプリケーション層に提供します。
メリット
- シンクライアントアプローチよりもパフォーマンスが高く、シッククライアントアプローチよりも管理が簡単です。
- 再利用性とスケーラビリティを強化します。要求が増加するにつれて、サーバーを追加できます。
- マルチスレッドサポートを提供し、ネットワークトラフィックも削減します。
- 保守性と柔軟性を提供します
デメリット
- テストツールの不足による不十分なテスト可能性。
- より重要なサーバーの信頼性と可用性。
ブローカーの建築スタイル
ブローカーアーキテクチャスタイルは、分散コンピューティングで使用されるミドルウェアアーキテクチャであり、登録されたサーバーとクライアント間の通信を調整および可能にします。 ここでは、オブジェクト通信は、オブジェクトリクエストブローカー（ソフトウェアバス）と呼ばれるミドルウェアシステムを介して行われます。
- クライアントとサーバーは互いに直接対話しません。 クライアントとサーバーは、仲介業者と通信するプロキシに直接接続しています。
- サーバーは、インターフェースをブローカーに登録および公開することによりサービスを提供し、クライアントはルックアップにより静的または動的にブローカーにサービスを要求できます。
- CORBA（Common Object Request Broker Architecture）は、ブローカーアーキテクチャの優れた実装例です。
ブローカーのアーキテクチャスタイルのコンポーネント
ブローカーのアーキテクチャスタイルのコンポーネントについては、次のヘッドを通して説明します-
ブローカ
ブローカーは、結果や例外の転送やディスパッチなど、通信の調整を担当します。 呼び出し指向のサービス、ドキュメント、またはクライアントがメッセージを送信するメッセージ指向のブローカーのいずれかです。
- サービスリクエストの仲介、適切なサーバーの特定、リクエストの送信、クライアントへのレスポンスの返信を行います。
- サーバーは、機能やサービス、位置情報などのサーバーの登録情報を保持します。
- クライアントが要求するAPI、応答するサーバー、サーバーコンポーネントを登録または登録解除する、メッセージを転送する、サーバーを見つけるAPIを提供します。
スタブ
スタブは静的コンパイル時に生成され、クライアントのプロキシとして使用されるクライアント側に展開されます。 クライアント側プロキシは、クライアントとブローカーの間のメディエーターとして機能し、それらとクライアントの間の透過性をさらに高めます。リモートオブジェクトはローカルオブジェクトのように見えます。
プロキシは、プロトコルレベルでIPC（プロセス間通信）を非表示にし、パラメーター値のマーシャリングとサーバーからの結果のマーシャリング解除を実行します。
スケルトン
スケルトンは、サービスインターフェイスのコンパイルによって生成され、サーバー側に展開されます。サーバー側は、サーバーのプロキシとして使用されます。 サーバー側プロキシは、低レベルのシステム固有のネットワーク機能をカプセル化し、サーバーとブローカーの間を仲介する高レベルAPIを提供します。
リクエストを受け取り、リクエストをアンパックし、メソッド引数を非整列化し、適切なサービスを呼び出し、さらに結果を整列化してからクライアントに送り返します。
ブリッジ
ブリッジは、異なる通信プロトコルに基づいて2つの異なるネットワークを接続できます。 DCOM、.NETリモート、Java CORBAブローカーなどのさまざまなブローカーを仲介します。
ブリッジはオプションのコンポーネントであり、2つのブローカーが相互運用し、リクエストとパラメーターをある形式で受け取り、それらを別の形式に変換するときに実装の詳細を隠します。
- CORBAでのブローカー実装*
CORBAは、Object Request Brokerの国際標準です。OMG（オブジェクト管理グループ）によって定義された分散オブジェクト間の通信を管理するミドルウェアです。
サービス指向アーキテクチャ（SOA）
サービスは、明確に定義された自己完結型の独立した公開されたビジネス機能のコンポーネントであり、標準のプログラミングインターフェイスを介して使用できます。 サービス間の接続は、SOAP Webサービスプロトコルなどの一般的な汎用のメッセージ指向プロトコルによって行われます。このプロトコルは、サービス間で要求と応答を緩やかに配信できます。
サービス指向アーキテクチャは、アプリケーションがソフトウェアサービスとソフトウェアサービスコンシューマ（クライアントまたはサービスリクエスタとも呼ばれる）で構成されるビジネス駆動型ITアプローチをサポートするクライアント/サーバー設計です。
SOAの機能
サービス指向アーキテクチャは、次の機能を提供します-
- 分散展開-エンタープライズデータとビジネスロジックを、疎結合、結合、発見、構造化、標準ベース、粗粒度、サービスと呼ばれる機能のステートレスユニットとして公開します。
- コンポーザビリティ-明確に定義され、公開され、標準的な苦情インターフェイスを通じて、希望の粒度で公開されている既存のサービスから新しいプロセスを組み立てます。
- 相互運用性-基盤となるプロトコルや実装技術に関係なく、ネットワーク全体で機能を共有し、共有サービスを再利用します。
- 再利用性-サービスプロバイダーを選択し、サービスとして公開されている既存のリソースにアクセスします。
SOAオペレーション
次の図は、SOAの動作方法を示しています-
メリット
- サービス指向の疎結合により、企業はプラットフォームやテクノロジーの制限に関係なく、利用可能なすべてのサービスを利用できるようになります。
- ステートレスサービス機能により、各サービスコンポーネントは他のサービスから独立しています。
- 公開されたインターフェイスが変更されない限り、サービスの実装はサービスのアプリケーションに影響を与えません。
- クライアントまたはサービスは、プラットフォーム、テクノロジー、ベンダー、または言語の実装に関係なく、他のサービスにアクセスできます。
- サービスのクライアントは、そのパブリックインターフェイス、サービス構成を知るだけでよいため、資産とサービスの再利用性。
- SOAベースのビジネスアプリケーション開発は、時間とコストの面ではるかに効率的です。
- スケーラビリティを強化し、システム間の標準接続を提供します。
- 「ビジネスサービス」の効率的かつ効果的な使用。
- 統合がはるかに簡単になり、本質的な相互運用性が向上します。
- 開発者の複雑さを抽象化し、エンドユーザーにより近いビジネスプロセスを活性化します。
