(57)【特許請求の範囲】
【請求項１】
サービス統合プラットフォームシステムであって、
独立系ソフトウェアベンダー（ＩＳＶ）によって開始されたサービス要求を受信するよう構成されたインターフェースと、
１または複数のプロセッサであって、
実際のサービスを提供する配備環境に対応する配備用統一リソース識別子（ＵＲＩ）およびテストサービスに対するアクセスを提供するテスト環境に対応するテスト用統一リソース識別子（ＵＲＩ）を提供し、前記テスト用ＵＲＩは前記配備用ＵＲＩとは別個かつ異なり、
前記サービス要求を認証し、
前記サービス要求の認証が成功した場合に、さらに処理されるべきサービスを提供するインターネットサービスプロバイダ（ＩＳＰ）まで前記サービス要求をルーティングすることであって、
前記サービス要求が前記テスト用ＵＲＩまたは前記配備用ＵＲＩのいずれにおいて受信されたか決定し、
前記サービス要求が前記テスト用ＵＲＩで受信された場合には、テストのために、前記サービス要求を前記テスト環境までルーティングし、
前記サービス要求が前記配備用ＵＲＩで受信された場合には、更なる処理のために、前記サービス要求を前記配備環境までルーティングするように構成されている１または複数のプロセッサと、を備え、
前記配備環境および前記テスト環境は少なくともセキュリティ関連認証データを共有し、
前記サービス要求の認証は、
前記サービス要求を開始したＩＳＶのパラメータが正規であるか否かを判定し、
前記パラメータが正規である場合には、
前記サービス要求に関連するサービスが存在するか否かを判定し、
前記サービスが存在する場合には、前記サービス要求の認証は成功する、システム。
【請求項２】
請求項１に記載のシステムであって、前記１または複数のプロセッサは、さらに、
前記サービス要求を開始した前記ＩＳＶによって要求された前記サービスが、前記ＩＳＰへのログインを必要とすることを決定し、
前記ＩＳＰへのログイン要求を開始し、
前記ＩＳＰのログイン処理結果に従ってトークンを生成し、
前記ＩＳＶの前記サービス要求を前記ＩＳＰに転送するよう構成されている、システム。
【請求項３】
請求項１に記載のシステムであって、前記１または複数のプロセッサは、さらに、認証およびルーティングに関連する作業のログを記録するよう構成されている、システム。
【請求項４】
請求項３に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記ログを解析するよう構成されている、システム。
【請求項５】
請求項４に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記ログの解析結果に従ってシステムアクセスを監視するよう構成されている、システム。
【請求項６】
請求項４に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記ログの解析結果に従って代金を計上するよう構成されている、システム。
【請求項７】
請求項１に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記ＩＳＰによって提供されたサンドボックスを前記ＩＳＶのテストサービスにリンクするよう構成されている、システム。
【請求項８】
請求項１に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記サービス要求が前記テスト環境までルーティングされた場合に、システムデバッグプロシージャをテストするよう構成されている、システム。
【請求項９】
請求項８に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記システムデバッグプロシージャのテスト結果に従って、前記ＩＳＶによって開始された前記サービス要求を再認証するよう構成されている、システム。
【請求項１０】
請求項１に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記サービス要求が前記テスト環境までルーティングされた場合に、アプリケーションインターフェースをテストするよう構成されている、システム。
【請求項１１】
請求項１に記載のシステムであって、前記１または複数のプロセッサは、さらに、各ＩＳＰのアプリケーションインターフェーステストアドレスおよびサービスアドレスを取得し、前記サービス要求が前記テスト用ＵＲＩで受信された場合に前記サービス要求を前記アプリケーションインターフェーステストアドレスまでルーティングするよう構成されている、システム。
【請求項１２】
請求項１に記載のシステムであって、前記１または複数のプロセッサは、さらに、各ＩＳＰのサービス記述文書を少なくとも１つのＩＳＶに提供するよう構成されている、システム。
【請求項１３】
コンピュータにより実行されるインターネットサービスを提供するための方法であって、
実際のサービスを提供する配備環境に対応する配備用統一リソース識別子（ＵＲＩ）およびテストサービスに対するアクセスを提供するテスト環境に対応するテスト用統一リソース識別子（ＵＲＩ）を提供し、前記テスト用ＵＲＩは前記配備用ＵＲＩとは別個かつ異なり、前記配備環境および前記テスト環境は少なくともセキュリティ関連認証データを共有し、
独立系ソフトウェアベンダー（ＩＳＶ）によって開始されたサービス要求を受信し、
前記サービス要求を開始したＩＳＶのパラメータが正規であるか否か判定し、前記パラメータが正規である場合には前記サービス要求に関連するサービスが存在するか否かを判定して前記サービス要求を認証し、
前記サービスが存在し前記サービス要求の認証が成功した場合に、さらに処理されるべきサービスを提供するインターネットサービスプロバイダ（ＩＳＰ）まで前記サービス要求をルーティングするために前記サービス要求が前記テスト用ＵＲＩまたは前記配備用ＵＲＩのいずれにおいて受信されたか決定し、
前記サービス要求が前記テスト用ＵＲＩで受信された場合には、テストのために、前記サービス要求を前記テスト環境までルーティングし、
前記サービス要求が前記配備用ＵＲＩで受信された場合には、更なる処理のために、前記サービス要求を前記配備環境までルーティングすること、
を備える、方法。
【請求項１４】
請求項１３に記載の方法であって、さらに、
前記サービス要求を開始した前記ＩＳＶによって要求された前記サービスが、前記ＩＳＰへのログインを必要とすることを決定し、
前記ＩＳＰへのログイン要求を開始し、
前記ＩＳＰのログイン処理結果に従ってトークンを生成し、
前記ＩＳＶの前記サービス要求を前記ＩＳＰに転送すること、
を備える、方法。
【請求項１５】
請求項１４に記載の方法であって、さらに、認証およびルーティングに関連するログを記録することを備える、方法。
【請求項１６】
請求項１５に記載の方法であって、さらに、前記ログを解析することを備える、方法。
【請求項１７】
請求項１６に記載の方法であって、さらに、前記ログの解析結果に従ってシステムアクセスを監視することを備える、方法。
【請求項１８】
請求項１６に記載の方法であって、さらに、前記ログの解析結果に従って代金を計上することを備える、方法。
【請求項１９】
請求項１３に記載の方法であって、さらに、前記ＩＳＰによって提供されたサンドボックスを前記ＩＳＶのテストサービスにリンクすることを備える、方法。
【請求項２０】
請求項１３に記載の方法であって、さらに、前記サービス要求が前記テスト環境までルーティングされた場合に、システムデバッグプロシージャのテストをトリガすることを備える、方法。
【請求項２１】
請求項２０に記載の方法であって、さらに、前記システムデバッグプロシージャのテスト結果に従って、前記ＩＳＶによって開始された前記サービス要求を再認証することを備える、方法。
【請求項２２】
請求項１３に記載の方法であって、さらに、前記サービス要求が前記テスト環境までルーティングされた場合に、アプリケーションインターフェースをテストすることを備える、方法。
【請求項２３】
請求項１６に記載の方法であって、さらに、各ＩＳＰのアプリケーションインターフェーステストアドレスおよびサービスアドレスを取得し、前記サービス要求が前記テスト用ＵＲＩで受信された場合に前記サービス要求を前記アプリケーションインターフェーステストアドレスまでルーティングすること、を備える、方法。
【請求項２４】
請求項１６に記載の方法であって、さらに、各ＩＳＰのサービス記述文書を少なくとも１つのＩＳＶに提供することを備える、方法。
【請求項２５】
サービス統合プラットフォームシステムであって、
独立系ソフトウェアベンダー（ＩＳＶ）によって開始されたサービス要求を受信するよう構成されたインターフェースと、
前記サービス要求を認証するよう構成された認証モジュールと、
ルーティングモジュールであって、
実際のサービスを提供する配備環境に対応する配備用統一リソース識別子（ＵＲＩ）およびテストサービスに対するアクセスを提供するテスト環境に対応するテスト用統一リソース識別子（ＵＲＩ）を提供し、前記テスト用ＵＲＩは前記配備用ＵＲＩとは別個かつ異なり、
前記サービス要求の認証が成功した場合に、さらなる処理に向けて前記サービス要求を、サービスを提供するインターネットサービスプロバイダ（ＩＳＰ）までルーティングすることであって、
前記サービス要求が前記テスト用ＵＲＩまたは前記配備用ＵＲＩのいずれにおいて受信されたか決定し、
前記サービス要求が前記テスト用ＵＲＩで受信された場合には、テストのために、前記サービス要求を前記テスト環境までルーティングし、
前記サービス要求が前記配備用ＵＲＩで受信された場合には、更なる処理のために、前記サービス要求を前記配備環境までルーティングするよう構成されたルーティングモジュールと、
を備え、
前記配備環境および前記テスト環境は少なくともセキュリティ関連認証データを共有し、
前記サービス要求の認証は、
前記サービス要求を開始したＩＳＶのパラメータが正規であるか否かを判定し、
前記パラメータが正規である場合には、
前記サービス要求に関連するサービスが存在するか否かを判定し、
前記サービスが存在する場合には、前記サービス要求の認証は成功する、システム。
【請求項２６】
請求項１に記載のシステムであって、前記サービス要求に関連する前記サービスが存在するか否かの判定は、
署名が必要であるか否か判定し、
前記署名が必要である場合には、
前記署名が有効であるか否か判定し、
前記署名が有効でない場合には、前記サービス要求を中止する、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、２００８年６月２６日付けで出願され「SERVICE INTEGRATION PLATFORM SYSTEM AND A METHOD FOR PROVIDING INTERNET SERVICES（インターネットサービスを提供するための方法およびサービス統合プラットフォームシステム）」と題された中国特許出願第２００８１０１２６１１２．６号の優先権を主張する。当該出願は、あらゆる目的のために参照によって本明細書に組み込まれる。
【０００２】
本発明は、ネットワークサービスの分野に関し、特に、インターネットサービスを提供するためのサービス統合プラットフォームシステムおよび方法に関する。
【背景技術】
【０００３】
サービス指向アーキテクチャ（ＳＯＡ）の成熟に伴い、リプリゼンテーショナル・ステート・トランスファ（ＲＥＳＴ）スタイルのソフトウェアアーキテクチャが、ますます一般的になり、オープン・アプリケーションプログラムインターフェース（Ｏｐｅｎ  ＡＰＩ）が次第に新興のインターネットリソースとなった。従来のインターネットソフトウェア企業は、自身のサービスリソースをさらにオープンにすることによって、ウェブサイト開発のための新しいオープンモードを提供するために、サービスプロバイダとしての新たな役割を果たそうと努めてきた。Ｗｅｂ２．０の出現により、ネットワークサービスリソースを利用したウェブベースのソフトウェアを製作する多くの独立系ソフトウェアベンダー（ＩＳＶ）が育っている。これらのＩＳＶは、顧客の要求に応じて、異なるインターネットサービスプロバイダ（ＩＳＰ）によって提供されるサービスを組み合わせ、様々な対話型の革新的アプリケーションを作成する。
【０００４】
現在、いくつかの大規模なサービスプロバイダが、サービスプロバイダの提供するアプリケーションを充実させると共にサービスプロバイダに顧客を引きつけるネットワーク効果をもたらすべく、これらのオープンＡＰＩ専用の独特なアプリケーションを構築するために、オープンＡＰＩでＩＳＶを引き寄せている。
【０００５】
既存のオープンＡＰＩプラットフォームは、通例、単一ＩＳＰのオープンモデルであり、これは、単一ＩＳＰが、セキュリティ、課金、および、監視などのソリューションを含むサービスリリースの完全なセットを提供することを意味する。単一ＩＳＰのオープンモデルは、小規模ＩＳＰおよびＩＳＶにとって、インターネットリソースの活用に参加するのにあまり便利なものではない。
【図面の簡単な説明】
【０００６】
【図１】サービス統合プラットフォームシステムの一実施形態のブロック図。
【図２】サービス統合プラットフォームシステムの一実施形態が配備されるアプリケーション環境の一例を示す概略図。
【図３】追加のテスト機能を提供するサービス統合プラットフォームシステムの別の実施形態を示すブロック図。
【図４】ＩＳＶ開発プロセスの一実施形態におけるテストおよびアプリケーションの実装フローチャート。
【図５】インターネットサービスを提供する方法の一実施形態のフローチャート。
【図６】サービス統合プラットフォームシステムの認証およびルーティングプロセスの一例を示すプロセス図。
【図７】ＳＩＰでのアプリケーション開発を示す概略図。
【発明を実施するための形態】
【０００７】
本発明は、処理、装置、システム、物質の組成、コンピュータ読み取り可能な格納媒体上に具現化されたコンピュータプログラム製品、および／または、プロセッサ（プロセッサに接続されたメモリに格納および／またはそのメモリによって提供される命令を実行するよう構成されたプロセッサ）を含め、様々な形態で実装されうる。本明細書では、これらの実装または本発明が取りうる任意の他の形態を、技術と呼ぶ。一般に、開示された処理の工程の順序は、本発明の範囲内で変更されてもよい。特に言及しない限り、タスクを実行するよう構成されるものとして記載されたプロセッサまたはメモリなどの構成要素は、ある時間にタスクを実行するよう一時的に構成された一般的な構成要素として、または、タスクを実行するよう製造された特定の構成要素として実装されてよい。本明細書では、「プロセッサ」という用語は、１または複数のデバイス、回路、および／または、コンピュータプログラム命令などのデータを処理するよう構成された処理コアを指すものとする。
【０００８】
以下では、本発明の原理を示す図面を参照しつつ、本発明の１または複数の実施形態の詳細な説明を行う。本発明は、かかる実施形態に関連して説明されているが、どの実施形態にも限定されない。本発明の範囲は、特許請求の範囲によってのみ限定されるものであり、多くの代替物、変形物、および、等価物を含む。以下の説明では、本発明の完全な理解を提供するために、多くの具体的な詳細事項が記載されている。これらの詳細事項は、例示を目的としたものであり、本発明は、これらの具体的な詳細事項の一部または全てがなくとも特許請求の範囲に従って実施可能である。簡単のために、本発明に関連する技術分野で周知の技術事項については、本発明が必要以上にわかりにくくならないように、詳細には説明していない。
【０００９】
現在の単一ＩＳＰのオープンモードには多くの不利な点があることがわかっている。ＩＳＰの視点からすると、典型的なＩＳＰは、今日、オープンＡＰＩソリューションのセットを完全に提供および実装する能力を持つ大規模なウェブサイトであることが多い。しかし、中規模または小規模なＩＳＰは、通例、ブランド認知、技術力、および、クライアントリソースの不足から、独自の開発者コミュニティを構成することが難しいため、通例は、良好な開発の見通しが立たない。さらに、事業と関係のない様々な要件、特に、セキュリティ、課金、および、監視を、オープンＡＰＩに対して考慮する必要があるが、それらは、技術的に困難であることが多く、時に、オープンＡＰＩ環境の障害となりうる。
【００１０】
ＩＳＶの視点からすると、ＩＳＶによって開発されたアプリケーションは、今日、通常は１つのＩＳＰのサービスに集中している。現在のモデルでは、アプリケーションが、商品の検索、物流の支払い、および、電子地図など、複数のＩＳＰのサービスを統合する必要がある場合、ＩＳＶは、通例、複数のＩＳＰと共に開発を行うというさらなる労力を費やす必要があり、システムセキュリティ、共同デバッグ、統合テストなどに関する高い参入障壁に直面する。したがって、既存の従来の単一ＩＳＰオープンモデルでは、様々なＩＳＰサービスの統合の結果として得られる集約の効果は、容易に実現することができない。一方、様々なセキュリティポリシーにより、いくつかの事業以外のプロセスにＩＳＶを集中させることがあり、それにより、開発効率が下がる。
【００１１】
この観点から、サービス統合プラットフォームシステムが、様々なＩＳＰのサービスを統合するために開発された。セキュリティ、課金、監視、および、ルーティングなど、事業以外の機能は、サービス統合プラットフォームシステムによって実装される。ＩＳＶにとっては、統一的な基準および規格でサービス統合プラットフォームシステムにサービスを統合してアクセスすれば、異種のサービスシステムを統合する諸経費を大幅に削減できる。図１は、サービス統合プラットフォームシステムの一実施形態を示すブロック図である。この例において、サービス統合プラットフォームシステム１００は、認証モジュール１０１、応答モジュール１０２、および、ルーティングモジュール１０３を備える。システム１００は、さらに、記録モジュール１０４、タスクモジュール１０５、監視モジュール１０６、および、課金モジュール１０７など、複数のオプションモジュールを備える。サービス統合プラットフォームシステムの他の実施形態は、オプションモジュールの内の１または複数を備えてよい。一部の実施形態において、各モジュールは、１または複数のプロセッサで実行する１または複数のソフトウェアプロセスを実装する。一部の実施形態において、モジュールは、１または複数のシングルプロセッサまたはマルチプロセッサコンピュータ上で実行される。この例において、認証モジュール１０１は、ＩＳＶがサービス要求を開始した時に、ＩＳＶを認証するよう構成される。一部の実施形態において、認証モジュール１０１は、以下に挙げることの１または複数を認証するよう構成される：ＩＳＶのパラメータが正規のものか否か、サービスが存在するか否か、署名が必要か否か、権限があるか否か、署名が有効か否か、ＩＳＶのタイムスタンプが期限切れであるか否か、および、トークンが有効か否か。他の実施形態において、その他の認証基準が含まれてもよい。
【００１２】
ＩＳＶが認証に失敗した場合には、代わりに、応答モジュール１０２がトリガされる。一部の実施形態において、応答モジュールは、サービス要求が、許可されない、または、それ以外のエラーであることを示すエラーメッセージを生成する。異なる種類のエラーに対して、異なる応答が生成されてよく、エラーを修正するために必要になりうる任意の追加／修正の情報／動作を示唆する。例えば、ユーザバインディングを必要とすることによってエラーが起きた場合、対応するバインディングされたユーザアドレスおよび関連情報が戻され、不正確なパラメータが入力および検出されたことによってエラーが起きた場合、関連するプロンプティング情報が戻されうる。
【００１３】
ＩＳＶが認証された場合には、ルーティングモジュール１０３がトリガされる。この例において、ルーティングモジュール１０３は、ＩＳＶによって要求されたサービスを、その要求されたサービスを提供するＩＳＰまでルーティングするよう構成される。
【００１４】
図の例において、ルーティングモジュール１０３は、ログイン判定ユニット１０３１、ログインユニット１０３２、および、転送ユニット１０３３を備える。ログイン判定ユニット１０３１は、ＩＳＶによって要求されたサービスがＩＳＶにログインを要求するか否かを判定するよう構成される。ログインユニット１０３２は、肯定判定によってトリガされ、転送ユニット１０３３は、否定判定によってトリガされる。ログインユニット１０３２は、サービス要求を開始した要求側ＩＳＶのサービス要求に従ってサービスを提供するＩＳＰへのログイン要求を開始すると共に、ＩＳＶがＩＳＰにログインする時に生成されたトークンを伝えるよう構成される。転送ユニット１０３３は、サービス要求を開始したＩＳＶのサービス要求を、サービスを提供するＩＳＰに転送し、ＩＳＰの処理結果に従って応答を転送するよう構成される。
【００１５】
オプションの記録モジュール１０４は、認証モジュール１０１、応答モジュール１０２、および、ルーティングモジュール１０３の作業のログを記録するよう構成される。
【００１６】
オプションのタスクモジュール１０５は、記録モジュール１０４にリンクされており、記録モジュールによって記録されたログを解析するよう構成されている。
【００１７】
オプションの監視モジュール１０６は、タスクモジュールによるログの解析に従って、システムアクセスを監視するよう構成される。オプションの課金モジュール１０７は、タスクモジュールによるログの解析に従って、代金を計上するよう構成される。
【００１８】
この例において、サービス統合プラットフォームシステムは、ＩＳＶのアプリケーションのためのテストサービスを提供する。テストサービスを提供するために、サービス統合プラットフォームシステムは、さらに、様々なＩＳＰによって提供される様々なテスト環境（サンドボックス）に接続するよう構成されたサンドボックスモジュール１０８を備える。本明細書で用いるように、サンドボックスとは、配備されているより大きい環境に影響を与えることなく、かつ、顧客にサービスすることなく、ソフトウェアを安全にテストすることができるテスト環境のことを指す。ＩＳＶによって提供されたアプリケーションがセキュリティおよび信頼性などの要件に適合することを保証するために、ほとんどのＩＳＰが、独自のサンドボックス環境を提供して様々なテストを実行するものと仮定する。また、少なくとも１つのＩＳＶがテストサービス要求を開始した時に、テストサービス要求を開始したＩＳＶのテストサービスを、テストサービスを提供するＩＳＰによって提供されたサンドボックスに、サンドボックスモジュールを介して接続するためのテスト要求処理モジュール１０９が含まれる。
【００１９】
さらに、サービス統合プラットフォームシステムは、ＩＳＶがマニュアルなどのサービス文書を提供することを可能にするよう構成されたサービス文書モジュール１１０を備えてよい。
【００２０】
図２は、サービス統合プラットフォームシステムの一実施形態が配備されるアプリケーション環境の一例を示す概略図である。この例において、サービス統合プラットフォームシステムは、サービス統合プラットフォーム（ＳＩＰ）に基づいて構築される。ＳＩＰは、インターネット、ローカルエリアネットワーク（ＬＡＮ）、または、任意のその他の適切なネットワークを介して、ＩＳＶおよびＩＳＰを接続する。この例において、ＩＳＶは、２つのエンドユーザとＩＳＶアプリケーション（ＩＳＶ  ＡＰＰ）とを備えている。これは、２つのＡＰＩサーバを備える。ＩＳＶ  ＡＰＰは、一般的なインターネットアプリケーションまたはクライアントデスクトップアプリケーションであってよい。例えば、ＳＩＰを備えた通信路が、ＨＴＴＰ（ハイパーテキスト・トランスファー・プロトコル）アクセスによって構築されてよく、ＳＩＰおよびＩＳＰは、ＨＴＴＰスキームによってリンクされてよい。一部の実施形態において、セキュア・ソケット・レイヤ（ＳＳＬ）または専用回線スキームが、ＨＴＴＰのセキュリティを確保するために用いられてよい。この例において、ＳＩＰハードウェアは、ＡＰＩルートサーバおよびタイミングタスクサーバを含む。すなわち、サービス統合プラットフォームシステムの認証モジュール、応答モジュール、ルーティングモジュール、および、記録モジュールは、サービスルーティングおよびセキュリティ認証の機能を主に処理するために、ＡＰＩルートサーバ上に特別に構成されてよい。一方、サーバの訪問記録は、記録モジュールによってログ内にローカルに直接格納されてよい。サービス統合プラットフォームシステムのタイミングタスクモジュールは、タイミングタスクサーバ上に構成され、タイミングタスクサーバは、ログを収集し、並行して非同期的にログを解析する。解析は、監視モジュールおよび課金モジュールでの利用のために提供される。課金モジュールは、図２に示すように、課金ＤＢ（データベース）上に構成される。
【００２１】
上記の構成によると、この例においては、ＡＰＩルートサーバは、セキュリティ、認証、および、アクセス記録を一様に処理し、ＩＳＶのアイデンティティを認証し、ユーザのアイデンティティを認証し、サービス呼び出しに応答し、サービス呼び出しをカウントすることができる。課金ＤＢは、無料、月ごとの課金、呼び出し回数での課金、および、フローレートによる課金など、様々な課金体系をサポートしうる。
【００２２】
図２に示すように、エンドユーザは、ログイン要求を開始し、ＩＳＶ  ＡＰＰは、その要求を分配する。ＡＰＩルートサーバは、ＩＳＰのＡＰＩサーバを呼び出し、ログイン要求を転送して、ＡＰＩサーバによって生成されたトークンを受信する。ＳＩＰのタイミングタスクサーバは、ログを収集して解析し、課金ＤＢで利用できるように解析結果を提供する。この例において、ＩＳＶ  ＡＰＰは、主に、ＩＳＰによって提供されるいくつかの基本的なインターフェースに従ってデータを取得するか、または、ユーザの要件を満たすアプリケーションを設計するために計算結果を取得する。
【００２３】
生成されたトークンは、実装においてアイデンティティトークンとも見なされる。ユーザがログインした時に、ＩＳＶシステムにおけるユーザのアイデンティティおよびＳＩＰにおけるアイデンティティは、関連づけられてよい。各要求において、ＩＳＶシステムでのユーザのアイデンティティは、ＳＩＰの生成済みアイデンティティトークンと関連づけられ、ＳＩＰは、トークンを有するＩＳＶアプリケーションのユーザを、ＩＳＰのユーザの関連情報を操作する権限を有するものとして見なす。
【００２４】
ＩＳＰおよびＩＳＶの間でデータを通信するためのキャリヤは、サービス統合プラットフォームシステムをＳＩＰに実装する際に提供されることが、上述の実施形態からわかる。プラットフォームシステムにおいて、ＩＳＰのリソースおよびサービスは、深く十分に統合されてよく、ＩＳＶが、サードパーティサービスにアクセスしたりソフトウェア統合プラットフォームに速やかにアクセスしたりする際に便利である。一方、ＳＩＰは、セキュリティ、課金、および、認証の包括的および統一的なポリシーをＩＳＰに提供する。ＩＳＰは、自身のサービスのリアルタイム監視、発行、テスト、および、ルーティングなどの管理機能をＳＩＰ内に揃えることができるため、その結果、より高い商業価値を実現できる。
【００２５】
テストサービス要求を開始した少なくとも１つのＩＳＶに関して、テストサービスの提供方法が提供され、その結果、アプリケーションがサービス統合プラットフォームシステムに基づいて開発される時に、テスト環境および配備環境の間のシームレスな連結が実現されうる。ここで、実施形態について説明する。
【００２６】
図３は、追加のテスト機能を提供するサービス統合プラットフォームシステムの別の実施形態を示すブロック図である。図３に示すように、認証モジュール１０１、ルーティングモジュール１０３、応答モジュール１０２など、上記のシステムが備える機能モジュールに加えて、ＩＳＶのテストアプリケーションのために、システムは、さらに、少なくとも１つのＩＳＶによって開始されたテストサービス要求の受信時にテストモジュールおよびテストルーティングモジュールをトリガするよう構成されたテスト要求受信モジュール３０１；テストサービス要求を開始したＩＳＶのシステムデバッグプロシージャをテストするよう構成されたテストモジュール３０２；ＩＳＶによって要求されたテストサービスを、アプリケーションインターフェーステストを実行するためのテストサービスを提供するＩＳＰまでルーティングするよう構成されたテストルーティングモジュール３０３を備える。
【００２７】
一部の実施形態において、ルーティングモジュール１０３は、さらに、テストサービスを提供するＩＳＰにおいてＩＳＶアプリケーションインターフェーステストが完了した後に処理を行うためのサービスを提供するＩＳＰまで、ＩＳＶのテスト済みのサービス要求をルーティングしてもよい。認証モジュール１０１は、さらに、テストサービス要求を開始したＩＳＶのアプリケーションインターフェーステストが完了した後に、テストモジュール３０２のシステムデバッグプロシージャのテスト結果に従って、ＩＳＶによって開始されたサービス要求を認証してもよい。
【００２８】
この例に示されたシステムは、さらに、各ＩＳＰのアプリケーションインターフェーステストアドレスおよびサービスアドレスを取得するよう構成されたルーティングアドレス取得モジュール３０４を備える。
【００２９】
テストルーティングモジュール３０３は、さらに、テストサービスを提供するＩＳＰのアプリケーションインターフェーステストアドレスまでテストサービスをルーティングするよう構成される。ルーティングモジュール１０３は、さらに、アプリケーションインターフェーステストの後に、サービスを提供するＩＳＰのサービスアドレスまで、ＩＳＶのテスト済みサービス要求をルーティングする。
【００３０】
一実施形態において、システムは、少なくとも１つのＩＳＶに各ＩＳＰのサービス記述文書を提供するよう構成されたサービス文書モジュール１１０を随意的に備える。サービス記述文書は、サービス関数呼び出し、サービス呼び出しおよびエラーコードの入力／出力に関する記述などの情報を含む。サービス記述文書は、ＩＳＶのための開発ガイドとして機能し、ＩＳＶは、記述に従い、アプリケーションを記述に適合させる。
【００３１】
サービス統合プラットフォームシステムは、２つの環境セット、すなわち、アプリケーション開発の際にＩＳＶが用いるテスト環境および配備環境、を提供する。ＩＳＶの開発においては、２つの開発環境の間の大きな差違が、間違いなくテストの有効性を低下させ、実際の環境が忠実にシミュレートされることができなくなり、公式なオンライン環境でのリスクが増大するため、２つの開発環境間には高い統一性が必要とされる。したがって、リリースされるテスト済みサービスに関して修正されるコンテンツの量を削減することにより、サービステスト開発の円滑な移行を実現するには、サービスのテストおよびリリースを行うシームレスなシステムが必要とされる。
【００３２】
ＩＳＰによって提供されたテスト環境および配備環境を含むサービス統合プラットフォームシステムが別個に配備された後に統合される場合、ＩＳＶのアプリケーション開発プロセスにおける関連サービスデータは、２つの異なる環境で互いに隔離され、ＩＳＶの開発コストが増大するだけでなく、重複したデータが必要になる。例えば、アイデンティティおよびアプリケーションプライベートキーなど、同様のアプリケーションのための固有データの２つのコピーが、テスト用、および、通常のアプリケーション用として必要になるため、開発者にとって開発コストおよびテストコストの増大になると共に、公式なオンライン配備でのリスクが増大する。
【００３３】
ＩＳＶのテスト環境および配備環境のサービスデータを共有し、データを繰り返し作成するコストを削減するために、同じサービスおよびシステムデータは、プロセスの開発およびプロセスのリリースの際にデータの統一性を確保して、データの変更によって生じるリスクを低減するように、同時にシミュレートされる。実際には、テスト環境および配備環境は、選択的なルートの間およびアプリケーション自体のハードウェアアドレスの間の差違によって区別されうる。特に、図４は、ＩＳＶ開発プロセスの一実施形態におけるテストおよびアプリケーションの実装フローチャートを示しており、フローは以下のような工程を備えうる。
【００３４】
４０１において、ＩＳＰは、公式アクセスのためのＵＲＩ（統一リソース識別子）と、テストアクセスのための別のＵＲＩとを含むサービス情報を登録する。例えば、ｓｉｐ．ａｌｉｓｏｆｔ．ｃｏｍ／ｓｉｐ／ｒｅｓｔというＵＲＩを、配備環境への公式アクセスのために利用し、ｓｉｐｄｅｖ．ａｌｉｓｏｆｔ．ｃｏｍ／ｓｉｐ／ｒｅｓｔというＵＲＩを、テスト環境へのテストアクセスのために利用する。
【００３５】
４０２において、ＩＳＶは、サービス統合プラットフォームシステムのテスト環境を介してアプリケーション登録を申請する。
【００３６】
４０３において、ＩＳＶは、サービス統合プラットフォームシステムによって提供されたＩＳＰサービス開発文書に従ってアプリケーションを開発し、テストを行うためにサービス統合プラットフォームシステムのテスト環境に加わる。
【００３７】
４０４において、ＩＳＶアプリケーションは、テストに向けて、サービス統合プラットフォームシステムを介してサービステスト用ＵＲＩまでルーティングされる。
【００３８】
４０５において、ＩＳＶアプリケーションは、テストおよび承認チェックをパスし、配備に向けてアプリケーションを公式にリリースするためにアプリケーションを提出する。
【００３９】
４０６において、ＩＳＶアプリケーションは、公式リリースを承認される。ＩＳＶは、サービス統合プラットフォームシステムの配備環境に切り替えて、アプリケーションを公式にリリースする。
【００４０】
上記のフローからわかるように、ＩＳＶは、テストプロセスにおいて配備環境を完全にシミュレートし、配備環境に切り替えるための追加コストはほとんど必要なく、サービス統合プラットフォームシステムによって要求されるアクセスアドレスだけが修正されるため、テスト環境におけるデータが最大限に利用され、配備環境への切り替えコストが最小化され、ＩＳＶ開発の複雑さおよびコストが削減され、データ変更によるアプリケーションのバグの出現可能性が低下する。
【００４１】
上記の実施形態のメカニズムは、サービス統合プラットフォームシステムが、実際のサービスを提供する配備環境に対応する配備用統一リソース識別子（ＵＲＩ）と、テストサービスへのアクセスを提供するテスト環境に対応する別個のテスト用ＵＲＩとを提供することである。サービス要求がテスト用ＵＲＩで受信された場合、ＩＳＶによるサービス要求は、テストに向けて、サービス統合プラットフォームシステムを通してサービステスト環境までルーティングされる。テストおよび承認チェックがうまく完了すると、ＩＳＶアプリケーションは、公式にアプリケーションをリリースするために、サービス統合プラットフォームシステムの配備環境にアクセスための配備用ＵＲＩの利用に切り替える。この場合、ＩＳＶによってなされたサービス要求は、配備環境の実際のサービスまでルーティングされて、処理される。
【００４２】
ＩＳＶのアプリケーション開発は、主に、システムプロシージャおよびアプリケーションインターフェースのデバックを含む。システムプロシージャのデバッグは、セキュリティ、課金などのプロセスを制御するプラットフォームをデバッグすることを含む。サービス統合プラットフォームシステムは、公式環境およびテスト環境の間で共有されるべきセキュリティに関連する認証構成を発行する。公式環境およびテスト環境の両方において同じデータがシステムプロシージャによって用いられるため、配備環境での正常動作を保証するのに、ＩＳＶは、開発プロセスでデバッグにパスするだけでよい。サービスインターフェースのデバッグに関して、正常なデータが戻されるか否かを判定するために、インターフェースサービスパラメータがシミュレートされる。例えば、テストサービス呼び出しｔａｏｂａｏ．ｕｓｅｒ．ｇｅｔは、特定のユーザ名を備えたユーザ名パラメータを必要とする。テストユーザ名「Ａｌｉｃｅ」を備えた呼び出しが、Ａｌｉｃｅの情報（ＸＭＬフォーマット）を戻すと、そのテスト呼び出しはパスする。しかし、エラーコードが戻された場合、テスト呼び出しは失敗する。ほとんどの場合、公開されるサービスはステートレスサービスであり、送信されるパラメータは、自己記述され自己完結していることが好ましいため、サービス呼び出しパラメータには共有データがない。したがって、開発およびテストプロセスにおいて、リリースされたデータの共有は、主に、プラットフォームレベルのデータで起こり、すなわち、システムデバッグプロシージャデータのみが共有され、サービスレベルのデータ（つまり、アプリケーションインターフェースデバッグデータ）は共有されない。このように、ＩＳＶのテスト環境および配備環境のサービスデータを共有することにより、データを繰り返し作成することが低減され、開発されたデータおよびリリースされたデータの間の統一性が維持される。
【００４３】
ＩＳＰに関しては、２つのアドレスにリンクされた環境は、それらが一貫している限りは、同じ１つの環境であってもよいし２つの別個の環境であってもよい。１つの環境が存在するか、２つの別個の環境が存在するかについては、ＩＳＰ自体によって決定される。ＩＳＰは、さらに、２つの環境間で、データを共有するか、データを隔離するかを決定してよい。ＩＳＰは、２つの環境のサービスインターフェースロジックが一貫していることを保証するだけでよい。
【００４４】
ＩＳＶに関して、テストプロセスにおいて、セキュリティ、課金、監視などのデバッグモードでのプラットフォームレベルの機能は、通常モードのものと同一であり、サービスインターフェースのデバッグの統一性が、２つの環境間のＩＳＰの一貫性によって確保され、それにより、ＩＳＶのテストプロセスにおいて配備環境を完全にシミュレートするという効果が実現される。もちろん、ＩＳＶアプリケーションは、適用性を保証するために、配備環境で用いられる前に、配備環境下でプレリリースすることによりテストされることが好ましい。
【００４５】
したがって、上述の解決法によれば、ＩＳＶアプリケーション開発のサービスデータは、最大限まで再利用され、データの差違によって引き起こされるアプリケーションオンラインリスクは低減され、テスト環境および配備環境のシームレスな連結が実現される。
【００４６】
図５は、インターネットサービスを提供するための方法の一実施形態を示すフローチャートである。プロセスは、ＡＰＩルートサーバなどのデバイスで実施されてよい。図５に示すように、方法は、以下の工程を備えてよい。
【００４７】
５０１において、ＩＳＶによって開始されたサービス要求が認証される。ＩＳＶが認証をパスできなかった場合、５０２において、認証失敗の指示が送信され、ＩＳＶはサービスを拒否される。サービス要求の認証が成功した場合、５０３において、サービス要求は、サービスを提供するＩＳＰまでルーティングされて、さらに処理される。
【００４８】
一部の実施形態において、方法は、さらに、作業ログを実装して解析する際に処理された認証、応答、および、ルーティング作業のログを記録する工程を備えてもよい。
【００４９】
作業ログの記録および解析の後、作業ログの解析結果に従って、監視および代金の計上を行うことが可能である。
【００５０】
ここで、各工程の特別な実装例について説明する。
【００５１】
５０１において、認証は、例えば、以下に挙げることの１または複数を認証することを含みうる：サービス要求を開始したＩＳＶのパラメータが正規のものか否か、サービスが存在するか否か、署名が必要か否か、権限があるか否か、署名が有効か否か、タイムスタンプが期限切れであるか否か、トークンが有効であるか否か、および、その他の検証テスト。
【００５２】
５０３において、ＩＳＶによって要求されたサービスを、処理に向けて、サービスを提供するＩＳＰまでルーティングする工程は、例えば、サービス要求を開始したＩＳＶによって要求されたサービスが、ＩＳＶのログインを要求するか否かを判定することを含みうる。イエスの場合には、ＩＳＶのサービス要求に従ってサービスを提供するＩＳＰへのログイン要求を開始して、ＩＳＰのプロセスに従ってトークンを生成し、ノーの場合には、ＩＳＶのサービス要求を、サービスを提供するＩＳＰに転送し、ＩＳＰのプロセスに従って応答を転送する。
【００５３】
図６は、サービス統合プラットフォームシステムの認証およびルーティングプロセスの一例を示すプロセス図である。プロセスは、例えば、ＡＰＩルートサーバ、ＡＰＩサーバ、または、それらを組み合わせたものに実装されてよい。
【００５４】
６０１において、ＩＳＶによって開始されたサービス要求が受信される。
【００５５】
６０２において、パラメータが正規のものか否かが判定される。イエスの場合、制御は６０３に移行され、ノーの場合、制御は６１０に移行される。
【００５６】
６０３において、サービスが存在するか否かが判定される。イエスの場合、制御は６０４に移行され、ノーの場合、制御は６１０に移行される。
【００５７】
６０４において、署名が必要か否かが判定される。イエスの場合、制御は６０５に移行され、ノーの場合、制御は６１２に移行される。
【００５８】
６０５において、権限があるか否かが判定される。イエスの場合、制御は６０６に移行され、ノーの場合、制御は６１０に移行される。
【００５９】
６０６において、署名が有効か否かが判定される。イエスの場合、制御は６０７に移行され、ノーの場合、制御は６１０に移行される。
【００６０】
６０７において、タイムスタンプが期限切れか否かが判定される。イエスの場合、制御は６０８に移行され、ノーの場合、制御は６１０に移行される。
【００６１】
６０８において、トークンが有効か否かが判定される。イエスの場合、制御は６０９に移行され、ノーの場合、制御は６１０に移行される。
【００６２】
６０９において、ログインが必要か否かが判定される。イエスの場合、制御は６１１に移行され、ノーの場合、制御は６１２に移行される。
【００６３】
６１０において、失敗の条件に対応して、ＩＳＶのサービス要求は拒否される。拒否を示す応答が生成される。
【００６４】
６１１において、ログイン要求がＩＳＶのサービス要求に従ってＩＳＰに対して開始される。
【００６５】
６１２において、ＩＳＶのサービス要求はＩＳＰに転送される。
【００６６】
ここで、ＩＳＶのアプリケーション開発プロセスの実装について説明する。
【００６７】
ＩＳＶのアプリケーション開発を実装するために、方法は、さらに、ＩＳＰのサービス記述文書をＩＳＶに提供する工程を含んでよい。
【００６８】
一部の実施形態において、ＩＳＰによって提供されたサンドボックスは、サンドボックスモジュールを介して互いにリンクされる。一部の実施形態において、テスト要求処理モジュールが、受信されたＩＳＶのテストサービス要求に従って、サンドボックスモジュールを介して、ＩＳＶのテストサービスをＩＳＰによって提供されたサンドボックスにリンクする。例えば、テスト用ＵＲＩでＨＴＴＰ要求を受信したサーバは、その要求にサービスする適切なサンドボックスモジュールにＨＴＴＰ要求を導く。
【００６９】
一部の実施形態において、ＩＳＰは、最初にサービス統合プラットフォームシステム上でアプリケーションを作成することを申請する。承認されると、サービス統合プラットフォームシステムは、アプリケーションアイデンティティおよびアプリケーション暗号化キーをＩＳＶに発行する。
【００７０】
次いで、ＩＳＶは、サービス文書モジュールによって提供されたサービス記述文書から各ＩＳＰのサービス記述文書を取得する。
【００７１】
サービス統合プラットフォームシステムは、ＩＳＶのサービスアクセスレベルに従って利用されるＩＳＰサービスを申請する。
【００７２】
アプリケーションの開発およびテストのプロセスにおいて、ＩＳＶは、サービス統合プラットフォームシステムのサンドボックス環境を介して、各ＩＳＰのサンドボックスにリンクされる。
【００７３】
テスト後、ＩＳＶは、アプリケーションをリリースして、アプリケーションオンライン要求をサービス統合プラットフォームシステムに送信してよい。
【００７４】
ここで、ＳＩＰにおける実装について説明する。図７は、ＳＩＰでのアプリケーション開発を示す概略図である。図７に示すように、方法は、以下のように実装されてよい。
【００７５】
７０１において、ＩＳＶは、申請したアプリケーションを登録する。
【００７６】
７０２において、ＳＩＰは、アプリケーションアイデンティティおよびアプリケーション暗号化キーを発行する。
【００７７】
７０３において、ＩＳＶは、アプリケーションを開発する。例えば、個々のユーザが自分の銀行口座にアクセスし、様々な取引関連の動作を行うことを可能にするために、インターネットバンキングアプリケーションが開発されてよい。アプリケーションは、バンキングサービスを提供するＩＳＰによる認証を必要とし、ユーザが銀行取引明細書の閲覧や送金などの特定のタスクを実行するためのユーザインターフェースを提供する。認証機能およびユーザインターフェースは、別個にテストされる。
【００７８】
７０４において、ＩＳＶは、ＩＳＰのサービス記述文書を取得する。
【００７９】
７０５において、ＩＳＶは、審査されるＡＰＩをカスタマイズする。一部のＡＰＩは、ＩＳＰによって審査および認可されて始めて、ＩＳＶによって利用されることができる。例えば、データ解析のための特定のＡＰＩは、ＩＳＶがデータ解析サービスを契約した場合にのみ、アクセス可能になる。
【００８０】
７０６において、ＳＩＰは、ＩＳＰに審査を依頼する。
【００８１】
７０７において、ＩＳＰは、事前に承認されたＡＰＩリストの検討および／またはＩＳＶとのサービス契約の検討などによって審査を実行し、ＩＳＶがＡＰＩを用いることを許可されているか否かを判定する。
【００８２】
７０８において、ＳＩＰは、審査の通過後に審査結果を記録する。
【００８３】
７０９において、ＩＳＶはアプリケーションをテストする。
【００８４】
７１０において、ＩＳＶはアプリケーションをリリースする。
【００８５】
７１１において、ＳＩＰは、アプリケーションを審査し、オンラインに置く。
【００８６】
上記の解決法に従ってアプリケーションが開発された後、サービス統合プラットフォームシステムは、迅速なアクセスおよび配信のサービスをＩＳＶに提供しうるため、サービスの統合および管理を単純化し、セキュリティ、課金、および、認証の共通ポリシーを提供できる。さらに、この単純な標準化されたアクセス解決法は、Ｊａｖａ（登録商標）、．ＮＥＴ、および、ＰＨＰのような異種のシステムに、統一的なサンドボックステスト環境を提供する。
【００８７】
テストサービス要求を開始する少なくとも１つのＩＳＶに対して、テストサービスを提供するための本明細書に記載の技術は、ＩＳＶがアプリケーションを開発する時に、テスト環境および配備環境のシームレスな連結を実現することができる。ここで、詳細な実装方法について説明する。
【００８８】
少なくとも１つのＩＳＶによって開始されたテストサービス要求の受信後に、テストサービス要求を開始したＩＳＶのシステムデバッグプロシージャがテストされ、ＩＳＶによって要求されたテストサービスは、アプリケーションインターフェーステストを実行するためのテストサービスを提供するＩＳＰまでルーティングされる。
【００８９】
さらに、テスト終了後にプロシージャを処理するために、方法は、テストサービスを提供するＩＳＰにおいてＩＳＶのアプリケーションインターフェーステストが完了した後に、処理を行うためのサービスを提供するＩＳＰまで、ＩＳＶのテスト済みのサービス要求をルーティングする工程を備えてよい。
【００９０】
一部の実施形態において、方法は、さらに、ＩＳＶアプリケーションインターフェーステストが完了した後に、システムデバッグプロシージャのテスト結果に従って、ＩＳＶによって開始されたサービス要求を認証する工程を備える。
【００９１】
一部の実施形態において、方法は、さらに、各ＩＳＰのアプリケーションインターフェーステストアドレスおよびサービスアドレスを取得する工程と、テストサービスを提供するＩＳＰのアプリケーションインターフェーステストアドレスまでテストサービスをルーティングする工程と、アプリケーションインターフェーステストが完了した後に、サービスを提供するＩＳＰのサービスアドレスまで、ＩＳＶのテスト済みのサービス要求をルーティングする工程とを備える。
【００９２】
上記の説明からわかるように、複数のＩＳＰのサービスの統合およびルーティングが、サービス統合プラットフォームシステムによって解決される結果として、ＩＳＰは、セキュリティ、課金、および、認証など、事業以外の機能要件を考慮することなく、サービスの提供に集中することができる。さらに、ＩＳＶにとっては、複数のＩＳＰのサービスを学習してアクセスする困難が効果的に低減されるため、ＩＳＶの開発プロセスが単純化される。
【００９３】
ＩＳＰに関しては、新たなタイプのＩＳＰの出現がサポートされる。このタイプのＩＳＰは、基本的なサービスプロバイダのサービスに基づいて再開発および再パッケージを行い、開発したサービスをサービス統合プラットフォームシステムにリリースしうる。
【００９４】
ＩＳＶに関しては、サービス統合プラットフォームシステムは、開発者向けのオープンＡＰＩコミュニティに、基本的なサービスアクセス／管理プラットフォームを提供するため、ＩＳＶおよび個人の開発者は、システムにおける自身のアプリケーションシーンに従って、ＩＳＰによって提供されるＡＰＩを検索、研究、起動、および、テストすることができる。
【００９５】
したがって、サービス統合プラットフォームシステムは、ＩＳＰをデータサービス設計に集中させるだけではなく、ＩＳＶをアプリケーション／製品の開発に集中させることができる。ＩＳＰおよびＩＳＶアプリケーションは、オープンで協調的かつ統一的な環境でサービスによって柔軟かつ効果的に結びつけられることができるため、エコスフィア全体の社会的価値を拡張する。さらに、インターネットサービスは、大規模なＩＳＰに加えて中規模または小規模なＩＳＰがさらに加わるため、実際に、豊富なリソースプールになる。
【００９６】
さらに、システムデバッグプロシージャおよびアプリケーションインターフェースの２つの部分のテストは、別個に処理される、すなわち、サービス統合プラットフォームシステムは、システムデバッグプロシージャに関するテストを処理して、この部分のデータを共有し、ＩＳＰは、アプリケーションインターフェースのテストを処理し、それにより、最小のコストで配備環境に切り替え、ＩＳＶの開発の複雑さおよびコストを削減し、データ変更によるアプリケーションのバグの出現可能性を低減する。
【００９７】
もちろん、当業者は、本発明の精神および範囲から逸脱することなく、本発明に様々な変更および変形を施すことができる。したがって、本発明に対するこれらの変更例および変形例が、本発明およびその等価物の請求の範囲に属している場合には、本発明は、これらの変更例および変形例を含むものである。
【００９８】
上述の実施形態は、理解しやすいように少し詳しく説明されているが、本発明は、提供された詳細事項に限定されるものではない。本発明を実施する多くの代替方法が存在する。開示された実施形態は、例示であり、限定を意図するものではない。
適用例１：サービス統合プラットフォームシステムであって、独立系ソフトウェアベンダー（ＩＳＶ）によって開始されたサービス要求を受信するよう構成されたインターフェースと、前記サービス要求を認証すると共に、前記サービス要求が認証された場合に、さらなる処理のために前記サービス要求を、サービスを提供するインターネットサービスプロバイダ（ＩＳＰ）までルーティングするよう構成された１または複数のプロセッサと、を備え、前記サービス要求は、前記サービス要求が、前記ＩＳＰによって提供された配備環境に対応する配備用統一リソース識別子（ＵＲＩ）で受信された場合には、前記配備環境までルーティングされ、前記サービス要求は、前記サービス要求が、前記ＩＳＰによって提供されたテスト環境に対応するテスト用ＵＲＩで受信された場合には、前記テスト環境までルーティングされる、システム。
適用例２：適用例１に記載のシステムであって、前記認証は、前記サービス要求を開始した前記ＩＳＶのパラメータが正規のものか否か、前記サービスが存在するか否か、署名が必要か否か、権限があるか否か、前記署名が有効か否か、タイムスタンプが期限切れであるか否か、トークンが有効であるか否か、の内の１または複数を認証することを含む、システム。
適用例３：適用例１に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記サービスを開始した前記ＩＳＶによって要求されたサービスが、前記ＩＳＰへのログインを必要とすることを決定し、前記ＩＳＰへのログイン要求を開始し、前記ＩＳＰの処理に従ってトークンを生成し、前記ＩＳＶの前記サービス要求を前記ＩＳＰに転送するよう構成されている、システム。
適用例４：適用例１に記載のシステムであって、前記１または複数のプロセッサは、さらに、認証およびルーティングに関連する作業のログを記録するよう構成されている、システム。
適用例５：適用例４に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記ログを解析するよう構成されている、システム。
適用例６：適用例５に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記ログの解析結果に従ってシステムアクセスを監視するよう構成されている、システム。
適用例７：適用例５に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記ログの解析結果に従って代金を計上するよう構成されている、システム。
適用例８：適用例１に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記ＩＳＰによって提供されたサンドボックスを前記ＩＳＶのテストサービスにリンクするよう構成されている、システム。
適用例９：適用例１に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記サービス要求が前記テスト環境までルーティングされた場合に、システムデバッグプロシージャをテストするよう構成されている、システム。
適用例１０：適用例９に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記システムデバッグプロシージャのテスト結果に従って、前記ＩＳＶによって開始された前記サービス要求を認証するよう構成されている、システム。
適用例１１：適用例１に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記サービス要求が前記テスト環境までルーティングされた場合に、アプリケーションインターフェースをテストするよう構成されている、システム。
適用例１２：適用例１に記載のシステムであって、前記１または複数のプロセッサは、さらに、各ＩＳＰのアプリケーションインターフェーステストアドレスおよびサービスアドレスを取得し、前記サービス要求が前記テスト用ＵＲＩで受信された場合に前記サービス要求を前記アプリケーションインターフェーステストアドレスまでルーティングするよう構成されている、システム。
適用例１３：適用例１に記載のシステムであって、前記１または複数のプロセッサは、さらに、各ＩＳＰのサービス記述文書を少なくとも１つのＩＳＶに提供するよう構成されている、システム。
適用例１４：インターネットサービスを提供するための方法であって、独立系ソフトウェアベンダー（ＩＳＶ）によって開始されたサービス要求を受信し、前記サービス要求を認証し、前記サービス要求が認証された場合に、さらなる処理のために前記サービス要求を、サービスを提供するインターネットサービスプロバイダ（ＩＳＰ）までルーティングすること、を備え、前記サービス要求は、前記サービス要求が、前記ＩＳＰによって提供された配備環境に対応する配備用統一リソース識別子（ＵＲＩ）で受信された場合には、前記配備環境までルーティングされ、前記サービス要求は、前記サービス要求が、前記ＩＳＰによって提供されたテスト環境に対応するテスト用ＵＲＩで受信された場合には、前記テスト環境までルーティングされる、方法。
適用例１５：適用例１４に記載の方法であって、前記認証は、前記サービス要求を開始した前記ＩＳＶのパラメータが正規のものか否か、前記サービスが存在するか否か、署名が必要か否か、権限があるか否か、前記署名が有効か否か、タイムスタンプが期限切れであるか否か、トークンが有効であるか否か、の内の１または複数の認証を含む、方法。
適用例１６：適用例１４に記載の方法であって、さらに、前記サービスを開始した前記ＩＳＶによって要求されたサービスが、前記ＩＳＰへのログインを必要とすることを決定し、前記ＩＳＰへのログイン要求を開始し、前記ＩＳＰの処理に従ってトークンを生成し、前記ＩＳＶの前記サービス要求を前記ＩＳＰに転送すること、を備える、方法。
適用例１７：適用例１６に記載の方法であって、さらに、認証およびルーティングに関連するログを記録することを備える、方法。
適用例１８：適用例１７に記載の方法であって、さらに、前記ログを解析することを備える、方法。
適用例１９：適用例１８に記載の方法であって、さらに、前記ログの解析結果に従ってシステムアクセスを監視することを備える、方法。
適用例２０：適用例１８に記載の方法であって、さらに、前記ログの解析結果に従って代金を計上することを備える、方法。
適用例２１：適用例１４に記載の方法であって、さらに、前記ＩＳＰによって提供されたサンドボックスを前記ＩＳＶのテストサービスにリンクすることを備える、方法。
適用例２２：適用例１４に記載の方法であって、さらに、前記サービス要求が前記テスト環境までルーティングされた場合に、システムデバッグプロシージャのテストをトリガすることを備える、方法。
適用例２３：適用例２２に記載のシステムであって、さらに、前記システムデバッグプロシージャのテスト結果に従って、前記ＩＳＶによって開始された前記サービス要求を認証することを備える、システム。
適用例２４：適用例１４に記載の方法であって、さらに、前記サービス要求が前記テスト環境までルーティングされた場合に、アプリケーションインターフェースをテストすることを備える、方法。
適用例２５：適用例１４に記載の方法であって、さらに、各ＩＳＰのアプリケーションインターフェーステストアドレスおよびサービスアドレスを取得し、前記サービス要求が前記テスト用ＵＲＩで受信された場合に前記サービス要求を前記アプリケーションインターフェーステストアドレスまでルーティングすること、を備える、方法。
適用例２６：適用例１４に記載の方法であって、さらに、各ＩＳＰのサービス記述文書を少なくとも１つのＩＳＶに提供することを備える、方法。
適用例２７：サービス統合プラットフォームシステムであって、独立系ソフトウェアベンダー（ＩＳＶ）によって開始されたサービス要求を受信するよう構成されたインターフェースと、前記サービス要求を認証するよう構成された認証モジュールと、前記サービス要求が認証された場合に、さらなる処理に向けて前記サービス要求を、サービスを提供するインターネットサービスプロバイダ（ＩＳＰ）までルーティングするよう構成されたルーティングモジュールと、を備え、前記サービス要求は、前記サービス要求が、前記ＩＳＰによって提供された配備環境に対応する配備用統一リソース識別子（ＵＲＩ）で受信された場合には、前記配備環境までルーティングされ、前記サービス要求は、前記サービス要求が、前記ＩＳＰによって提供されたテスト環境に対応するテスト用ＵＲＩで受信された場合には、前記テスト環境までルーティングされる、システム。
【図１】
0005502861.tif 000002
【図２】
0005502861.tif 000003
【図３】
0005502861.tif 000004
【図４】
0005502861.tif 000005
【図５】
0005502861.tif 000006
【図６】
0005502861.tif 000007
【図７】
0005502861.tif 000008