インテグレーションのパターンと実践
jミドルウェアの用語と定義
次の表は、ミドルウェアに関連する主要な用語と、各パターンで使用される場合の定義の一覧です。
| 用語 | 定義 |
|---|---|
| イベント処理 | イベント処理とは、識別可能な発生イベントが指定された受信者 (「ハンドラ」) で受信されることです。イベント処理に含まれる主要なプロセスは次のとおりです。
イベントハンドラは、最終的にイベントをイベントコンシューマに転送します。 この機能のミドルウェアでの一般的な使用方法を拡張し、よく使われる「公開/登録」 (pub/sub) 機能を追加することもできます。公開/登録シナリオでは、ミドルウェアが要求またはメッセージを有効なデータイベント公開者から有効なデータイベント登録者にルーティングします。それを受けて、有効なリスナーを持つこれらのコンシューマが、公開されたイベントを取得できます。 ミドルウェアを使用した Salesforce インテグレーションでは、イベント処理の制御をミドルウェアレイヤが担い、すべての関連イベント (同期および非同期) を収集して、Salesforce を含むすべてのエンドポイントへの配布を管理します。 または、Salesforce エンタープライズメッセージングプラットフォームでも、プラットフォームイベントと共にイベントバスを使用してこの機能を実現できます。 http://searchsoa.techtarget.com/definition/event-handler を参照してください。 |
| プロトコル変換 | プロトコル変換とは、「通常、ソフトウェアアプリケーションによって、あるデバイスの標準または独自プロトコルを別のデバイスに適したプロトコルに変換し、相互運用性を実現することです。 ミドルウェアの観点では、特定の対象システムへの接続はプロトコルによって制約されます。その場合、メッセージ形式を、対象システムの形式に変換またはカプセル化して、対象システムでペイロードを抽出できるようにする必要があります。これはトンネリングとも呼ばれます。」1 Salesforce は、ネイティブプロトコル変換をサポートしていないため、こうした要件をミドルウェアレイヤかエンドポイントで処理することが前提となります。 Https://www.techopedia.com/definition/30653/protocol-conversion を参照してください。 |
| 変換/加工 | 加工は、あるデータ形式を別の形式に対応付けて、インテグレーション対象のさまざまなシステム間で相互運用性を確保する機能です。通常、これには、送信者または受信者の要件に合うように配信途中でメッセージ形式を再設定することが含まれます。より複雑なケースとして、あるアプリケーションが独自のネイティブ形式でメッセージを送信し、他の複数のアプリケーションがそれぞれ独自のネイティブ形式でそのメッセージのコピーを受信する場合もあります。 ミドルウェア変換/加工ツールの多くには、レガシーのエンドポイントやその他の非標準エンドポイント用にサービスファサードを作成する機能が含まれています。この機能により、それらのエンドポイントがサービス対応可能であることがわかるようにすることができます。 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 ツールには変更データキャプチャ機能が搭載されています。この機能では、ツールが供給元システム内で前回の抽出以降に変更されたレコードを識別することで、レコード処理量を削減します。 Salesforce では、Salesforce レコードの変更を表す変更イベントが公開される Salesforce 変更データキャプチャもサポートされるようになりました。変更データキャプチャを使用すると、クライアントまたは外部システムは Salesforce レコードのほぼリアルタイムの変更を受信します。これにより、クライアントまたは外部システムは外部データストアの対応するレコードを同期します。 http://en.wikipedia.org/wiki/Extract,_transform,_load および『変更データキャプチャ開発者ガイド』を参照してください。 |
| long polling | long polling は Comet プログラミングとも呼ばれ、サーバからクライアントへの情報プッシュをエミュレートします。通常のポーリングと同様、クライアントがサーバに接続し、サーバに情報を要求します。ただし、使用できる情報がない場合は空の応答を送信するのではなく、サーバが要求を保留して、情報が使用できるようになるまで (イベントが発生するまで) 待機します。情報が使用できるようになると、サーバは完全な応答をクライアントに送信します。クライアントは情報を受け取るとすぐに、次の情報を再要求します。クライアントは、サーバへの接続を継続して維持するため、常に応答の受信を待機しています。サーバがタイムアウトした場合は、クライアントは再接続し、最初からやり直します。 Salesforce ストリーミング API は、long polling に Bayeux プロトコルと CometD を使用します。
|