電気通信クライアントサービス要求をサポートするためのサービスブローカー統合層
【課題】第三者電気通信サービス要求を処理する電気通信システムアーキテクチャ内の層を提供する。
【解決手段】電気通信アーキテクチャは、安全なアクセスゲートウェイを通じて第三者から受信した電気通信サービス要求を処理する。第三者は、それ自体の製品及びサービスをサポートするためにそれらのサービスを用いる他の電気通信サービスプロバイダとすることができ、又は個々の加入者とすることができる。サービスブローカーは、サービス要求を処理するために電気通信アーキテクチャ内の柔軟かつ効率的な層を提供する。サービスブローカーはまた、第三者サービス要求処理に関連する技術的問題を克服する。公開されたサービスに対するサービス要求の効率的かつ安全な処理のための技術的解決法の提供に加えて、このアーキテクチャはまた、既存の電気通信サービスプロバイダのための付加的な収益チャンネルを提供する。
【解決手段】電気通信アーキテクチャは、安全なアクセスゲートウェイを通じて第三者から受信した電気通信サービス要求を処理する。第三者は、それ自体の製品及びサービスをサポートするためにそれらのサービスを用いる他の電気通信サービスプロバイダとすることができ、又は個々の加入者とすることができる。サービスブローカーは、サービス要求を処理するために電気通信アーキテクチャ内の柔軟かつ効率的な層を提供する。サービスブローカーはまた、第三者サービス要求処理に関連する技術的問題を克服する。公開されたサービスに対するサービス要求の効率的かつ安全な処理のための技術的解決法の提供に加えて、このアーキテクチャはまた、既存の電気通信サービスプロバイダのための付加的な収益チャンネルを提供する。
【発明の詳細な説明】
【技術分野】
【0001】
優先権の請求
本出願は、2005年10月28日出願のEPO特許出願第05425764.7号、及び2005年10月28日出願のイタリア特許出願第MI2005A002073号に対する優先権の恩典を請求するものであり、これらの両方は、本明細書においてその全内容が引用により組み込まれている。
本発明は、電気通信処理システムアーキテクチャに関する。特に、本発明は、第三者電気通信サービス要求を処理する電気通信システムアーキテクチャ内の層に関する。
【背景技術】
【0002】
データ処理及び電気通信技術の急速な進歩は、消費者が利用可能な広範な通信サービスをもたらした。そのような電気通信サービスは、従来の電話サービス、「インターネット」サービス、ケーブルテレビジョンサービス、セルラー電話サービス、呼び出しサービス、複合音声及びデータ配信サービス、並びに多くの他のサービスを含む。更に、多くのサービスは、無線又は有線のいずれかに基づくものとすることができる。
従来の電気通信サービスプロバイダは、多岐にわたる電気通信製品及びサービスを実施し、確実に供給するために莫大な量の時間、経費、及び先端技術に投資してきた。過去においては、この投資は、電気通信サービスプロバイダに対してのみ主な利益をもたらすものであった。すなわち、電気通信サービスプロバイダは、自身の技術を秘密裏に、かつ自身の使用のために内部的に維持してきた。
【0003】
高度な電気通信アーキテクチャのこの背景に対して、各電気通信サービスプロバイダ内には、新しい収益チャンネルをもたらす新しい商機を探求して開発するという要望がある。サービスプロバイダアーキテクチャにおける既存の技術は、そのような新しい収益チャンネルを推進することができるであろう。しかし、過去においては、第三者がサービスプロバイダアーキテクチャの潜在的な機能性にアクセスすることを可能にする十分に安全で柔軟性があり、かつ効率的な機構が存在していなかった。
更に、たとえ第三者がサービスプロバイダアーキテクチャの機能性にアクセスできたとしても、第三者のサービス要求を処理するためのサポートするアーキテクチャが存在していなかった。第三者がサービスプロバイダから電気通信サービスを要求できるだけでは十分ではない。サポートする処理アーキテクチャなしでは、第三者の要求には無回答である。
【0004】
【特許文献1】EPO特許出願第05425764.7号
【特許文献2】イタリア特許出願第MI2005A002073号
【発明の開示】
【発明が解決しようとする課題】
【0005】
拡張された電気通信サービスプロバイダアーキテクチャに対する必要性が長らく存在している。
【課題を解決するための手段】
【0006】
拡張された電気通信サービスプロバイダアーキテクチャの確立は、かなりの技術的難問を課している。一例として、同時又はほぼ同時の可能性がある第三者から受信する非常に多くのサービス要求の受信及び編成に技術的困難がある。別の例として、調整された効率的な方法でどのサービス要求を処理するかの判断に技術的困難がある。付加的な技術的難問は、抽出されたサービス要求を実行して要求された処理を実際に達成し、耐障害性のサービス要求処理を提供し、サービス要求処理の性能を最大にすることにある。
【0007】
本発明の一態様は、電気通信アーキテクチャのためのサービス要求処理システムを提供するサービスブローカー層である。サービス要求処理システムは、サービス要求インタフェース、ディスパッチャーシステム、フェッチャーシステム、及びワークフローエンジンを含む。付加的な又は異なる構成要素をサービス要求処理システムに含めることができる。
サービスブローカーは、サービス配信プラットフォームの一部であり、いくつかの技術的利点を提供する。第1の利点は、ワークフロー、タスク、及びアクションの技術指令管理データベース定義を通じて達成することができる構成可能性である。サービスブローカーは、電気通信サービスプロバイダが既存のビルディングブロックから開始して新しいサービスを作成することを可能にし、かつサービスプロバイダが所定のテンプレートから新しいビルディングブロックを作成することを可能にする。サービスブローカーは、それによって、サービスプロバイダを完全に特別仕様で柔軟性のないインフラストラクチャに制限することなく、サービスプロバイダにサービスを定義する多大な柔軟性を提供する。
【0008】
第2の利点は制御である。サービスブローカーは、サービスを配信するために実行されるワークフロー(特に非同期ワークフロー)上でエラー処理、記録、及び制御を提供する。サービスブローカーは、エラー管理グラフィックユーザインタフェースを提供する。インタフェースを通じて、経験豊かなオペレータは、サービスを配信するワークフロー処理の終了、再提出、変更、修正、又はそうでなければ訂正を行うことができる。
【0009】
第3の利点は保守である。一般的に、サービスブローカーは、ワークフロー、メッセージ、及びデータ要素のハードコーディングを避ける。その代わりに、サービスブローカーは、再構成可能XML、並びにメタデータベースのワークフロー、メッセージ、及びデータ要素を用いる。その結果、サービスブローカーの機能性は、ハードコードされた実施と比較して、維持、改訂、拡張、及び改善が遥かに容易である。
【0010】
更に、サービスブローカーは、同期及び非同期ワークフローの両方を実行する機能を提供する。結果として、拡張した性能が生じる。一部の実施例では、毎秒500トランザクション又はそれよりも多くを処理することができる。
サービス要求インタフェースは、電気通信サービスに対するサービス要求を外部エンティティから受信する。各サービス要求は、サービス識別子フィールドを含む。サービス識別子フィールドは、サービスブローカーにサービス要求の中で要求さているサービスのタイプを通知する。
【0011】
サービスブローカー内のディスパッチャーは、各サービス要求を受信する。サービス識別子フィールドに基づいて、ディスパッチャーは、異なるサービス待ち行列の中にサービス要求を分配する。個々のサービス待ち行列は、特定の要求エンティティ及び/又はサービスのタイプに対する要求を独立して待ち行列に入れるように設定することができる。例えば、サービス待ち行列は、メッセージ配信(例えば、「SMS」又は「MMS」)サービス要求待ち行列、課金サービス要求待ち行列、「サービスアクティブ化」要求待ち行列、又は他のタイプのサービス待ち行列を含むことができる。
【0012】
サービスブローカーはまた、フェッチャーシステムを含む。フェッチャーシステムは、処理のために個々のサービス待ち行列から待機サービス要求を検索する。一部の実施例では、サービスブローカーは、複数の独立したフェッチャーエンジンを提供する複数のフェッチャーシステムを含むことができる。一組のトラフィック制御パラメータは、フェッチャーシステムによる個々のサービス待ち行列からの待機サービス要求の検索を支配する。
ワークフローエンジンは、検索されたサービス要求を満足させるワークフロー段階のシーケンスを開始する。サービスブローカーは、複数の独立したワークフローエンジンを実行することができる。ワークフローエンジンは、例えば、特定のフェッチャーシステムによって選択されたサービス要求に対して定義されたワークフローを処理することができる。
【0013】
本発明の付加的な態様は、電気通信サービス要求処理を効率的に順序付けする方法及びシステムを含む。特に、サービスブローカーは、複数のサービス待ち行列を設定し、複数の待機電気通信サービス要求記録をサービス待ち行列の中に分配する。サービスブローカーはまた、サービス要求を検索するために複数のフェッチャーエンジンの同時実行を開始する。
第1のフェッチャーエンジンは、次に、サービス待ち行列に格納された電気通信サービス要求記録(例えば、「技術サービス指令識別子(TSO_ID))の一部を検索する。サービス要求記録は、外部エンティティによって提出された第1のサービス要求を表すものである。同様に、第2のフェッチャーエンジンは、サービス待ち行列に格納された別の電気通信サービス要求の一部を検索する。このサービス要求記録は、外部エンティティによって提出された第2のサービス要求を表すものである。
【0014】
サービスブローカーは、次に、第1のサービス要求及び第2のサービス要求を実施するワークフロー実行を開始するための異なるワークフロー要求配信技術を用いる。例えば、サービスブローカーは、ワークフローエンジンが加入しているメッセージ公開/加入システムを通じてワークフロー要求メッセージを公開することにより、第1のワークフロー要求を実施することができる。代替的なワークフロー要求配信技術として、サービスブローカーは、第2のワークフローエンジンを直接呼び出し、第2のサービス要求を指定することができる。
【0015】
サービスブローカーアーキテクチャは、それによって外部サービス要求の処理に関連する技術的困難を克服する。待ち行列内のサービス要求の分配は、莫大な数の同時又はほぼ同時のサービス要求を受信して編成する技術的困難に対処する。多重フェッチャー及びワークフローエンジンアーキテクチャは、調整された効率的方法でサービス要求を抽出し、抽出されたサービス要求を実行して要求された処理を実際に達成し、耐障害性のサービス要求処理を提供し、サービス要求処理の性能を最大にする際の技術的困難に対処するものである。
【0016】
本発明の他のシステム、方法、特徴、及び利点は、下記の図及び詳細説明の吟味によって当業者には明らかであろうし、又は明らかになるであろう。全てのそのような付加的なシステム、方法、特徴、及び利点は、本説明に含まれ、本発明の範囲内であり、特許請求の範囲によって保護されるように意図されている。
本発明は、下記の図面及び説明への参照によってより良く理解することができる。図中の構成要素は、必ずしも縮尺通りではなく、代わりに本発明の原理の例示に重点が置かれている。更に、図中、同じ参照番号は、異なる図を通して対応する部分又は要素を指定している。
【発明を実施するための最良の形態】
【0017】
図1は、第三者102と対話する電気通信アーキテクチャ100を示している。第三者102は、形態及び実施例において広範に変化することができる。例えば、第三者102は、セルラー電話、携帯情報端末、及びネットワーク(例えば、「インターネット」)通信装置のような加入者装置104、「ショートメッセージサービス(SMS)」メッセージングアプリケーション、「セッション開始プロトコル(SIP)」システム、及び製品及びサービスについて顧客に課金する請求アプリケーションなどの、他のサービスプロバイダによって実施された電気通信サービスアプリケーションのようなアプリケーション106、及び他の装置、プログラム、又はエンティティ108を含むことができる。
【0018】
電気通信アーキテクチャ100は、電気通信製品及びサービスをサポートする機能を実施する。電気通信アーキテクチャ100は、選択された機能を第三者102に公開する。言い換えれば、第三者102は、アーキテクチャ100内に既に置かれている機能を用いるために電気通信アーキテクチャ100と通信することができる。その結果、第三者102は、電気通信アーキテクチャ100によって既に提供されている機能をローカルに複製するために要求されるリソースを消費する必要がない。
【0019】
製品及びサービス、並びにそれらの公開された基本的な機能は、実施例間で変わる場合がある。例えば、電気通信アーキテクチャ100は、「SMS」メッセージングサービス(「SMS」メッセージを配信し、それに対して課金するため)、「マルチメディアメッセージングシステム(MMS)」メッセージングサービス(「MMS」メッセージを配信し、それに対して課金するため)、及び「SIP」サービス(「SIP」呼び出しを設定し、その呼び出しに対して課金するため)を公開することができる。付加的な例として、電気通信アーキテクチャ100は、「課金」サービス(アカウントに対して課金請求を要求するため)、「インターネットプロトコルテレビジョン(IPTV)」サービス(テレビジョン番組の配信を要求するため)、「ユーザステータス」サービス(「オンライン」、「オフライン」、「話し中」、又は「不在」のような現在のユーザステータスを要求するため)、及びユーザ認証サービス(例えば、モバイルユーザが存在するか否か、及びそのモバイルユーザが「IPTV」サービスのような望ましいサービスを購入するための資格を有するか否かの証明を要求するため)を公開することができる。他の機能は、追加的に又は代替として提供することができる。更に、電気通信アーキテクチャ100はまた、第三者アクセスゲートウェイ110を通じて通信ネットワークサービス(例えば、「インターネット」閲覧サービス)へのアクセスを提供することができる。
電気通信アーキテクチャ100は、公開されたサービスへのアクセスを保護する。その目的のために、アーキテクチャ100は、第三者アクセスゲートウェイ110を提供する。第三者アクセスゲートウェイ110は、第三者102に対して公開されたサービスへの単一の点としての役割を達成する。
【0020】
図1に示すように、第三者アクセスゲートウェイ110は、第三者102からサービス要求112を受信する。それに応答して、第三者アクセスゲートウェイ110は、サービス要求が、認証された又は許可された第三者から発せられたものであることを確認する。ネットワーク通信サービス要求の場合は(一例として)、第三者アクセスゲートウェイ110は、許可されたサービス要求を処理し、そのサービス要求をサービスプロバイダ114に中継する。「SMS」、「MMS」、及び「SIP」サービス要求のような公開されたサービス要求の場合には、第三者アクセスゲートウェイ110は、許可されたサービス要求を処理し、サービスブローカー116に中継する。
【0021】
サービスブローカー116は、サービス要求を実行する。それを行う際に、サービスブローカー116は、電気通信製品及びサービスを作成、配備、管理、及び維持するためにアーキテクチャ100が実施する「ビジネスサポートシステム(BBS)」及び「オペレーションサポートシステム(OSS)」118と通信することができる。例えば、「OSS/BSS」システム118は、請求システム、ディレクトリ及びプレゼンスシステム、認証システム、サービス提供システム、又は他のサポートシステムを含むことができる。サービス要求の実行において、サービスブローカー116は、サービス関連データをサービスブローカー116に配信又は返信することができるネットワーク層120と追加的に又は選択的に通信することができる。サービスプロバイダ114及びサービスブローカー116からの応答は、発信元の第三者の要求者への配信のために第三者アクセスゲートウェイ110に返信される。
【0022】
第三者アクセスゲートウェイ110は、第三者102と電気通信アーキテクチャ100内に実施される公開された機能性との間にセキュリティ層を提供する。同時に、サービスブローカー116は、柔軟かつ効率的に第三者のサービス要求を処理するためのアーキテクチャ層を提供する。すなわち、アーキテクチャ100は、サービスプロバイダが第三者102に向けて核心機能性を公開し、第三者102からのサービス要求を安全で標準化かつ制御された方法で処理することを可能にする。
【0023】
図1はまた、サービスブローカー116と通信状態にある顧客関係管理(CRM)システム122を示している。下記で更に詳述することになるが、「CRM」システム122もまた、サービスブローカー116にサービス要求を公開することができる。例えば、「CRM」システム122によって提出されるサービス要求は、サービスのアクティブ化、一時停止、再開、又は終了を含むことができる。要求は、電気通信製品及びサービス(例えば、セルラー電話サービス)を確立、一時停止、又は終了するための顧客支援担当者の「CRM」システム122との対話からもたらすことができる。
【0024】
各サービス要求は、サービスタイプ識別子フィールド及びサービス要求識別子フィールドを含むことができる。下記の説明において、「TSO_LABEL」フィールドは、サービスタイプ識別子フィールドを提供し、「TSO_ID」フィールドは、サービス要求識別子フィールドを提供する。サービス要求内の「TSO_LABEL」は、要求されたサービスのタイプ(例えば、特定の製品又はサービスをアクティブ化する要求)を指定するサービスタイプ識別子である。サービス要求内の「TSO_ID」は、サービス要求自体の識別子(例えば、固有識別子)を提供するサービス要求識別子である。
【0025】
図2は、サービスブローカー116の一実施例の更に詳細な図を示している。上述のように、サービスブローカー116は、サービス要求インタフェース201を通じて「OSS/BSS」システム118を含む外部システム、第三者ゲートウェイ110、及び「CRM」システム122に接続する。サービス要求インタフェースは、物理アダプタ、論理アダプタ、又は物理及び論理アダプタの両方を含むことができる。「OSS/BSS」システムは、物理アダプタ202及び論理アダプタ208を通じてサービスブローカー116に接続し、第三者ゲートウェイは、物理アダプタ204及び論理アダプタ210を通じてサービスブローカー116と接続し、「CRM」システムは、物理アダプタ206及び論理アダプタ212を通じてサービスブローカーと接続する。
【0026】
物理アダプタ202〜206は、外部システムとサービスブローカーの間の通信を統御する通信ソフトウエアによって実施することができる。論理アダプタ208〜212は、サービスブローカーと外部システムの異なるデータモデル間でメッセージマッピングを実行するデータ変換プログラム、マッパー、及び/又はトランスフォーマーを表している。論理アダプタ208〜212は、外部システムからのメッセージデータが、サービスブローカー116が予想する形式でサービスブローカー116に到着することを保証する。一実施例では、アダプタ208〜212は、1つのスキーマによって定義されたフォーマット(例えば、メッセージが第三者ゲートウェイ110内に添付するためのXMLスキーマ)から別のスキーマによって定義された別のフォーマット(例えば、サービスブローカー116が受信するメッセージのためのXMLスキーマ)へのメッセージ及び/又はメッセージコンテントの変換をサポートする。
【0027】
メッセージ公開システム214は、外部システムとサービスブローカー116との間でメッセージを通信するメッセージバスを提供する。更に、メッセージバスは、サービスブローカー116自体の構成要素間のメッセージを通信することができる。メッセージ公開システム214は、あるトピックに割り当てられたメッセージを受信し、そのトピックに対する加入者にメッセージを公開する。加入者は、処理システム(例えば、システム110、118、及び122)、プログラム、又は他のエンティティとすることができる。しかし、他の実施例では、バッチファイル転送、共有ファイル又はメモリ、又は他の相互処理通信技術を含む、他のメッセージ通信技術を用いることができる。
【0028】
メッセージ公開システム及びアダプタ202〜212は、例えば、カリフォルニア州パロアルト所在の「TIBCO Software Inc.」から入手可能な「TIBCOアダプタ(登録商標)」及び「TIBCO Rendezvous(登録商標)」メッセージングによって実施することができる。他の実施例では、物理アダプタは、カリフォルニア州サンホゼ所在の「BEA systems」から入手可能な「BEA Weblogic」統合制御によって実施することができる。一実施例では、メッセージは、「拡張可能マークアップ言語(XML)」のメッセージであり、アダプタは、「変換用拡張可能スタイルシート言語(XSLT)」のスタイルシートに従って変換を実行する。変換は、「XML」、「ハイパーテキスト伝送プロトコル(HTTP)」、「簡易オブジェクトアクセスプロトコル(SOAP)」、「Webサービス定義言語(WSDL)」、「拡張可能スキームダイアグラム(XSD)」、「Java(登録商標)データベース接続性/オープンデータベース接続性(JDBC/ODBC)」、又は他のメッセージフォーマット、コンテント規格、又は通信プロトコルのうちのいずれかのためのスキーマ間でデータを変換することができる。
【0029】
サービスブローカー116はまた、着信サービス要求をサービス要求待ち行列218の中に分配するディスパッチャーシステム216を含む。サービス要求待ち行列218は、特定タイプのサービス要求に割り当てられた1つ又はそれよりも多くの独立した待ち行列を含むことができる。図2に示されている例では、サービス待ち行列218は、第三者ゲートウェイ110から受信したサービス要求を待ち行列に入れる1つ又はそれよりも多くの第三者ゲートウェイサービス要求待ち行列220、及び「CRM」システム122からのサービス要求を待ち行列に入れる1つ又はそれよりも多くの顧客関係管理待ち行列232を含む。
【0030】
例えば、第三者ゲートウェイサービス要求待ち行列220は、メッセージサービス要求待ち行列224(例えば、「SMS」又は「MMS」メッセージ配信要求を待ち行列に入れるための)、及び「課金」サービス要求待ち行列226(例えば、課金要求を待ち行列に入れるための)を含むことができる。待ち行列220の付加的な例は、「認証」要求待ち行列及び「ステータス」要求待ち行列を含む。同様に、「CRM」待ち行列222は、「サービスアクティブ化」要求待ち行列228、「サービス終了」要求待ち行列230、及び「CRM」システム122から受信するサービス要求に対する他の待ち行列を含むことができる。待ち行列220及び222は、上述のタイプ及び個数に限定されてはいない。むしろ、1つ又はそれよりも多くの待ち行列は、いずれか1つ又はそれよりも多くのサービス要求者から受信するいずれか1つ又はそれよりも多くのタイプのサービス要求を待ち行列に入れるように実施し、かつ割り当てることができる。
【0031】
サービスブローカー116は、フェッチャーシステム232を含む。トラフィック制御パラメータ234の制御下で、フェッチャーシステム232は、サービス待ち行列218から待機サービス要求を検索する。次に、フェッチャーシステム232は、検索済みサービス要求をワークフローシステム236に配信する。ワークフローシステム236は、サービス要求を実施するために所定の順序でのワークフロー段階の実行を判断して要求するワークフローエンジン(例えば、ワークフローエンジン238、240、242)の実行を開始する。
【0032】
例えば、「SMS」メッセージを配信し、それに対して課金を行うために、ワークフローシステム236は、「SMS」ワークフローエンジンの実行を開始することができ、このエンジンは、1つの段階として、「SMS」メッセージに対して課金するように請求システムに請求要求を出し、別の段階として、そのメッセージを送信するように「SMS」システムにメッセージ送信要求を出す。ワークフローシステム236は、カリフォルニア州パロアルト所在の「TIBCO Software Inc.」から入手可能な「Tibco InConcert(登録商標)」ワークフローエンジン又は他のワークフローシステムによって実施することができる。
【0033】
サービスブローカーはまた、技術指令管理(TOM)データベース240を含む。「TOM」データベースは、サービス要求を満足させるワークフローにおいて実行されるべき一組の技術サービス指令段階を定義する構成ルールを格納する。「TOM」データベース240は、下記で更に詳述される。
図3は、サービスブローカー302の代替的な実施例を示している。サービスブローカー302は、第2のフェッチャーシステム304を含む。第2のフェッチャーシステム304も同様に、トラフィック制御パラメータ234の制御下でサービス待ち行列218からサービス要求を検索する。代替的に、第2のフェッチャーシステム304は、独立した一組のトラフィック制御パラメータの制御下で作動することができる。付加的なフェッチャーシステム及びトラフィック制御パラメータの組を提供することができる。
【0034】
第2のフェッチャーシステム304は、フェッチャーシステム232とは異なるワークフロー要求配信技術を用いる。特に、第2のフェッチャーシステム304は、システム214のようなメッセージ公開システムにワークフロー要求メッセージを公開する。次に、メッセージ公開システム214は、メッセージ公開システム214におけるワークフロー要求メッセージに加入している第2のワークフローシステム306にワークフロー要求メッセージを配信することができる。言い換えれば、メッセージ公開システム214は、第2のフェッチャーシステム304をワークフローシーケンスの直接呼び出しという負担及び問題から解放する。
【0035】
代わりに、第2のワークフローシステム306は、公開されたワークフロー要求メッセージを受信し、サービス要求を実施するためにワークフローの実行を開始する。第2のワークフローシステム306は、第1のワークフローシステム236と同一の方法で実施される必要はない。図3に示されている例では、第2のワークフローシステム306は、インバウンド要求マネージャ308、ワークフローエンジン310、及び並列タスクマネージャ312を含む。アクションマネージャ320及びアクションビルダ322を含むアクションエンジン318は、ワークフロー内のネットワークサービス提供アクションを実行する。各々は、下記で更に詳述される。
【0036】
第2のワークフローシステム306の追加は、いくつかの利益を発生させる。特に、第2のワークフローシステム306は、第1のフェッチャーシステム232を通じてワークフローシステム236を直接呼び出すことによってサービス要求を処理するという潜在的問題の除去に役立つ。更に、第1のフェッチャーシステム232及び第2のフェッチャーシステム304は、一緒に実行することができ、これは、サービス要求を並列に処理することにより端末間の性能を改善させるだけでなく、サービス要求を処理するための2つの独立したフェッチャー/ワークフローエンジンシステムを提供することによって強力な耐障害性エンジンシステムを達成する。
【0037】
サービスブローカー302又は116はまた、ウェブエラー・グラフィカルユーザインタフェース(GUI)を含むことができる。図3は、第2のフェッチャーシステム304に設けられたウェブエラー「GUI」314の例を示している。ウェブエラー「GUI」314は、「ウェブ」サーバ(例えば、カリフォルニア州サンホゼ所在の「BEA Systems」から入手可能な「Weblogicアプリケーション」サーバ)を実行する「Java(登録商標)」サーバページの「ウェブ」アプリケーションとして実施することができる。
【0038】
ウェブエラー「GUI」314は、サービス要求処理中に遭遇するあらゆるエラーに関する情報をユーザインタフェースディスプレイに掲載する。ウェブエラー「GUI」314はまた、入力機構を提供することができ、それによって検閲者は、修正入力(例えば、データを変更するか、又はサービス要求内の欠損データを完成させるか、又はサービス要求又はタスクを修正するためにワークフロータスクをサポートする入力)を与え、サービス要求又はタスクを手動で完成させるか又は処理のためにサービス要求又はタスクを再提出する。
【0039】
一実施例では、エラーに遭遇した各サービス要求は、ウェブエラー「GUI」において説明的なタイトル及びサービス要求特性の付加的な詳細へのハイパーリンクによって表すことができる。ウェブエラー「GUI」314は、更に検索インタフェースを提供することができる。検索インタフェースは、検索判断基準(例えば、「MSISDN」番号、「TSO_ID」、データ範囲、サービス要求タイプ、エラーコード、顧客又は他の識別子、又はサービス要求の他のあらゆる特性)を受け入れ、適合するエラー記録の応答的検索及び表示を実行する。ハイパーリンク上のクリックは、ウェブエラー「GUI」314に選択されたサービス要求に特定のエラー情報、及びそのサービス要求について入手可能な追加特性(例えば、要求タイプ、「IMSI」番号、「MSISDN」番号、送信者、受信者、メッセージテキスト、顧客名及び住所、又は他のあらゆる特性)のディスプレイへの掲載を誘発する。
【0040】
ウェブエラー「GUI」314は、検閲者からの修正入力を受け入れる。検閲者は、ウェブエラー「GUI」314に修正済みサービス、タスク、又はアクションをフェッチャーシステム304に再公開するように指示することができる。フェッチャーシステム304は、修正済みサービス要求メッセージを受信し、修正済みサービス要求、タスク、又はアクションを元の場所で処理する。この方法で、フェッチャーシステム304は、元のサービス要求がエラーに遭遇した点で既にインスタンスが生成されているワークフローを継続することによって貴重な時間と処理リソースを節約する。
【0041】
同様に別々のウェブエラー「GUI」を第1のフェッチャーシステム232に対して提供することができる。メッセージ公開システム214を用いる他に、第1のフェッチャーシステム232に対するウェブエラー「GUI」は、API内に定義された関数呼び出しを通じてエラー情報を通信することができる。関数呼び出しは、「Tibco InConcert(登録商標)」ワークフローエンジンによって達成することができ、ウェブエラー「GUI」314について上述したように、このウェブエラー「GUI」は、エラー情報を報告し、修正入力を受け入れることができる。
【0042】
サービスブローカーはまた、ワークフロー「GUI」324を提供することができる。ワークフロー「GUI」324は、ワークフロー定義のためにグラフィカルインタフェースを提供し、これは、サービスブローカーに多大な構成可能性を提供する。ワークフロー「GUI」324は、ドラッグアンドドロップインタフェースを実施し、これを通じてオペレータは、新しいワークフローを作成するためにタスクを選択して順序付けることができる。
【0043】
図3は、オペレータが4つのタスク326,328、330、及び332を順番に配列して新しいワークフロー334を形成する一例を示している。サービスプロバイダが望むあらゆる機能に対してサービスブローカーをカスタマイズする新しいワークフローを定義するために、あらゆる個数のタスクをあらゆる順序で配列することができる。ワークフロー「GUI」324は、「TOM」データベース内に定義された所定のワークフロー、タスク、及びアクションの1つ又はそれよりも多くについてワークフロー、タスク、及びアクションのグラフィカルな表現をもたらすことができる。ワークフロー、タスク、及びアクションは、ワークフローテーブル902、タスク構成テーブル904、及び/又はアクションテーブル906内に定義されたワークフロー、タスク、及びアクションを表すことができ、これらは下記に説明される。
【0044】
拡張「TOM」データベース316もまた、サービスブローカー302内に存在する。拡張「TOM」データベース316は、第2のワークフローシステム306及びウェブエラー「GUI」314をサポートするために第1の「TOM」データベース244を拡張する。下記でより詳細に説明することになるが、拡張「TOM」データベース316は、特定のサービス要求を実施するために取られるべきタスク及びアクションのシーケンスを定義し、ウェブエラー「GUI」314のために報告テーブルを提供する。
【0045】
図4は、トラフィック制御パラメータ234の例を示している。特に、図4は機能名パラメータ402、プールサイズパラメータ404,及びポーリング時間パラメータ406を示している。図4はまた、提出タイマパラメータ408、判断基準パラメータ410、及び待機パラメータ412を示している。付加的なトラフィック制御パラメータは、待ちパラメータ414,制御ロックパラメータ416、及びデータパラメータ418を含む。
【0046】
下記の表1は、各トラフィック制御パラメータ234に関する説明を提供する。
【0047】
【0048】
トラフィック制御パラメータ234は、作動時にフェッチャーシステム232及び304を動的に再構成することができる。この目的のために、トラフィック制御パラメータ234は、フェッチャーシステム232及び304内部のトラフィック制御マネージャ処理と通信することができる(例えば、「URL」内にパラメータを埋め込んだ「HTTP」接続を通じて)。次に、トラフィック制御マネージャは、サービス要求ブロックの次の検索のために新しパラメータによって内部変数を設定することができる。
【0049】
図5は、ディスパッチャー216の実施の例である。ディスパッチャー216は、メモリ504に連結されたプロセッサ502を含むことができる。メモリ504は、ディスパッチプログラム506を格納する。ディスパッチプログラム506は、マルチスレッド処理とすることができる。メモリ504はまた、ディスパッチプログラム506よる処理に向けたインバウンドメッセージ508を保持する。インバウンドメッセージ508は、技術サービス指令ラベル(TSO_LABEL)フィールド510、「TSO_ID」フィールド511、及び更にサービス要求を定義する(例えば、「SMS」メッセージデータ、受信者、又はサービス要求をサポートする他のデータを指定することにより)サービス要求メッセージデータ512を含む。「TSO_LABEL」フィールドは、要求されたサービスを表すサービスタイプ識別子フィールドを提供する。
【0050】
インバウンドメッセージ508は、メッセージ内の各データ要素の周囲に識別タグを含む「拡張可能マークアップ言語(XML)」メッセージとすることができる。ディスパッチプログラム506は、インバウンドメッセージ508内の「XML」データを吟味し、「XML」データ内のタグが付けられたフィールドに基づいてサービス待ち行列218内のサービス要求記録を設定する。特に、サービス識別子フィールドに基づいて(例えば、「TSO_LABEL」に基づいて)、ディスパッチプログラム506は、「TSO_LABEL」510に基づいて特定のサービス待ち行列内のサービス要求記録を設定する。言い換えれば、「TSO_LABEL」510は、ディスパッチプログラム506のためにサービス要求のタイプ、従って、サービス要求が存在すべき適切なサービス待ち行列を識別する。
【0051】
サービス待ち行列218は、データベーステーブルとして実施することができる。図5は、サービス待ち行列218内で定義することができるサービス要求記録514の例を示している。しかし、他のサービス要求記録定義を実施することもできる。サービス要求記録514のフィールドは、下記に表2において説明する。
【0052】
【0053】
「TSO_ID」、「TSO_LABEL」、及び「TSO_DATE」は、別々のフィールドに格納される。ディスパッチプログラム506がインバウンドメッセージ508を受信すると、ディスパッチプログラムは、メッセージ508から「TSO_ID」、「TSO_LABEL」、及び「TSO_DATE」データを別々に抽出し、サービス要求記録514内の対応するフィールド内にそのデータを格納することができる。従って、フェッチャーシステム232及び304は、あらゆるフィールド又はフィールドの組合せによって待ち行列テーブルから列データを抽出することができる。
【0054】
一実施例では、ディスパッチプログラム506がサービス待ち行列テーブル内の列に新しいサービス要求記録514を挿入すると、ディスパッチプログラム506は、以下のフィールドにデータを挿入する。
TSO_ID
TSO_LABEL
TSO_DATE
XML_IN
BP_FLAG=0
AP_FLAG=0
INS_TMS=システム日付
【0055】
図6は、フェッチャーシステム232の実施を示している。フェッチャーシステム232は、メモリ604に連結されたプロセッサ602を含む。メモリ604は、フェッチャープログラム606(例えば、マルチスレッド処理)を格納する。メモリはまた、サービス要求記録列リスト608を保持する。サービス要求記録列リスト608内のエントリは、サービス待ち行列218内のサービス要求を提示している。
【0056】
トラフィック制御パラメータ234に従って、フェッチャープログラム606は、サービス待ち行列218をポーリングする。フェッチャープログラム606は、選択されたサービス要求記録から「TSO_ID」のプールを検索する。フェッチャープログラム606は、サービス待ち行列218内のテーブルにアクセスするために、格納された「構造化照会言語(SQL)」手順を呼び出すことができる。
【0057】
格納された手順は、サービス待ち行列218内の各列に対して「BP_FLAG」を1に設定することができ、これは、フェッチャーシステムによって与えられる検索判断基準を満たすものである。格納された手順は、検索判断基準を満たす列の列リスト608をフェッチャーシステム232に返信する。列リスト608は、各適合したサービス要求記録からの「TSO_ID」フィールドを含むことができる。
【0058】
フェッチャープログラム606は、格納された手順から列リスト608を取得する。次に、フェッチャープログラム606は、列リスト608をワークフロー呼び出しプログラム610に渡す。ワークフロー呼び出しプログラム610は、列リスト内で識別される、サービス要求記録内に表された各サービス要求を実施する適切なワークフローの実行を開始するためにワークフローシステム236を呼び出す。
より具体的には、ワークフロー呼び出しプログラム610は、列リスト608を各列について非同期に処理する。ワークフロー呼び出しプログラム610は、トラフィック制御パラメータ234内で指定される「WAIT」時間の間待っている。「WAIT」時間が満了すると、ワークフロー呼び出しプログラム610は、現時点で処理中のサービス要求に対して「BP_FLAG」を「2」に設定する。
【0059】
次に、ワークフロー呼び出しプログラム610は、現在の列に関するサービス要求を実施するワークフローを開始するためにワークフローシステム236を直接呼び出す。ワークフローを開始するための呼び出しにおいては、ワークフロー呼び出しプログラム610は、ワークフローシステム236に「TSO_ID」フィールドを非同期に渡すことができる。次に、ワークフロー呼び出しプログラム610は、ワークフローが呼び出されたことを表すために「BP_FLAG」を「3」に設定する。
【0060】
ワークフローシステム236では、ワークフローエンジンは、特定のサービス要求を実施するワークフロー段階(例えば、タスク、アクション、及び「TSO」)を実行する。サービス要求の実施において、ワークフローエンジンを実行する第1のタスクは待ち行列テーブルから「XML_IN」データを検索することである。ワークフローエンジンは、フェッチャーシステム232によって与えられる「TSO_ID」に適合するサービス要求記録から「XML_IN」データを検索する。それによってサービスワークフローは、要求されたサービスに対するデータのサポートを含む要求されたサービスの完全な定義を取得する。例えば、「SMS」メッセージ配信に関する「XML_IN」データは、メッセージテキスト及び受信者の識別子を含むことになる。
【0061】
「TSO_LABEL」フィールドは、要求されたサービスを指定する。ワークフローは、要求されたサービスを実施するタスクを実行する。「SMS」メッセージ配信においては、例えば、ワークフローエンジンは、請求システムに課金メッセージを送信することができ、その後「SMS」配信サブシステムにメッセージテキストを送信することができる。ワークフローエンジンはまた、サービス要求処理の結果を返信する。例えば、ワークフローは、詳細説明、又はサービス要求処理から生じる他のあらゆる情報を任意的に添えて成功メッセージ又はエラーメッセージを返信することができる。
【0062】
ワークフローは、適切な「TSO_ID」に関するサービス要求記録を更新することによって終了する。ワークフローエンジンは、サービス要求記録の中に「XML_OUT」文字列を書き込む。「XML_OUT」文字列は、サービス要求処理の結果を含むことができる。更に、ワークフローエンジンは、ワークフローが終了したことを表すために「AP_FLAG」を「1」に設定し、「END_TMS」を現在のシステム日付に設定する(すなわち、ワークフロー終了の日付/時間)。
【0063】
ワークフローエンジンは、技術指令管理(TOM)データベース244を参考にして実行すべきタスク及びアクション、及び実行の順序を判断する。図7は、「TOM」データベース244に対するデータモデルの一実施例を示している。データモデルは、図7に示されている実施例に限定されてはおらず、むしろデータモデルが用いられる特定の実施例に従って広範に変化する。「TOM」データベース244は、「サービス技術指令カタログ(STOC)」テーブル702、「アクション」テーブル704、及び「STOC」パラメータテーブル706を含む。「TOM」データベース244は、「「ClassBuild」テーブル708、「PutSequenceInClassテーブル」710、及び「SequenceBuildテーブル」712を更に含む。
【0064】
「STOC」テーブルは、主要キーとしての「STOC_ID」フィールド714、及び追加フィールド716を含む。「アクション」テーブルは、主要キーとしての「Action_ID」フィールド718、及び追加フィールド720を含む。「STOCParam」テーブル706は、主要キーとしての「STOCParam_ID」フィールド722、及び追加フィールド724を含む。「ClassBuild」テーブル708は、主要キーとしての「Param_ID」フィールド726、及び追加フィールド728を含む。「PutSequenceInClass」テーブル710は、主要キーとしての「PutSequence_ID」フィールド730、及び追加フィールド732を含む。「SequenceBuild」テーブル712は、主要キーとしての「Sequence_ID」フィールド734、及び追加フィールド736を含む。
【0065】
「STOC」テーブル702は、サービス要求を統御するための「技術サービス指令(TSO)」と呼ばれる、ワークフロー段階のワークフローテンプレートを定義する。「アクション」テーブル704は、あらゆる所定のサービス要求を満足させるために実行されるべき「TSO」(すなわち、アクション)及びそれらの実行順序を定義し、それらを「STOC」テーブルに連結して戻す。一部の実施例では、データベース228は、「アクション」テーブル704と同様な「逆アクション」テーブルを定義することができる。ワークフロー内でのアクションの処理中にエラーが発生すると、関連の「逆アクション」を実行することができる。「逆アクション」は、顧客アカウントステータス、注文ステータス、又は独立した処理システム間の他のデータと同期させることができる。「TOM」データベース244は、サービス要求者から受信することができるか又はワークフローエンジン自体によって与えることができるアクションに関するパラメータを更に定義する。追加フィールドを含む各テーブル702〜712は、下記においてより詳細に説明される。
【0066】
【0067】
【0068】
【0069】
【0070】
【0071】
【0072】
ワークフローシステム236は、サービス指令処理を2つのタスクに分割する。第1のタスクは、「TOM」データベース244内でワークフロー定義を検索することによってサービス要求が「TSO」の中に分割される方法を判断することである。第2のタスクは、「TSO」を正しいシーケンスで送信し、応答を受信し、エラーを処理することによってこれらの「TSO」を管理することである。
「TSO_LABEL」及び「TOM」データベース244内に設定された定義に基づいて、ワークフローシステム236は、実行すべき「TSO」の組及びそれらの順序を判断する。ワークフローシステム236はまた、実行されるべき各「TSO」に対して属性リストを構築する。属性は、サービス要求者(例えば、「CRM」システム122)によって全体を又は部分的に指定することができ、また、「TOM」データベース244によっても全体を又は部分的に指定することができる。「TSO」が実行されると、ワークフローエンジンは、実行すべき現時点の「TSO」を提示するインデックスを増分する。
【0073】
ワークフローエンジンは、「TSO」の実行を要求するメッセージを構築する。例えば、メッセージは、全体のサービス要求の実施の一部としてメッセージ内に指定されたアクションを実行するサービス提供システムに対して公開することができる。「TOM」データベース244は、メッセージ構築をサポートし、「TSO」が実行すべき指令、「TSO」に関する属性(「TOM」データベース244内で指定される静的属性、及びサービス要求者によって提出される動的属性)、メッセージが公開されるサブジェクト、及び上述の他のパラメータを提供する。
このように、「TOM」データベース244は、「TSO_LABEL」に関連するサービス要求ワークフローを、サービス要求を実施する一組の「TSO」に分割する構成ルールを提供する。それによって「TOM」データベース244は、ワークフロー、ワークフローを実施する「TSO」、及び「TSO」を実行する順序を定義するための極めて柔軟で再構成可能な拡張性のある機構を提供する。
【0074】
図8は、第2のフェッチャーシステム304の実施例を示している。フェッチャーシステム304は、メモリ804に連結されたプロセッサ802を含むことができる。メモリ804は、フェッチャープログラム806(例えば、マルチスレッド処理)を格納する。メモリはまた、サービス要求記録列リスト808を保持する。サービス要求記録列リスト808内のエントリは、第三者ゲートウェイ110、「CRM」システム122、又は他のあらゆる外部サービス要求者によって提出され、サービス待ち行列218内で待機しているサービス要求を提示している。
【0075】
トラフィック制御パラメータ234(又は、フェッチャーシステム304に対して設定されたトラフィック制御パラメータの独立した一組)に従って、フェッチャープログラム806は、サービス待ち行列218をポーリングする。フェッチャープログラム806は、適合するサービス要求記録を「TSO_ID」ブロックから検索する。フェッチャープログラム806は、サービス待ち行列218内のテーブルへのアクセスのために格納された「構造化照会言語(SQL)」手順を実行することができる。
処理されるべき各サービス要求に対して、フェッチャープログラムは、インスタンスマネージャプログラム814を呼び出す。インスタンスマネージャプログラムは、「TOM」データベース316内のテーブルにデータを追加し、サービス要求に対するワークフローテーブルのインスタンスを作成する。「TOM」データベーステーブルは、下記で更に詳述される。
【0076】
フェッチャープログラム806は、列リスト808をメッセージ公開プログラム810に渡す。メッセージ公開プログラム810は、第2のワークフローシステム306にワークフロー要求メッセージ812(サービス要求を指定する)を公開する。すなわち、フェッチャーシステム304は、メッセージ公開システム214が第2のワークフローシステム306にワークフロー要求メッセージを配信することを可能にすることにより、ワークフローエンジンを直接呼び出すという潜在的問題を除去する。ワークフロー要求メッセージは、「TSO_ID」(「TSO_ID」フィールド814内)及び「TSO_LABEL」(「TSO_LABEL」フィールド816内)を指定することができる。「TSO_ID」及び「TSO_LABEL」は、サービス待ち行列218内のサービス記録から得られる。フェッチャーシステム304は、各ワークフロー要求メッセージを公開した後にメッセージ公開システム214からの応答を待つことができる。
より具体的には、要求/回答メッセージは、下記の表9〜12に示すように定義することができる。
【0077】
【表1】
【0078】
【表2】
【0079】
【表3】
【0080】
【表4】
【0081】
図9は、第2のフェッチャーシステム304をサポートする、「TOM」データベース316内にある拡張を示している。サービス要求を実施するために取る段階のシーケンスは、「Workflows」テーブル902、「Task_cfg」テーブル904、及び「アクション」テーブル906によって定義される。特に、「Workflows」テーブル902は、ワークフローテンプレートを定義し、「Task_cfg」テーブル904は、ワークフローを実施するタスクを定義し、「アクション」テーブル906は、各タスクに関連するアクションを定義する。タスク及びアクションは、例えば、外部「Tibco BusinessWorks(登録商標)」処理システムにおいて実行される処理によって実行することができる。サポートするタスクインスタンステーブル908及びサポートするアクションインスタンステーブル910もまた存在する。各テーブルは、下記で更に詳述される。
【0082】
【0083】
【0084】
【0085】
「TASK_INST」テーブル908は、「TASK_CFG」テーブル904と同一のフィールド、及び以下の追加フィールドを含むことができる。
【0086】
【0087】
「ACTION_INST」テーブル910は、「アクション」テーブル906と同一のフィールド、及び以下の追加フィールドを含むことができる。
【0088】
【0089】
更に、拡張「TOM」データベース316は、ウェブエラー「GUI」314に対してサポートを提供する。特に、拡張「TOM」データベース316は、「GUIユーザ」テーブル912、「GUI」役割テーブル914,及び「GUI」ステータステーブル916を含む。同じく含まれているのは、「GUI」履歴テーブル918である。各テーブルは、下記で更に詳述される。
【0090】
【0091】
【0092】
【0093】
【0094】
各サービス要求に対して、対応するサービス要求メッセージ公開の前に、インスタンスマネージャプログラム814は、「TASK_INST」テーブル908に実行されるべきワークフロータスクを追加する。インスタンスマネージャプログラム814はまた、「ACTION_INST」テーブル910に各タスク内のサービス提供アクションを追加する。テーブル908及び910に加わるデータは、カタログテーブル902、904、及び906内に定義されたテンプレートから得られる。すなわち、処理されるべき各サービス要求は、「TASK_INST」テーブル908及び「ACTION_INST」910において準備が整った、インスタンスが生成されたワークフローを有する。
第2のワークフローシステム306は、メッセージ公開システム214から公開されたワークフロー要求メッセージを受信する。ワークフローシステム306は、最初にインバウンド要求マネージャ308を通じてワークフロー要求メッセージを処理する。
【0095】
図10は、インバウンド要求マネージャ308によって取られたアクション1000の流れ図の例を示している。インバウンド要求マネージャ308は、メッセージ公開システム214によって公開された公開済みサービス要求メッセージを受信する(段階1002)。インバウンド要求マネージャは、サービス要求メッセージから「TSO_ID」を抽出し(段階1004)、サービス要求メッセージから「TSO_LABEL」を抽出する(段階1006)。
【0096】
「TSO_ID」を用いて、インバウンド要求マネージャ308は、「TSO_ID」によって表されるサービス要求を実施する、インスタンスが生成されたワークフローテンプレートを得るために拡張「TOM」データベース316を検索する。テンプレートが定義されていない場合には、インバウンド要求マネージャ308は、フェッチャーシステム304に「否定」応答を返信する(段階1010)。そうでなければ、インバウンド要求マネージャ308は、フェッチャーシステム304に「肯定」応答を返信し(段階1012)、この「TSO_ID」及び「TSO_LABEL」を伴って「ワークフロー」エンジン310を呼び出す(段階1014)。
【0097】
図11は、ワークフローマネージャ310によって取られるアクション1100の流れ図の例を示している。ワークフローマネージャ310は、インバウンド要求マネージャ308から「TSO_ID」及び「TSO_LABEL」を受信する(段階1102)。次に、ワークフローエンジン310は、「TASK_INST」テーブル908からのワークフローテンプレート内でワークフロータスクを検索する(段階1104)。
【0098】
ワークフロー内に更にいずれかのタスクが存在する場合には、ワークフローエンジン310は、順番に次のタスクを実行する(段階1106)。そうするために、ワークフローエンジン310は、「TASK_INST」テーブル908内のタスクに対して識別されるサブ処理を起動する。シーケンスで起動されるタスクに対して、ワークフローエンジン310は、タスクサブ処理を起動し、このサブ処理からの応答を待つ(段階1108)。他のタスクと並列して起動することができるタスクに対しては、ワークフローエンジン310は、タスクのサブ処理を起動し、待つことなしに次のタスクへと続行する(段階1110)。
【0099】
いくつかのステータスは、タスクに対して定義される。ワークフローエンジン310及びウェブエラー「GUI」314は、タスク実行中にステータスを設定し、維持することができる。タスクに対する初期ステータスは、「I」(初期)であり、終了ステータスは、「D」(終了)又は「C」(強制完了)のいずれかとすることができる。最初は、各タスクは、「I」に設定されたステータスを有することができる。ワークフローエンジン310がタスク実行のためにサブ処理を起動すると、タスクステータスは、「X」(実行)に変化する。「X」ステータスは、サブ処理がタスクを実行中であることを示している。
【0100】
タスクの終了の成功及びサブ処理からの回答の受信は、タスクの「D」(終了)ステータスへの移行を誘発する。次に、ワークフローシステム306内のワークフローエンジン310は、ワークフロー内の次のタスクに移動することができる。サブ処理がエラーを伴って回答した場合には、ワークフローエンジン310は、タスクステータスを「E」(エラー)に設定することができる。それに応答して、ワークフローエンジン310は、そのタスクをウェブエラー「GUI」314に渡す。
【0101】
上述のように、ウェブエラー「GUI」314は、インタフェースを提供し、これを通じてオペレータは、メッセージコンテントを修正、タスクを省略、又はタスクを(修正を加えて)処理のために再提出することができる。タスクが再提出されると、タスクステータスは、「R」(再提出)に移行する。ワークフローシステム306は、再提出されたタスクを受信し、そのタスクを統御するサブ処理を実行し、タスクステータスを「X」に設定する。エラーステータス「E」を伴うタスクに対しては、ワークフローエンジン310は、タスク実行を停止する。ウェブエラー「GUI」314は、タスク処理を要求するためにワークフローシステム306に要求/回答メッセージを公開することによってタスクを再開することができる。
【0102】
ウェブエラー「GUI」314がタスクを省略する場合には、タスクステータスは、「C」(完了)に設定される。これに加えて、オペレータは、ウェブエラー「GUI」314を通じてタスク実行を制御することができる。オペレータは、ウェブエラー「GUI」314を通じてタスクを即時に完了させる要求を出すことができ(タスクを「C」ステータスに移行させる)、又はタスクを再提出させることができる(タスクを「R」ステータスに移行させる)。ワークフローシステム306は、「C」ステータスが最終ステータスであると考え、それに応答してワークフローシーケンス内の次のタスクに移動する。
【0103】
図12は、並列タスクマネージャ312によって取られる段階1200の例を示している。ある一定のタスクは、他のタスクと同時に実行することができる並列タスクとして指定することができる。それにも関わらず、一部のタスクは、続行するために他のタスクから得られる結果を必要とする可能性がある。従って、並列タスクマネージャ312は、並列タスクを実行しているサブ処理からの応答をモニタし(段階1202)、応答を取得し(段階1204)、続行することができるようになる前に応答を待っている他のタスクに応答を提供する(例えば、ワークフローエンジン310を通じて)(段階1206)。それによって並列タスクマネージャ312は、入力データを待っている待機状態のタスクの障害を取り除くように作用する。
【0104】
上述のように、ワークフローシステム306はまた、アクションエンジン318を含む。アクションエンジン318は、個々のタスク内でネットワークサービス提供アクションを実行する。言い換えれば、拡張「TOM」データベース316がある一定のタスクに対してネットワークサービス提供アクションを指定した場合に、第2のワークフローシステム306は、アクションを処理するためにこのアクションエンジン318を呼び出すことができる。
【0105】
アクションエンジン318は、2つの層、すなわち、アクションマネージャ320及びアクションビルダ322を含む。アクションマネージャ320は、「TOM」データベース316内に定義されている正しいシーケンスでのサービス提供アクションの実行を判断して開始する。アクションビルダ322は、アクションの実行を要求するためにメッセージ公開システム214に対して適切なメッセージを作成して送信し、同様にメッセージ公開システム214から応答を受信する。
アクションエンジン318は、ワークフローエンジン310と同様な方法で実行する(図11)。より具体的には、アクションエンジン318は、ワークフロー内のタスクの処理に対する要求を受信する。それに応答して、アクションマネージャ320は、そのタスクに対して実行すべきアクションを「ACTION_INST」テーブル910から検索する。
【0106】
実行されるべき各アクションに対して、アクションマネージャ320は、アクションビルダ322を呼び出す。アクションが「デタッチ」されない(すなわち、並列に実行されない)場合には、アクションマネージャ320は、アクションビルダ322からの応答を待つ。そうでなければ、アクションマネージャ320は、アクションビルダ322からの応答を待たずにシーケンス内の次のアクションの実行を開始する。ウェブエラー「GUI」314は、ここでもまた、タスクエラーと同じ方法で、かつ同じステータス移行を伴ってアクション実行中に発生するエラーを管理することができる。
【0107】
アクションビルダ322は、アクションを実行することになるシステム又は処理への配信に向けてアクション要求メッセージを構築し、メッセージ公開システム214に送信する。アクションビルダ322は、メッセージ公開システム214からアクション実行から生じる応答を受信する。アクションビルダ322は、この応答をアクションマネージャ320に戻す。応答に基づいて、アクションマネージャ320は、あらゆるエラーを処理するか(例えば、ウェブエラー「GUI」314を通じて)、又は存在するならば次のネットワークアクションを実行する。
【0108】
ワークフロー、タスク、及びアクションは、広範囲なサービス要求について定義することができる。一例として、「UMTS加入者識別モジュール(USIM)」をアクティブ化するためのワークフローは、「ACTIVATE_USM」の「TSO_LABEL」に関連付けることができ、以下のタスクへと分割することができる:コア基本サービスを「アクティブ化」する(例えば、関連の「IMSI」及び「MSISDN」を提供する)、メッセージサービスを「変更」する(例えば、関連のメッセージサービスに「MSISDN」及び顧客名を提供する)、及び警告サービスを「変更」する(例えば、警告サービスに顧客名、誕生日、住所、又は他の顧客情報を提供する)。「CRM」システム122からのサービス要求に関連するワークフローの付加的な例は、「USIM」を「変更」し、「USIM」を「一時停止」し、「USIM」を「再開」し、「MSISDN」番号を「変更」し、送受話器を「非アクティブ化」し、先払い又は後払い「USIM」を「事前アクティブ化」し、サービスを「アクティブ化」し、サービスの「終了」し、「USIM」を「終了」するワークフローを含む。
【0109】
サービスブローカー116は、広範な電気通信サービスに対するサービス要求を処理する。1つの役割では、サービスブローカー116は、第三者ゲートウェイ110から受信するサービス要求を処理する。一般的に、サービスブローカー116は、インバウンドサービス要求を一連の段階(例えば、タスク及びアクション)にマッピングし、サービス要求の実施に導くものである。サービスブローカー116は、各段階の実行に対する要求を適切なシステム又は処理に配信し、結果を判断し、この結果に関して第三者ゲートウェイ110と通信する。
【0110】
図13は、第三者ゲートウェイ110から受信した「認証」サービス要求から生じるメッセージフローの例を示している(フロー1302)。例えば、ユーザがサービスを購入することができる前に識別される必要がある場合には、第三者ゲートウェイ110は、「認証」要求(「MSISDN」及び/又は「IMSI」番号のようなユーザを認識するために用いられる情報を含む)を送信することができる。サービスブローカー116は、ユーザプロフィールに対する要求をディレクトリシステムに提出し(フロー1304)、ディレクトリシステムは、ユーザプロフィールを返信する(フロー1306)。
【0111】
サービスブローカー116は、第三者ゲートウェイ110に結果を返信する(フロー1308)。ディレクトリシステムがユーザを認証できなかった場合には、サービスブローカー116は、第三者ゲートウェイに「非許可」メッセージを返信する。そうでなければ、サービスブローカー116は、ユーザプロフィールデータと共に「許可」メッセージを返信する。ユーザが許可された場合には、サービスブローカー116は、次に、ユーザのサービスプロフィールに対する要求という形態でユーザに関する追加情報をディレクトリシステムに要求することができ(フロー1310)、ディレクトリシステムは、そのプロフィールを返信する(フロー1312)。
【0112】
サービスブローカー116は、結果を第三者ゲートウェイ110に返信する(フロー1314)。プロフィール情報が入手不能であった場合には、サービスブローカー116は、「非許可」メッセージを第三者ゲートウェイ110に返信する。そうでなければ、サービスブローカー116は、サービスプロフィールデータと共に「許可」メッセージを返信する。
表22及び23は、「認証」サービス要求メッセージ及び応答の例を示している。
【0113】
【表5】
【0114】
【表6】
【0115】
図14は、第三者ゲートウェイ110から受信した「課金」サービス要求から生じるメッセージフローの例を示している(フロー1402)。第三者ゲートウェイ110は、ユーザアカウントにサービス額を課金するために「課金」要求を送信することができる。サービスブローカー116は、課金額を含む課金要求を請求システムに提出する(フロー1404)。請求システムは、サービスをアカウントに課金し、サービスブローカー116に結果ステータスを返信する(フロー1406)。サービスブローカー116は、結果ステータスを第三者ゲートウェイ110に返信する(フロー1408)。
表24及び25は、「課金」サービス要求メッセージ及び応答の例を示している。
【0116】
【表7】
【0117】
【表8】
【0118】
図15は、第三者ゲートウェイ110から受信した「SMS」配信サービス要求から生じるメッセージフローの例を示している(フロー1502)。第三者ゲートウェイ110は、ユーザアカウントに対して課金し、「SMS」メッセージを配信するために「SMS」要求を送信することができる。サービスブローカー116は、サービスについてアカウントに課金するように請求システムに要求し(フロー1504)、請求システムから結果ステータスを受信する(フロー1506)。サービスブローカー116は、結果ステータスを第三者ゲートウェイ110に返信する(フロー1508)。次に、サービスブローカー116は、「SMS」を送信するためにネットワークインタフェースを通じて「SMS」処理又はシステムを呼び出し(フロー1510)、確認応答を受信する(フロー1512)。サービスブローカー116は、エラー発生時には「SMS」メッセージ送信を再試行するように続行することができる。
表26及び27は、「SMS」サービス要求メッセージ及び応答の例を示している。
【0119】
【表9】
【0120】
【表10】
【0121】
図16は、第三者ゲートウェイ110から受信した「MMS」配信サービス要求から生じるメッセージフローの例を示している(フロー1602)。第三者ゲートウェイ110は、ユーザアカウントに対して課金し、「MMS」メッセージを配信するために「MMS」要求を送信することができる。サービスブローカー116は、サービスについてアカウントに課金するように請求システムに要求し(フロー1604)、請求システムから結果ステータスを受信する(フロー1606)。サービスブローカー116は、結果ステータスを第三者ゲートウェイ110に返信する(フロー1608)。次にサービスブローカー116は、「MMS」を送信するためにネットワークインタフェースを通じて「MMS」処理又はシステムを呼び出し(フロー1610)、確認応答を受信する(フロー1612)。サービスブローカー116は、エラー発生時には「MMS」メッセージ送信を再試行するように続行することができる。
表28及び29は、「MMS」サービス要求メッセージ及び応答の例を示している。
【0122】
【表11】
【0123】
【表12】
【0124】
図17は、第三者ゲートウェイ110から受信した「セッション開始プロトコル(SIP)」サービス要求から生じるメッセージフローの例を示している(フロー1702)。第三者ゲートウェイ110は、「SIP」呼び出しを設定してアカウントに課金するために「SIP」要求を送信することができる。サービスブローカー116は、サービスについてアカウントに課金するように請求システムに要求し(フロー1704)、請求システムから結果ステータスを受信する(フロー1706)。サービスブローカー116は、結果ステータスを第三者ゲートウェイ110に返信する(フロー1708)。次に、サービスブローカー116は、「SIP」接続を設定するためにネットワークインタフェースを通じて「SIP」処理又はシステムを呼び出し(フロー1710)、確認応答を受信する(フロー1712)。サービスブローカー116は、エラー発生時には「SIP」接続の設定を再試行するように続行することができる。
表30及び31は、「SIP」サービス要求メッセージ及び応答の例を示している。
【0125】
【表13】
【0126】
【表14】
【0127】
図18は、第三者ゲートウェイ110から受信した「ユーザステータス」サービス要求から生じるメッセージフローの例を示している(フロー1802)。第三者ゲートウェイ110は、他のユーザのオンライン存在検査を行うために「ステータス」要求を送信することができる。サービスブローカー116は、ディレクトリシステムにステータス要求メッセージを送信し(フロー1804)、ディレクトリシステムは、ユーザステータスを返信する(フロー1806)。サービスブローカー116は、ユーザステータスを第三者ゲートウェイ110に返信する(フロー1808)。
表32及び33は、「ステータス」サービス要求メッセージ及び応答の例を示している。
【0128】
【表15】
【0129】
【表16】
【0130】
図19は、第三者ゲートウェイ110から受信した「モバイルユーザステータス」認証サービス要求から生じるメッセージフローの例を示している(フロー1902)。例えば、ユーザが「インターネットプロトコルテレビジョン(IPTV)」サービスのようなサービスの購入することができる前に識別される必要がある場合、第三者ゲートウェイ110は、「認証」要求(「MSISDN」及び/又は「IMSI」番号のようなユーザを認識するために用いられる情報を含む)を送信することができる。サービスブローカー116は、ディレクトリシステムにユーザサービスデータ(例えば、ユーザに関するネットワーク特性)に対する要求を提出し(フロー1904)、ディレクトリシステムは、ユーザサービスデータを返信する(フロー1906)。
【0131】
サービスブローカー116は、第三者ゲートウェイ110に結果を返信する(フロー1908)。ディレクトリシステムがユーザを認証できなかった場合には、サービスブローカー116は、第三者ゲートウェイに「非許可」メッセージを返信する。そうでなければ、サービスブローカー116は、ユーザプロフィールデータと共に「許可」メッセージを返信する。ユーザが許可された場合には、次に、サービスブローカー116は、ユーザのアプリケーションサービスプロフィールに対する要求という形態でユーザに関する追加情報をディレクトリシステムに要求することができ(フロー1910)、ディレクトリシステムは、そのプロフィールを返信する(フロー1912)。
【0132】
サービスブローカー116は、結果を第三者ゲートウェイ110に返信する(フロー1914)。アプリケーションサービス情報が入手不能であった場合には、サービスブローカー116は「非許可」メッセージを第三者ゲートウェイ110に返信する。そうでなければ、サービスブローカー116は、アプリケーションサービスデータと共に「許可」メッセージを返信する。
表34及び35は、モバイルユーザ認証サービス要求メッセージ及び応答の例を示している。
【0133】
【表17】
【0134】
【表18】
【0135】
図20は、第三者ゲートウェイ110から受信した「IPTV」ユーザ認証要求から生じるメッセージフローの例を示している(フロー2002)。例えば、ユーザがモバイル「IPTV」アプリケーションに接続を試みる場合、第三者ゲートウェイ110は、「認証」要求(「MSISDN」及び/又は「IMSI」番号のようなユーザを認識するために用いられる情報を含む)を送信することができる。サービスブローカー116は、ディレクトリシステムにユーザサービスデータ(例えば、ユーザに関するネットワーク特性)に対する要求を提出し(フロー2004)、ディレクトリシステムは、ユーザサービスデータを返信する(フロー2006)。
【0136】
サービスブローカー116は、第三者ゲートウェイ110に結果を返信する(フロー2008)。ディレクトリシステムがユーザを認証できなかった場合には、サービスブローカー116は、第三者ゲートウェイに「非許可」メッセージを返信する。そうでなければ、サービスブローカー116は、ユーザサービスデータと共に「許可」メッセージを返信する。ユーザが許可された場合には、次に、サービスブローカー116は、ユーザのアプリケーションサービスプロフィールに対する要求という形態でユーザに関する追加情報をディレクトリシステムに要求することができ(フロー2010)、ディレクトリシステムは、そのプロフィールを返信する(フロー2012)。
【0137】
サービスブローカー116は、結果を第三者ゲートウェイ110に返信する(フロー2014)。アプリケーションサービス情報が入手不能であった場合には、サービスブローカー116は「非許可」メッセージを第三者ゲートウェイ110に返信する。そうでなければ、サービスブローカー116は、アプリケーションサービスデータと共に「許可」メッセージを返信する。
表36及び37は、「IPTV」ユーザ認証サービス要求メッセージ及び応答の例を示している。
【0138】
【表19】
【0139】
【表20】
【0140】
上述の説明の全ては、説明された特定の実施例に係わらず、制限的なものではなく本質的に例示的なものである。例えば、実施例の選択された態様、特徴、又は構成要素は、メモリ内に格納されているように示されているが、サービスブローカーと適合するシステム及び方法の全て又は一部は、他の機械可読媒体、例えば、ハードディスク、フレキシブルディスク、及びCD−ROMのような2次記憶装置、ネットワークから受信する信号、又は現時点で公知であるか又は今後開発されるROM又はRAMの他の形態に格納、又はそれらにわたって分配、又はそれらから読み取ることができる。
【0141】
更に、サービスブローカーアーキテクチャの特定の構成要素が説明されているが、サービスブローカーに適合する方法、システム、及び製造品は、付加的な又は異なる構成要素を含むことができる。例えば、プロセッサは、マイクロプロセッサ、マイクロコントローラ、特定用途向け集積回路(ASIC)、個別論理回路、又は他のタイプの回路又は論理回路の組合せとして実施することができる。同様に、メモリは、DRAM、SRAM、フラッシュ、又は他のあらゆるタイプのメモリとすることができる。フラグ、データ、データベース、テーブル、及び他のデータ構造は、別々に格納及び管理することができ、単一のメモリ又はデータベースに組み込むことができ、分配することができ、又は様々な手法で論理的にかつ物理的に編成することができる。プログラムは、単一のプログラムの各部分、又は別々のプログラムとすることができ、又はいくつかのメモリ及びプロセッサにわたって分配することができる。システムは、1つの処理システム内の又は複数の処理システムにわたって分配されたハードウエア、ソフトウエア、又はハードウエアとソフトウエアの組合せで実施することができる。
【0142】
サービスブローカー層は、外部のサービス要求の処理に関連する技術的困難を克服するものである。待ち行列におけるサービス要求の分配は、莫大な数の同時又はほぼ同時のサービス要求を受信して編成するという技術的困難に対処する。多重フェッチャー及びワークフローエンジンアーキテクチャは、調整された効率的方法でサービス要求を抽出し、抽出されたサービス要求を実行して要求された処理を実際に達成し、耐障害性サービス要求処理を提供し、サービス要求処理の性能を最大にする際の技術的困難に対処するものである。
本発明の様々な実施形態を説明したが、本発明の範囲内で更に多くの実施形態及び実施例が可能であることは当業者には明らかであろう。従って、本発明は、特許請求の範囲及びそれらの均等物に照らしたもの以外は制限されないものとする。
【図面の簡単な説明】
【0143】
【図1】第三者アクセスゲートウェイに接続したサービスブローカーを含む電気通信アーキテクチャの一部分を示す図である。
【図2】電気通信アーキテクチャ内のサービスブローカーを示す図である。
【図3】電気通信アーキテクチャ内のサービスブローカーの代替的な実施例を示す図である。
【図4】サービスブローカー内のフェッチャーシステムのためのトラフィック制御パラメータを例示する図である。
【図5】電気通信アーキテクチャ内のサービスブローカーのためのディスパッチャーシステムを例示する図である。
【図6】電気通信アーキテクチャ内のサービスブローカーのための第1のフェッチャーシステムを示す図である。
【図7】電気通信アーキテクチャ内のフェッチャーシステムのための技術指令管理データベースを例示する図である。
【図8】電気通信アーキテクチャ内のサービスブローカーのための第2のフェッチャーシステムを示す図である。
【図9】電気通信アーキテクチャ内のフェッチャーシステムのための拡張技術指令管理データベースを例示する図である。
【図10】電気通信サービス要求を処理するためにインバウンド要求マネージャが取ることができる作動を示す図である。
【図11】電気通信サービス要求を処理するためにワークフローエンジンが取ることができる作動を示す図である。
【図12】電気通信サービス要求を処理するために並列タスクマネージャが取ることができる作動を示す図である。
【図13】「認証」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図14】「課金」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図15】「SMS」配信及び「課金」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図16】「MMS」配信及び「課金」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図17】「SIP」呼び出し要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図18】ユーザ「ステータス」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図19】モバイルユーザ「認証」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図20】「IPTV」ユーザ「認証」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【符号の説明】
【0144】
100 電気通信アーキテクチャ
102 第三者
112 サービス要求
116 サービスブローカー
【技術分野】
【0001】
優先権の請求
本出願は、2005年10月28日出願のEPO特許出願第05425764.7号、及び2005年10月28日出願のイタリア特許出願第MI2005A002073号に対する優先権の恩典を請求するものであり、これらの両方は、本明細書においてその全内容が引用により組み込まれている。
本発明は、電気通信処理システムアーキテクチャに関する。特に、本発明は、第三者電気通信サービス要求を処理する電気通信システムアーキテクチャ内の層に関する。
【背景技術】
【0002】
データ処理及び電気通信技術の急速な進歩は、消費者が利用可能な広範な通信サービスをもたらした。そのような電気通信サービスは、従来の電話サービス、「インターネット」サービス、ケーブルテレビジョンサービス、セルラー電話サービス、呼び出しサービス、複合音声及びデータ配信サービス、並びに多くの他のサービスを含む。更に、多くのサービスは、無線又は有線のいずれかに基づくものとすることができる。
従来の電気通信サービスプロバイダは、多岐にわたる電気通信製品及びサービスを実施し、確実に供給するために莫大な量の時間、経費、及び先端技術に投資してきた。過去においては、この投資は、電気通信サービスプロバイダに対してのみ主な利益をもたらすものであった。すなわち、電気通信サービスプロバイダは、自身の技術を秘密裏に、かつ自身の使用のために内部的に維持してきた。
【0003】
高度な電気通信アーキテクチャのこの背景に対して、各電気通信サービスプロバイダ内には、新しい収益チャンネルをもたらす新しい商機を探求して開発するという要望がある。サービスプロバイダアーキテクチャにおける既存の技術は、そのような新しい収益チャンネルを推進することができるであろう。しかし、過去においては、第三者がサービスプロバイダアーキテクチャの潜在的な機能性にアクセスすることを可能にする十分に安全で柔軟性があり、かつ効率的な機構が存在していなかった。
更に、たとえ第三者がサービスプロバイダアーキテクチャの機能性にアクセスできたとしても、第三者のサービス要求を処理するためのサポートするアーキテクチャが存在していなかった。第三者がサービスプロバイダから電気通信サービスを要求できるだけでは十分ではない。サポートする処理アーキテクチャなしでは、第三者の要求には無回答である。
【0004】
【特許文献1】EPO特許出願第05425764.7号
【特許文献2】イタリア特許出願第MI2005A002073号
【発明の開示】
【発明が解決しようとする課題】
【0005】
拡張された電気通信サービスプロバイダアーキテクチャに対する必要性が長らく存在している。
【課題を解決するための手段】
【0006】
拡張された電気通信サービスプロバイダアーキテクチャの確立は、かなりの技術的難問を課している。一例として、同時又はほぼ同時の可能性がある第三者から受信する非常に多くのサービス要求の受信及び編成に技術的困難がある。別の例として、調整された効率的な方法でどのサービス要求を処理するかの判断に技術的困難がある。付加的な技術的難問は、抽出されたサービス要求を実行して要求された処理を実際に達成し、耐障害性のサービス要求処理を提供し、サービス要求処理の性能を最大にすることにある。
【0007】
本発明の一態様は、電気通信アーキテクチャのためのサービス要求処理システムを提供するサービスブローカー層である。サービス要求処理システムは、サービス要求インタフェース、ディスパッチャーシステム、フェッチャーシステム、及びワークフローエンジンを含む。付加的な又は異なる構成要素をサービス要求処理システムに含めることができる。
サービスブローカーは、サービス配信プラットフォームの一部であり、いくつかの技術的利点を提供する。第1の利点は、ワークフロー、タスク、及びアクションの技術指令管理データベース定義を通じて達成することができる構成可能性である。サービスブローカーは、電気通信サービスプロバイダが既存のビルディングブロックから開始して新しいサービスを作成することを可能にし、かつサービスプロバイダが所定のテンプレートから新しいビルディングブロックを作成することを可能にする。サービスブローカーは、それによって、サービスプロバイダを完全に特別仕様で柔軟性のないインフラストラクチャに制限することなく、サービスプロバイダにサービスを定義する多大な柔軟性を提供する。
【0008】
第2の利点は制御である。サービスブローカーは、サービスを配信するために実行されるワークフロー(特に非同期ワークフロー)上でエラー処理、記録、及び制御を提供する。サービスブローカーは、エラー管理グラフィックユーザインタフェースを提供する。インタフェースを通じて、経験豊かなオペレータは、サービスを配信するワークフロー処理の終了、再提出、変更、修正、又はそうでなければ訂正を行うことができる。
【0009】
第3の利点は保守である。一般的に、サービスブローカーは、ワークフロー、メッセージ、及びデータ要素のハードコーディングを避ける。その代わりに、サービスブローカーは、再構成可能XML、並びにメタデータベースのワークフロー、メッセージ、及びデータ要素を用いる。その結果、サービスブローカーの機能性は、ハードコードされた実施と比較して、維持、改訂、拡張、及び改善が遥かに容易である。
【0010】
更に、サービスブローカーは、同期及び非同期ワークフローの両方を実行する機能を提供する。結果として、拡張した性能が生じる。一部の実施例では、毎秒500トランザクション又はそれよりも多くを処理することができる。
サービス要求インタフェースは、電気通信サービスに対するサービス要求を外部エンティティから受信する。各サービス要求は、サービス識別子フィールドを含む。サービス識別子フィールドは、サービスブローカーにサービス要求の中で要求さているサービスのタイプを通知する。
【0011】
サービスブローカー内のディスパッチャーは、各サービス要求を受信する。サービス識別子フィールドに基づいて、ディスパッチャーは、異なるサービス待ち行列の中にサービス要求を分配する。個々のサービス待ち行列は、特定の要求エンティティ及び/又はサービスのタイプに対する要求を独立して待ち行列に入れるように設定することができる。例えば、サービス待ち行列は、メッセージ配信(例えば、「SMS」又は「MMS」)サービス要求待ち行列、課金サービス要求待ち行列、「サービスアクティブ化」要求待ち行列、又は他のタイプのサービス待ち行列を含むことができる。
【0012】
サービスブローカーはまた、フェッチャーシステムを含む。フェッチャーシステムは、処理のために個々のサービス待ち行列から待機サービス要求を検索する。一部の実施例では、サービスブローカーは、複数の独立したフェッチャーエンジンを提供する複数のフェッチャーシステムを含むことができる。一組のトラフィック制御パラメータは、フェッチャーシステムによる個々のサービス待ち行列からの待機サービス要求の検索を支配する。
ワークフローエンジンは、検索されたサービス要求を満足させるワークフロー段階のシーケンスを開始する。サービスブローカーは、複数の独立したワークフローエンジンを実行することができる。ワークフローエンジンは、例えば、特定のフェッチャーシステムによって選択されたサービス要求に対して定義されたワークフローを処理することができる。
【0013】
本発明の付加的な態様は、電気通信サービス要求処理を効率的に順序付けする方法及びシステムを含む。特に、サービスブローカーは、複数のサービス待ち行列を設定し、複数の待機電気通信サービス要求記録をサービス待ち行列の中に分配する。サービスブローカーはまた、サービス要求を検索するために複数のフェッチャーエンジンの同時実行を開始する。
第1のフェッチャーエンジンは、次に、サービス待ち行列に格納された電気通信サービス要求記録(例えば、「技術サービス指令識別子(TSO_ID))の一部を検索する。サービス要求記録は、外部エンティティによって提出された第1のサービス要求を表すものである。同様に、第2のフェッチャーエンジンは、サービス待ち行列に格納された別の電気通信サービス要求の一部を検索する。このサービス要求記録は、外部エンティティによって提出された第2のサービス要求を表すものである。
【0014】
サービスブローカーは、次に、第1のサービス要求及び第2のサービス要求を実施するワークフロー実行を開始するための異なるワークフロー要求配信技術を用いる。例えば、サービスブローカーは、ワークフローエンジンが加入しているメッセージ公開/加入システムを通じてワークフロー要求メッセージを公開することにより、第1のワークフロー要求を実施することができる。代替的なワークフロー要求配信技術として、サービスブローカーは、第2のワークフローエンジンを直接呼び出し、第2のサービス要求を指定することができる。
【0015】
サービスブローカーアーキテクチャは、それによって外部サービス要求の処理に関連する技術的困難を克服する。待ち行列内のサービス要求の分配は、莫大な数の同時又はほぼ同時のサービス要求を受信して編成する技術的困難に対処する。多重フェッチャー及びワークフローエンジンアーキテクチャは、調整された効率的方法でサービス要求を抽出し、抽出されたサービス要求を実行して要求された処理を実際に達成し、耐障害性のサービス要求処理を提供し、サービス要求処理の性能を最大にする際の技術的困難に対処するものである。
【0016】
本発明の他のシステム、方法、特徴、及び利点は、下記の図及び詳細説明の吟味によって当業者には明らかであろうし、又は明らかになるであろう。全てのそのような付加的なシステム、方法、特徴、及び利点は、本説明に含まれ、本発明の範囲内であり、特許請求の範囲によって保護されるように意図されている。
本発明は、下記の図面及び説明への参照によってより良く理解することができる。図中の構成要素は、必ずしも縮尺通りではなく、代わりに本発明の原理の例示に重点が置かれている。更に、図中、同じ参照番号は、異なる図を通して対応する部分又は要素を指定している。
【発明を実施するための最良の形態】
【0017】
図1は、第三者102と対話する電気通信アーキテクチャ100を示している。第三者102は、形態及び実施例において広範に変化することができる。例えば、第三者102は、セルラー電話、携帯情報端末、及びネットワーク(例えば、「インターネット」)通信装置のような加入者装置104、「ショートメッセージサービス(SMS)」メッセージングアプリケーション、「セッション開始プロトコル(SIP)」システム、及び製品及びサービスについて顧客に課金する請求アプリケーションなどの、他のサービスプロバイダによって実施された電気通信サービスアプリケーションのようなアプリケーション106、及び他の装置、プログラム、又はエンティティ108を含むことができる。
【0018】
電気通信アーキテクチャ100は、電気通信製品及びサービスをサポートする機能を実施する。電気通信アーキテクチャ100は、選択された機能を第三者102に公開する。言い換えれば、第三者102は、アーキテクチャ100内に既に置かれている機能を用いるために電気通信アーキテクチャ100と通信することができる。その結果、第三者102は、電気通信アーキテクチャ100によって既に提供されている機能をローカルに複製するために要求されるリソースを消費する必要がない。
【0019】
製品及びサービス、並びにそれらの公開された基本的な機能は、実施例間で変わる場合がある。例えば、電気通信アーキテクチャ100は、「SMS」メッセージングサービス(「SMS」メッセージを配信し、それに対して課金するため)、「マルチメディアメッセージングシステム(MMS)」メッセージングサービス(「MMS」メッセージを配信し、それに対して課金するため)、及び「SIP」サービス(「SIP」呼び出しを設定し、その呼び出しに対して課金するため)を公開することができる。付加的な例として、電気通信アーキテクチャ100は、「課金」サービス(アカウントに対して課金請求を要求するため)、「インターネットプロトコルテレビジョン(IPTV)」サービス(テレビジョン番組の配信を要求するため)、「ユーザステータス」サービス(「オンライン」、「オフライン」、「話し中」、又は「不在」のような現在のユーザステータスを要求するため)、及びユーザ認証サービス(例えば、モバイルユーザが存在するか否か、及びそのモバイルユーザが「IPTV」サービスのような望ましいサービスを購入するための資格を有するか否かの証明を要求するため)を公開することができる。他の機能は、追加的に又は代替として提供することができる。更に、電気通信アーキテクチャ100はまた、第三者アクセスゲートウェイ110を通じて通信ネットワークサービス(例えば、「インターネット」閲覧サービス)へのアクセスを提供することができる。
電気通信アーキテクチャ100は、公開されたサービスへのアクセスを保護する。その目的のために、アーキテクチャ100は、第三者アクセスゲートウェイ110を提供する。第三者アクセスゲートウェイ110は、第三者102に対して公開されたサービスへの単一の点としての役割を達成する。
【0020】
図1に示すように、第三者アクセスゲートウェイ110は、第三者102からサービス要求112を受信する。それに応答して、第三者アクセスゲートウェイ110は、サービス要求が、認証された又は許可された第三者から発せられたものであることを確認する。ネットワーク通信サービス要求の場合は(一例として)、第三者アクセスゲートウェイ110は、許可されたサービス要求を処理し、そのサービス要求をサービスプロバイダ114に中継する。「SMS」、「MMS」、及び「SIP」サービス要求のような公開されたサービス要求の場合には、第三者アクセスゲートウェイ110は、許可されたサービス要求を処理し、サービスブローカー116に中継する。
【0021】
サービスブローカー116は、サービス要求を実行する。それを行う際に、サービスブローカー116は、電気通信製品及びサービスを作成、配備、管理、及び維持するためにアーキテクチャ100が実施する「ビジネスサポートシステム(BBS)」及び「オペレーションサポートシステム(OSS)」118と通信することができる。例えば、「OSS/BSS」システム118は、請求システム、ディレクトリ及びプレゼンスシステム、認証システム、サービス提供システム、又は他のサポートシステムを含むことができる。サービス要求の実行において、サービスブローカー116は、サービス関連データをサービスブローカー116に配信又は返信することができるネットワーク層120と追加的に又は選択的に通信することができる。サービスプロバイダ114及びサービスブローカー116からの応答は、発信元の第三者の要求者への配信のために第三者アクセスゲートウェイ110に返信される。
【0022】
第三者アクセスゲートウェイ110は、第三者102と電気通信アーキテクチャ100内に実施される公開された機能性との間にセキュリティ層を提供する。同時に、サービスブローカー116は、柔軟かつ効率的に第三者のサービス要求を処理するためのアーキテクチャ層を提供する。すなわち、アーキテクチャ100は、サービスプロバイダが第三者102に向けて核心機能性を公開し、第三者102からのサービス要求を安全で標準化かつ制御された方法で処理することを可能にする。
【0023】
図1はまた、サービスブローカー116と通信状態にある顧客関係管理(CRM)システム122を示している。下記で更に詳述することになるが、「CRM」システム122もまた、サービスブローカー116にサービス要求を公開することができる。例えば、「CRM」システム122によって提出されるサービス要求は、サービスのアクティブ化、一時停止、再開、又は終了を含むことができる。要求は、電気通信製品及びサービス(例えば、セルラー電話サービス)を確立、一時停止、又は終了するための顧客支援担当者の「CRM」システム122との対話からもたらすことができる。
【0024】
各サービス要求は、サービスタイプ識別子フィールド及びサービス要求識別子フィールドを含むことができる。下記の説明において、「TSO_LABEL」フィールドは、サービスタイプ識別子フィールドを提供し、「TSO_ID」フィールドは、サービス要求識別子フィールドを提供する。サービス要求内の「TSO_LABEL」は、要求されたサービスのタイプ(例えば、特定の製品又はサービスをアクティブ化する要求)を指定するサービスタイプ識別子である。サービス要求内の「TSO_ID」は、サービス要求自体の識別子(例えば、固有識別子)を提供するサービス要求識別子である。
【0025】
図2は、サービスブローカー116の一実施例の更に詳細な図を示している。上述のように、サービスブローカー116は、サービス要求インタフェース201を通じて「OSS/BSS」システム118を含む外部システム、第三者ゲートウェイ110、及び「CRM」システム122に接続する。サービス要求インタフェースは、物理アダプタ、論理アダプタ、又は物理及び論理アダプタの両方を含むことができる。「OSS/BSS」システムは、物理アダプタ202及び論理アダプタ208を通じてサービスブローカー116に接続し、第三者ゲートウェイは、物理アダプタ204及び論理アダプタ210を通じてサービスブローカー116と接続し、「CRM」システムは、物理アダプタ206及び論理アダプタ212を通じてサービスブローカーと接続する。
【0026】
物理アダプタ202〜206は、外部システムとサービスブローカーの間の通信を統御する通信ソフトウエアによって実施することができる。論理アダプタ208〜212は、サービスブローカーと外部システムの異なるデータモデル間でメッセージマッピングを実行するデータ変換プログラム、マッパー、及び/又はトランスフォーマーを表している。論理アダプタ208〜212は、外部システムからのメッセージデータが、サービスブローカー116が予想する形式でサービスブローカー116に到着することを保証する。一実施例では、アダプタ208〜212は、1つのスキーマによって定義されたフォーマット(例えば、メッセージが第三者ゲートウェイ110内に添付するためのXMLスキーマ)から別のスキーマによって定義された別のフォーマット(例えば、サービスブローカー116が受信するメッセージのためのXMLスキーマ)へのメッセージ及び/又はメッセージコンテントの変換をサポートする。
【0027】
メッセージ公開システム214は、外部システムとサービスブローカー116との間でメッセージを通信するメッセージバスを提供する。更に、メッセージバスは、サービスブローカー116自体の構成要素間のメッセージを通信することができる。メッセージ公開システム214は、あるトピックに割り当てられたメッセージを受信し、そのトピックに対する加入者にメッセージを公開する。加入者は、処理システム(例えば、システム110、118、及び122)、プログラム、又は他のエンティティとすることができる。しかし、他の実施例では、バッチファイル転送、共有ファイル又はメモリ、又は他の相互処理通信技術を含む、他のメッセージ通信技術を用いることができる。
【0028】
メッセージ公開システム及びアダプタ202〜212は、例えば、カリフォルニア州パロアルト所在の「TIBCO Software Inc.」から入手可能な「TIBCOアダプタ(登録商標)」及び「TIBCO Rendezvous(登録商標)」メッセージングによって実施することができる。他の実施例では、物理アダプタは、カリフォルニア州サンホゼ所在の「BEA systems」から入手可能な「BEA Weblogic」統合制御によって実施することができる。一実施例では、メッセージは、「拡張可能マークアップ言語(XML)」のメッセージであり、アダプタは、「変換用拡張可能スタイルシート言語(XSLT)」のスタイルシートに従って変換を実行する。変換は、「XML」、「ハイパーテキスト伝送プロトコル(HTTP)」、「簡易オブジェクトアクセスプロトコル(SOAP)」、「Webサービス定義言語(WSDL)」、「拡張可能スキームダイアグラム(XSD)」、「Java(登録商標)データベース接続性/オープンデータベース接続性(JDBC/ODBC)」、又は他のメッセージフォーマット、コンテント規格、又は通信プロトコルのうちのいずれかのためのスキーマ間でデータを変換することができる。
【0029】
サービスブローカー116はまた、着信サービス要求をサービス要求待ち行列218の中に分配するディスパッチャーシステム216を含む。サービス要求待ち行列218は、特定タイプのサービス要求に割り当てられた1つ又はそれよりも多くの独立した待ち行列を含むことができる。図2に示されている例では、サービス待ち行列218は、第三者ゲートウェイ110から受信したサービス要求を待ち行列に入れる1つ又はそれよりも多くの第三者ゲートウェイサービス要求待ち行列220、及び「CRM」システム122からのサービス要求を待ち行列に入れる1つ又はそれよりも多くの顧客関係管理待ち行列232を含む。
【0030】
例えば、第三者ゲートウェイサービス要求待ち行列220は、メッセージサービス要求待ち行列224(例えば、「SMS」又は「MMS」メッセージ配信要求を待ち行列に入れるための)、及び「課金」サービス要求待ち行列226(例えば、課金要求を待ち行列に入れるための)を含むことができる。待ち行列220の付加的な例は、「認証」要求待ち行列及び「ステータス」要求待ち行列を含む。同様に、「CRM」待ち行列222は、「サービスアクティブ化」要求待ち行列228、「サービス終了」要求待ち行列230、及び「CRM」システム122から受信するサービス要求に対する他の待ち行列を含むことができる。待ち行列220及び222は、上述のタイプ及び個数に限定されてはいない。むしろ、1つ又はそれよりも多くの待ち行列は、いずれか1つ又はそれよりも多くのサービス要求者から受信するいずれか1つ又はそれよりも多くのタイプのサービス要求を待ち行列に入れるように実施し、かつ割り当てることができる。
【0031】
サービスブローカー116は、フェッチャーシステム232を含む。トラフィック制御パラメータ234の制御下で、フェッチャーシステム232は、サービス待ち行列218から待機サービス要求を検索する。次に、フェッチャーシステム232は、検索済みサービス要求をワークフローシステム236に配信する。ワークフローシステム236は、サービス要求を実施するために所定の順序でのワークフロー段階の実行を判断して要求するワークフローエンジン(例えば、ワークフローエンジン238、240、242)の実行を開始する。
【0032】
例えば、「SMS」メッセージを配信し、それに対して課金を行うために、ワークフローシステム236は、「SMS」ワークフローエンジンの実行を開始することができ、このエンジンは、1つの段階として、「SMS」メッセージに対して課金するように請求システムに請求要求を出し、別の段階として、そのメッセージを送信するように「SMS」システムにメッセージ送信要求を出す。ワークフローシステム236は、カリフォルニア州パロアルト所在の「TIBCO Software Inc.」から入手可能な「Tibco InConcert(登録商標)」ワークフローエンジン又は他のワークフローシステムによって実施することができる。
【0033】
サービスブローカーはまた、技術指令管理(TOM)データベース240を含む。「TOM」データベースは、サービス要求を満足させるワークフローにおいて実行されるべき一組の技術サービス指令段階を定義する構成ルールを格納する。「TOM」データベース240は、下記で更に詳述される。
図3は、サービスブローカー302の代替的な実施例を示している。サービスブローカー302は、第2のフェッチャーシステム304を含む。第2のフェッチャーシステム304も同様に、トラフィック制御パラメータ234の制御下でサービス待ち行列218からサービス要求を検索する。代替的に、第2のフェッチャーシステム304は、独立した一組のトラフィック制御パラメータの制御下で作動することができる。付加的なフェッチャーシステム及びトラフィック制御パラメータの組を提供することができる。
【0034】
第2のフェッチャーシステム304は、フェッチャーシステム232とは異なるワークフロー要求配信技術を用いる。特に、第2のフェッチャーシステム304は、システム214のようなメッセージ公開システムにワークフロー要求メッセージを公開する。次に、メッセージ公開システム214は、メッセージ公開システム214におけるワークフロー要求メッセージに加入している第2のワークフローシステム306にワークフロー要求メッセージを配信することができる。言い換えれば、メッセージ公開システム214は、第2のフェッチャーシステム304をワークフローシーケンスの直接呼び出しという負担及び問題から解放する。
【0035】
代わりに、第2のワークフローシステム306は、公開されたワークフロー要求メッセージを受信し、サービス要求を実施するためにワークフローの実行を開始する。第2のワークフローシステム306は、第1のワークフローシステム236と同一の方法で実施される必要はない。図3に示されている例では、第2のワークフローシステム306は、インバウンド要求マネージャ308、ワークフローエンジン310、及び並列タスクマネージャ312を含む。アクションマネージャ320及びアクションビルダ322を含むアクションエンジン318は、ワークフロー内のネットワークサービス提供アクションを実行する。各々は、下記で更に詳述される。
【0036】
第2のワークフローシステム306の追加は、いくつかの利益を発生させる。特に、第2のワークフローシステム306は、第1のフェッチャーシステム232を通じてワークフローシステム236を直接呼び出すことによってサービス要求を処理するという潜在的問題の除去に役立つ。更に、第1のフェッチャーシステム232及び第2のフェッチャーシステム304は、一緒に実行することができ、これは、サービス要求を並列に処理することにより端末間の性能を改善させるだけでなく、サービス要求を処理するための2つの独立したフェッチャー/ワークフローエンジンシステムを提供することによって強力な耐障害性エンジンシステムを達成する。
【0037】
サービスブローカー302又は116はまた、ウェブエラー・グラフィカルユーザインタフェース(GUI)を含むことができる。図3は、第2のフェッチャーシステム304に設けられたウェブエラー「GUI」314の例を示している。ウェブエラー「GUI」314は、「ウェブ」サーバ(例えば、カリフォルニア州サンホゼ所在の「BEA Systems」から入手可能な「Weblogicアプリケーション」サーバ)を実行する「Java(登録商標)」サーバページの「ウェブ」アプリケーションとして実施することができる。
【0038】
ウェブエラー「GUI」314は、サービス要求処理中に遭遇するあらゆるエラーに関する情報をユーザインタフェースディスプレイに掲載する。ウェブエラー「GUI」314はまた、入力機構を提供することができ、それによって検閲者は、修正入力(例えば、データを変更するか、又はサービス要求内の欠損データを完成させるか、又はサービス要求又はタスクを修正するためにワークフロータスクをサポートする入力)を与え、サービス要求又はタスクを手動で完成させるか又は処理のためにサービス要求又はタスクを再提出する。
【0039】
一実施例では、エラーに遭遇した各サービス要求は、ウェブエラー「GUI」において説明的なタイトル及びサービス要求特性の付加的な詳細へのハイパーリンクによって表すことができる。ウェブエラー「GUI」314は、更に検索インタフェースを提供することができる。検索インタフェースは、検索判断基準(例えば、「MSISDN」番号、「TSO_ID」、データ範囲、サービス要求タイプ、エラーコード、顧客又は他の識別子、又はサービス要求の他のあらゆる特性)を受け入れ、適合するエラー記録の応答的検索及び表示を実行する。ハイパーリンク上のクリックは、ウェブエラー「GUI」314に選択されたサービス要求に特定のエラー情報、及びそのサービス要求について入手可能な追加特性(例えば、要求タイプ、「IMSI」番号、「MSISDN」番号、送信者、受信者、メッセージテキスト、顧客名及び住所、又は他のあらゆる特性)のディスプレイへの掲載を誘発する。
【0040】
ウェブエラー「GUI」314は、検閲者からの修正入力を受け入れる。検閲者は、ウェブエラー「GUI」314に修正済みサービス、タスク、又はアクションをフェッチャーシステム304に再公開するように指示することができる。フェッチャーシステム304は、修正済みサービス要求メッセージを受信し、修正済みサービス要求、タスク、又はアクションを元の場所で処理する。この方法で、フェッチャーシステム304は、元のサービス要求がエラーに遭遇した点で既にインスタンスが生成されているワークフローを継続することによって貴重な時間と処理リソースを節約する。
【0041】
同様に別々のウェブエラー「GUI」を第1のフェッチャーシステム232に対して提供することができる。メッセージ公開システム214を用いる他に、第1のフェッチャーシステム232に対するウェブエラー「GUI」は、API内に定義された関数呼び出しを通じてエラー情報を通信することができる。関数呼び出しは、「Tibco InConcert(登録商標)」ワークフローエンジンによって達成することができ、ウェブエラー「GUI」314について上述したように、このウェブエラー「GUI」は、エラー情報を報告し、修正入力を受け入れることができる。
【0042】
サービスブローカーはまた、ワークフロー「GUI」324を提供することができる。ワークフロー「GUI」324は、ワークフロー定義のためにグラフィカルインタフェースを提供し、これは、サービスブローカーに多大な構成可能性を提供する。ワークフロー「GUI」324は、ドラッグアンドドロップインタフェースを実施し、これを通じてオペレータは、新しいワークフローを作成するためにタスクを選択して順序付けることができる。
【0043】
図3は、オペレータが4つのタスク326,328、330、及び332を順番に配列して新しいワークフロー334を形成する一例を示している。サービスプロバイダが望むあらゆる機能に対してサービスブローカーをカスタマイズする新しいワークフローを定義するために、あらゆる個数のタスクをあらゆる順序で配列することができる。ワークフロー「GUI」324は、「TOM」データベース内に定義された所定のワークフロー、タスク、及びアクションの1つ又はそれよりも多くについてワークフロー、タスク、及びアクションのグラフィカルな表現をもたらすことができる。ワークフロー、タスク、及びアクションは、ワークフローテーブル902、タスク構成テーブル904、及び/又はアクションテーブル906内に定義されたワークフロー、タスク、及びアクションを表すことができ、これらは下記に説明される。
【0044】
拡張「TOM」データベース316もまた、サービスブローカー302内に存在する。拡張「TOM」データベース316は、第2のワークフローシステム306及びウェブエラー「GUI」314をサポートするために第1の「TOM」データベース244を拡張する。下記でより詳細に説明することになるが、拡張「TOM」データベース316は、特定のサービス要求を実施するために取られるべきタスク及びアクションのシーケンスを定義し、ウェブエラー「GUI」314のために報告テーブルを提供する。
【0045】
図4は、トラフィック制御パラメータ234の例を示している。特に、図4は機能名パラメータ402、プールサイズパラメータ404,及びポーリング時間パラメータ406を示している。図4はまた、提出タイマパラメータ408、判断基準パラメータ410、及び待機パラメータ412を示している。付加的なトラフィック制御パラメータは、待ちパラメータ414,制御ロックパラメータ416、及びデータパラメータ418を含む。
【0046】
下記の表1は、各トラフィック制御パラメータ234に関する説明を提供する。
【0047】
【0048】
トラフィック制御パラメータ234は、作動時にフェッチャーシステム232及び304を動的に再構成することができる。この目的のために、トラフィック制御パラメータ234は、フェッチャーシステム232及び304内部のトラフィック制御マネージャ処理と通信することができる(例えば、「URL」内にパラメータを埋め込んだ「HTTP」接続を通じて)。次に、トラフィック制御マネージャは、サービス要求ブロックの次の検索のために新しパラメータによって内部変数を設定することができる。
【0049】
図5は、ディスパッチャー216の実施の例である。ディスパッチャー216は、メモリ504に連結されたプロセッサ502を含むことができる。メモリ504は、ディスパッチプログラム506を格納する。ディスパッチプログラム506は、マルチスレッド処理とすることができる。メモリ504はまた、ディスパッチプログラム506よる処理に向けたインバウンドメッセージ508を保持する。インバウンドメッセージ508は、技術サービス指令ラベル(TSO_LABEL)フィールド510、「TSO_ID」フィールド511、及び更にサービス要求を定義する(例えば、「SMS」メッセージデータ、受信者、又はサービス要求をサポートする他のデータを指定することにより)サービス要求メッセージデータ512を含む。「TSO_LABEL」フィールドは、要求されたサービスを表すサービスタイプ識別子フィールドを提供する。
【0050】
インバウンドメッセージ508は、メッセージ内の各データ要素の周囲に識別タグを含む「拡張可能マークアップ言語(XML)」メッセージとすることができる。ディスパッチプログラム506は、インバウンドメッセージ508内の「XML」データを吟味し、「XML」データ内のタグが付けられたフィールドに基づいてサービス待ち行列218内のサービス要求記録を設定する。特に、サービス識別子フィールドに基づいて(例えば、「TSO_LABEL」に基づいて)、ディスパッチプログラム506は、「TSO_LABEL」510に基づいて特定のサービス待ち行列内のサービス要求記録を設定する。言い換えれば、「TSO_LABEL」510は、ディスパッチプログラム506のためにサービス要求のタイプ、従って、サービス要求が存在すべき適切なサービス待ち行列を識別する。
【0051】
サービス待ち行列218は、データベーステーブルとして実施することができる。図5は、サービス待ち行列218内で定義することができるサービス要求記録514の例を示している。しかし、他のサービス要求記録定義を実施することもできる。サービス要求記録514のフィールドは、下記に表2において説明する。
【0052】
【0053】
「TSO_ID」、「TSO_LABEL」、及び「TSO_DATE」は、別々のフィールドに格納される。ディスパッチプログラム506がインバウンドメッセージ508を受信すると、ディスパッチプログラムは、メッセージ508から「TSO_ID」、「TSO_LABEL」、及び「TSO_DATE」データを別々に抽出し、サービス要求記録514内の対応するフィールド内にそのデータを格納することができる。従って、フェッチャーシステム232及び304は、あらゆるフィールド又はフィールドの組合せによって待ち行列テーブルから列データを抽出することができる。
【0054】
一実施例では、ディスパッチプログラム506がサービス待ち行列テーブル内の列に新しいサービス要求記録514を挿入すると、ディスパッチプログラム506は、以下のフィールドにデータを挿入する。
TSO_ID
TSO_LABEL
TSO_DATE
XML_IN
BP_FLAG=0
AP_FLAG=0
INS_TMS=システム日付
【0055】
図6は、フェッチャーシステム232の実施を示している。フェッチャーシステム232は、メモリ604に連結されたプロセッサ602を含む。メモリ604は、フェッチャープログラム606(例えば、マルチスレッド処理)を格納する。メモリはまた、サービス要求記録列リスト608を保持する。サービス要求記録列リスト608内のエントリは、サービス待ち行列218内のサービス要求を提示している。
【0056】
トラフィック制御パラメータ234に従って、フェッチャープログラム606は、サービス待ち行列218をポーリングする。フェッチャープログラム606は、選択されたサービス要求記録から「TSO_ID」のプールを検索する。フェッチャープログラム606は、サービス待ち行列218内のテーブルにアクセスするために、格納された「構造化照会言語(SQL)」手順を呼び出すことができる。
【0057】
格納された手順は、サービス待ち行列218内の各列に対して「BP_FLAG」を1に設定することができ、これは、フェッチャーシステムによって与えられる検索判断基準を満たすものである。格納された手順は、検索判断基準を満たす列の列リスト608をフェッチャーシステム232に返信する。列リスト608は、各適合したサービス要求記録からの「TSO_ID」フィールドを含むことができる。
【0058】
フェッチャープログラム606は、格納された手順から列リスト608を取得する。次に、フェッチャープログラム606は、列リスト608をワークフロー呼び出しプログラム610に渡す。ワークフロー呼び出しプログラム610は、列リスト内で識別される、サービス要求記録内に表された各サービス要求を実施する適切なワークフローの実行を開始するためにワークフローシステム236を呼び出す。
より具体的には、ワークフロー呼び出しプログラム610は、列リスト608を各列について非同期に処理する。ワークフロー呼び出しプログラム610は、トラフィック制御パラメータ234内で指定される「WAIT」時間の間待っている。「WAIT」時間が満了すると、ワークフロー呼び出しプログラム610は、現時点で処理中のサービス要求に対して「BP_FLAG」を「2」に設定する。
【0059】
次に、ワークフロー呼び出しプログラム610は、現在の列に関するサービス要求を実施するワークフローを開始するためにワークフローシステム236を直接呼び出す。ワークフローを開始するための呼び出しにおいては、ワークフロー呼び出しプログラム610は、ワークフローシステム236に「TSO_ID」フィールドを非同期に渡すことができる。次に、ワークフロー呼び出しプログラム610は、ワークフローが呼び出されたことを表すために「BP_FLAG」を「3」に設定する。
【0060】
ワークフローシステム236では、ワークフローエンジンは、特定のサービス要求を実施するワークフロー段階(例えば、タスク、アクション、及び「TSO」)を実行する。サービス要求の実施において、ワークフローエンジンを実行する第1のタスクは待ち行列テーブルから「XML_IN」データを検索することである。ワークフローエンジンは、フェッチャーシステム232によって与えられる「TSO_ID」に適合するサービス要求記録から「XML_IN」データを検索する。それによってサービスワークフローは、要求されたサービスに対するデータのサポートを含む要求されたサービスの完全な定義を取得する。例えば、「SMS」メッセージ配信に関する「XML_IN」データは、メッセージテキスト及び受信者の識別子を含むことになる。
【0061】
「TSO_LABEL」フィールドは、要求されたサービスを指定する。ワークフローは、要求されたサービスを実施するタスクを実行する。「SMS」メッセージ配信においては、例えば、ワークフローエンジンは、請求システムに課金メッセージを送信することができ、その後「SMS」配信サブシステムにメッセージテキストを送信することができる。ワークフローエンジンはまた、サービス要求処理の結果を返信する。例えば、ワークフローは、詳細説明、又はサービス要求処理から生じる他のあらゆる情報を任意的に添えて成功メッセージ又はエラーメッセージを返信することができる。
【0062】
ワークフローは、適切な「TSO_ID」に関するサービス要求記録を更新することによって終了する。ワークフローエンジンは、サービス要求記録の中に「XML_OUT」文字列を書き込む。「XML_OUT」文字列は、サービス要求処理の結果を含むことができる。更に、ワークフローエンジンは、ワークフローが終了したことを表すために「AP_FLAG」を「1」に設定し、「END_TMS」を現在のシステム日付に設定する(すなわち、ワークフロー終了の日付/時間)。
【0063】
ワークフローエンジンは、技術指令管理(TOM)データベース244を参考にして実行すべきタスク及びアクション、及び実行の順序を判断する。図7は、「TOM」データベース244に対するデータモデルの一実施例を示している。データモデルは、図7に示されている実施例に限定されてはおらず、むしろデータモデルが用いられる特定の実施例に従って広範に変化する。「TOM」データベース244は、「サービス技術指令カタログ(STOC)」テーブル702、「アクション」テーブル704、及び「STOC」パラメータテーブル706を含む。「TOM」データベース244は、「「ClassBuild」テーブル708、「PutSequenceInClassテーブル」710、及び「SequenceBuildテーブル」712を更に含む。
【0064】
「STOC」テーブルは、主要キーとしての「STOC_ID」フィールド714、及び追加フィールド716を含む。「アクション」テーブルは、主要キーとしての「Action_ID」フィールド718、及び追加フィールド720を含む。「STOCParam」テーブル706は、主要キーとしての「STOCParam_ID」フィールド722、及び追加フィールド724を含む。「ClassBuild」テーブル708は、主要キーとしての「Param_ID」フィールド726、及び追加フィールド728を含む。「PutSequenceInClass」テーブル710は、主要キーとしての「PutSequence_ID」フィールド730、及び追加フィールド732を含む。「SequenceBuild」テーブル712は、主要キーとしての「Sequence_ID」フィールド734、及び追加フィールド736を含む。
【0065】
「STOC」テーブル702は、サービス要求を統御するための「技術サービス指令(TSO)」と呼ばれる、ワークフロー段階のワークフローテンプレートを定義する。「アクション」テーブル704は、あらゆる所定のサービス要求を満足させるために実行されるべき「TSO」(すなわち、アクション)及びそれらの実行順序を定義し、それらを「STOC」テーブルに連結して戻す。一部の実施例では、データベース228は、「アクション」テーブル704と同様な「逆アクション」テーブルを定義することができる。ワークフロー内でのアクションの処理中にエラーが発生すると、関連の「逆アクション」を実行することができる。「逆アクション」は、顧客アカウントステータス、注文ステータス、又は独立した処理システム間の他のデータと同期させることができる。「TOM」データベース244は、サービス要求者から受信することができるか又はワークフローエンジン自体によって与えることができるアクションに関するパラメータを更に定義する。追加フィールドを含む各テーブル702〜712は、下記においてより詳細に説明される。
【0066】
【0067】
【0068】
【0069】
【0070】
【0071】
【0072】
ワークフローシステム236は、サービス指令処理を2つのタスクに分割する。第1のタスクは、「TOM」データベース244内でワークフロー定義を検索することによってサービス要求が「TSO」の中に分割される方法を判断することである。第2のタスクは、「TSO」を正しいシーケンスで送信し、応答を受信し、エラーを処理することによってこれらの「TSO」を管理することである。
「TSO_LABEL」及び「TOM」データベース244内に設定された定義に基づいて、ワークフローシステム236は、実行すべき「TSO」の組及びそれらの順序を判断する。ワークフローシステム236はまた、実行されるべき各「TSO」に対して属性リストを構築する。属性は、サービス要求者(例えば、「CRM」システム122)によって全体を又は部分的に指定することができ、また、「TOM」データベース244によっても全体を又は部分的に指定することができる。「TSO」が実行されると、ワークフローエンジンは、実行すべき現時点の「TSO」を提示するインデックスを増分する。
【0073】
ワークフローエンジンは、「TSO」の実行を要求するメッセージを構築する。例えば、メッセージは、全体のサービス要求の実施の一部としてメッセージ内に指定されたアクションを実行するサービス提供システムに対して公開することができる。「TOM」データベース244は、メッセージ構築をサポートし、「TSO」が実行すべき指令、「TSO」に関する属性(「TOM」データベース244内で指定される静的属性、及びサービス要求者によって提出される動的属性)、メッセージが公開されるサブジェクト、及び上述の他のパラメータを提供する。
このように、「TOM」データベース244は、「TSO_LABEL」に関連するサービス要求ワークフローを、サービス要求を実施する一組の「TSO」に分割する構成ルールを提供する。それによって「TOM」データベース244は、ワークフロー、ワークフローを実施する「TSO」、及び「TSO」を実行する順序を定義するための極めて柔軟で再構成可能な拡張性のある機構を提供する。
【0074】
図8は、第2のフェッチャーシステム304の実施例を示している。フェッチャーシステム304は、メモリ804に連結されたプロセッサ802を含むことができる。メモリ804は、フェッチャープログラム806(例えば、マルチスレッド処理)を格納する。メモリはまた、サービス要求記録列リスト808を保持する。サービス要求記録列リスト808内のエントリは、第三者ゲートウェイ110、「CRM」システム122、又は他のあらゆる外部サービス要求者によって提出され、サービス待ち行列218内で待機しているサービス要求を提示している。
【0075】
トラフィック制御パラメータ234(又は、フェッチャーシステム304に対して設定されたトラフィック制御パラメータの独立した一組)に従って、フェッチャープログラム806は、サービス待ち行列218をポーリングする。フェッチャープログラム806は、適合するサービス要求記録を「TSO_ID」ブロックから検索する。フェッチャープログラム806は、サービス待ち行列218内のテーブルへのアクセスのために格納された「構造化照会言語(SQL)」手順を実行することができる。
処理されるべき各サービス要求に対して、フェッチャープログラムは、インスタンスマネージャプログラム814を呼び出す。インスタンスマネージャプログラムは、「TOM」データベース316内のテーブルにデータを追加し、サービス要求に対するワークフローテーブルのインスタンスを作成する。「TOM」データベーステーブルは、下記で更に詳述される。
【0076】
フェッチャープログラム806は、列リスト808をメッセージ公開プログラム810に渡す。メッセージ公開プログラム810は、第2のワークフローシステム306にワークフロー要求メッセージ812(サービス要求を指定する)を公開する。すなわち、フェッチャーシステム304は、メッセージ公開システム214が第2のワークフローシステム306にワークフロー要求メッセージを配信することを可能にすることにより、ワークフローエンジンを直接呼び出すという潜在的問題を除去する。ワークフロー要求メッセージは、「TSO_ID」(「TSO_ID」フィールド814内)及び「TSO_LABEL」(「TSO_LABEL」フィールド816内)を指定することができる。「TSO_ID」及び「TSO_LABEL」は、サービス待ち行列218内のサービス記録から得られる。フェッチャーシステム304は、各ワークフロー要求メッセージを公開した後にメッセージ公開システム214からの応答を待つことができる。
より具体的には、要求/回答メッセージは、下記の表9〜12に示すように定義することができる。
【0077】
【表1】
【0078】
【表2】
【0079】
【表3】
【0080】
【表4】
【0081】
図9は、第2のフェッチャーシステム304をサポートする、「TOM」データベース316内にある拡張を示している。サービス要求を実施するために取る段階のシーケンスは、「Workflows」テーブル902、「Task_cfg」テーブル904、及び「アクション」テーブル906によって定義される。特に、「Workflows」テーブル902は、ワークフローテンプレートを定義し、「Task_cfg」テーブル904は、ワークフローを実施するタスクを定義し、「アクション」テーブル906は、各タスクに関連するアクションを定義する。タスク及びアクションは、例えば、外部「Tibco BusinessWorks(登録商標)」処理システムにおいて実行される処理によって実行することができる。サポートするタスクインスタンステーブル908及びサポートするアクションインスタンステーブル910もまた存在する。各テーブルは、下記で更に詳述される。
【0082】
【0083】
【0084】
【0085】
「TASK_INST」テーブル908は、「TASK_CFG」テーブル904と同一のフィールド、及び以下の追加フィールドを含むことができる。
【0086】
【0087】
「ACTION_INST」テーブル910は、「アクション」テーブル906と同一のフィールド、及び以下の追加フィールドを含むことができる。
【0088】
【0089】
更に、拡張「TOM」データベース316は、ウェブエラー「GUI」314に対してサポートを提供する。特に、拡張「TOM」データベース316は、「GUIユーザ」テーブル912、「GUI」役割テーブル914,及び「GUI」ステータステーブル916を含む。同じく含まれているのは、「GUI」履歴テーブル918である。各テーブルは、下記で更に詳述される。
【0090】
【0091】
【0092】
【0093】
【0094】
各サービス要求に対して、対応するサービス要求メッセージ公開の前に、インスタンスマネージャプログラム814は、「TASK_INST」テーブル908に実行されるべきワークフロータスクを追加する。インスタンスマネージャプログラム814はまた、「ACTION_INST」テーブル910に各タスク内のサービス提供アクションを追加する。テーブル908及び910に加わるデータは、カタログテーブル902、904、及び906内に定義されたテンプレートから得られる。すなわち、処理されるべき各サービス要求は、「TASK_INST」テーブル908及び「ACTION_INST」910において準備が整った、インスタンスが生成されたワークフローを有する。
第2のワークフローシステム306は、メッセージ公開システム214から公開されたワークフロー要求メッセージを受信する。ワークフローシステム306は、最初にインバウンド要求マネージャ308を通じてワークフロー要求メッセージを処理する。
【0095】
図10は、インバウンド要求マネージャ308によって取られたアクション1000の流れ図の例を示している。インバウンド要求マネージャ308は、メッセージ公開システム214によって公開された公開済みサービス要求メッセージを受信する(段階1002)。インバウンド要求マネージャは、サービス要求メッセージから「TSO_ID」を抽出し(段階1004)、サービス要求メッセージから「TSO_LABEL」を抽出する(段階1006)。
【0096】
「TSO_ID」を用いて、インバウンド要求マネージャ308は、「TSO_ID」によって表されるサービス要求を実施する、インスタンスが生成されたワークフローテンプレートを得るために拡張「TOM」データベース316を検索する。テンプレートが定義されていない場合には、インバウンド要求マネージャ308は、フェッチャーシステム304に「否定」応答を返信する(段階1010)。そうでなければ、インバウンド要求マネージャ308は、フェッチャーシステム304に「肯定」応答を返信し(段階1012)、この「TSO_ID」及び「TSO_LABEL」を伴って「ワークフロー」エンジン310を呼び出す(段階1014)。
【0097】
図11は、ワークフローマネージャ310によって取られるアクション1100の流れ図の例を示している。ワークフローマネージャ310は、インバウンド要求マネージャ308から「TSO_ID」及び「TSO_LABEL」を受信する(段階1102)。次に、ワークフローエンジン310は、「TASK_INST」テーブル908からのワークフローテンプレート内でワークフロータスクを検索する(段階1104)。
【0098】
ワークフロー内に更にいずれかのタスクが存在する場合には、ワークフローエンジン310は、順番に次のタスクを実行する(段階1106)。そうするために、ワークフローエンジン310は、「TASK_INST」テーブル908内のタスクに対して識別されるサブ処理を起動する。シーケンスで起動されるタスクに対して、ワークフローエンジン310は、タスクサブ処理を起動し、このサブ処理からの応答を待つ(段階1108)。他のタスクと並列して起動することができるタスクに対しては、ワークフローエンジン310は、タスクのサブ処理を起動し、待つことなしに次のタスクへと続行する(段階1110)。
【0099】
いくつかのステータスは、タスクに対して定義される。ワークフローエンジン310及びウェブエラー「GUI」314は、タスク実行中にステータスを設定し、維持することができる。タスクに対する初期ステータスは、「I」(初期)であり、終了ステータスは、「D」(終了)又は「C」(強制完了)のいずれかとすることができる。最初は、各タスクは、「I」に設定されたステータスを有することができる。ワークフローエンジン310がタスク実行のためにサブ処理を起動すると、タスクステータスは、「X」(実行)に変化する。「X」ステータスは、サブ処理がタスクを実行中であることを示している。
【0100】
タスクの終了の成功及びサブ処理からの回答の受信は、タスクの「D」(終了)ステータスへの移行を誘発する。次に、ワークフローシステム306内のワークフローエンジン310は、ワークフロー内の次のタスクに移動することができる。サブ処理がエラーを伴って回答した場合には、ワークフローエンジン310は、タスクステータスを「E」(エラー)に設定することができる。それに応答して、ワークフローエンジン310は、そのタスクをウェブエラー「GUI」314に渡す。
【0101】
上述のように、ウェブエラー「GUI」314は、インタフェースを提供し、これを通じてオペレータは、メッセージコンテントを修正、タスクを省略、又はタスクを(修正を加えて)処理のために再提出することができる。タスクが再提出されると、タスクステータスは、「R」(再提出)に移行する。ワークフローシステム306は、再提出されたタスクを受信し、そのタスクを統御するサブ処理を実行し、タスクステータスを「X」に設定する。エラーステータス「E」を伴うタスクに対しては、ワークフローエンジン310は、タスク実行を停止する。ウェブエラー「GUI」314は、タスク処理を要求するためにワークフローシステム306に要求/回答メッセージを公開することによってタスクを再開することができる。
【0102】
ウェブエラー「GUI」314がタスクを省略する場合には、タスクステータスは、「C」(完了)に設定される。これに加えて、オペレータは、ウェブエラー「GUI」314を通じてタスク実行を制御することができる。オペレータは、ウェブエラー「GUI」314を通じてタスクを即時に完了させる要求を出すことができ(タスクを「C」ステータスに移行させる)、又はタスクを再提出させることができる(タスクを「R」ステータスに移行させる)。ワークフローシステム306は、「C」ステータスが最終ステータスであると考え、それに応答してワークフローシーケンス内の次のタスクに移動する。
【0103】
図12は、並列タスクマネージャ312によって取られる段階1200の例を示している。ある一定のタスクは、他のタスクと同時に実行することができる並列タスクとして指定することができる。それにも関わらず、一部のタスクは、続行するために他のタスクから得られる結果を必要とする可能性がある。従って、並列タスクマネージャ312は、並列タスクを実行しているサブ処理からの応答をモニタし(段階1202)、応答を取得し(段階1204)、続行することができるようになる前に応答を待っている他のタスクに応答を提供する(例えば、ワークフローエンジン310を通じて)(段階1206)。それによって並列タスクマネージャ312は、入力データを待っている待機状態のタスクの障害を取り除くように作用する。
【0104】
上述のように、ワークフローシステム306はまた、アクションエンジン318を含む。アクションエンジン318は、個々のタスク内でネットワークサービス提供アクションを実行する。言い換えれば、拡張「TOM」データベース316がある一定のタスクに対してネットワークサービス提供アクションを指定した場合に、第2のワークフローシステム306は、アクションを処理するためにこのアクションエンジン318を呼び出すことができる。
【0105】
アクションエンジン318は、2つの層、すなわち、アクションマネージャ320及びアクションビルダ322を含む。アクションマネージャ320は、「TOM」データベース316内に定義されている正しいシーケンスでのサービス提供アクションの実行を判断して開始する。アクションビルダ322は、アクションの実行を要求するためにメッセージ公開システム214に対して適切なメッセージを作成して送信し、同様にメッセージ公開システム214から応答を受信する。
アクションエンジン318は、ワークフローエンジン310と同様な方法で実行する(図11)。より具体的には、アクションエンジン318は、ワークフロー内のタスクの処理に対する要求を受信する。それに応答して、アクションマネージャ320は、そのタスクに対して実行すべきアクションを「ACTION_INST」テーブル910から検索する。
【0106】
実行されるべき各アクションに対して、アクションマネージャ320は、アクションビルダ322を呼び出す。アクションが「デタッチ」されない(すなわち、並列に実行されない)場合には、アクションマネージャ320は、アクションビルダ322からの応答を待つ。そうでなければ、アクションマネージャ320は、アクションビルダ322からの応答を待たずにシーケンス内の次のアクションの実行を開始する。ウェブエラー「GUI」314は、ここでもまた、タスクエラーと同じ方法で、かつ同じステータス移行を伴ってアクション実行中に発生するエラーを管理することができる。
【0107】
アクションビルダ322は、アクションを実行することになるシステム又は処理への配信に向けてアクション要求メッセージを構築し、メッセージ公開システム214に送信する。アクションビルダ322は、メッセージ公開システム214からアクション実行から生じる応答を受信する。アクションビルダ322は、この応答をアクションマネージャ320に戻す。応答に基づいて、アクションマネージャ320は、あらゆるエラーを処理するか(例えば、ウェブエラー「GUI」314を通じて)、又は存在するならば次のネットワークアクションを実行する。
【0108】
ワークフロー、タスク、及びアクションは、広範囲なサービス要求について定義することができる。一例として、「UMTS加入者識別モジュール(USIM)」をアクティブ化するためのワークフローは、「ACTIVATE_USM」の「TSO_LABEL」に関連付けることができ、以下のタスクへと分割することができる:コア基本サービスを「アクティブ化」する(例えば、関連の「IMSI」及び「MSISDN」を提供する)、メッセージサービスを「変更」する(例えば、関連のメッセージサービスに「MSISDN」及び顧客名を提供する)、及び警告サービスを「変更」する(例えば、警告サービスに顧客名、誕生日、住所、又は他の顧客情報を提供する)。「CRM」システム122からのサービス要求に関連するワークフローの付加的な例は、「USIM」を「変更」し、「USIM」を「一時停止」し、「USIM」を「再開」し、「MSISDN」番号を「変更」し、送受話器を「非アクティブ化」し、先払い又は後払い「USIM」を「事前アクティブ化」し、サービスを「アクティブ化」し、サービスの「終了」し、「USIM」を「終了」するワークフローを含む。
【0109】
サービスブローカー116は、広範な電気通信サービスに対するサービス要求を処理する。1つの役割では、サービスブローカー116は、第三者ゲートウェイ110から受信するサービス要求を処理する。一般的に、サービスブローカー116は、インバウンドサービス要求を一連の段階(例えば、タスク及びアクション)にマッピングし、サービス要求の実施に導くものである。サービスブローカー116は、各段階の実行に対する要求を適切なシステム又は処理に配信し、結果を判断し、この結果に関して第三者ゲートウェイ110と通信する。
【0110】
図13は、第三者ゲートウェイ110から受信した「認証」サービス要求から生じるメッセージフローの例を示している(フロー1302)。例えば、ユーザがサービスを購入することができる前に識別される必要がある場合には、第三者ゲートウェイ110は、「認証」要求(「MSISDN」及び/又は「IMSI」番号のようなユーザを認識するために用いられる情報を含む)を送信することができる。サービスブローカー116は、ユーザプロフィールに対する要求をディレクトリシステムに提出し(フロー1304)、ディレクトリシステムは、ユーザプロフィールを返信する(フロー1306)。
【0111】
サービスブローカー116は、第三者ゲートウェイ110に結果を返信する(フロー1308)。ディレクトリシステムがユーザを認証できなかった場合には、サービスブローカー116は、第三者ゲートウェイに「非許可」メッセージを返信する。そうでなければ、サービスブローカー116は、ユーザプロフィールデータと共に「許可」メッセージを返信する。ユーザが許可された場合には、サービスブローカー116は、次に、ユーザのサービスプロフィールに対する要求という形態でユーザに関する追加情報をディレクトリシステムに要求することができ(フロー1310)、ディレクトリシステムは、そのプロフィールを返信する(フロー1312)。
【0112】
サービスブローカー116は、結果を第三者ゲートウェイ110に返信する(フロー1314)。プロフィール情報が入手不能であった場合には、サービスブローカー116は、「非許可」メッセージを第三者ゲートウェイ110に返信する。そうでなければ、サービスブローカー116は、サービスプロフィールデータと共に「許可」メッセージを返信する。
表22及び23は、「認証」サービス要求メッセージ及び応答の例を示している。
【0113】
【表5】
【0114】
【表6】
【0115】
図14は、第三者ゲートウェイ110から受信した「課金」サービス要求から生じるメッセージフローの例を示している(フロー1402)。第三者ゲートウェイ110は、ユーザアカウントにサービス額を課金するために「課金」要求を送信することができる。サービスブローカー116は、課金額を含む課金要求を請求システムに提出する(フロー1404)。請求システムは、サービスをアカウントに課金し、サービスブローカー116に結果ステータスを返信する(フロー1406)。サービスブローカー116は、結果ステータスを第三者ゲートウェイ110に返信する(フロー1408)。
表24及び25は、「課金」サービス要求メッセージ及び応答の例を示している。
【0116】
【表7】
【0117】
【表8】
【0118】
図15は、第三者ゲートウェイ110から受信した「SMS」配信サービス要求から生じるメッセージフローの例を示している(フロー1502)。第三者ゲートウェイ110は、ユーザアカウントに対して課金し、「SMS」メッセージを配信するために「SMS」要求を送信することができる。サービスブローカー116は、サービスについてアカウントに課金するように請求システムに要求し(フロー1504)、請求システムから結果ステータスを受信する(フロー1506)。サービスブローカー116は、結果ステータスを第三者ゲートウェイ110に返信する(フロー1508)。次に、サービスブローカー116は、「SMS」を送信するためにネットワークインタフェースを通じて「SMS」処理又はシステムを呼び出し(フロー1510)、確認応答を受信する(フロー1512)。サービスブローカー116は、エラー発生時には「SMS」メッセージ送信を再試行するように続行することができる。
表26及び27は、「SMS」サービス要求メッセージ及び応答の例を示している。
【0119】
【表9】
【0120】
【表10】
【0121】
図16は、第三者ゲートウェイ110から受信した「MMS」配信サービス要求から生じるメッセージフローの例を示している(フロー1602)。第三者ゲートウェイ110は、ユーザアカウントに対して課金し、「MMS」メッセージを配信するために「MMS」要求を送信することができる。サービスブローカー116は、サービスについてアカウントに課金するように請求システムに要求し(フロー1604)、請求システムから結果ステータスを受信する(フロー1606)。サービスブローカー116は、結果ステータスを第三者ゲートウェイ110に返信する(フロー1608)。次にサービスブローカー116は、「MMS」を送信するためにネットワークインタフェースを通じて「MMS」処理又はシステムを呼び出し(フロー1610)、確認応答を受信する(フロー1612)。サービスブローカー116は、エラー発生時には「MMS」メッセージ送信を再試行するように続行することができる。
表28及び29は、「MMS」サービス要求メッセージ及び応答の例を示している。
【0122】
【表11】
【0123】
【表12】
【0124】
図17は、第三者ゲートウェイ110から受信した「セッション開始プロトコル(SIP)」サービス要求から生じるメッセージフローの例を示している(フロー1702)。第三者ゲートウェイ110は、「SIP」呼び出しを設定してアカウントに課金するために「SIP」要求を送信することができる。サービスブローカー116は、サービスについてアカウントに課金するように請求システムに要求し(フロー1704)、請求システムから結果ステータスを受信する(フロー1706)。サービスブローカー116は、結果ステータスを第三者ゲートウェイ110に返信する(フロー1708)。次に、サービスブローカー116は、「SIP」接続を設定するためにネットワークインタフェースを通じて「SIP」処理又はシステムを呼び出し(フロー1710)、確認応答を受信する(フロー1712)。サービスブローカー116は、エラー発生時には「SIP」接続の設定を再試行するように続行することができる。
表30及び31は、「SIP」サービス要求メッセージ及び応答の例を示している。
【0125】
【表13】
【0126】
【表14】
【0127】
図18は、第三者ゲートウェイ110から受信した「ユーザステータス」サービス要求から生じるメッセージフローの例を示している(フロー1802)。第三者ゲートウェイ110は、他のユーザのオンライン存在検査を行うために「ステータス」要求を送信することができる。サービスブローカー116は、ディレクトリシステムにステータス要求メッセージを送信し(フロー1804)、ディレクトリシステムは、ユーザステータスを返信する(フロー1806)。サービスブローカー116は、ユーザステータスを第三者ゲートウェイ110に返信する(フロー1808)。
表32及び33は、「ステータス」サービス要求メッセージ及び応答の例を示している。
【0128】
【表15】
【0129】
【表16】
【0130】
図19は、第三者ゲートウェイ110から受信した「モバイルユーザステータス」認証サービス要求から生じるメッセージフローの例を示している(フロー1902)。例えば、ユーザが「インターネットプロトコルテレビジョン(IPTV)」サービスのようなサービスの購入することができる前に識別される必要がある場合、第三者ゲートウェイ110は、「認証」要求(「MSISDN」及び/又は「IMSI」番号のようなユーザを認識するために用いられる情報を含む)を送信することができる。サービスブローカー116は、ディレクトリシステムにユーザサービスデータ(例えば、ユーザに関するネットワーク特性)に対する要求を提出し(フロー1904)、ディレクトリシステムは、ユーザサービスデータを返信する(フロー1906)。
【0131】
サービスブローカー116は、第三者ゲートウェイ110に結果を返信する(フロー1908)。ディレクトリシステムがユーザを認証できなかった場合には、サービスブローカー116は、第三者ゲートウェイに「非許可」メッセージを返信する。そうでなければ、サービスブローカー116は、ユーザプロフィールデータと共に「許可」メッセージを返信する。ユーザが許可された場合には、次に、サービスブローカー116は、ユーザのアプリケーションサービスプロフィールに対する要求という形態でユーザに関する追加情報をディレクトリシステムに要求することができ(フロー1910)、ディレクトリシステムは、そのプロフィールを返信する(フロー1912)。
【0132】
サービスブローカー116は、結果を第三者ゲートウェイ110に返信する(フロー1914)。アプリケーションサービス情報が入手不能であった場合には、サービスブローカー116は「非許可」メッセージを第三者ゲートウェイ110に返信する。そうでなければ、サービスブローカー116は、アプリケーションサービスデータと共に「許可」メッセージを返信する。
表34及び35は、モバイルユーザ認証サービス要求メッセージ及び応答の例を示している。
【0133】
【表17】
【0134】
【表18】
【0135】
図20は、第三者ゲートウェイ110から受信した「IPTV」ユーザ認証要求から生じるメッセージフローの例を示している(フロー2002)。例えば、ユーザがモバイル「IPTV」アプリケーションに接続を試みる場合、第三者ゲートウェイ110は、「認証」要求(「MSISDN」及び/又は「IMSI」番号のようなユーザを認識するために用いられる情報を含む)を送信することができる。サービスブローカー116は、ディレクトリシステムにユーザサービスデータ(例えば、ユーザに関するネットワーク特性)に対する要求を提出し(フロー2004)、ディレクトリシステムは、ユーザサービスデータを返信する(フロー2006)。
【0136】
サービスブローカー116は、第三者ゲートウェイ110に結果を返信する(フロー2008)。ディレクトリシステムがユーザを認証できなかった場合には、サービスブローカー116は、第三者ゲートウェイに「非許可」メッセージを返信する。そうでなければ、サービスブローカー116は、ユーザサービスデータと共に「許可」メッセージを返信する。ユーザが許可された場合には、次に、サービスブローカー116は、ユーザのアプリケーションサービスプロフィールに対する要求という形態でユーザに関する追加情報をディレクトリシステムに要求することができ(フロー2010)、ディレクトリシステムは、そのプロフィールを返信する(フロー2012)。
【0137】
サービスブローカー116は、結果を第三者ゲートウェイ110に返信する(フロー2014)。アプリケーションサービス情報が入手不能であった場合には、サービスブローカー116は「非許可」メッセージを第三者ゲートウェイ110に返信する。そうでなければ、サービスブローカー116は、アプリケーションサービスデータと共に「許可」メッセージを返信する。
表36及び37は、「IPTV」ユーザ認証サービス要求メッセージ及び応答の例を示している。
【0138】
【表19】
【0139】
【表20】
【0140】
上述の説明の全ては、説明された特定の実施例に係わらず、制限的なものではなく本質的に例示的なものである。例えば、実施例の選択された態様、特徴、又は構成要素は、メモリ内に格納されているように示されているが、サービスブローカーと適合するシステム及び方法の全て又は一部は、他の機械可読媒体、例えば、ハードディスク、フレキシブルディスク、及びCD−ROMのような2次記憶装置、ネットワークから受信する信号、又は現時点で公知であるか又は今後開発されるROM又はRAMの他の形態に格納、又はそれらにわたって分配、又はそれらから読み取ることができる。
【0141】
更に、サービスブローカーアーキテクチャの特定の構成要素が説明されているが、サービスブローカーに適合する方法、システム、及び製造品は、付加的な又は異なる構成要素を含むことができる。例えば、プロセッサは、マイクロプロセッサ、マイクロコントローラ、特定用途向け集積回路(ASIC)、個別論理回路、又は他のタイプの回路又は論理回路の組合せとして実施することができる。同様に、メモリは、DRAM、SRAM、フラッシュ、又は他のあらゆるタイプのメモリとすることができる。フラグ、データ、データベース、テーブル、及び他のデータ構造は、別々に格納及び管理することができ、単一のメモリ又はデータベースに組み込むことができ、分配することができ、又は様々な手法で論理的にかつ物理的に編成することができる。プログラムは、単一のプログラムの各部分、又は別々のプログラムとすることができ、又はいくつかのメモリ及びプロセッサにわたって分配することができる。システムは、1つの処理システム内の又は複数の処理システムにわたって分配されたハードウエア、ソフトウエア、又はハードウエアとソフトウエアの組合せで実施することができる。
【0142】
サービスブローカー層は、外部のサービス要求の処理に関連する技術的困難を克服するものである。待ち行列におけるサービス要求の分配は、莫大な数の同時又はほぼ同時のサービス要求を受信して編成するという技術的困難に対処する。多重フェッチャー及びワークフローエンジンアーキテクチャは、調整された効率的方法でサービス要求を抽出し、抽出されたサービス要求を実行して要求された処理を実際に達成し、耐障害性サービス要求処理を提供し、サービス要求処理の性能を最大にする際の技術的困難に対処するものである。
本発明の様々な実施形態を説明したが、本発明の範囲内で更に多くの実施形態及び実施例が可能であることは当業者には明らかであろう。従って、本発明は、特許請求の範囲及びそれらの均等物に照らしたもの以外は制限されないものとする。
【図面の簡単な説明】
【0143】
【図1】第三者アクセスゲートウェイに接続したサービスブローカーを含む電気通信アーキテクチャの一部分を示す図である。
【図2】電気通信アーキテクチャ内のサービスブローカーを示す図である。
【図3】電気通信アーキテクチャ内のサービスブローカーの代替的な実施例を示す図である。
【図4】サービスブローカー内のフェッチャーシステムのためのトラフィック制御パラメータを例示する図である。
【図5】電気通信アーキテクチャ内のサービスブローカーのためのディスパッチャーシステムを例示する図である。
【図6】電気通信アーキテクチャ内のサービスブローカーのための第1のフェッチャーシステムを示す図である。
【図7】電気通信アーキテクチャ内のフェッチャーシステムのための技術指令管理データベースを例示する図である。
【図8】電気通信アーキテクチャ内のサービスブローカーのための第2のフェッチャーシステムを示す図である。
【図9】電気通信アーキテクチャ内のフェッチャーシステムのための拡張技術指令管理データベースを例示する図である。
【図10】電気通信サービス要求を処理するためにインバウンド要求マネージャが取ることができる作動を示す図である。
【図11】電気通信サービス要求を処理するためにワークフローエンジンが取ることができる作動を示す図である。
【図12】電気通信サービス要求を処理するために並列タスクマネージャが取ることができる作動を示す図である。
【図13】「認証」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図14】「課金」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図15】「SMS」配信及び「課金」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図16】「MMS」配信及び「課金」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図17】「SIP」呼び出し要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図18】ユーザ「ステータス」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図19】モバイルユーザ「認証」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【図20】「IPTV」ユーザ「認証」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。
【符号の説明】
【0144】
100 電気通信アーキテクチャ
102 第三者
112 サービス要求
116 サービスブローカー
【特許請求の範囲】
【請求項1】
電気通信アーキテクチャのためのサービス要求処理システムであって、
各サービス要求がサービスタイプ識別子フィールドとサービス要求識別子フィールドとを含む電気通信サービスに対するサービス要求を受信するサービス要求インタフェースと、
前記サービスタイプ識別子フィールドに基づいて前記サービス要求を異なるサービス待ち行列(queues)内に分配し、それによって待機サービス要求(queued service requests)を確立するディスパッチャーシステムと、
待機サービス要求を処理するために前記サービス要求識別子フィールドから選択されたサービス要求識別子を取得する複数の(multiple)独立したフェッチャーシステムと、
前記フェッチャーシステムの少なくとも1つによる前記待機サービス要求の選択を支配するトラフィック制御パラメータと、
前記選択されたサービス要求識別子によって識別された前記待機サービス要求を満足させるワークフローシーケンスを開始するワークフローシステムと、
を含むことを特徴とするシステム。
【請求項2】
前記異なるサービス待ち行列は、
顧客関係管理サービス要求待ち行列と、
第三者サービス要求待ち行列と、
を含む、
ことを特徴とする請求項1に記載のサービス要求処理システム。
【請求項3】
前記第三者サービス要求待ち行列は、
メッセージサービス要求待ち行列と、
課金サービス要求待ち行列と、
を含む、
ことを特徴とする請求項2に記載のサービス要求処理システム。
【請求項4】
前記メッセージサービス要求待ち行列は、ショートメッセージングサービス(SMS)要求待ち行列を含むことを特徴とする請求項3に記載のサービス要求処理システム。
【請求項5】
前記メッセージサービス要求待ち行列は、マルチメディアメッセージングサービス(MMS)要求待ち行列を含むことを特徴とする請求項3に記載のサービス要求処理システム。
【請求項6】
前記第三者サービス要求待ち行列は、
認証要求待ち行列と、
ステータス要求待ち行列と、
を含む、
ことを特徴とする請求項2に記載のサービス要求処理システム。
【請求項7】
前記認証要求待ち行列は、モバイルユーザ認証要求待ち行列を含むことを特徴とする請求項6に記載のサービス要求処理システム。
【請求項8】
前記顧客関係管理サービス要求待ち行列は、
サービスアクティブ化要求待ち行列と、
サービス終了要求待ち行列と、
を含む、
ことを特徴とする請求項2に記載のサービス要求処理システム。
【請求項9】
前記異なるサービス待ち行列は、入力メッセージフィールドと出力メッセージフィールドとを含むデータベーステーブルを含むことを特徴とする請求項1に記載のサービス要求処理システム。
【請求項10】
電気通信サービス要求を処理する方法であって、
各サービス要求がサービスタイプ識別子フィールドとサービス要求識別子フィールドとを含む電気通信サービスに対するサービス要求を受信する段階と、
前記サービスタイプ識別子フィールドに基づいて前記サービス要求を異なるサービス待ち行列内に送り出し、それによって待機サービス要求を確立する段階と、
前記個々のサービス待ち行列からの前記待機サービス要求の選択を支配するトラフィック制御パラメータを確立する段階と、
前記サービス要求識別子フィールドから選択されたサービス要求識別子を取得するために複数の独立したフェッチャーシステムの実行を開始する段階と、
前記選択されたサービス要求識別子によって識別された前記待機サービス要求を満足させるワークフローを開始する段階と、
を含むことを特徴とする方法。
【請求項11】
複数の独立したフェッチャーエンジンの実行を開始する段階は、
第1のフェッチャーシステムの実行を開始する段階と、
第2のフェッチャーシステムの実行を開始する段階と、
を含み、
ワークフローシーケンスを開始する段階は、
前記第1のフェッチャーエンジンのための第1のワークフローエンジンに対して、前記選択されたサービス要求識別子の第1のものを通信する段階と、
前記第2のフェッチャーエンジンのための第2のワークフローエンジンに対して、前記選択されたサービス要求識別子の第2のものを通信する段階と、
を含む、
ことを特徴とする請求項10に記載の方法。
【請求項12】
送り出す段階は、
顧客関係管理サービス要求待ち行列と、
第三者サービス要求待ち行列と、
の間で前記サービス要求を送り出す段階、
を含む、
ことを特徴とする請求項10に記載の方法。
【請求項13】
前記第三者サービス要求待ち行列は、メッセージサービス要求待ち行列を含むことを特徴とする請求項12に記載の方法。
【請求項14】
前記メッセージサービス要求待ち行列は、ショートメッセージングサービス(SMS)要求待ち行列を含むことを特徴とする請求項13に記載の方法。
【請求項15】
前記メッセージサービス要求待ち行列は、マルチメディアメッセージングサービス(MMS)要求待ち行列を含むことを特徴とする請求項13に記載の方法。
【請求項16】
前記第三者サービス要求待ち行列は、
認証要求待ち行列と、
ステータス要求待ち行列と、
を含む、
ことを特徴とする請求項12に記載の方法。
【請求項17】
前記認証要求待ち行列は、モバイルユーザ認証要求待ち行列を含むことを特徴とする請求項16に記載の方法。
【請求項18】
前記異なるサービス待ち行列は、データベース待ち行列テーブルを含むことを特徴とする請求項10に記載の方法。
【請求項19】
前記データベース待ち行列テーブルは、待ち行列エントリがフェッチされたか否かを示す「処理ステータス」フィールドを含むことを特徴とする請求項18に記載の方法。
【請求項20】
前記データベース待ち行列テーブルは、前記待ち行列エントリの処理が完了したか否かを示す「処理完了」フィールドを含むことを特徴とする請求項19に記載の方法。
【請求項1】
電気通信アーキテクチャのためのサービス要求処理システムであって、
各サービス要求がサービスタイプ識別子フィールドとサービス要求識別子フィールドとを含む電気通信サービスに対するサービス要求を受信するサービス要求インタフェースと、
前記サービスタイプ識別子フィールドに基づいて前記サービス要求を異なるサービス待ち行列(queues)内に分配し、それによって待機サービス要求(queued service requests)を確立するディスパッチャーシステムと、
待機サービス要求を処理するために前記サービス要求識別子フィールドから選択されたサービス要求識別子を取得する複数の(multiple)独立したフェッチャーシステムと、
前記フェッチャーシステムの少なくとも1つによる前記待機サービス要求の選択を支配するトラフィック制御パラメータと、
前記選択されたサービス要求識別子によって識別された前記待機サービス要求を満足させるワークフローシーケンスを開始するワークフローシステムと、
を含むことを特徴とするシステム。
【請求項2】
前記異なるサービス待ち行列は、
顧客関係管理サービス要求待ち行列と、
第三者サービス要求待ち行列と、
を含む、
ことを特徴とする請求項1に記載のサービス要求処理システム。
【請求項3】
前記第三者サービス要求待ち行列は、
メッセージサービス要求待ち行列と、
課金サービス要求待ち行列と、
を含む、
ことを特徴とする請求項2に記載のサービス要求処理システム。
【請求項4】
前記メッセージサービス要求待ち行列は、ショートメッセージングサービス(SMS)要求待ち行列を含むことを特徴とする請求項3に記載のサービス要求処理システム。
【請求項5】
前記メッセージサービス要求待ち行列は、マルチメディアメッセージングサービス(MMS)要求待ち行列を含むことを特徴とする請求項3に記載のサービス要求処理システム。
【請求項6】
前記第三者サービス要求待ち行列は、
認証要求待ち行列と、
ステータス要求待ち行列と、
を含む、
ことを特徴とする請求項2に記載のサービス要求処理システム。
【請求項7】
前記認証要求待ち行列は、モバイルユーザ認証要求待ち行列を含むことを特徴とする請求項6に記載のサービス要求処理システム。
【請求項8】
前記顧客関係管理サービス要求待ち行列は、
サービスアクティブ化要求待ち行列と、
サービス終了要求待ち行列と、
を含む、
ことを特徴とする請求項2に記載のサービス要求処理システム。
【請求項9】
前記異なるサービス待ち行列は、入力メッセージフィールドと出力メッセージフィールドとを含むデータベーステーブルを含むことを特徴とする請求項1に記載のサービス要求処理システム。
【請求項10】
電気通信サービス要求を処理する方法であって、
各サービス要求がサービスタイプ識別子フィールドとサービス要求識別子フィールドとを含む電気通信サービスに対するサービス要求を受信する段階と、
前記サービスタイプ識別子フィールドに基づいて前記サービス要求を異なるサービス待ち行列内に送り出し、それによって待機サービス要求を確立する段階と、
前記個々のサービス待ち行列からの前記待機サービス要求の選択を支配するトラフィック制御パラメータを確立する段階と、
前記サービス要求識別子フィールドから選択されたサービス要求識別子を取得するために複数の独立したフェッチャーシステムの実行を開始する段階と、
前記選択されたサービス要求識別子によって識別された前記待機サービス要求を満足させるワークフローを開始する段階と、
を含むことを特徴とする方法。
【請求項11】
複数の独立したフェッチャーエンジンの実行を開始する段階は、
第1のフェッチャーシステムの実行を開始する段階と、
第2のフェッチャーシステムの実行を開始する段階と、
を含み、
ワークフローシーケンスを開始する段階は、
前記第1のフェッチャーエンジンのための第1のワークフローエンジンに対して、前記選択されたサービス要求識別子の第1のものを通信する段階と、
前記第2のフェッチャーエンジンのための第2のワークフローエンジンに対して、前記選択されたサービス要求識別子の第2のものを通信する段階と、
を含む、
ことを特徴とする請求項10に記載の方法。
【請求項12】
送り出す段階は、
顧客関係管理サービス要求待ち行列と、
第三者サービス要求待ち行列と、
の間で前記サービス要求を送り出す段階、
を含む、
ことを特徴とする請求項10に記載の方法。
【請求項13】
前記第三者サービス要求待ち行列は、メッセージサービス要求待ち行列を含むことを特徴とする請求項12に記載の方法。
【請求項14】
前記メッセージサービス要求待ち行列は、ショートメッセージングサービス(SMS)要求待ち行列を含むことを特徴とする請求項13に記載の方法。
【請求項15】
前記メッセージサービス要求待ち行列は、マルチメディアメッセージングサービス(MMS)要求待ち行列を含むことを特徴とする請求項13に記載の方法。
【請求項16】
前記第三者サービス要求待ち行列は、
認証要求待ち行列と、
ステータス要求待ち行列と、
を含む、
ことを特徴とする請求項12に記載の方法。
【請求項17】
前記認証要求待ち行列は、モバイルユーザ認証要求待ち行列を含むことを特徴とする請求項16に記載の方法。
【請求項18】
前記異なるサービス待ち行列は、データベース待ち行列テーブルを含むことを特徴とする請求項10に記載の方法。
【請求項19】
前記データベース待ち行列テーブルは、待ち行列エントリがフェッチされたか否かを示す「処理ステータス」フィールドを含むことを特徴とする請求項18に記載の方法。
【請求項20】
前記データベース待ち行列テーブルは、前記待ち行列エントリの処理が完了したか否かを示す「処理完了」フィールドを含むことを特徴とする請求項19に記載の方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【公開番号】特開2007−149099(P2007−149099A)
【公開日】平成19年6月14日(2007.6.14)
【国際特許分類】
【外国語出願】
【出願番号】特願2006−319265(P2006−319265)
【出願日】平成18年10月27日(2006.10.27)
【出願人】(504051087)アクセンチュア グローバル サーヴィシズ ゲゼルシャフト ミット ベシュレンクテル ハフツング (17)
【Fターム(参考)】
【公開日】平成19年6月14日(2007.6.14)
【国際特許分類】
【出願番号】特願2006−319265(P2006−319265)
【出願日】平成18年10月27日(2006.10.27)
【出願人】(504051087)アクセンチュア グローバル サーヴィシズ ゲゼルシャフト ミット ベシュレンクテル ハフツング (17)
【Fターム(参考)】
[ Back to top ]