(57)【要約】本開示は、ＦＩＸプロトコルに基づくサービス実施方法、装置及びシステムを開示し；インターネット技術の分野に関連し、サービスプラットフォームでのＦＩＸサービス環境を展開する際の高コストの問題を解決する。本開示における前記方法は以下を含む：送信側によって、ＦＩＸパケットをＦＩＸメッセージにカプセル化し、前記ＦＩＸメッセージをサービスプラットフォームに送信するするステップ；送信側によって送信されたＦＩＸメッセージを、サービスプラットフォームによって受信するステップであって、前記ＦＩＸメッセージは異なるタイプのサービスデータを含み、前記サービスデータは文字列形式である、前記受信するステップ；前記サービスデータ内のサービスタイプ情報に基づいて前記ＦＩＸメッセージに対応するサービススクリプトを求めてスクリプトリストを検索するステップであって、前記スクリプトリストは異なるＦＩＸプロトコルバージョンに対応するサービススクリプトを格納し、前記サービススクリプトはサービスロジックを含む、前記検索するステップ；前記サービススクリプトを実行し、前記サービスロジックに基づいて前記サービスデータを処理するステップ。本開示は、主として、ＦＩＸプロトコルにおけるセッション層サービスロジックの実施に適用される。
2019512138.tif 000002
【特許請求の範囲】
【請求項１】
送信側によって送信されるＦＩＸメッセージを、サービスプラットフォームによって受信するステップであって、前記ＦＩＸメッセージは異なるタイプのサービスデータを含み、前記サービスデータは文字列形式である、前記受信するステップと；
前記サービスデータ内のサービスタイプ情報に基づいて前記ＦＩＸメッセージに対応するサービススクリプトを求めてスクリプトリストを検索するステップであって、前記スクリプトリストは異なるＦＩＸプロトコルバージョンに対応するサービススクリプトを格納し、前記サービススクリプトはサービスロジックを含む、前記検索するステップと；
前記サービススクリプトを実行し、前記サービスロジックに基づいて前記サービスデータを処理するステップと；を備える、
金融情報交換ＦＩＸプロトコルに基づくサービス実施方法。
【請求項２】
前記ＦＩＸメッセージは普遍的ＦＩＸメッセージにカプセル化される、
請求項１に記載の方法。
【請求項３】
普遍的サービスロジックを前記サービスプラットフォーム上のプロトコルコードに書き込むステップであって、前記普遍的サービスロジックは任意のサービスタイプに適用可能である、前記書き込むステップ；を更に備える、
請求項１に記載の方法。
【請求項４】
送信側によって送信されるＦＩＸメッセージを受信する前記ステップの後：
前記サービスデータ内のメッセージタイプ情報に基づいて前記ＦＩＸメッセージのメッセージタイプを特定するステップと；
前記メッセージタイプがアプリケーション層メッセージを示した場合、アプリケーション層メソッドを呼び出してアプリケーション層で普遍的サービスロジックを実行するステップと；
前記メッセージタイプがセッション層メッセージを示した場合、セッション層メソッドを呼び出してセッション層で普遍的サービスロジックを実行するステップと；を更に備える、
請求項３に記載の方法。
【請求項５】
セッション層メソッドを呼び出してセッション層で普遍的サービスロジックを実行する前記ステップは：
前記普遍的サービスロジックが前記セッション層におけるシーケンス番号再設定ロジックである場合、セッションシーケンス番号が所定の最大シーケンス番号に達すると、前記セッションシーケンス番号を０に再設定するステップ；又は、
前記普遍的サービスロジックが前記セッション層における取引拒否ロジックである場合、セッションシーケンス番号を再設定するステップが失敗すると、前記ＦＩＸメッセージの処理を拒否するステップ；又は、
前記普遍的サービスロジックが前記セッション層におけるキュークリアロジックである場合、メッセージキューによって占有されたキャッシュが所定のキャッシュ閾値を超えると、前記メッセージキュー内のキャッシュ格納されたＦＩＸメッセージをクリアするステップ；を備える、
請求項４に記載の方法。
【請求項６】
ＦＩＸサービスが追加された場合、前記追加されたＦＩＸサービスのサービスロジックを含むサービススクリプトを取得するステップと；
前記取得されたサービススクリプトを前記スクリプトリストに追加するステップと；を更に備える、
請求項１に記載の方法。
【請求項７】
非ＦＩＸプロトコルベースパケットの場合、前記非ＦＩＸプロトコルベースパケットのカプセル化規則に基づいてパケットパーサを選択するステップと；
前記パケットパーサを用いて前記非ＦＩＸプロトコルベースパケットのデータストリームを解析してサービスデータを取得するステップと；を更に備える、
請求項１に記載の方法。
【請求項８】
処理されたＦＩＸメッセージを受信側へ送信するステップを更に備える、
請求項１に記載の方法。
【請求項９】
受信されたＦＩＸメッセージに対して、複数のコンピューティングノードを用いて分散処理を実行するステップであって、各コンピューティングノードは少なくとも１つのセッションのＦＩＸメッセージを処理する、前記実行するステップを更に備える、
請求項１乃至請求項８のいずれか１項に記載の方法。
【請求項１０】
送信側によって、ＦＩＸパケットをＦＩＸメッセージにカプセル化するステップであって、前記ＦＩＸメッセージは異なるタイプのサービスデータを含み、詳細なＦＩＸプロトコルバージョンに対応するサービスロジックを含まず、前記サービスデータは前記文字列形式である、前記カプセル化するステップと；
前記カプセル化されたＦＩＸメッセージをサービスプラットフォームへ送信するステップであって、前記サービスプラットフォームはサービスロジックを含むサービススクリプトに基づいて前記サービスデータを処理する、前記送信するステップと；を備える、
金融情報交換ＦＩＸプロトコルに基づくサービス実施方法。
【請求項１１】
金融情報交換ＦＩＸプロトコルに基づくＦＩＸパケットをＦＩＸメッセージにカプセル化する前記ステップは、前記ＦＩＸパケットを普遍的ＦＩＸメッセージにカプセル化するステップを備える、
請求項１０に記載の方法。
【請求項１２】
前記ＦＩＸパケットを普遍的ＦＩＸメッセージにカプセル化する前記ステップは：
前記ＦＩＸパケットのヘッダ及び本文から文字列を抽出して普遍的ＦＩＸメッセージをアセンブルするステップ；を備える、
請求項１１に記載の方法。
【請求項１３】
送信側によって送信されたＦＩＸメッセージを受信するように構成された受信ユニットであって、前記ＦＩＸメッセージは異なるタイプのサービスデータを含み、前記サービスデータは文字列形式である、前記受信ユニットと；
前記サービスデータ内のサービスタイプ情報に基づいて前記ＦＩＸメッセージに対応するサービススクリプトを求めてスクリプトリストを検索するよう構成された検索ユニットであって、前記スクリプトリストは異なるＦＩＸプロトコルバージョンに対応するサービススクリプトを格納し、前記サービススクリプトはサービスロジックを含む、前記検索ユニットと；
前記サービススクリプトを実行し、前記サービスロジックに基づいて前記サービスデータを処理するよう構成された実行ユニットと；を備える、
金融情報交換ＦＩＸプロトコルに基づくサービス実施装置。
【請求項１４】
前記受信ユニットによって受信される前記ＦＩＸメッセージは普遍的ＦＩＸメッセージにカプセル化される、
請求項１３に記載の装置。
【請求項１５】
普遍的サービスロジックをサービスプラットフォーム上のプロトコルコードに書き込むよう構成された書込ユニットであって、前記普遍的サービスロジックは任意のサービスタイプに適用可能である、前記書込ユニットを更に備える、
請求項１３に記載の装置。
【請求項１６】
前記送信側によって送信された前記ＦＩＸメッセージが受信された後、前記サービスデータ内のメッセージタイプ情報に基づいて前記ＦＩＸメッセージのメッセージタイプを特定するように構成された特定ユニットを更に備え；
前記実行ユニットは、前記メッセージタイプがアプリケーション層メッセージを示す場合、アプリケーション層メソッドを呼び出してアプリケーション層で普遍的サービスロジックを実行するように構成され；
前記実行ユニットは、更に、前記メッセージタイプがセッション層メッセージを示す場合、セッション層メソッドを呼び出してセッション層において普遍的サービスロジックを実行するよう構成された、
請求項１５に記載の装置。
【請求項１７】
前記実行ユニットは：
前記普遍的サービスロジックが前記セッション層におけるシーケンス番号再設定ロジックである場合、セッションシーケンス番号が所定の最大シーケンス番号に達すると、前記セッションシーケンス番号を０に再設定する；又は、
前記普遍的サービスロジックが前記セッション層における取引拒否ロジックである場合、セッションシーケンス番号を再設定することに失敗すると、前記ＦＩＸメッセージの処理を拒否する；又は、
前記普遍的サービスロジックが前記セッション層におけるキュークリアロジックである場合、メッセージキューによって占有されたキャッシュが所定のキャッシュ閾値を超えると、前記メッセージキュー内のキャッシュ格納されたＦＩＸメッセージをクリアする；ように構成された、
請求項１６に記載の装置。
【請求項１８】
ＦＩＸサービスが追加された場合、前記追加されたＦＩＸサービスのサービスロジックを含むサービススクリプトを取得するように構成された取得ユニットと；
前記取得されたサービススクリプトを前記スクリプトリストに追加するよう構成された付加ユニットと；を更に備える、
請求項１３に記載の装置。
【請求項１９】
非ＦＩＸプロトコルベースパケットの場合、前記非ＦＩＸプロトコルベースパケットのカプセル化規則に基づいてパケットパーサを選択するように構成された選択ユニットと；
サービスデータを取得するために前記パケットパーサを用いることによって前記非ＦＩＸプロトコルベースパケットのデータストリームを解析するように構成された解析ユニットと；を更に備える、
請求項１３に記載の装置。
【請求項２０】
処理したＦＩＸメッセージを受信側へ送信するように構成された送信ユニットを更に備える、
請求項１３に記載の装置。
【請求項２１】
前記装置は複数のコンピューティングノードを用いることによって前記受信したＦＩＸメッセージに関して分散処理を実行するよう構成され、各コンピューティングノードは少なくとも１つのセッションのＦＩＸメッセージを処理する、
請求項１３乃至請求項２０のいずれか１項に記載の装置。
【請求項２２】
ＦＩＸパケットをＦＩＸメッセージにカプセル化するように構成された処理ユニットであって、前記ＦＩＸメッセージは異なるタイプのサービスデータを含み、詳細なＦＩＸプロトコルバージョンに対応するサービスロジックを含まず、前記サービスデータは文字列形式である、前記処理ユニットと；
前記カプセル化されたＦＩＸメッセージをサービスプラットフォームへ送信し、前記サービスプラットフォームが、サービスロジックを含むサービススクリプトに基づいて前記サービスデータを処理するよう構成された送信ユニットと；を備える、
金融情報交換ＦＩＸプロトコルに基づくサービス実施装置。
【請求項２３】
前記処理ユニットは、前記ＦＩＸパケットを、普遍的ＦＩＸメッセージにカプセル化するように構成された、
請求項２２に記載の装置。
【請求項２４】
前記処理ユニットは、前記ＦＩＸパケットのヘッダ及び本文から文字列を抽出して普遍的ＦＩＸメッセージをアセンブルするように構成された、
請求項２３に記載の装置。
【請求項２５】
サービスプラットフォームと送信側とを備え；
前記サービスプラットフォームは、請求項１３乃至請求項２１のいずれか１項に記載された前記装置を備え；
前記送信側は、請求項２２乃至請求項２４のいずれか１項に記載された前記装置を備える；
金融情報交換ＦＩＸプロトコルに基づくサービス実施システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、２０１６年２月２９日に出願され「ＦＩＸプロトコルに基づくサービス実施方法、装置、及びシステム」と題された中国特許出願第２０１６１０１１２７０５．１号の優先権を主張し、上記中国特許出願は参照によってその全体が本明細書に組み込まれる。
【０００２】
本開示は、インターネット技術の分野に関し、特に、ＦＩＸプロトコルに基づくサービス実施方法、装置、及びシステムに関する。
【背景技術】
【０００３】
金融情報交換（ＦＩＸ）プロトコルは単一の事業体によって管理されることのないオープンメッセージ標準である。それはどの企業のサービス要件にも適合するように調整でき、それを用いて安全な取引に関する情報交換を容易にすることができる。ＦＩＸプロトコルは、第１に、直接的な情報の流れに基づく合衆国内の委託者間の有価証券取引を支援するために用いられている。時とともに発展するＦＩＸプロトコルは、更に、統合投資、金融派生商品、及び外国為替取引、を含む派生商品（デリバティブ）及びその他商品のサービス分野に関係するようになっている。
【０００４】
ＦＩＸプロトコル標準に基づいて、両当事者は直接取引を行うことができる、又は、サードパーティによって確立された金融サービスプラットフォーム（以下、サービスプラットフォームと称する）上で取引を行うことができる。金融市場の開設及び多数の小規模事業体の出現により、サービスプラットフォームベースの取引形態は、これらの事業体から多くの注目を集めている。
【０００５】
サービスプラットフォームベースの取引形態のために、事業体及びサービスプラットフォームは同一バージョンのＦＩＸプロトコルを用いるべきである。現在、ＦＩＸプロトコルバージョンはＦＩＸ１．０からＦＩＸ５．０まで開発されている。ＦＩＸ５．０バージョンプロトコルは、アプリケーション層（レイヤ）プロトコルから旧バージョンのセッション層プロトコルを分離し、更に、２つのプロトコルバージョン、即ちＦＩＸＴ  Ｘ．Ｙ及びＦＩＸ  Ｘ．Ｙを生成する。既存の技術において、サービスプラットフォームは、事業体によって用いられるプロトコルバージョンを要求したり、制限したりすることができない。ＦＩＸプロトコルバージョンの互換性を確保するには、サービスプラットフォームは全てのプロトコルバージョンのサービス環境を設定する必要があり、それにより、異なるプロトコルバージョン向けに取引サービスロジックが別々に開発されている。ＦＩＸプロトコルバージョンのアップグレード及びサービスタイプの絶えざる増加により、サービスプラットフォーム上で環境を展開するコストはますます高くなる。
【発明の概要】
【０００６】
本開示は、ＦＩＸプロトコルに基づくサービス実施方法、装置、及びシステムを提供してサービスプラットフォーム上でのＦＩＸサービス環境の展開に伴う高コスト問題を解決する。
【０００７】
前述の問題を解決するために、第１の態様により本開示はＦＩＸプロトコルに基づくサービス実施方法を提供する。前記方法は以下を含む：送信側によって送信されるＦＩＸメッセージを、サービスプラットフォームが受信するステップであって、前記ＦＩＸメッセージは異なるタイプのサービスデータを含み、前記サービスデータは文字列形式である、前記受信するステップ；前記サービスデータ内のサービスタイプ情報に基づいて前記ＦＩＸメッセージに対応するサービススクリプトを求めてスクリプトリストを検索するステップであって、前記スクリプトリストは異なるＦＩＸプロトコルバージョンに対応するサービススクリプトを格納し、前記サービススクリプトはサービスロジックを含む、前記検索するステップ；前記サービススクリプトを実行し、前記サービスロジックに基づいて前記サービスデータを処理するステップ。
【０００８】
第２の態様により、本開示はＦＩＸプロトコルに基づくサービス実施方法を更に提供する。前記方法は以下を含む：送信側によって、ＦＩＸパケットをＦＩＸメッセージにカプセル化するステップであって、前記ＦＩＸメッセージは異なるタイプのサービスデータを含み、詳細なＦＩＸプロトコルバージョンに対応するサービスロジックを含まず、前記サービスデータは前記文字列形式である、前記カプセル化するステップ；前記カプセル化されたＦＩＸメッセージをサービスプラットフォームへ送信するステップであって、前記サービスプラットフォームはサービスロジックを含むサービススクリプトに基づいて前記サービスデータを処理する、前記送信するステップ。
【０００９】
第３の態様により、本開示はＦＩＸプロトコルに基づくサービス実施装置を更に提供する。前記装置は以下を含む：送信側によって送信されたＦＩＸメッセージを受信するように構成された受信ユニットであって、前記ＦＩＸメッセージは異なるタイプのサービスデータを含み、前記サービスデータは文字列形式である、前記受信ユニット；前記サービスデータ内のサービスタイプ情報に基づいて前記ＦＩＸメッセージに対応するサービススクリプトを求めてスクリプトリストを検索するよう構成された検索ユニットであって、前記スクリプトリストは異なるＦＩＸプロトコルバージョンに対応するサービススクリプトを格納し、前記サービススクリプトはサービスロジックを含む、前記検索ユニット；前記サービススクリプトを実行し、前記サービスロジックに基づいて前記サービスデータを処理するよう構成された実行ユニット。
【００１０】
第４の態様により、本開示はＦＩＸプロトコルに基づくサービス実施装置を更に提供する。前記装置は以下を含む： ＦＩＸパケットをＦＩＸメッセージにカプセル化するように構成された処理ユニットであって、前記ＦＩＸメッセージは異なるタイプのサービスデータを含み、詳細なＦＩＸプロトコルバージョンに対応するサービスロジックを含まず、前記サービスデータは文字列形式である、前記処理ユニット；前記カプセル化されたＦＩＸメッセージをサービスプラットフォームへ送信するよう構成された送信ユニットであって、前記サービスプラットフォームは、サービスロジックを含むサービススクリプトに基づいて前記サービスデータを処理する、前記送信ユニット。
【００１１】
第５の態様により、本開示はＦＩＸプロトコルに基づくサービス実施システムを更に提供し、前記システムはサービスプラットフォームと送信側とを備え；前記サービスプラットフォームは第３の態様による装置を含み；前記送信側は第４の態様による装置を含む。
【００１２】
先の解決策に基づき、そして、本開示において提供されるＦＩＸプロトコルに基づいて、サービス実施方法、装置、及びシステムは、ＦＩＸパケットに対して高レベルの抽象化及びカプセル化を実行して、サービスデータだけを保持するが、詳細なサービスロジックを含まない普遍的ＦＩＸメッセージを取得することができる。詳細なサービスロジックをＦＩＸパケットから削除することによって、ＦＩＸパケットの厳密にタイプ指定されたサービスが弱められ、その結果、ＦＩＸメッセージを任意のバージョンのＦＩＸプロトコルに対して用いることができる。サービスロジックはサービススクリプトを用いることによってＦＩＸプロトコルコードとは無関係に構成される。異なるサービススクリプトが異なるＦＩＸプロトコルバージョン向けに開発される。ＦＩＸ取引サービスは、スクリプト言語の「動的構成」及び「動的ローディング」の特徴に基づいて実施される。既存の技術と比べて、本開示はサービスロジックとＦＩＸプロトコルコードとの間の完全な分離を実施し、その結果、サービスロジックの実施はもはやプロトコルコード自体には依存しない。したがって、サービスプラットフォームは１つのバージョンのＦＩＸプロトコルだけを展開することによって全てのＦＩＸプロトコルバージョンの取引サービスを実施でき、その結果、ＦＩＸサービス環境の展開コストを大幅に下げることができる。
【００１３】
先の説明は本開示の技術的解決策の単なる概要である。明細書の内容を実施できるよう本開示の技術的手段を良好に理解するために、そして、本開示の先の及び他の目的、特徴及び利点をより理解するために、本開示の詳細な実施を以下列挙する。
【図面の簡単な説明】
【００１４】
以下の実施態様の詳細な説明を読むことにより、当業者は様々な他の利点及び利益を理解することができる。 添付の図面は、単に実施の目的を説明するために使用されており、本開示を限定するものとみなされるものではない。更に、図面全体を通して同一の構成要素を表すために同一の参照符号が使用される。添付図面においては下記のとおりである。
【００１５】
【図１】図１は、本開示の実施によるＦＩＸプロトコルに基づく第１のサービス実施方法を示すフローチャートである。
【００１６】
【図２】図２は、本開示の実施によるＦＩＸプロトコルに基づく第２のサービス実施方法を示すフローチャートである。
【００１７】
【図３】図３は、本開示の実施によるＦＩＸプロトコルに基づく第３のサービス実施方法を示すフローチャートである。
【００１８】
【図４】図４は、本開示の実施による非標準ＦＩＸプロトコルを解析する方法を示すフローチャートである。
【００１９】
【図５】図５は、本開示の実施によるＦＩＸメッセージを処理するための第１の相互作用図である。
【００２０】
【図６】図６は、本開示の実施によるＦＩＸメッセージを処理するための第２の相互作用図である。
【００２１】
【図７】図７は、本開示の実施によるＦＩＸプロトコルに基づく第１のサービス実施装置を示す構成ブロック図である。
【００２２】
【図８】図８は、本開示の実施によるＦＩＸプロトコルに基づく第２のサービス実施装置を示す構成ブロック図である。
【００２３】
【図９】図９は、本開示の実施によるＦＩＸプロトコルに基づく第３のサービス実施装置を示す構成ブロック図である。
【００２４】
【図１０】図１０は、本開示の実施によるＦＩＸプロトコルに基づくサービス実施システムを示す概略図である。
【発明を実施するための形態】
【００２５】
以下では、添付の図面を参照しながら、本開示の例示的な実施をより詳細に説明する。添付の図面は、本開示の例示的な実施を示すが、本開示は様々な形態で実施することができ、本明細書に記載された実施によって限定されるものではないことを理解されたい。代わりに、これらの実施は、本開示のより完全な理解を提供し、本開示の範囲を当業者に完全に伝えるために提供される。
【００２６】
本開示の実施は金融情報交換（ＦＩＸ）プロトコルに基づくサービス実施方法を開示する。図１に示すように、前記方法は以下を含む。
【００２７】
１０１．サービスプラットフォームは、送信側によって送信されたＦＩＸメッセージを受信する。
【００２８】
送信側は、通常、株式取引及び先物取引のクライアント等の事業体である。送信側はカプセル化ＦＩＸメッセージをサービスプラットフォームへ送信する。ここでＦＩＸメッセージの内容は文字列の形をしており、取引額、取引時間、買手及び売手のＩＤ、サービスタイプ、及びメッセージ長等の異なるタイプのサービスデータを含んでいる。実際のアプリケーションにおいて、既存のＦＩＸプロトコル内の全てのデータフィールド（又はフィールドと称される）は、本実施においてサービスデータとして用いることができる。既存のＦＩＸプロトコルにおいて、取引の両当事者によって予め定められたデータフィールドもサービスデータとして用いることができる。本実施はサービスデータのタイプ及び量に対して何らの制限も設けない。
【００２９】
このステップで受信されるＦＩＸメッセージは、送信側が高レベルの抽象化及びカプセル化を行った後に得られるメッセージである。既存の実施との相違は、様々なデータフィールドを含むことに加え、既存のＦＩＸパケットが詳細な取引サービスに特有なサービスロジックを含むことである。サービスロジックは、本質的に、様々なデータフィールドのための制約制御情報である。例えば、「株式購入」サービスの場合、詳細な制約制御情報は、少なくとも、購入対象（株式等）の特定、株価が所定の価格に到達するかどうかの特定、買い入れる株の数量、及び買いオペレーションの開始方法を含む。ＦＩＸパケット内のサービスロジックは取引サービスを実施するための詳細な制約制御条件を扱うので、ＦＩＸパケットは既存の技術において厳密にタイプ指定されたパケットと称される。加えて、詳細なサービスロジックは同じ取引サービスのためのＦＩＸパケット内に存在するので、異なるＦＩＸプロトコルバージョンに対応するサービスロジックは、ＦＩＸプロトコルバージョン間の相違に起因して異なる。したがって、サービスロジックは、既存の技術において異なるＦＩＸプロトコルバージョン向けに別々に開発される必要がある。本実施において、サービスロジックはＦＩＸパケットから切り離され、スクリプト言語の形でサービスプラットフォーム上に別々に構成される。ＦＩＸパケットのため、送信側はそのデータフィールド（サービスデータ）を普遍集合に抽象化して文字列の形でサービスデータを取得する。普遍的サービスデータは任意のＦＩＸプロトコルバージョンに適用できる。
【００３０】
１０２．サービスプラットフォームは、サービスデータ内のサービスタイプ情報に基づいてＦＩＸメッセージに対応するサービススクリプトを求めてスクリプトリストを検索する。
【００３１】
各サービススクリプトは詳細なＦＩＸバージョンに対応する１つの詳細なサービスロジックを記録する。スクリプトリストはサービススクリプトを検索するために用いられるインデックスファイルであり、サービスタイプとサービススクリプトとのマッピング関係を記録する。ＦＩＸメッセージを受信した後、サービスプラットフォームはサービスタイプ情報に基づいて、対応するサービススクリプトを求めてスクリプトリストを検索して、対応するサービスロジックを実施する。
【００３２】
更に、サービスロジックの一片が、正確な識別のために、異なるＦＩＸプロトコルバージョンに対応するサービススクリプトを持てることを考慮すると、サービスプラットフォームは、サービスデータからプロトコルバージョン情報を更に抽出できる。その上、それはプロトコルバージョン情報をサービスタイプ情報と結合させてサービススクリプトを識別することができる。それに応じて、１次元の情報であるプロトコルバージョン情報は、サービスタイプと、プロトコルバージョンと、サービススクリプトとの間のマッピング関係を記録するようスクリプトリストに追加されるべきである。
【００３３】
この実施において、開発者は様々なサービススクリプトを予めコンパイルする必要があり、サービスプラットフォームは、ある特定のＦＩＸプロトコルバージョンのための様々なサービスロジックに対応する異なるサービススクリプトを、開発者に開発させることができる。それは、１つの詳細なサービスロジックのための全てのＦＩＸプロトコルバージョンに対応する異なるサービススクリプトを、開発者に開発させることができる。実際のアプリケーションにおいて、オンデマンドのサービスロジックカスタマイゼーションを実施するために、サービスプラットフォームは、更に、事業体によって開発されたサービススクリプトを受信できるよう、事業体に対してサービススクリプトを開発するためのアプリケーションプログラミングインターフェース（ＡＰＩ）を開放することができる。
【００３４】
スクリプト言語は軽量動的言語であり、スクリプト言語の開発に費やされる時間的コスト及びコンピュータリソースは、ＦＩＸプロトコルコードにおけるサービスロジックの開発に費やされるよりずっと少ないことは注目に値する。したがって、既存の技術と比べて、展開されるプロトコルバージョンの数が減ることに加え、この実施は、スクリプト言語を構成することによってＦＩＸプロトコルの展開コストを下げることができる。
【００３５】
１０３．サービスプラットフォームがサービススクリプトを実行し、サービスロジックに基づいてサービスデータを処理する。
【００３６】
一般に、サービススクリプトはデータベースサーバ上に格納され得る。必要とされるサービススクリプトをデータベース内で識別した後、サービスプラットフォームはそれをキャッシュに入れ、キャッシュを更新することによってサービススクリプトを動的にロードする。
【００３７】
一般に、サービスロジックの実施は、異なるサービスデータを用いることができる。例えば、商品取引工程において、少なくとも買手ＩＤ、売手ＩＤ、商品ＩＤ、商品価格等のサービスデータが必要とされる。サービスデータのタイプの選択及びサービスデータの処理方法の選択はサービススクリプト内のサービスロジック次第である。言い換えれば、サービスロジック内の制約制御情報次第である。この実施では、サービススクリプトを実行するために用いられるサービスデータのタイプ及び数は制限されない。
【００３８】
実際のアプリケーションにおいて、或る取引サービスがサービスプラットフォーム上で完了する一方、或る取引サービスは、サービスプラットフォームによって、受信側としての役割を果たす事業体へ転送される必要がある（例えば、交渉サービス）。後者の場合に対して、ステップ１０３が実行された後、サービスプラットフォームは、更に、処理したＦＩＸメッセージを受信側へ送信する必要がある。
【００３９】
更に、本開示の実施はＦＩＸプロトコルに基づくサービス実施方法を開示する。図２に示すように、この方法は以下を含む。
【００４０】
２０１．送信側が、ＦＩＸパケットをＦＩＸメッセージにカプセル化する。
【００４１】
図２に示す方法は、主に送信側に適用されて、従来のＦＩＸパケットに対して高レベルの抽象化及びカプセル化を実行して普遍的なＦＩＸメッセージを得る。ＦＩＸメッセージは文字列形式でのサービスデータだけを含み、詳細なＦＩＸプロトコルバージョンに対応するサービスロジックを含まないので、ＦＩＸメッセージを、任意のバージョンのＦＩＸプロトコルに適用できる。
【００４２】
加えて、サービスロジックは予め開発されるサービススクリプトに記述される。それはサービスプラットフォーム上に構成され、その結果、サービスプラットフォームはサービスロジックを含むサービススクリプトに基づいてサービスデータを処理する。
【００４３】
２０２．送信側が、カプセル化されたＦＩＸメッセージをサービスプラットフォームへ送信する。
【００４４】
本開示のこの実施で提供される方法において、ＦＩＸパケット内のサービスロジックを、実施のためにサービスプラットフォーム上のサービススクリプトにまで、減らすことができる。サービスロジック内の制約制御情報は、異なるＦＩＸプロトコルバージョンに基づいて内容と形式とが異なる。したがって、ＦＩＸメッセージが普遍的なサービスデータを含み、詳細なサービスロジックを含まない場合、ＦＩＸメッセージはＦＩＸプロトコルバージョンによって制限されず、任意のバージョンのＦＩＸプロトコルに適用できる。既存の技術と比べて、この実施ではＦＩＸプロトコルバージョンの互換性が向上し、展開されるＦＩＸプロトコルバージョンの数が減り、よって、ＦＩＸサービス環境の展開コストを下げることができる。
【００４５】
更に、図１及び図２に示す方法の改良として、本開示の実施は、ＦＩＸプロトコルに基づくサービス実施方法を更に提供する。図３に示すように、この方法は以下を含む。
【００４６】
３０１．送信側が、ＦＩＸパケットをＦＩＸメッセージにカプセル化する。
【００４７】
送信側は、ＦＩＸパケットを普遍的なＦＩＸメッセージにカプセル化する。送信側は、ＦＩＸパケットのヘッダと本文とから文字列を抽出して普遍的なＦＩＸメッセージをアセンブルする。送信側は、所定のヘッダ長に基づいてパケットヘッダを取り込み、ヘッダ内容に基づいて本文長さを解析し、本文長さに基づいて本文の文字列を取り込み、最終的に、取り込んだ文字列をＦＩＸメッセージにアセンブルする。
【００４８】
実際のアプリケーションにおいて、送信側は、ＦＩＸパケットをメッセージタイプＦＩＸメッセージにカプセル化することができるが、これに限定されない。
【００４９】
３０２．送信側が、カプセル化されたＦＩＸメッセージをサービスプラットフォームへ送信する。
【００５０】
既存のＦＩＸプロトコルに基づいて、ＦＩＸパケットの受信及び送信の両当事者は１セッションで互いに通信すべきである。セッションが確立された後、送信側は既存の送信メソッドを呼び出してＦＩＸメッセージをサービスプラットフォームへ送信する、例えば、静的メソッドｓｅｎｄＴｏＴａｒｇｅｔを用いてＦＩＸメッセージを送信する。
【００５１】
３０３．サービスプラットフォームが、サービスデータ内のサービスタイプ情報に基づいてＦＩＸメッセージに対応するサービススクリプトを求めてスクリプトリストを検索する。
【００５２】
上で説明したように、メッセージ受信及び送信の両当事者が同じセッションに基づいて互いに通信する必要がある。ＦＩＸメッセージを送信する場合、送信側は現在のセッションＩＤを一緒に送信する。サービスプラットフォームはセッションＩＤに基づいてセッションリスト内の対応するセッションを識別してから、セッション内の後続の手順を実行する。
【００５３】
既存の技術において、ＦＩＸパケット内のサービスデータはデータフィールド形式で存在する、すなわち、タグ−値ペアの形式で存在する。この実施におけるサービスデータもタグ−値ペアの形式で存在する。ＦＩＸプロトコルによって指定されるタグ−値ペアのいくつかを以下に表す。
2019512138.tif 000003
【００５４】
ＦＩＸメッセージを解析した後、送信側はメッセージに含まれるサービスデータを取得する。１つのタグ−値ペアは、１つのタイプのサービスデータに対応する。
【００５５】
タグ−値ペアが得られた後、サービスプラットフォームはサービスタイプのタグ−値ペアを検索し、取引サービスのサービスタイプ情報を取得し、サービスタイプ情報に基づいてＦＩＸメッセージに対応するサービススクリプトを求めてスクリプトリストを検索する。
【００５６】
更に、サービスプラットフォームは多数の取引サービスに関わるので、サービスプラットフォームは、反復や混乱を避けるために、送信者ＩＤ、メッセージタイプ（アプリケーション層メッセージ又はセッション層メッセージ）、及びセッションＩＤとさえも組み合わせてサービススクリプトを更に検索できる。
【００５７】
３０４．サービスプラットフォームがサービススクリプトを実行し、サービスロジックに基づいてサービスデータを処理する。
【００５８】
サービスプラットフォームが、識別したサービススクリプトをキャッシュに入れ、キャッシュを更新することによってサービススクリプトをロードして対応するサービスロジックを実施する。
【００５９】
実際のアプリケーションにおいて、ＦＩＸプロトコルに関するサービスロジックは以下２つのカテゴリに分けることができる。
【００６０】
一方のカテゴリは、詳細な取引対象又は詳細な取引に特有なサービスロジックである。サービスロジックは、異なる取引対象又は異なる取引において普遍的に用いることができず、それは、パケット内容解析（異なる解析規則に関する）、パケットフィールドチェック（例えば、データフォーマット、金額フォーマット、金額等）、パケットフィールド変換（データフォーマット変換、金額フォーマット変換、通貨識別子変換）、署名照合、リターンコード変換、冪等性制御、及びトラフィック制御を含むが、これらに限定されない詳細な事例に対して別々に開発される必要がある。
【００６１】
他方のカテゴリは、全ての事業体によって用いられる可能性があるサービスロジックである。このタイプのサービスロジックは、両当事者間の最下層通信工程の確立、保証、及び登録抹消に主に用いられる。それは、任意のサービスタイプに適用可能な取引サービスのより普遍的なサービスロジックも含む。代表的なサービスロジックとして、ハートビート管理、ネットワーク試験、メッセージ再送信、メッセージ拒否、シーケンス番号再設定、登録抹消、セッション層でのログイン検証、離脱要求、拒絶命令、実行報告、状態（ステータス）要求、状態（ステータス）チェック、及びアプリケーション層での新規命令が挙げられる。
【００６２】
特定のサービスロジックはステップ３０４を実行することによって実施されるサービススクリプトの形式でサービスプラットフォーム上に構成される。しかし、普遍的サービスロジックに関しては、サービススクリプトは異なる事業体のために繰り返し構成される必要はない。ＦＩＸサービス環境の開発において、普遍的サービスロジックは後続のステップ３０５乃至３０７を実行することによって実施されるサービスプラットフォーム上のプロトコルコードに直接記述される。普遍的サービスロジックは全てのサービスタイプに適用でき、使用中に修正される必要がないため、ＦＩＸサービス環境の保守費用が増加することはない。
【００６３】
３０５．サービスプラットフォームが、サービスデータ内のメッセージタイプ情報に基づいてＦＩＸメッセージのメッセージタイプを特定する。
【００６４】
サービスプラットフォームは、キー「ＭｓｇＴｙｐｅ」を持つタグ−値ペアに基づいてＦＩＸメッセージのメッセージタイプを取得する。メッセージタイプは２つのタイプ、即ち、アプリケーション層メッセージとセッション層メッセージとを含む。異なるメッセージタイプに対して、サービスプラットフォームは後続のステップ３０６又は３０７を選択して実行する。
【００６５】
３０６．メッセージタイプがアプリケーション層メッセージを示した場合、サービスプラットフォームがアプリケーション層メソッドを呼び出して、アプリケーション層で普遍的サービスロジックを実行する。
【００６６】
サービスプラットフォームはアプリケーションクラス内のｔｏＡｐｐメソッド又はｆｒｏｍＡｐｐメソッドを呼び出してアプリケーション層で普遍的サービスロジックを実行する。ｔｏＡｐｐメソッドとｆｒｏｍＡｐｐメソッドとは以下の点で異なる。即ち、受信側へ送信されるＦＩＸメッセージが処理される場合には、ｔｏＡｐｐメソッドが呼び出され、受信されたＦＩＸメッセージが処理される場合には、ｆｒｏｍＡｐｐメソッドが呼び出される。
【００６７】
３０７．メッセージタイプがセッション層メッセージを示した場合、サービスプラットフォームがセッション層メソッドを呼び出してセッション層で普遍的サービスロジックを実行する。
【００６８】
サービスプラットフォームは、アプリケーションクラス内のｔｏＡｄｍｉｎメソッド又はｆｒｏｍＡｄｍｉｎメソッドを呼び出してアプリケーション層で普遍的サービスロジックを実行する。ｔｏＡｄｍｉｎメソッドとｆｒｏｍＡｄｍｉｎメソッドとは以下の点で異なる。即ち、受信側へ送信されるＦＩＸメッセージが処理される場合には、ｔｏＡｄｍｉｎメソッドが呼び出され、受信されたＦＩＸメッセージが処理される場合、ｆｒｏｍＡｄｍｉｎメソッドが呼び出される。
【００６９】
実際のアプリケーションにおいて、送信及び受信されたＦＩＸメッセージのセッションシーケンス番号は別々に維持される。送信及び受信されたメッセージのメッセージキューも互いに独立している。したがって、サービスプラットフォームはＦＩＸメッセージのセッションシーケンス番号に基づいてｔｏＡｐｐ／ｔｏＡｄｍｉｎ及びｆｒｏｍＡｐｐ／ｆｒｏｍＡｄｍｉｎを選択して呼び出すことができる。
【００７０】
この実施において、ステップ３０４に続くステップ３０５乃至ステップ３０７は、説明を簡単にするために用いられているに過ぎない。実際のアプリケーションにおいて、ＦＩＸメッセージを受信した後、サービスプラットフォームは先ずステップ３０５乃至ステップ３０７を実行してからステップ３０３乃至ステップ３０４を実行できる、又は、ステップ３０５乃至ステップ３０７と、ステップ３０３乃至ステップ３０４とを同時に実行できる。
【００７１】
この実施の実施において、セッションシーケンス番号に基づくフィールドチェック及び送信消失チェック等の普遍的なチェックサービスは、ＦＩＸプロトコルコードに記述でき、セッション層メソッドを呼び出すことによって実施できる。
【００７２】
更に、サービスプラットフォームは普遍的サービスロジックの以下の新しいタイプをＦＩＸプロトコルコードに記述し、セッション層メソッドを用いてサービスロジックを実行できる。
【００７３】
１．シーケンス番号再設定ロジック
【００７４】
既存のＦＩＸプロトコル標準はシーケンス番号保護メカニズムを含む。メッセージ送信者は、セッションシーケンス番号を、送信されるメッセージに追加する。メッセージ受信者にとって、現在受信したメッセージのシーケンス番号と先に受信したメッセージのシーケンス番号とが連続していなければ、これら２つのメッセージの間に、失敗したメッセージが存在することを示している。メッセージ再送信メカニズムがトリガされる必要がある。シーケンス番号が連続していれば、送信者はメッセージを再び送信し、先のメッセージのシーケンス番号に１が加算され、これが次のメッセージのセッションシーケンス番号として用いられる。
【００７５】
通信工程の連続する展開により、両通信当事者が使用するセッションシーケンス番号が増えていくことが分かる。セッションシーケンス番号の値が、システム又はデータベースによってサポートされる上限を超えると、システムはセッションシーケンス番号を識別できなくなるので、エラー再送信が容易に起きる可能性がある。セッションシーケンス番号がシステム上限を超えてしまうことを避けるために、この実施は、セッション層メソッドを用いて実施される、シーケンス番号を再設定するための普遍的サービスロジックを提供する。サービスプラットフォームは、システムによってサポートされる上限に基づく所定の最大シーケンス番号を設定する。一般に、シーケンス番号の最大値はシステムの上限未満である。実際のアプリケーションにおいて、シーケンス番号の最大値はシステムの上限の７０％乃至９５％に設定されてもよい。例えば、システムの上限が９９０，０００である場合、シーケンス番号の最大値を９００，０００に設定してもよい。
【００７６】
シーケンス番号ロジックを再設定する場合、サービスプラットフォームは、現在のメッセージのセッションシーケンス番号が所定の最大シーケンス番号に達しているかどうかを特定する。最大シーケンス番号に達した場合、セッションシーケンス番号は０に再設定される。その結果、後続のシーケンス番号は、０から始まり、累積していく。最大シーケンス番号に達していなければ、何らの処理もなされない。
【００７７】
この実施において、セッション層のシーケンス番号再設定ロジックは、メッセージのセッションシーケンス番号がシステム又はデータベースによってサポートされる上限を超えることを防ぐことにより、セッションシーケンス番号のオーバーフローに起因するシステム例外を効果的に回避できる。
【００７８】
２．取引拒否ロジック
【００７９】
セッションシーケンス番号が再設定される場合、事業体による処理拒否やシステム例外が理由で、再設定不具合を生じる可能性がある。この場合、セッションシーケンス番号がシステム又はデータベースによってサポートされている上限を超えてしまわないように、サービスプラットフォームがセッション層メソッドを用いて取引拒否ロジックを実施し、現在のＦＩＸメッセージの処理を拒否することにより、セッションシーケンス番号の更なる累積の可能性を解消することができる。
【００８０】
３．キュークリアロジック
【００８１】
既存のＦＩＸプロトコルの再送信メカニズムにおいて、セッションシーケンス番号が連続しない場合、現在のメッセージはメッセージキュー内にキャッシュ格納され、送信側は失敗したシーケンス番号に対応するメッセージを再送信するよう指示される。この場合、送信側によって送信された現在のメッセージに続く全てのメッセージはメッセージキュー内にキャッシュ格納される必要があり、メッセージキューにおいてメモリオーバーフローのリスクがある。この実施において、サービスプラットフォームはキュークリアロジックを実行することによってメッセージキューの大きさを監視できる。メッセージキューによって占有されたキャッシュが所定のキャッシュ閾値を超えた場合、メッセージキュー内にキャッシュ格納されたＦＩＸメッセージは、システムが安定し、高度に利用可能であることを保証するためにクリアされる。実際のアプリケーションにおいて、キャッシュ閾値はシステムのメモリサイズに基づいて比例して設定でき、詳細な値はこの実施において限定されない。
【００８２】
更に、この実施において、事業体がＦＩＸサービスを追加する場合、サービスプラットフォームは、新規に追加されたサービスのサービスロジックを含むサービススクリプトを取得し、取得したサービススクリプトをスクリプトリストに追加できる。この実施において、サービスロジックはスクリプト言語形式でサービスプラットフォーム上に構成される。サービスロジックが追加される必要がある場合、新規に開発されたサービススクリプトだけがサービスプラットフォーム上に構成される必要があり、ＦＩＸプロトコルコードは修正される必要がない。既存の技術と比べて、サービスロジックを追加する柔軟性及び利便性は大幅に向上し、それは事業体が個人向け取引サービスをカスタマイズすることを容易にする。
【００８３】
同様に、幾つかのサービスロジックがサービスプラットフォームから削除される必要がある場合、対応するサービススクリプトだけがサービスタイプに基づいて識別される必要があり、その結果、サービススクリプトはスクリプトリストから削除される。同様に、ＦＩＸプロトコルコードは変更される必要がない。
【００８４】
更に、実際のアプリケーションにおいてそれを考慮すると、事業体によってはセッションシーケンス番号を繰り返し再設定することを望まないので、通信のために標準のＦＩＸプロトコルパケットを用いない。非標準ＦＩＸプロトコルパケットを用いる事業体向けに、サービスプラットフォームは、更に、この実施における異なる非ＦＩＸプロトコルパケットのカプセル化規則に基づいて異なるパケットパーサ（構文解析器）を予め開発してその取引サービスを実施できる。非ＦＩＸプロトコルパケットが受信されると、サービスプラットフォームはカプセル化規則に基づいて対応するパケットパーサを選択し、選択したパケットパーサを用いて非ＦＩＸプロトコルパケットのデータストリームを解析してサービスデータを取得する。
【００８５】
実際のアプリケーションにおいて、証券会社の資産照会取引は非標準ＦＩＸプロトコルパケットを用いて実施される。非標準ＦＩＸプロトコルはシーケンス番号の増加速度を遅くするために用いられる。資産照会の頻度は取引頻度よりもはるかに高いので、資産照会はセッションシーケンス番号の急増を必然的に招き、よって頻繁な再設定を招くことになる。非標準ＦＩＸプロトコルパケットに関しては、それらのカプセル化規則は普遍的ＦＩＸメッセージのカプセル化規則とは異なるので、普遍的解析手段では、基礎バイナリデータストリームを文字列形式のデータに正しく解析できない。この実施において、非標準ＦＩＸプロトコルパケットの正しい解析は、サービスロジックの実施を保証するカスタマイズされたパケットパーサを用いて実施できる。図４に、パケットパーサを用いることによって非標準ＦＩＸプロトコルパケットを解析する工程を示す。
【００８６】
４０１．一致したヘッダ長に基づいてパケットヘッダを取り込む。
【００８７】
サービスプラットフォームはカプセル化規則において指定されたヘッダ長に基づいて非標準ＦＩＸプロトコルパケットのデータストリームからパケットヘッダを取り込む。ヘッダ長はサービスプラットフォームによって予め事業体（送信側）と合意されていてもよい。
【００８８】
４０２．パケットヘッダに基づいてパケットタイプ及び本文長さ情報を取得する。
【００８９】
パケットヘッダが取得された後、パケットタイプ及び本文長さ等のフィールド情報を取得できる。サービスプラットフォームは、本文長さ情報に基づいてステップ４０３を実行して本文を取り込む。
【００９０】
４０３．本文長さに基づいて本文を取り込む。
【００９１】
本文を取り込む工程において、サービスプラットフォームは、取り込んだ本文が複数の機会に対して十分に長いかどうか、言い換えれば、取り込んだ本文が本文長さに達しているかどうかを特定する必要がある。長さが本文長さに達した場合、取り込みは停止される。そうでなければ、データストリームは、本文長さに達するまで、又は、データストリームが完全に読み込まれるまで引き続き読み込まれる。
【００９２】
４０４．パケットヘッダ及び本文をアセンブルし、それを文字列形式で上位層へ返す。
【００９３】
パケットヘッダ及び本文に対応するデータストリームが取り込まれた後、データストリームは文字列形式でデータにアセンブルされ、上位層に返される。上位層は文字列をタグ−値ペアに分割する。フィールドチェック後、サービスデータの抽出を完了する。
【００９４】
更に、この実施の別の実施において、受信したＦＩＸメッセージを処理した後、サービスプラットフォームは、処理したＦＩＸメッセージを受信側へ更に送信できる。一般に、サービスプラットフォーム上で実施できる取引サービスに加えて、両当事者によって合同で実施される必要がある幾つかの取引サービス、例えば、価格問い合わせ／カウンターオファー、がある。この場合、サービスプラットフォームは、一方の当事者（送信側）によって送信されたＦＩＸメッセージを処理し、処理したＦＩＸメッセージを他方の当事者（受信側）へ送信する必要がある。本開示の実施は、次に、２つの工程、即ち、メッセージの受信及びメッセージの送信、に基づくＦＩＸサービスの実施工程について述べる。
【００９５】
更に、この実施の最終の実施において、サービスプラットフォームは分散ネットワークアーキテクチャを更に用いて、複数のコンピューティングノードを用いることによって受信したＦＩＸメッセージに関する分散処理を実行できる。各コンピューティングノードは少なくとも１つのセッションのＦＩＸメッセージを処理する。初期セッション段階において、負荷バランシングは、ハッシュアルゴリズムを用い、セッションＩＤに基づきセッションに関して実行でき、その結果、各コンピューティングノードは同じ又は略同じ数のセッションに対してその責を担う。セッションを新規に追加する場合、セッションを最小数のセッションを有するコンピューティングノードに割り当てることができる、又は、コンピューティングノードが同じ数のセッションを有する場合、新規に追加されたセッションを、セッション登録抹消を最近実行されたコンピューティングノードに割り当てることができる。この実施は、分散構造におけるコンピューティングノードの数、割当方法、及びノード上のセッションの数に対して何ら制限しない。
【００９６】
先の実施において、コンピューティング効率を向上させ、単一のコンピューティングノードの負荷を軽減することに加え、分散ネットワーク構造は、各コンピューティングノードがそのセッションシーケンス番号を独立に管理してセッションシーケンス番号の水平拡張をサポートすることを可能にし、それによって、シーケンス番号の順次送信に起因するパフォーマンスボトルネックを解消する。
【００９７】
以下は、本開示の実施の２つのアプリケーションシナリオである。
【００９８】
第１のシナリオでは、サービスプラットフォームがＦＩＸメッセージを外部へ送信する。このシナリオにおいて、サービスプラットフォームは送信側によって送信されたＦＩＸメッセージを受信し、ＦＩＸメッセージを処理し、処理したＦＩＸメッセージを受信側へ送信する。図５に示すように、シナリオ手順は以下のステップを含む。
【００９９】
１．送信側がＦＩＸメッセージをカプセル化し、静的メソッドＳｅｎｄＴｏＴａｒｇｅｔを呼び出してＦＩＸメッセージをサービスプラットフォームへ送信する。
【０１００】
２．サービスプラットフォームが、メッセージに含まれるセッションＩＤに基づいて、対応するセッションを検索する。
【０１０１】
３．サービスプラットフォームが、メッセージに含まれるサービスタイプ情報に基づいて、対応するｇｒｏｏｖｙスクリプトを検索し、これを実行する。ＦＩＸメッセージは、ｇｒｏｏｖｙスクリプトを用いてスクリプト内のサービスロジックを実施することによって処理される。
【０１０２】
４．サービスプラットフォームが、メッセージに含まれるメッセージタイプ情報に基づいて、ＦＩＸメッセージのタイプを特定する。タイプがセッション層メッセージを示す場合、セッション層におけるｔｏＡｄｍｉｎメソッドが呼び出されて、セッション層の普遍的サービスロジックを実施するようＦＩＸプロトコルを処理する。タイプがアプリケーション層メッセージを示す場合、アプリケーション層におけるｔｏＡｐｐメソッドが呼び出されて、アプリケーション層の普遍的サービスロジックを実施するようＦＩＸプロトコルを処理する。
【０１０３】
５．サービスプラットフォームが、オブジェクトＩｏＳｅｓｓｉｏｎＲｅｓｐｏｎｄｅｒを呼び出して処理したＦＩＸメッセージを受信側へ送信する。オブジェクトＩｏＳｅｓｓｉｏｎＲｅｓｐｏｎｄｅｒが、ＩｎｉｔｉａｔｏｒＩＯＨａｎｄｌｅｒによって初期化される。
【０１０４】
６．サービスプラットフォーム及び送信側が、それぞれ格納したセッションシーケンス番号を１つ増やす。
【０１０５】
第２のシナリオでは、サービスプラットフォームが、外部によって送信されたＦＩＸメッセージを受信する。このシナリオにおいて、サービスプラットフォームは送信側によって送信されたＦＩＸメッセージを受信し、ＦＩＸメッセージを処理する。図６に示すように、シナリオ手順は以下のステップを含む。
【０１０６】
１．サービスプラットフォームが、オブジェクトＩｎｉｔｉａｔｏｒＩｏＨａｎｄｌｅｒを用いることによって送信側のソケットに対して非同期非停止監視を実行する。
【０１０７】
２．送信側によって送信されたＦＩＸメッセージを受信する場合、サービスプラットフォームがクラスＥｖｅｎｔＨａｎｄｌｉｎｇＳｔｒａｔｅｇｙを呼び出してメッセージをメッセージキューｂｌｏｃｋｉｎｇＱｕｅｕｅに追加する。
【０１０８】
３．サービスプラットフォームが、クラスＥｖｅｎｔＨａｎｄｌｉｎｇＳｔｒａｔｅｇｙを呼び出してｂｌｏｃｋｉｎｇＱｕｅｕｅからＦＩＸメッセージを繰り返し読み込む。
【０１０９】
４．サービスプラットフォームが、メッセージに含まれるセッションＩＤに基づいて、対応するセッションを検索する。
【０１１０】
５．サービスプラットフォームが、セッションシーケンス番号が連続しているかどうかをチェックする。セッションシーケンス番号が連続していた場合、後続のステップを実行する。そうでなければ、送信側は正規のシーケンス番号範囲内でＦＩＸメッセージを再送する。
【０１１１】
６．サービスプラットフォームが、メッセージに含まれるサービスタイプ情報に基づいて、対応するｇｒｏｏｖｙスクリプトを検索し、これを実行する。ＦＩＸメッセージは、ｇｒｏｏｖｙスクリプトを用いてスクリプト内のサービスロジックを実施することによって処理される。
【０１１２】
７．サービスプラットフォームが、メッセージに含まれるメッセージタイプ情報に基づいて、ＦＩＸメッセージのタイプを特定する。タイプがセッション層メッセージを示す場合、セッション層におけるｆｒｏｍＡｄｍｉｎメソッドが呼び出されて、セッション層の普遍的サービスロジックを実施するようＦＩＸプロトコルを処理する。タイプがアプリケーション層メッセージを示す場合、アプリケーション層におけるｆｒｏｍＡｐｐメソッドが呼び出されて、アプリケーション層の普遍的サービスロジックを実施するようＦＩＸプロトコルを処理する。
【０１１３】
８．サービスプラットフォーム及び送信側が、それぞれ格納したセッションシーケンス番号を１つ増やす。
【０１１４】
先の両シナリオにおいて、サービススクリプトはｇｒｏｏｖｙ言語を用いて開発される。Ｇｒｏｏｖｙは、Ｊａｖａ（登録商標）仮想マシンに基づくアジャイル動的言語である。それは全ての既存のＪａｖａ（登録商標）オブジェクトとクラスライブラリとをシームレスに統合できる。サービススクリプトを開発するためには、ｇｒｏｏｖｙ言語及びＪａｖａ（登録商標）環境を用いることがより便利である。実際のアプリケーションにおいて、サービススクリプトは、例えばＪＰｙｔｈｏｎ、ＪＲｕｂｙ等のＪａｖａ（登録商標）仮想マシンに基づく言語を用いて更に実施でき、それはこの実施において限定されない。
【０１１５】
更に、図１及び図３に示す方法の実施として、本開示の実施は、更に、ＦＩＸプロトコルに基づくサービス実施装置を提供する。装置は主にサービスプラットフォーム上に配置される。図７に示すように、装置は、受信ユニット７１と、検索ユニット７２と、実行ユニット７３とを含む。
【０１１６】
受信ユニット７１は、送信側によって送信されたＦＩＸメッセージを受信するように構成され、ここでＦＩＸメッセージは異なるタイプのサービスデータを含み、サービスデータは文字列形式である。検索ユニット７２は、サービスデータ内のサービスタイプ情報に基づいて、ＦＩＸメッセージに対応するサービススクリプトを求めてスクリプトリストを検索するように構成され、ここでスクリプトリストには、異なるＦＩＸプロトコルバージョンに対応するサービススクリプトが格納される。サービススクリプトはサービスロジックを含み、実行ユニット７３は、サービスロジックに基づいてサービススクリプトを実行し、サービスデータを処理するように構成される。
【０１１７】
更に、受信ユニット７１によって受信されるＦＩＸメッセージは普遍的ＦＩＸメッセージである。
【０１１８】
更に、図８に示すように、装置は、普遍的サービスロジックをサービスプラットフォーム上のプロトコルコードに書き込むように構成された書込ユニット７４を更に含み、ここで普遍的サービスロジックは任意のサービスタイプに適用可能である。
【０１１９】
更に、図８に示すように、装置は、送信側によって送信されたＦＩＸメッセージが受信された後、サービスデータ内のメッセージタイプ情報に基づいてＦＩＸメッセージのメッセージタイプを特定するように構成された特定ユニット７５を更に含む。
【０１２０】
実行ユニット７３は、メッセージタイプがアプリケーション層メッセージを示す場合、アプリケーション層メソッドを呼び出してアプリケーション層において普遍的サービスロジックを実行するように構成され、更に、メッセージタイプがセッション層メッセージを示す場合、セッション層メソッドを呼び出してセッション層において普遍的サービスロジックを実行するよう構成される。
【０１２１】
更に、実行ユニット７３は：普遍的サービスロジックがセッション層におけるシーケンス番号再設定ロジックである場合、セッションシーケンス番号が所定の最大シーケンス番号に到達すれば、セッションシーケンス番号を０に再設定するように構成される；又は、普遍的サービスロジックがセッション層における取引拒否ロジックである場合、セッションシーケンス番号を再設定することに失敗すれば、ＦＩＸメッセージを処理することを拒否するように構成される；又は、普遍的サービスロジックがセッション層におけるキュークリアロジックである場合、メッセージキューによって占有されたキャッシュが所定のキャッシュ閾値を超えれば、メッセージキュー内のキャッシュ格納されたＦＩＸメッセージをクリアするように構成される。
【０１２２】
更に、図８に示すように、装置は：ＦＩＸサービスが追加される場合、追加されたＦＩＸサービスのサービスロジックを含むサービススクリプトを取得するよう構成された取得ユニット７６と；取得されたサービススクリプトをスクリプトリストに追加するように構成された付加ユニット７７と；を更に含む。
【０１２３】
更に、図８に示すように、装置は：非ＦＩＸプロトコルベースパケットの場合、非ＦＩＸプロトコルベースパケットのカプセル化規則に基づいてパケットパーサを選択するように構成された選択ユニット７８と；サービスデータを取得するためにパケットパーサを用いることによって非ＦＩＸプロトコルベースパケットのデータストリームを解析するように構成された解析ユニット７９と；を更に含む。
【０１２４】
更に、図８に示すように、装置は、処理したＦＩＸメッセージを受信側へ送信するよう構成された送信ユニット７１０を更に含む。
【０１２５】
更に、装置は、複数のコンピューティングノードを用いて受信したＦＩＸメッセージに対して分散処理を実行するように構成され、ここで各コンピューティングノードは少なくとも１つのセッションのＦＩＸメッセージを処理する。
【０１２６】
更に、図２及び図３に示す方法の実施として、本開示の実施は、更に、ＦＩＸプロトコルに基づくサービス実施装置を提供する。装置は主に送信側に配置される。図９に示すように、装置は処理ユニット９１と送信ユニット９２とを含む。
【０１２７】
処理ユニット９１は、ＦＩＸパケットをＦＩＸメッセージにカプセル化するように構成され、ここでＦＩＸメッセージは異なるタイプのサービスデータを含み、詳細なＦＩＸプロトコルバージョンに対応するサービスロジックを含まない。サービスデータは文字列形式であり、送信ユニット９２は、カプセル化されたＦＩＸメッセージをサービスプラットフォームへ送信するように構成され、その結果、サービスプラットフォームはサービスロジックを含むサービススクリプトに基づいてサービスデータを処理する。
【０１２８】
更に、処理ユニット９１は、カプセル化されたＦＩＸパケットを普遍的ＦＩＸメッセージにカプセル化するように構成される。
【０１２９】
更に、処理ユニット９１は、ＦＩＸパケットのヘッダ及び本文から文字列を抽出して普遍的ＦＩＸメッセージをアセンブルするように構成される。
【０１３０】
更に、図３に示す方法の実施として、本開示の実施は、更に、ＦＩＸプロトコルに基づくサービス実施システムを提供する。図１０に示すように、システムはサービスプラットフォーム１０１と送信側１０２とを含む。
【０１３１】
サービスプラットフォーム１０１は図７又は図８に示す装置を含み、送信側１０２は図９に示す装置を含む。
【０１３２】
本開示の実施において提供されるＦＩＸプロトコルに基づくサービス実施装置及びシステムは、ＦＩＸパケットに関する高レベルの抽象化及びカプセル化を実行して、サービスデータだけを保持し、詳細なサービスロジックを含まない普遍的ＦＩＸメッセージを取得することができる。詳細なサービスロジックをＦＩＸパケットから削除することによって、ＦＩＸパケットの厳密にタイプ指定されたサービスが弱められ、その結果、ＦＩＸメッセージを任意のバージョンのＦＩＸプロトコルに対して用いることができる。サービスロジックは、サービススクリプトを用いることによってＦＩＸプロトコルコードとは無関係に構成される。異なるサービススクリプトが異なるＦＩＸプロトコルバージョン向けに開発される。ＦＩＸ取引サービスは、スクリプト言語の「動的構成」及び「動的ローディング」の特徴に基づいて実施される。既存の技術と比べて、本開示の実施はサービスロジックとＦＩＸプロトコルコードとの間の完全な分離を実施し、その結果、サービスロジックの実施はもはやプロトコルコード自体に依存しない。したがって、サービスプラットフォームは１つのバージョンのＦＩＸプロトコルだけを展開することによって全てのＦＩＸプロトコルバージョンの取引サービスを実施でき、その結果、ＦＩＸサービス環境の展開コストを大幅に下げることができる。
【０１３３】
先の実施において、各実施で説明するのはそれぞれの着目点である。ある実施において詳細に説明されていない部分については、他の実施における関連説明を参照することができる。
【０１３４】
これまでの方法及び装置の関連する特徴を相互に参照できることが理解できる。更に、前の実施における「第１」「第２」などは、実施を区別するために使用され、各実施の長所及び短所を表すものではない。
【０１３５】
当業者であれば、説明の便宜及び簡潔さのために、上記のシステム、装置、及びユニットの特定の作業プロセスについて、上記の方法の実施における対応するプロセスを参照することができることを明確に理解することができ、詳細はここでは再度説明しない。
【０１３６】
ここで提供されるアルゴリズムとディスプレイは、特定のコンピュータ、仮想システム、又は他のデバイスにも本質的に関連していない。さまざまな汎用システムを、ここに基づいた命令と一緒に利用することができる。上記の説明に基づいて、そのようなシステムを構築するために必要な構造は明らかである。更に、本開示は、特定のプログラミング言語に適用されるものではない。本明細書に記載される本開示の内容は、様々なプログラミング言語を使用することによって実施することができ、詳細な言語の前述の説明は、本開示の最良の実施を開示するために用いられることを理解されたい。
【０１３７】
明細書には詳細が多数提供されている。しかし、これらの詳細なしに本開示の実施が行われ得ることを理解されよう。場合によっては、本明細書の理解を曖昧にしないために、周知の方法、構造、及び技術は詳細に示されていない。
【０１３８】
同様に、本開示を合理化し、様々な発明の態様のうちの１つ以上を理解するのを助けるために、本開示の特徴は、時には本開示の単一の実施、図面、記載に一緒にまとめられることを理解すべきである。しかしながら、開示された方法は、以下の意図を反映すると解釈されるべきではない。言い換えると、請求項での開示は各請求項に特定される特徴よりも多くの特徴を必要とする。より正確には、下記の請求項に反映されているように、開示の態様は前述の開示された単一の実施のすべての特徴よりも少ない。したがって、詳細な実施に続く請求項は、詳細な実施を確実に組み込んでいる。各請求項は、本開示の別個の実施として機能する。
【０１３９】
当業者であれば、実施のデバイス内のモジュールを、実施とは異なる１つ又は複数のデバイスに適応するように変更して配置することができることを理解されよう。実施におけるモジュール、ユニット、又はコンポーネントは、１つのモジュール、ユニット、又はコンポーネントに組み合わされてもよく、更に、複数のサブモジュール、サブユニット、又はサブコンポーネントに分割されてもよい。これらの特徴及び／又はプロセス又はユニットの少なくともいくつかが相互に排他的であるという場合を除き、明細書（添付の特許請求の範囲、要約及び添付図面を含む）にそのように開示された、方法又はデバイスのすべての開示された特徴及びすべてのプロセス又はユニットは、任意の組み合わせモードで組み合わせることができる。明示的に述べられていない限り、明細書（添付の特許請求の範囲、要約及び添付図面を含む）に開示された各特徴は、同一、同等又は類似の目的を果たす代替機能によって置き換えられてもよい。
【０１４０】
更に、当業者であれば、本明細書で説明されるいくつかの実施は、別の機能を含む代わりに、別の実施に含まれるいくつかの機能を含むが、異なる実施の特徴の組み合わせは、本開示の範囲内にあり、異なる実施を形成することを理解されよう。例えば、後述の特許請求の範囲において、企図された実施のいずれか１つを任意の組合せモードで使用することができる。
【０１４１】
本開示における様々な部分の実施は、１つ又は複数のプロセッサ上で実行される、ハードウェアジュール又はソフトウェアモジュール又はそれらの組み合わせによって実施されてもよい。当業者であれば、実際には、本開示の実施に基づく開示名（例えば、ウェブサイトにおいてリンクレベルを決定する装置）の構成要素の一部又は全部の機能の一部又は全部を実施するためにマイクロプロセッサ又はデジタル信号プロセッサ（ＤＳＰ）を使用できることを理解すべきである。本開示はまた、本明細書で説明される方法の一部又は全部を実行するための装置又はデバイスプログラム（例えば、コンピュータプログラム及びコンピュータプログラム製品）として実施されてもよい。本開示を実施するためのそのようなプログラムは、コンピュータ可読媒体に格納されてもよく、又は１つ又は複数の信号の形態を有してもよい。そのような信号は、インターネットのウェブサイトからダウンロードされるか、搬送波信号で提供されるか、又は他の形態で提供されてもよい。
【０１４２】
前述の実施は、本開示を限定するのではなく本開示を説明することを意図しており、当業者は、添付の特許請求の範囲から逸脱することなく代替の実施を設計することができることに留意されたい。特許請求の範囲において、括弧の間に位置する参照記号は、請求項の限定として構成されるものではない。「含む、”include”」という単語は、特許請求の範囲に記載されていない要素又はステップの存在を排除するものではない。要素の前の単語「一つ、”one”」又は「一つ、”ａ/an”」は、複数のそのような要素の存在を排除しない。本開示は、いくつかの異なる要素を含むハードウェア及び適切にプログラムされたコンピュータによって実施することができる。いくつかの装置を列挙する単位の請求項において、これらの装置のいくつかは、同じハードウェアアイテムを使用することによって具体化されてもよい。第一、第二、及び第三という言葉の使用は、いかなる順序も示さない。これらの単語は名前として解釈されてもよい。
【図１】
2019512138.tif 000004
【図２】
2019512138.tif 000005
【図３】
2019512138.tif 000006
【図４】
2019512138.tif 000007
【図５】
2019512138.tif 000008
【図６】
2019512138.tif 000009
【図７】
2019512138.tif 000010
【図８】
2019512138.tif 000011
【図９】
2019512138.tif 000012
【図１０】
2019512138.tif 000013
【国際調査報告】
2019512138.tif 000014
2019512138.tif 000015
2019512138.tif 000016
2019512138.tif 000017