ESBレベルでプロキシキャッシュを作成するための前提条件と、あるバージョンから別のバージョンに切り替える理由を説明します。 大手銀行のいずれかで決定が実施された後、それは放棄され、現時点ではその運命は完全にはわかっていません。 この記事の目的は、提案されたソリューションが提供する考え方と機会を共有することです。
コンテキスト
アプリケーションビジネスプロセスは、標準の形式で
request_queue Tibco EMS要求をキューに入れます。
<request> <service>service_name</service> <client>client_id</client> <requestData>request_data</requestData > <replyTo>response_queue</replyTo> </request>
- service_name-いずれかのIPによって実装されたサービスの名前
- client_id-呼び出しが発生するクライアントの識別子
- request_data-サービスへのリクエストの本文
- response_queue-非同期応答のキュー名
Tibco BW統合プロセスは
service_nameを解析し、要求を適切なサービスにリダイレクトします。 サービス応答は
response_queueキューに配置され、アプリケーションプロセスによって取得されます。
<response> <service>service_name</service> <client>client_id</client> <responseData>response_data</responseData > </response>
一部のサービスは数秒間応答し、一部のサービスは数十秒間応答します。 これは、申請プロセスには長すぎます。 特に、同じ要求を同じまたは異なるアプリケーションプロセスで繰り返すことができると考える場合。
これらは、プロキシキャッシュを作成するための論理的な前提条件です。
最初のバージョンと前提条件
プロキシオプションが実装されました。 彼は、さらなる改善の前提条件となった多くの機能を持っていました。
1：ビジネスデータストレージ
各サービスの応答は、ビジネスデータとして個別のデータベーステーブルに保存されました。 そのため
、さまざまなシステムのクライアント識別子の
リストは 、列のあるテーブルに保存されていました。
2：DBレベルのロジック
各サービスの応答には、データベースレベルで独自のサービスロジックがありました。 そのため、
クライアント識別子は XML応答から解析され、更新日とともに提供され、データベースに保存されました。
3：アプリケーションプロセスからデータベースへのアクセス
適用されたプロセスのロジックは、データベースの構造に関連付けられていました。 その
ため、システムのクライアント識別子は、テーブルの対応するフィールドにアクセスすることにより取得されました。
4：アプリケーションプロセスの追加機能
アプリケーションプロセスロジックには、キャッシュ関連性サポート機能がロードされました。 そのため、データベースに実際の値がない場合、プロセスは対応するサービスへの要求を開始し、データベースの値を更新しました。
5：いくつかのレベルでの変更
新しいビジネスデータをキャッシュする必要があるため、いくつかのレベルで変更が必要でした。 その
ため、システムのクライアント識別子に新しい属性を追加する必要があります。
- テーブルに新しいフィールドを追加します
- XML解析ロジックの変更
- 関連するアプリケーションプロセスで新しい列の名前を指定する
タスク
前提から、ソリューションを改善するために多くのタスクが発生しました。
1：単純化
サポートを促進し、潜在的なエラーの数を減らすために、既存のメカニズムを簡素化する必要がありました。
2：新しいサービスを接続するときの透明性
新しいサービスをキャッシュしたり、既存のサービスを変更したりする手順を簡単で理解しやすいものにする必要がありました。
3：接続性の削減
アプリケーションプロセスを変更せずに、プロキシを独立してさらに最適化するために、プロキシを個別のレイヤーに分離することは魅力的と思われました。 また、キャッシュを保存するためのツールとして、データベースとのプロキシ接続を減らして、置き換えを可能にします。
解決策
新しいプロキシバージョンは、受信キューを備えた別個のサービスとして実装されました。 アプリケーションプロセスは、
request_queueリクエストをプロキシにキューイングします。
<request> <service>proxy</service> <client>client_id</client> <requestData> service_name request_data live_time </requestData > <replyTo>response_queue</replyTo> </request>
- live_time - service_nameサービスからの応答時間
パラメータ
service_nameおよび
client_idに基づいて、プロキシはクライアント
client_idの service_nameサービスからの現在の応答をキャッシュで検索します。 応答がある場合、
service_nameサービスからの応答として
response_queueキューに送信されます。 回答がない場合、
service_nameサービスへのリクエストが生成されます。
<request> <service>service_name</service> <client>client_id</client> <requestData>request_data</requestData > <replyTo>proxy_response_queue</replyTo> </request>
- proxy_response_queue-サービス応答の着信プロキシキュー
応答が
proxy_response_queueキューに到着すると、キャッシュに保存されます。 次に、プロキシ
応答が
response_queueキューに配置されます。
<response> <service>service_name</service> <client>client_id</client> <responseData>response_data</responseData > </response>
キャッシュには、サービス応答が完全にXMLとして保存されることに注意してください。
利益
開発コストを回収するソリューションの利点は次のとおりです。
1：実装の容易さ
このメカニズムにはデータベースレベルのロジックはなく、限られたテーブルセットが含まれています。 リストとテーブル構造は、キャッシュされたサービスとは無関係です。
2：アプリケーションのオフロード
アプリケーションプロセスはプロキシを要求し、最新の応答を受け取ります。 プロキシメカニズム自体が、キャッシュ内の実際の応答の可用性を判断し、必要に応じて、サービスへの要求を生成し、応答を受信して保存します。
3：カプセル化
プロキシ機能は、エントリポイントが固定された別のメカニズムにカプセル化されます。 キャッシュ（データベース）は交換可能であり、アプリケーションプロセスから直接アクセスすることはできません。
4：汎用性
キャッシュされたサービス応答の構造とビジネスデータのニーズを変更する場合、プロキシを調整する必要はありません。
5：透明性
新しい応答をキャッシュするには、管理プロキシ設定が必要です。
ご清聴ありがとうございました！