この記事では、この製品の開発のコンテキストで、IBM WebSphere ESB（以降-ESB）に特化したシリーズを開きたいと思います。 そして、まず第一に、あなたはこの種の技術をよりよく知る必要があります。
エンタープライズサービスバス（エンタープライズサービスバス）-サービス指向アーキテクチャの原則に基づいて、さまざまな情報システム間で一元化され統合されたイベント指向のメッセージングを提供するミドルウェア。
もちろん、特別なソフトウェアなしでこのアプローチに基づいて企業システムを構築し（おそらく共通の何かを開発する必要があるかもしれません）、結果をサービスバスに呼び出すことができます。 しかし、IBMの製品には、このプロセスを集中的にメッセージングおよび制御するための既製のデバイスだけでなく、ESB専用の柔軟なサービス指向アプリケーションを開発するためのフルセットの機能もあります。 要約すると、IBM WebSphere ESBの以下の機能と利点を強調できます。
- 建築関係の秩序と均一性
- 集中管理
- サーバー側のアプリケーション構成
- サービス指向アーキテクチャ原則の精神でのService Component Architecture（SCA）テクノロジーの実装
- 開発したプログラムコードのプロトコル非依存
- 広範なバスおよびアプリケーション構成オプション
同時に、ESBはトランザクション制御、データ変換、セキュリティ、および保証されたメッセージ配信を提供します。 単一のポイントを介してすべてのサービスサービスにアクセスすると、サービスの通信を一元的に構成できます。 また、大量エラー処理のために失敗したイベントを一元管理できます。
従来のESBビルドトポロジは、水平方向のスケーラビリティとフォールトトレランスを提供するクラスターです。 公式の推奨事項によれば、クラスターメンバーの数を増やすと、スタンドアロントポロジでサーバーの容量を増やすよりも効率的に生産性が向上します。 さらに、サービスを停止せずにクラスターを再起動できます（またはその一部が失敗する場合があります）。
通常、ESBはIBM BPMのサービスレイヤーとして使用されますが、強力な統合デバイスとしての企業システムの相互作用のモデルを構築する上で主要な役割を果たす可能性があります（IBM WebSphere Application ServerのアドオンとしてのESBを意味します）。
実際、これは「サービス収集ポイント」であるため、ESBから必要です。他のサービス（おそらく外部）と連携するサービスが必要な場合、これらのサービス間の統合はESBで最も論理的です。 外部サービスまたは異種サービスの場合、ESBサービスで「ラッパー」を作成できます。 サービスに「シングルハウジング」を使用する便利さを少し説明しましょう。
ご注文
システムが大きいほど、順序と均一性が重要になります。 大企業の複雑なシステムについて話している場合、それは確かに大規模システムと呼ぶことができます。 もちろん、何百ものサーバーの相互作用スキーム、または各モジュールの相互作用の内容を説明する関連性の低いドキュメントの束を念頭に置いた管理者をいつでも見つけることができます。
しかし、自分ですべてのやり取りを実行できるサービス（ESB）を使用する方がはるかに簡単です。 このアプローチにより、サブシステムの相互作用アーキテクチャの一部はすでに明確になっています。システム、サーバー、アプリケーション間の接続に混乱はありません。すべてがESBに接続され、ESBがすべてに接続されます。
集中管理
システムの構成、移動するサーバーへの適応、フォールトトレランスの提供、負荷分散、エラー処理または監視と分析など、システムを一元的に構成する方が常に便利です。
たとえば、データベースサーバーを移動する場合、既存のすべてのアプリケーションサーバーの構成にアクセスする必要はありません。特に、特定のアプリケーションの設定では、ESBにデータベースアドレスが示された環境変数が1つあれば十分です。
または、外部システムの1つが長時間使用できず、そのシステムへの要求が失われない場合は、サービスを使用して、失敗したイベントを処理し、必要に応じて見逃したメッセージを「スロー」できます。
システムへの同時リクエストの数を調整する必要がある場合、またはこれらのリクエストを監視する場合は、負荷を分析し、ボトルネックを探します-メッセージングコントロールセンターにアクセスする必要があります-ESBサーバーのコンソールにアクセスします。
サーバー側の構成
構成の観点から見ると、サービスの「シングルハウジング」を使用すると、いくつかの有用な目標を達成できます。 まず、これは構成の再利用です（SOAで非常に便利なコードとモジュールの再利用に似ています）。異なるモジュールとアプリケーションが同じデータベース接続パラメーター、リソース、認証パラメーター、環境変数などを使用できるためです。 。
第二に、サーバー側で設定する場合、さまざまな方法でテストに影響を与えることができるのはアプリケーション環境です。これにより、アプリケーションを変更せずに、異なるループ間でアプリケーションを転送し（テストと生産的）、調整し、バグを修正することさえできます。
これらのすべての利点を使用すると、アプリケーションは真のカメレオンの機能を取得します。アプリケーションは非常に柔軟であるため、作業環境の一部になり、同時に重要な機能をもたらします。
ただし、IBM WebSphere ESBのアプリケーションの柔軟性は、その環境に限定されません。 開発能力はこれに多大な貢献をします。 システムはどこで実行するかだけでなく、開発および開発する必要があるため、これらの興味深い点を見逃してはなりません。
SCA
このアーキテクチャは、コンポーネントが他のコンポーネントで利用可能なサービスの形で機能を提供するという原則に基づいています。 1つのモジュール内のコンポーネントは、対応するインターフェイスで記述された特定の機能を完全に実装するプログラムブロック（Javaコード）です。 コンポーネント実行のロジックは、それらをインターフェースおよび参照の構造にリンクすることで実装されます（パートナーリファレンス）。
このようなモジュール構造の開発、検証、開発、修正、および保守は非常に便利です。 コンポーネントに実装された機能の原子性により、コードレベルに落ちることなく、コンポーネント全体を操作できます。 一方、トランザクションコンテキストでのコンポーネントの実装を考慮すると、論理的に必要です。
各コンポーネントには、その実装が提供するインターフェースがあります。 したがって、コンポーネントを一緒にリンクすると、それらの内部機能を知る必要はありません-必要なインターフェースを実装すれば十分です。
このアーキテクチャを使用すると、「手動」フロー制御なしで並列操作を必要とするすべてのタスクを解決することもできます（たとえば、応答が遅延する複数のコンポーネントに対して非同期呼び出しを行うことができます）。
たとえば、エクスポートおよびインポートタイプの非Javaコンポーネントを使用すると、それぞれ外部使用のサービスを提供したり、外部サービスを使用したりできます。 Mediation Flowコンポーネントは、他のコンポーネント間で交換されるメッセージへの低レベルのアクセスを提供し、異種インターフェースを操作する際にさまざまな変換を可能にします。
インターフェースに加えて、IBMビジネスオブジェクトフレームワークは非常に便利な機能を提供します。 xsd-schemesで表されるビジネスオブジェクト（BO）は、コンポーネント間およびモジュール間の通信の両方で、インターフェイスでのデータ転送のオブジェクトとして使用されます。 たとえば、Webサービスを記述するためのwsdlスキームに直接統合されています。 つまり、たとえば、モジュール「A」がWebサービスの形式でその機能を提供する場合、モジュール「B」については、インターフェースと既製のBOを接続して使用するだけで十分であり、追加のJavaを作成せずにそのようなサービスで完全に動作することができます-データ転送用のオブジェクト。 BOは、他のコンポーネントがこのデータを使用する場合、データベースとデータを交換するときにも便利です（もちろん、これは「DAO」パターンに反しますが、不要なJavaオブジェクトとデータを「前後に」書き換える操作を排除します）。
プロトコル独立
ご覧のとおり、プロトコルに依存しないコードは、エクスポートおよびインポートコンポーネントを使用して実現されます。 これらのコンポーネントとの通信はインターフェースと参照を経由するため、プログラムコードは相互作用に使用されるプロトコルから完全に独立しています。 任意の数のサポートされているプロトコルと任意のインターフェースを介して、まったく同じ機能に簡単にアクセスできます。 次の図は、HTTP、JMS、およびWebサービスとしてインターフェースをすでに提供しているコンポーネントへのSCAバインドエクスポートの追加を示しています。
利便性は明らかです-柔軟性、汎用性、コードの再利用、開発と修正の速度。
ところで、SCAバインディングは特別なプロトコルを使用し、同じサーバー/クラスター内のモジュール間の通信を目的としています。 このバインディングによる相互作用は、他のプロトコルよりもリソース集約的でなく、高速です。
構成
サーバーとアプリケーションの構成は、IBMコンソールサーバーを介して行われます。
一般にIBM WebSphereのようにESBには、特定の機能と成果物がかなりあります。 たとえば、同じインポートとエクスポートを使用する場合、対応するサービスのエンドポイントをその場で構成できます。 サービスコールの場合、さまざまなルールでポリシーセットを設定できます（たとえば、クライアントが動作する同じトランザクションでWebサービスを呼び出すことができるWS-ATメカニズムのサポートをインストールできますが、トランザクション性は記事全体のトピックです）。認証パラメーターの設定、証明書の接続など。
構成により、例外的な状況に自動的に対応するためのメカニズムをいくつか構成できます（たとえば、エラーが発生したときにコンポーネントの実行を自動的に繰り返す）。 コンポーネントのトレースをその場で構成したり、ログレベルを変更したりできます。 失敗したイベントを管理するサービスも利用できます。これは、大量エラー処理のために意図的に使用できます。
もちろん、Java2EE仕様に従って他の多くのものを構成することができます。Java2EE仕様は、IBM Application Serverに実装される場合がありますが、非常に厳密です。
上記のすべては、ESBは便利で強力かつ柔軟な統合デバイスであると主張していますが、習得するのは必ずしも簡単ではありません。 将来的には、使用方法を学ぶ必要があります。
この記事では次の画像を使用しています： 1 2 3 4 5