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