インテグレーションのパターンと実践
jミドルウェアの用語と定義
次の表は、ミドルウェアに関連する主要な用語と、各パターンで使用される場合の定義の一覧です。
| 用語 | 定義 |
|---|---|
| イベント処理 | イベント処理とは、識別可能な発生イベントが指定された受信者 (「ハンドラ」) で受信されることです。イベント処理に含まれる主要なプロセスは次のとおりです。
イベントハンドラは、最終的にイベントをイベントコンシューマに転送します。 この機能のミドルウェアでの一般的な使用方法を拡張し、よく使われる「公開/登録」(pub/sub) 機能を追加することもできます。 公開/登録シナリオでは、ミドルウェアが要求またはメッセージを有効なデータイベント公開者から有効なデータイベント登録者にルーティングします。それを受けて、有効なリスナーを持つこれらのコンシューマが、公開されたイベントを取得できます。 ミドルウェアを使用した Salesforce インテグレーションでは、イベント処理の制御をミドルウェアレイヤが担い、すべての関連イベント (同期および非同期) を収集して、Salesforce を含むすべてのエンドポイントへの配布を管理します。 |
| プロトコル変換 | プロトコル変換とは、「通常、ソフトウェアアプリケーションによって、あるデバイスの標準または独自プロトコルを別のデバイスに適したプロトコルに変換し、相互運用性を実現することです。 ミドルウェアのコンテキストでは、特定のターゲットシステムへの接続はプロトコルによって制約されます。 その場合、メッセージ形式を、ターゲットシステムの形式に変換またはカプセル化して、ターゲットシステムでペイロードを抽出できるようにする必要があります。これはトンネリングとも呼ばれます。」 1 Salesforce は、ネイティブプロトコル変換をサポートしていないため、こうした要件をミドルウェアレイヤかエンドポイントで処理することが前提となります。 http://searchsoa.techtarget.com/definition/event-handlerを参照してください。 |
| 変換/加工 | 加工は、あるデータ形式を別の形式に対応付けて、インテグレーション対象のさまざまなシステム間で相互運用性を確保する機能です。通常、これには、送信者または受信者の要件に合うように配信途中でメッセージ形式を再設定することが含まれます。より複雑なケースとして、あるアプリケーションが独自のネイティブ形式でメッセージを送信し、他の複数のアプリケーションがそれぞれ独自のネイティブ形式でそのメッセージのコピーを受信する場合もあります。 ミドルウェア変換/加工ツールの多くには、レガシーのエンドポイントやその他の非標準エンドポイント用にサービスファサードを作成する機能が含まれています。この機能により、それらのエンドポイントがサービス対応可能であることがわかるようにすることができます。 Salesforce インテグレーションを使用する場合、そうした要件がミドルウェアレイヤかエンドポイントで処理されることが前提となります。 データの加工は、Apex でコーディングできますが、メンテナンスやパフォーマンスを考慮するとお勧めしません。 http://en.wikipedia.org/wiki/Message-oriented_middlewareを参照してください。 |
| キューイングとバッファリング | キューイングとバッファリングは、通常、要求-応答アーキテクチャとは対照的な非同期のメッセージの受け渡しに依存します。非同期システムでは、送信先プログラムがビジーか、接続に障害がある場合、メッセージキューが一時的な保管場所となります。さらに、ほとんどの非同期ミドルウェアシステムは、メッセージキューのバックアップ用に永続的なストレージを提供しています。 非同期メッセージプロセスの主要な利点は、受信者アプリケーションに何らかの理由で障害が発生した場合、送信者が影響を受けずに処理を続行できることです。送信されたメッセージはそのままメッセージキューに蓄積され、後で受信者が処理を再開したら処理されます。 Salesforce では、ワークフローベースのアウトバウンドメッセージ方式で明示的なキューイング機能のみを提供します。他のインテグレーションシナリオ (オーケストレーション、プロセスコレオグラフィ、サービスのシナリオなど) 用に本格的なメッセージキューイングを提供するには、ミドルウェアソリューションが必要です。 http://en.wikipedia.org/wiki/Message-oriented_middlewareを参照してください。 |
| 同期伝送プロトコル | 同期伝送プロトコルとは、次のようなアクティビティをサポートするプロトコルのことです。「コール側の 1 つのスレッドが要求メッセージを送信し、遮断状態になって返信メッセージを待機し、受信した返信を処理します。(中略)。応答待ちの要求スレッドは、未処理の要求が 1 つのみであるか、このスレッドではこの要求の返信チャネルが非公開であることを暗黙的に示します」。2 |
| 非同期伝送プロトコル | 非同期伝送プロトコルとは、次のようなアクティビティをサポートするプロトコルのことです。「コール側の 1 つのスレッドが要求メッセージを送信し、返信用のコールバックを設定します。別のスレッドが返信メッセージをリスンします。返信メッセージが到着すると、返信スレッドが適切なコールバックを呼び出し、そのコールバックがコール側のコンテキストを再確立して返信を処理します。この方法により、複数の未処理要求が 1 つの返信スレッドを共有できます」。3 |
| 仲介ルーティング | 仲介ルーティングとは、コンポーネント間の複雑なメッセージフローを指定することです。たとえば、多くのミドルウェアベースのソリューションは、メッセージキューシステムに依存します。実装によって、メッセージングレイヤ自体でルーティングロジックを提供することを許可する場合と、クライアントアプリケーションにルーティング情報の提供を依存したり、両方の仕組みを併用したりする場合があります。こうした複雑なケースでは、(ミドルウェア上の) 仲介機能によって、開発、インテグレーション、および検証が簡素化されます。 「特に、仲介者はオブジェクトのグループを調整して、互いにどう調整されたかをオブジェクトが認識せずにすむようにします。(中略)。その結果、各コンシューマが特定の種類のメッセージに集中でき、調整者 [仲介者] は適切なメッセージを適切なコ��シューマに確実に配信できます」。4 |
| プロセスコレオグラフィとサービスオーケストレーション | プロセスコレオグラフィとサービスオーケストレーションはそれぞれ「サービスコンポジション」の形式であり、複数のエンドポイントと機能が調整されます。 コレオグラフィとサービスオーケストレーションには次の違いがあります。
「オーケストレーションは各サービスの完全な動作を示すのに対し、コレオグラフィでは各サービスのインターフェース動作記述が結合されます」。7) ビジネスプロセスコレオグラフィの各部分は、Salesforce ワークフロー内で、または Apex を使用して構築できます。Salesforce にはタイムアウト値とガバナ制限があるため、複雑なオーケストレーションはすべてミドルウェアレイヤに実装することをお勧めします (特にトランザクション処理が必要なソリューションの場合)。 |
| トランザクション性 (暗号化、署名、信頼できる配信、トランザクション管理) | トランザクション性とは、必要な各リソースに対するすべての必要な操作を網羅するグローバルなトランザクションをサポートする機能と定義できます。トランザクション性は、4 つの ACID (原子性 (atomicity)、一貫性 (consistency)、独立性 (isolation)、永続性 (durability)) プロパティすべてをサポートすることを暗黙的に示します。このうち原子性は、作業単位 (トランザクション) について「オールオアナッシング」の結果を保証します。 Salesforce は、内部的にトランザクション性を備えていますが、分散トランザクションや Salesforce の外部で開始されたトランザクションに参加することはできません。 したがって、複雑な複数システムトランザクションが必要なソリューションについては、トランザクション性 (および関連するロールバック/補正メカニズム) がミドルウェアレイヤに実装されることが前提となります。 http://en.wikipedia.org/wiki/Distributed_transactionを参照してください。 |
| ルーティング | ルーティングは、コンポーネント間の複雑なメッセージフローを指定することと定義できます。 最新のサービスベースのソリューションでは、こうしたメッセージフローは、ヘッダー、コンテンツタイプ、ルール、優先度などの複数の条件に基づいている可能性があります。 Salesforce インテグレーションを使用する場合、そうした要件がミドルウェアレイヤかエンドポイントで処理されることが前提となります。メッセージルーティングは、Apex でコーディングできますが、メンテナンスおよびパフォーマンスを考慮するとお勧めしません。 |
| 抽出、加工、読み込み (ETL) | 抽出、加工、読み込み (ETL) とは、次の操作を含むプロセスを指します。
厳密に必要というわけではありませんが、多くの成熟した ETL ツールには変更データキャプチャ機能が搭載されています。この機能では、ツールがソースシステム内で前回の抽出以降に変更されたレコードを識別することで、レコード処理量を削減します。 http://en.wikipedia.org/wiki/Extract,_transform,_loadおよびhttp://en.wikipedia.org/wiki/Change_data_captureを参照してください。 |