JP2009501386A - 動的なアプリケーションの利用情報の分散取得および集約 - Google Patents

Abstract

【課題】
【解決手段】アプリケーションの開発者が、オンラインによりアプリケーションの利用情報分析を生成し、管理し、監視するウェブベースのホスト型ソリューションである。試験中のアプリケーションは、アプリケーションソフトウェア、スクリプトに対応したウェブアプリケーション、あるいはリッチインターネットアプリケーション（ＲＩＡ）のうちの１つである。開発工程において、利用監視ＡＰＩがアプリケーションに組み込まれ、アプリケーションが展開される。ユーザがアプリケーションと操作すると、ログファイルが、通常２つの方法のうちの一方により生成される。アプリケーションが（ユーザマシンの）ローカルファイルシステムに書き込みできる場合、利用情報が、展開されたアプリケーション近くのログファイルに集められ、バッチ処理を行うアップロードサーバに送信される。アプリケーションがユーザマシンのローカルファイルシステムに書き込みできない場合、利用情報が、好適にはジャストインタイムでリモートロギングサーバに送信され、ログファイルがロギングサーバに集められる。いずれの場合でも、追跡される利用情報が、展開されたアプリケーションインスタンスのプラットフォーム、位置、および数に拘わらず、アプリケーションの「機能」、「失敗」、および「誤り」を備えていることが好ましい。
【選択図】図２

Description

本願は、著作権の保護対象が含まれている。

本願は、２００５年７月１２日に出願された第６０／６９８，５６７に基づいており、これの優先権を主張する。

本発明は一般に、ソフトウェアのモニタリング、トラッキング、および投資回収率（ＲＯＩ）分析に関する。

関連技術の説明
強力なトレンドにより、ソフトウェア業界で用いられている方法およびソフトウェア開発方法が新たに作られている。最も大きなトレンドは、ほぼ間違いなく、情報技術（ＩＴ）をビジネスとして用いるトレンドである。米国商務省は、総ての設備投資のうちの５０％がＩＴおよびソフトウェアに使われていると判断している。公表されている研究によると、生産性およびＲＯＩに関する測定基準が欠如しており、ソフトウェア開発プロセスにおいては、開発者が、ユーザおよび顧客から簡単にフィードバックを集める能力が欠如しているため、設備投資の大部分が無駄になっている。このようなフィードバックが無いと、開発者および製品の管理者は、アプリケーションのいずれの機能が最も人気であり、ソフトが使用されたときにいずれの機能が最も問題であるかなどについて判断できない。このため、開発資源をどこに適切に割り当て、活用すべきか判断することは一定していない。ソフトウェア開発およびテスト作業は世界中に分散しているため、この問題は悪化している。かつては、開発者およびＩＴ管理者が、推測−見積り、ユーザ調査、およびフォーカスグループを含む様々な技術を用いて、アプリケーションの利用情報を確認および評価していたが、このような技術は通常、顧客基盤の小さなサンプルのみを示しており、また、これらのサンプルには、不正確および時機を失したデータがよく含まれている。

従来技術では、コンピュータネットワークにおけるエラー、トレース、オーディット、および他の情報を収集および蓄積する方法およびシステムが提供されていることが知られている。代表的な例は、Ｎｉｅｍｉ等に付与された米国特許第６，４７０，３８８である。この特許では、ネットワークの様々なエンティティあるいはホストで動作する選択されたアプリケーションあるいはプロセスが、所定の情報を収集する１以上の「デバッグ」オブジェクトのインスタンスを作成する。また、各エンティティは、アプリケーションあるいはプロセスと通信する少なくとも１のロギングサービス層を備えており、通信資源と、１以上の状態機械エンジンとを備えている。エラー、トレース、オーディット、あるいは他の情報を収集するのに応じて、デバッグオブジェクトそれぞれが、これらの情報を個別のロギングサービス層に送り、これが、ネットワークに配置された中央ロギング装置にデータを送るか判断する。収集された情報の送信は、デバッグオブジェクトの状態に依存する。中央ロギング装置では、これらの情報に時刻情報が付され、アプリケーションの名称と当該アプリケーションが動作しているエンティティあるいはホストの名称と共に、ログファイルに追加される。

別の代表的な特許は、Ｈａｌｌ等に付与された米国特許第６，５９１，２２８である。この特許では、ロギングサービスが、複数のマインフレームがデータストレージ領域に関連付けられたコンピュータ環境で動作するアプリケーションから、中央ログ分析メッセージにログを送信する。各メインフレームは、アプリケーションを実行する１以上のサブシステムを備えている。ロギングサービスＡＰＩが、問題の種類に応じて分析メッセージをデータストレージに書き込み、警告装置に連絡する。

通常、前述したアプリケーションのロギング技術は有用であるが、これらの技術は、比較的数の少ない追跡システムを利用して同様のコンピュータ環境において利用され、比較的制約のある情報を収集する。本分野において、プラットホーム、展開されたアプリケーションインスタンスの位置および数、特にソフトウェア開発プロセスの状況に依存せずに、アプリケーションの利用情報を追跡する方法およびシステムがを提供する必要性がある。

本発明はこれらの技術的な必要に取り組む。

本発明は、技術を最適化するために、特にソフトウェア開発工程において、事業価値分析を送達するソフトウェアプラットフォームである。通常、本発明では、トラッキングプラットフォームが、アプリケーションの利用情報を監視、収集、および集めるホスト型（あるいは管理）サーバとして動作する。試験中のアプリケーションは、エンドユーザのクライアントマシンなどの一組の展開されたマシンにおいて実行されると仮定する。アプリケーションは、利用情報を収集するように構成され、ある実施例では、この利用情報は中央位置に確実に伝送され、ここで、この利用情報が集められ、エクスポートされ、表示される。アプリケーションの詳細な利用情報を収集および測定することにより、本サービスは、ソフトウェア開発者が、より効率的に高性能のソフトウェアアプリケーションを構築するのを手助けする。本システムは、ウェブインタフェースをエクスポートし、利用者が、従来の技術（ウェブブラウザおよびネットワーク接続性を有するコンピュータ）および標準的な通信技術（ＨＴＴＰ、セキュアＨＴＴＰ、ＳＯＡＰに基づくウェブサービス等）を利用することにより、インターネットを介して本システムとやり取りできることが好ましい。代替的に、本システムは、プライベートネットワーク等を介したエクストラネットとして実施してもよい。所定のエンティティは、トランザクションに基づいてサービスにアクセスすることを選択してもよいが、エンティティは、定期的にホスト型ソリューションにアクセスするのが好ましい。

本発明のより特有の態様では、試験中のアプリケーションは、ウェブアプリケーション、あるいはリッチインターネットアプリケーション（ＲＩＡ）のいずれかである。開発工程では、ＡＰＩを監視する処理がアプリケーションに組み込まれ、このアプリケーションが展開される。ユーザがアプリケーションを操作すると、ログファイルが、通常２つの方法のうち１つの方法により生成される。アプリケーションが（ユーザのマシンの）ローカルファイルシステムに書き込みできる場合、利用情報が、展開されたアプリケーション近くのログファイルに集められ、次に、バッチ処理を行うアップロードサーバに送信される。アプリケーションが、（例えば、ウェブアプリケーションあるいはＲＩＡであるために）ユーザマシンのローカルファイルシステムに書き込みできない場合、利用情報が、好適にはジャストインタイムでリモートロギングサーバに送信され、ログファイルが、ロギングサーバ上で生成される。いずれの場合でも、追跡される利用情報は、プラットフォーム、位置、展開されたアプリケーションインスタンスの数に拘わらず、「機能」、「失敗」、および「誤り」を含んでいる。ここで使用されているように、「機能」データは通常、いずれの機能が使用されたのか、いつ使用されたのか、どの順序で使用されたのか、誰によって使用したのか、どのようなプラットホームで使用されたのか、どのようなエンドユーザ環境で使用されたのかなどの情報を示す。「失敗」データは通常、いずれの機能にプログラムエラー（例えば、例外）が生じているかを示す。「誤り」データは、例えば、データが誤った形式のフィールドに入力された場合に、いずれの機能が正しく終了しなかったかを特定する。

本発明のさらなる特徴によると、利用情報、あるいはより一般的にログファイルは、（好適には従来のＨＴＴＰトランスポートを利用して）非常に圧縮された状態で転送され、軽量な処理要求による高性能な分散型システムを可能にする。

前述の説明は、本発明のより関連のある特徴の概略である。これらの特徴は、単に説明の目的であると解すべきである。以下に説明するように、開示された本発明を異なる方法で使用し、あるいは本発明を修正することにより、他の多くの有利な効果を奏することができる。

図１は、代表的なサービスプロバイダあるいはシステムアーキテクチャを示しており、これは、好適な実施例では１以上のデータセンタで実施される。通常、データセンタは、インターネットに接続されている。ある実施例では、このシステムは、ウェブベースのホスト型ソリューションを提供し、これを用いて、アプリケーションの開発者（あるいはＩＴ担当者など）は、オンラインでアプリケーションの利用の分析を生成、管理、および監視する。関係者は、ホスト型サービスなどのプラットホームにより交信することが好適である。代替的な実施例では、このシステムをプライベートネットワークで実施してもよく、あるいは（ホスト型あるいは管理サーバとは対照的に）製品として実施してもよい。

サービスのユーザは、ワークステーションあるいはノート型コンピュータなどのインターネットにアクセス可能なマシンを保有している。通常、ユーザは、マシン上のウェブブラウザを開いて、サービスプロバイダのドメインあるいはサブドメインに関連するＵＲＬにより、サービスプロバイダアーキテクチャにアクセスする。次に、ユーザは、通常の方法、例えばユーザ名およびパスワードの入力により管理サーバを認証する。例えばＳＳＬ等により、マシンとサービスプロバイダのインフラストラクチャとの通信を暗号化し、あるいは安全性を高めてもよい。公のインターネットを介した接続が通常であるが、ユーザは、ローカルエリアネットワーク、広域ネットワーク、無線ネットワーク、有線ネットワーク、プライベートネットワーク、あるいは他の専用ネットワークを介して、サービスプロバイダのインフラストラクチャに接続してもよい。図１に示すように、サービスプロバイダアーキテクチャ１００は、ＩＰスイッチ１０２と、１以上のウェブサーバマシン１０４のセットと、１以上のアプリケーションサーバマシーン１０６のセットと、データベースマネージメントシステム１０８と、１以上の管理サーバマシン１１０のセットとを備えている。典型的なウェブサーバマシン１０４は、（例えば、Ｉｎｔｅｌベースの）有用なハードウェアと、Ｌｉｎｕｘなどのオペレーティングシステムと、Ａｐａｃｈ２．ｘなどのウェブサーバとを備えている。典型的なアプリケーションサーバマシン１０６は、有用なハードウェアと、Ｌｉｎｕｘと、アプリケーションサーバとを備えている。データベースマネージメントシステム１０８は、Ｏｒａｃｌｅのデータベースマネージメントパッケージのように実装される。使用価値の高い環境では、いくつかのサーバマシン、いくつかのアプリケーションサーバマシン、および多数の管理サーバマシンが存在する。詳しく示していないが、インフラストラクチャは、ネームサーバと、他の負荷平衡装置と、他のスイッチと、ストレージに接続されたネットワーク等とを備えてもよい。このシステムは通常、第三者のデータベースなどの外部のデータ資源との接続手段を備えている。システムの各マシンは通常、十分なディスクと、メモリと、入出力装置とを備えている。通常、ウェブサーバ１０４は、リクエストを提供する新たに入るビジネスエンティティを処理し、
以下により詳細に説明および図示するディスプレイインタフェースをエクスポートする。アプリケーションサーバ１０６は、データを管理し、プラットフォームの機能を強化する。管理サーバ１１０は、最終段階の計算および報告機能を担う。ここに説明する特定のハードウェアおよびソフトウェアの実施例は、説明のために記されているのであり、本発明の範囲を限定するものではない。

図２は、ロギングサービスの基本的な処理を示している。本実施例では、アプリケーションインスタンス２００ａおよび２００ｂが、本発明の利用監視ＡＰＩにより実現されている。利用監視ＡＰＩは、時々リモートノードと称される。したがって、アプリケーションインスタンス２００ａはリモートノード２０２ａに関連し、アプリケーションインスタンス２００ｂは、リモートノード２０２ｂに関連する。もちろん、２つのインスタンスを使用しているのは説明のためであり、本発明は、拡張性の高い分散型ロギングサービスを提供し、多数の展開されたアプリケーションのインスタンスが備えられ、追跡される。動作中は、リモートノード２０２ａが利用データセット２０４ａを生成し、リモートノード２０２ｂが利用データセット２０４ｂを生成する。この利用データは、非常に効率的な方法（以下に詳細に説明する）により中央サーバ（あるいは一組のサーバ）に送信され、データセットが集められ（２０６を参照）、分析および報告エンジン２０８で処理される。

本発明はソフトウェア開発およびテストの現場において有用であるが、当業者であれば、本発明は、これらの用途に限定されてないことは理解できるであろう。図３は、典型的なビジネスの例を示している。この例では、ウェブアプリケーションの開発者３００が、開発中にウェブアプリケーションあるいはリッチインターネットアプリケーションに利用監視ＡＰＩを追加する。このように開発されたアプリケーションは、ウェブサイトあるいは他の公開サーバ３０２が利用できるように作られている。エンドユーザ３０４が、サイトを操作し、ダウンロードし、アプリケーションを操作し、利用データを生成する。このデータは、ロギングサーバ３０６に送信され、ホスト型サービスデータベース３０８にアップロードされる。管理者３１０（あるいは開発者３００）は、ホスト型サービスウェブサイト３１２にログインでき、記録されたデータにアクセスできる。

図４は、ホスト型サーバの動作をより詳細に示している。この例では、多数のユーザ４００ａ乃至４００ｎが、アプリケーションを使用し、ロギングサーバ４０２に供給される利用データセットを生成する。ロギングサーバ４０２は、１以上のサーバを備えている。ロギングサーバ４０２は、ファイヤウォール４１０を介してアプリケーションサーバ４０４に定期的にデータセットをアップロードし、アプリケーションサーバは、処理されたデータをデータベース４０６に格納する。ホスト型サーバのユーザ４０５は、サーバ４１２を介してサービスにログインし、ファイヤウォール４１０を介して利用データにアクセスするサーバ４１４により利用報告を閲覧する。

試験用のアプリケーションは、（Ｊａｖａ、．Ｎｅｔ、Ｃ＋＋、Ｃ＃などの）アプリケーションソフトウェア、（Ｊａｖａｓｃｒｉｐｔ、ＡｃｔｉｏｎＳｃｒｉｐｔ等を含むウェブページなどの）スクリプトを使用したウェブアプリケーション、あるいは（例えば、Ｆｌａｓｈ、ＡＪＡＸ等を使用した）リッチインターネットアプリケーション（ＲＩＡ）のうちのいずれかである。開発プロセスにおいて、利用監視ＡＰＩがアプリケーションに組み込まれ、アプリケーションが展開される。ユーザがアプリケーションを操作すると、通常は２つの方法のうちの１の方法でログファイルが生成される。アプリケーションが、（ユーザのマシンの）ローカルファイルシステムに書き込める場合、利用データは、展開されたアプリケーションの近くのログファイルに集められ、バッチ処理を行うアップロードサーバに送出される。アプリケーションが、（例えば、ウェブアプリケーションあるいはＲＩＡであるために）ユーザマシンのローカルファイルシステムに書き込むことができない場合、利用情報は、好適にはジャストインタイムでリモートロギングサーバに送信され、ログファイルがロギングサーバに生成される。これは、ウェブブラウザによるロギングに用いられる技術である。このようなロギングは、データをｈｔｔｐのＵＲＬパラメータを介してロギングサーバに送信し、データをログファイルに変換することにより行われる。いずれの場合でも、追跡される利用データは、展開されたアプリケーションのプラットホーム、位置、数に拘わらず、アプリケーションの「機能」、「失敗」、および「誤り」を含んでいる。前述したように、「機能」データは通常、いずれの機能が使用されたのか、いつ使用されたのか、どの順序で使用されたのか、誰によって使用したのか、どのようなプラットホームで使用されたのか、どのようなエンドユーザ環境で使用されたのかなどの情報を示す。通常、機能はエンドユーザに提示される。「失敗」データは通常、いずれの機能にプログラムエラー（例えば、例外）が生じているかを示す。「誤り」データは、例えば、データが誤った形式のフィールドに入力された場合に、いずれの機能が正しく終了しなかったかを特定する。

このように、本発明の説明した使用によると、ホスト型サービスのユーザは、開発中のトラッキングモジュールを有するアプリケーションを使用し、予備的な顧客および予備的なテストの進行を理解する。前述したように、「トラッキングモジュール」は、追跡されるソフトウェアアプリケーションに埋め込まれている（あるいは関連付けられている）ことが好ましい。利用データは、軽量な独自の方法により集約および報告サーバに送信される。

以下の説明により、アプリケーションがログファイルをエンドユーザのマシンのローカルファイルシステムに書き込む実施例の詳細をさらに示す。この実施例では、ホスト型サービスプラットホームは、ここに示す多くの構成要素を介してエンドユーザからデータを収集する。第１の構成要素はリモートノードであり、これが、機能の追跡および構成情報を収集する。第２の構成要素はサーバであり、これが、リモートノードの結果を取得し、当該結果を他のリモートノードから収集したデータと結合させる。これらの２つの構成要素により、本発明のユーザが、同時に存在する多くのノードから機能の追跡および構成情報を収集できる。また、リモートノードには、３つの重要な目的がある。第１の目的は、統合の容易性である。第２の目的は、素早い動作である。第３の目的は、情報の転送が早く、アプリケーションの通常の実行に付随して起こることである。統合は、機能毎に追加される一行のコードのみを要求することにより行われることが好ましい。第２の目的は、この一行によりアプリケーションが速く動作することにより達成され、機能を１回呼び出すのに数ミリ秒のオーバーヘッドがアプリケーションに発生する。第３の目的は、最悪の状況でもファイルが常に小さくなるようにするログファイルの形式により達成され、これにより、データ転送時間が非常に短くなり、ＣＰＵの利用を抑え、したがって、転送が行われている間、ユーザのアプリケーションのパフォーマンスが低下することを防ぐ。以下に、リモートサーバとその部分について説明し、次に、関連するサーバ構成要素について説明する。

リモートノードは、所定のアプリケーションの１の例についての機能の追跡および構成情報を収集する。リモートノードは、ユーザが定義したときにサーバの構成要素に接続しようとし、一連のログファイルを送信する。リモート構成要素は、この情報を収集および転送するいくつかのサブ構成要素に依存する。これらの構成要素は、ユーザが特定の実行タスクを実行することを必要とする。以下の表１は、各構成要素について説明している。

表１

これらの構成要素を以下に説明する。初めに、代表的な実施例におけるリモートノードとサーバとの間のデータフローを以下に説明する。次に、ユーザが機能の追跡情報を収集するために、これらの構成要素をアプリケーションと統合する処理について説明する。

データはリモートノードからサーバに単一方向に流れ、サーバからリモートノードへの交信は行われない。図５は、代表的な処理フローを示している。データを転送する処理は直接的である。リモートノードは、ディスパッチイベント５００を待ち、これにより、リモートノードは、ユーザが決めたＵＲＬに接続する。ステップ５０２では、リモートノードがロギングサーバに接続を試みる。ステップ５０４の評価により、リモートノードがサーバに接続できるか判断する。接続可能な場合、リモートノードは、好適にはＵＲＬにより特定されるＨＴＭＬページのＨＴＭＬフォームにログファイルを合わせることにより、総てのログファイルを送信する。次に、リモートノードは、ログファイルが正常に送信されたことを検知するのが好適である。さらに、リモートノードは、サーバとの接続ができなかった場合に、ユーザが決めた日数のログファイルを格納するのが好ましい。また、リモートノードは、ディスパッチイベントが失敗した後に、各ログの日付をチェックするのが好適である。次に、リモートノードは、最大の日数よりも古いファイルを検出する。

本発明では、サーバ側は、単にファイルを転送するＨＴＭＬフォームを使用し、図８に示すコードの一部に示すように動作する。リモートノードは、ＨＴＭＬページを解析し、アップロードフォームを見つけ、ファイルフィールを設定し、情報を送信する。フォームを見つけるステップは、入手したファイルを拒否するフォームによりシステムが勝手にファイルアップロードすることがないようにする。ログファイルを取得すると、サーバは、取得したログファイルをインポートディレクトリに書き込む。サーバのインポート構成要素は、このディレクトリを定期的にスキャンするのが好適である。インポート構成要素は、新しいログファイルを開き、データをデータベースに追加する。

ファイルアップロードフォームを入手すべく、ロギングサーバの２つの構成があるのが好ましい。図６は、これらの構成の処理フローを示している。第１の構成（タイプＡ）が、図の上側に示されている。この構成では、サーバは、利用可能なフォームを生成し、リモートノードの接続を待つ。これはステップ６００である。ステップ６０２では、リモートノードが接続しようとしているか判断する。接続されると、サーバは、ステップ６０４でログファイルを受け取り、ステップ６０６でログファイルをインポートディレクトリに書き込む。ステップ６０８では、新しいログファイルがサービスデータベースにインポートされる。ステップ６１０では、データベースがアップデートされ、この後、ステップ６１２でログファイルが削除される。次に、サーバは、別のアップロードを待ち状態を返却する。第２の構成（タイプＢ）は通常、企業のウェブサイトの非武装地帯（ＤＭＺ）に設置されたロギングサーバに実装される。この実施例では、任意のＨＴＴＰサーバ６１３が、ファイル転送フォームを使用し、スップ６１４でリモートノードの接続を待つ。リモートノードが接続した場合、サーバ６１３は、ステップ６１６でアップロードフォーム要求を処理し、ステップ６１８でログファイルをローカルディスクに書き込み、ステップ６２０で、ホストサービスに関連するロギングサーバ６１５のログインポートディレクトリにファイルをコピーする。ロギングサーバ６１５は同時に動作する。具体的には、ステップ６２２で、ロギングサーバ６１５がインポートディレクトリをスキャンする。ステップ６２４において新たなログファイルが存在すると判断されると、ステップ６２６でログファイルがインポートされ、ステップ６２８でデータベースがアップデートされ、ステップ６３０でログファイルが削除される。構成Ｂは、ＨＴＴＰサーバが、会社のウェブページを提供するのに使われるサーバなどの会社の既存のＨＴＴＰサーバであるため、（構成Ａと比べて）より安全で信頼性がある。構成Ｂはまた、致命的なログデータが外部からアクセスできないため、より安全である。さらに、第２の構成は、会社のウェブサーバが同時に多くのユーザを処理するように設計され、また定期的に監視されているため信頼性が高く、障害が発生した場合に直ぐにバックアップできる。

この実施例では、ソフトウェア開発者は通常、一連のステップを実行し、機能および構成情報の収集を促進する。具体的には、以下のステップは、どのように開発者がアプリケーションを実装してログデータを生成するのかを示している（以下では、ＪＡＶＡについて知っていると仮定する）。
１．メッセージハンドラクラスのデリべーションを実装する。
２．一連のMessemger.store(...)メソッドをアプリケーションの既存のコードに追加する。所定の特徴のエントリ位置を示すコードの位置に追加すべきである。
３．アプリケーションのインストールツールをアップデートし、ＨＴＴＰプロキシ情報を収集し、開発者のアプリケーションにより読むことができる構成ファイルを生成し、この情報をメッセージハンドラに送信できる。

前述した各ステップを以下に詳細に説明する。

ステップ１
メッセージハンドラは、Ｊａｖａの抽象的なクラスである。このため、本発明では、インテグレータが、アプリケーションを特定するクラスの具体的な実装を得る。このメッセージハンドラは、以下に説明する一連のタスクを実行する。

典型的な実施例では、メッセージハンドラクラスは、ログファイルのフィルタリングとディスパッチを行う。クラスのインスタンスは通常、ログファイルの生成およびディスパッチに必要な一連の変数を設定する初期化コードから始まる。通常、ログファイルを生成することは、サービスプロバイダのサーバにより提供される一意の３２文字の識別子であるｍｙｃｏｍｐａｎｙ．ｃｏｍなどのインテグレータのドメイン名、プロジェクトおよびビルド（build）の名称を必要とする。３２文字の一意の識別子は、ユーザインタフェースあるいは他の便利な手段を介してサーバからユーザに提供される。識別子は、ユーザが特定のプロジェクトのためのビルドを生成したときに、生成および表示される。次に、ユーザは、３２文字の一意の識別子をユーザのメッセージハンドラクラスのインプリメンテーションにコピーする。３２文字の識別子を利用して、ログファイルデータをサービスプロバイダのサーバの特定のプロジェクトおよびビルドと照合する。次に、ログファイルから読み込んだデータは、サーバのデータリポジトリに格納される。プロジェクトおよびビルド名称を利用して、例えば、一部の開発者によるタイプエラーにより３２文字の識別子に問題があるプロジェクトおよびビルド名称とデータを照合するのが好ましい。また、メッセージハンドラのディスパッチ機構が、目的地のＵＲＬを要求するのが好適であり、ログイン名、パスワード、プロキシサーバ構成、およびログファイルをインポートサーバに送信する処理を記載した追加のコードなどの他の任意のアイテムを備えてもよい。メッセージハンドラは、アプリケーションがスタートするとき、ストップするとき、構成データを収集する間、あるいは機能が実行されたときにログファイルを送信してもよい。これらの方法の開発者の実装は、単に「ｔｒｕｅ」応答を返却し、次に、メッセージハンドラは、自動的にシステム内の総ての（あるいは一部の）ログファイルを送信する。「ｔｒｕｅ」応答を受信すると、ディスパッチャは通常、必要であればプロキシ情報を使用し、初めにファイアウォールを通ってＵＲＬのパラメータで特定されるサーバに接続する。ＵＲＬは、特別のログイン情報を要求してもよく、あるいは追加のスクリプトを提示してもよい。このとき、ディスパッチャは、追加的なログイン情報およびコードを実行し、ファイルアップロードフォームを取得する。次に、ディスパッチャは、このフォームによりログファイルを送信する。

メッセージハンドラのインスタンスは、表２で以下に説明する一組のメソッドを記述する。

表２

通常、Constructorメソッドは、アプリケーションの初期化に関する多くの情報を提供する。図１０に示すコードブロックは、メッセージハンドラの抽象的なクラスである。様々なｇｅｔＸＸＸおよびｓｅｔＸＸＸメソッドにより、ユーザが重要な構成情報を設定できる。

説明したフレームワークにより、ユーザが、データを転送するアプリケーションの能力を強化するために多くの要素を定義できる。表３は、様々なメソッドと、これらの動作を説明している（アスタリスクが付いているメソッドは任意である）。

表３

MessengerおよびLogDispatcherがこれらのメソッドを読み、ログファイルを保持および転送する。

ステップ２
Messenger．storefeature(...)メソッドは機能データを追跡する。これは、２つのパラメータを取得する。第１のパラメータは、カスタマイズされたメッセージハンドラのインスタンスである。第２のパラメータは、機能の名称を含む文字列である。機能の実行の数に関する得られた情報は、機能の価値を示す。もちろん、使用頻度の高い機能は、使用頻度の少ないあるいは使用されていない機能よりも価値がある。

典型的な実施例では、Messenger.storefeature(...)メソッドは、アプリケーション内の各機能エントリ位置に追加される。

ステップ３
遠隔的に動作するアプリケーションは、トランスペアレントあるいは認証プロキシサーバの背後でもよい。ユーザアプリケーションのインストレーション構成要素は、これを認識すべきであり、必要に応じてプロキシサーバのアドレス、ポート、ユーザ名、およびパスワードを収集し、これらの情報をカスタムメッセージハンドラのインスタンスが読むことができる構成ファイルに書き込む。次に、メッセージハンドラは、構成情報と共にsetProxyServerHost()、setProxyServerPort(...)、setProxyUserName(...)、setProxyUserPasswordメソッドをコールする。

これらの統合ステップにより、ユーザアプリケーションが機能の追跡情報を収集および転送できる。図７は、ユーザが追跡された機能を実行するときの代表的な処理フローを示している。図７に示すように、ステップ７００において、ユーザが機能を実行するときにルーチンが開始する。ステップ７０２では、機能の追跡コードが実行される。ステップ７０４では、アプリケーションを動かす最初の機能の実行かどうか判断される。最初の機能の実行である場合、ステップ７０６において、メッセージハンドラのStartupメソッドがコールされる。ステップ７０８では、ログファイルを送信すべきが判断される。送信すべきでない場合、ステップ７１０において、メッセージハンドラのhandleConfigMessageメソッドがコールされる。次に、ステップ７１２において、ルーチンがメッセージハンドラのhandleMessageメソッドをコールし、このステップは、ステップ７１４の結果が真である場合にも行われる。ステップ７１４は、送信がスタートアップイベントによるものか判断する。ステップ７１２の後、ステップ７１６で機能の統計量がアップロードされる。ステップ７１８において、機能をログファイルに書き込むべきか判断する。機能をログファイルに書き込むべき場合、ステップ７２０において機能がログファイルに書き込まれる。ステップ７２０の後、あるいはステップ７１８の結果が偽の場合、ステップ７２２において、ログファイルを送信すべきか判断する。ログファイルを送信すべき場合、ステップ７２４で、リモートノードが総てのログファイルを収集し、ステップ７２６で、リモートノードがリモートサーバに接続し、ステップ７２８で、リモートノードがサーバに接続できるかどうか判断する。リモートノードがサーバに接続できる場合、ステップ７３０において、リモートサーバにファイルアップロードフォームがあるか判断する。リモートサーバにファイルアップロードフォームが無い場合、あるいはステップ７２８の結果が偽の場合、ステップ７３４で、ユーザが定義した最大の日数よりもファイルが古いかどうか判断する。ステップ７３０の結果が真の場合、ステップ７３２において、ファイルがアップロードされる。ステップ７３２の後、あるいはステップ７３４の結果が真の場合、ステップ７３６においてファイルが削除され、制御がステップ７１４の判断に戻り、処理が完了する。

ログファイルは、特別にフォーマットされた一連のイベントを含むバイナリファイルであることが好適である。ファイルは、（従来のログファイルで一般的なように）機能の実行毎に１のエントリであるよりも、集められた機能情報を備えることが好ましく、これにより、ファイルが従来のログファイルよりも小さくなることを保証する。しかしながら、本発明は、集められた機能情報の利用に限られない。

各フィールドはうまく定義されているため、フォーマットは読むことができ、非常に効率的にデータベースに統合できる。従来のログファイルは、一行づつ読まなければならなかったため、データをテキストから解析しなければならなかった。これは、しばしば実装するのが難しく、このため、エラーが発生し易く性能が悪い。前記フォーマットは、符号無しのバイトの数字で記述される。以下のキーは、Ｊａｖａ仮想マシン（ＪＶＭ）仕様で定義されるような用語である。具体的には、数字が続くＵは、所定の長さの符号無し、８ビット、バイトである。Ｕ１は１の符号無しバイトであり、Ｕ４は４つの符号無しバイトを意味する。［］が続くＵはバイト配列を示している。別のフィールド名を含む［］は、フィールド名が配列の長さを指定していることを意味する。

各イベントの構成は、以下の表４に示すようなベースイベントフォーマットから導出されるのが好適である。

表４
総てのイベントがこのフォーマットから導出されることが好適である。このため、イベントは、Event_typeおよびEvent_Data_Lrngthにより開始するが、（イベントは通常、このフィールドを特別の実装により無効にするため）Event_Dataセクションを含まないのが好適である。代表的な実施例では、ファイルフォーマットは、Ｂａｓｅ＿Ｅｖｅｎｔを集めたものである。

機能のイベントタイプは、一連の機能の起動を意味する。各機能は、ログファイルに１以上のイベントを有する。様々な機能のログファイルには多くの機能イベントが存在する。以下の表５はフィールドの説明である。

表５

ユーザが設定したイベントタイプは、インテグレータにより生成され、任意の量の追加的な設定情報を格納できる。以下の表６はフィールドの説明である。

表６

以下に、本発明によるログファイルを処理および転送する好適な技術についてさらに説明する。前述したように、ログファイルは、ソフトウェアアプリケーションの機能、失敗、および／または誤りを追跡し、非常にコンパクトなフットプリントにおいて転送され、拡張可能な方法により、性能が高く軽量な処理を可能にすることが好適である。この目的を達成すべく、本発明の好適なログファイルフォーマットは、非常に効率的であり、連続的であり、関係性があり、関連性がある。効率は、好適には（例えば、ＸＭＬあるいは人間が読むことができる他のテキストとは対照的に）バイナリファイルの小さなメッセージを使用し、ログファイルの領域に保存すべく総ての数字を圧縮することにより実現される。総てのメッセージは、実際に発生した順序で書かれるのが好適である。メッセージの時刻情報は、最初のメッセージの時刻情報と関連するのが好ましい。したがって、例えば、最初のメッセージが１２：００に発生したイベントを示し、２番目のメッセージは１２：０１に発生したイベントを示すと仮定する。最初のメッセージは、協定世界時の日時の１２：００をミリ秒単位で格納し、２番目のメッセージは、最初のイベントと２番目のイベントとの間のミリ秒の数が格納される。また、この符号化技術は、ログファイル領域を保存する。リポートメカニズムは、時刻情報を使用して、ユーザが、いつアプリケーションに対して所定の操作を行ったか、あるいはアプリケーションが、いつ特定の方法により応答したかについて詳細な情報を提供する。リポートメカニズムはデータを分割し、機能の利用情報を１時間おき、１日おき、１週間おき、１月おき、あるいは他のタイムスケールで調査できる。ログファイルフォーマットは、メッセージ（例えば、機能実行メッセージ）、参照基準機能メッセージと同様に、関連性があることが好ましい。さらに、機能メッセージは、機能名のインデックスを生成し、このインデックスを用いて、機能が起動した数を数えることが好適である。

代表的な実施例では、追跡されるいくつかの個別のシナリオが存在する。第１のシナリオでは、コードは最初の機能の抽出を記録する。この場合、機能のロギングコードが、新しいログファイルを開き、ロギングコードが、以下のメッセージ、順に、プロジェクト、設定、ノード種類、および機能を書くのが好適である。第２のシナリオでは、コードが後続の機能の実行を記憶する。このシナリオでは、ロギングコードは、機能の実行を示す１のメッセージを追加するのが好適である。第３のシナリオでは、ロギングコートが機能の失敗を記録する。このシナリオでは、ロギングコードは、機能の失敗を示す１のメッセージを追加するのが好適である。最後に、最後のシナリオでは、ロギングコードが機能の誤りを記録する。機能の誤りを示す１のメッセージが再び生成される。関連するロギング文を含むロギングコードの例が、図９に示されている。

各ログファイルは、一連のメッセージで構成されるのが好ましい。各メッセージは通常、共通のフォーマットを有し、これによりメッセージの種類が明確になる。以下は、具体的なメッセージの種類である。
・NodeType Message−開発されたソフトウェアのインスタンスの種類
・Project Message−プロジェクト名称、例えば、追跡される開発されたソフトウェアのインスタンスの名称
・Feature Name−追跡される機能
・Startup Message−アプリケーションが始動した時間
・Feature Executon Message−実行した機能および実行されたときの機能
・Config Message−アプリケーションが展開される環境および構成についての情報
・UserConfig Message−ＡＰＩのユーザが所望する追加的な設定情報のプレースホールダ（例えば、アプリケーションがインストールされたサーバについての情報を集める）
・Feature Failure Message−機能の失敗、（ユーザが不適切なフォーマットデータを入力すると、機能は終了できない）、失敗した時間、および失敗した理由についての情報
・Feature Fault Message−発生した誤り（例外）、発生した時間、および発生した理由についての情報
・Feature Reset Message−最小のデータサイズを取得する機能を内部で特定するメカニズム−非常に数の多い機能のカウントをリセットする
・Subnode Use Message−エンドユーザマシンの設定および環境についての情報（例えば、どんなウェブブラウザが使用されているか等）
・Subnode User Configuration−エンドユーザの設定についてのカスタマイズ可能な情報のプレースホールダ
・Subnode Feature Execution−（ウェブアプリケーションサーバに対して、エンドユーザクライアントで実行されるリッチインターネットアプリケーションあるいはＤＨＴＭＬなどの環境において、クライアントの処理を追跡するのに必要とされる）サーバで実行される機能に対して、エンドユーザの設定で実行される機能
・Subnode Failure Message−エンドユーザのマシンで発生した失敗
・Subnode Fault Message−エンドユーザのマシンで発生した誤り−例えば、ブラウザを介したＪａｖａｓｃｒｉｐｔのランタイムエラー
・Subnode Reset Message−Feature Reset Messageと同様であるが、エンドユーザの機能専用
・Sub Type Message−追加の情報を追跡するために拡大する領域
・Null Message−テストのため、ログファイル中の列を整列して容易に識別できるする

ログファイルのメッセージの順序は、以下の順序であることが好適である。
１．Project−１のログファイルに対して、１のメッセージが存在することが好ましい
２．Configuration−１のログファイルに対して、１のメッセージが存在し得ることが好ましい
３．User Configuration−０以上存在できる
４．Node Type−１のログファイルに対して、１のメッセージが存在し得ることが好ましい
５．｛Startup｜Feature｜Sub Node User｝−１以上存在できる
６．｛Feature｜Feature Execution｜Feature Failure｜Feature Fault｜Reset｜Sub NodeUser｜Sub Node User Configuration｜Sub Node Feature Execution｜Sub Node Failure｜Sub Node Fault｜Sub Node Reset｝−０以上存在できる

データは、以下の示すようなデータベースレコードのようにログファイルに格納される。
・Message Formatは、「name」：サイズ、
−Type：１バイト
−Time Stamp：３バイト
−Message Type Specific Data：メッセージの種類、Feature Execution MessageあるいはSubnode User Configuration等に応じて長さが変る。

機能のトラッキングシステムの高い性能を維持しつつ、所望の情報を取得するために、ログファイルが、以下により詳細に説明するバイナリファイルフォーマットを使用するのが好適である。図１０は、（バイトが１６進数で表わされた）代表的なファイルフォーマットを示している。

以下は、バイナリファイルフォーマットを生成する符号化の方法、具体的には、数字を取得し、可能な限り最小のバイトに圧縮する方法について説明している。この方法は、総ての数のうち最も小さな負でない基準値０にバッファを初期化することにより開始する。バッファの各バイトの最上位ビット（ＭＳＢ）は、バイトが数字の最後の部分か、あるいは数字の最後の部分かを示すために予約されている。即ち、実際は、１バイト中の７ビットのみが数値を含み、最上位ビットはインジケータである。次に、符号化処理は、バッファ内の８から７ビットビットを解読し、ビット７の位置を右にシフトする。バッファの各バイトの数値のＭＳＢは、ＭＳＢが１に設定された状態で符号化される。数値の最後のビットは、ＭＳＢが０に設定された状態で符号化される。数値の復号化は、バッファのＭＳＢビットが１に設定されているか判断する処理である。バッファのＭＳＢビットが１に設定されている場合、ルーチンは７ビットを読み込み、７ビットが、３２あるいは６４ビットデータなどの対象とするデータタイプとなるように、数値を左にシフトさせる。ＭＳＢが０に設定されている場合、ルーチンは残りの７ビットを読み込み、同一のシフト処理を行い、読み込み処理を終了する。結果は、エンコーダの入力として使用される数字である。

このように、本発明の実施例では、データタイプは、最小の必要なビットに圧縮される総ての数字を示す。スキームは、一連のバイトの数値を解読することにより行われる。初めのＮバイトは、１０ｘｘ ｘｘｘｘに設定された最上位ビット（ＭＳＢ）を有し、ここで、ｘは実際の数字を表わすビットである。最後のバイトは、０ｘｘｘ ｘｘｘｘに設定された最上位ビット（ＭＳＢ）を有する、スキームの操作は、例示により最も理解できる。

例えば、数字１は、本スキームにより００００ ０００１として格納される。通常の符号化は、４バイトの００００ ００００ ００００ ００００ ００００ ００００ ００００ ０００１であり、既に知られているように本スキームはちょうど１バイトを使用する。別の例では、数字１，０００は、１０００ ０１１１ ０１１０ １０００として格納される。通常の符号化は、４バイトの００００ ００００ ００００ ００００ ００００ ００００ １１１０ １０００であり、本スキームは、ちょうど２バイト使用する。数字１００，０００は、１０００ ０１１０ １０００ １１０１ ００１０ ００００として格納される。通常の符号化は、４バイトの００００ ００００ ００００ ０００１ １０００ ０１１０ １０１０ ００００であり、本スキームは、ちょうど３バイトを使用する。この技術は、特に人間が読むことができる（例えば、ＸＭＬ）あるいは従来のバイナリ数字（４バイト）符号化に比べ、実質的にログファイルのサイズを縮小させる。

前述したログファイルフォーマットおよび圧縮したデータタイプにより、システムは、エンドユーザに対してトランスペアレントな高性能の方法により、非常に詳細なソフトウェアアプリケーションの機能、失敗、および誤りに関する利用情報を追跡できる。ほとんど数字であるログデータの多くは、ディスクレプリゼンテーティブからメモリディスクレプリゼンテーションに直接的にマップされる。この結果、データは非常にコンパクトになり、非常に効率的にロードおよび転送できる。さらに、データの位置が非常に明確であり、順序付けられているため、ログデータファイルの全体の大きさを縮小するのが容易である。このように、説明した実施例では、ログファイルは一連のメッセージを備えている。各メッセージは、機能の実行あるいは失敗などの関心のあるイベントを意味する。これらのメッセージは、特別のフォーマットおよびフィールド長にフォーマットするのが好適である。可変長フィールドは、以下のフィールドの長さを示すフィールドにより予め固定するのが好ましい。数字フィールドは可変長であるが、前述したデータタイプを使用するのが好適である。前述したように、符号化スキームは、バイナリフィールド内に数字を格納できる。

前述したように、ハードウェアおよびソフトウェアシステムで説明した本発明は、単なる例示である。本発明は通常、ソフトウェア、１以上のメカニズムで実行される。一般に、マシンは通常、有用なハードウェアおよびソフトウェアと、ストレージ（例えば、ディスク、ディスクアレイ等）と、メモリ（ＲＡＭ、ＲＯＭ等）とを備えている。ネットワークに使用される特別のマシンは、本発明の限定ではない。所定のマシンは、通常の方法でマシンをネットワークに接続するネットワークインタフェースおよびソフトウェアを備えている。図１に示すように、本発明は、１以上のネットワークに接続されあるいは接続可能な説明したマシンのセットを利用して、管理サービスとして実施される。一般に、オペレータが、前述した進歩性のある機能を強化あるいは提供する１以上のコンピュータに関連するエンティティ（システム、マシン、プロセス、プログラム、ライブラリ、機能等）を使用することにより、サービスが提供される。典型的な実施例では、サービスは、１以上のコンピュータのセットを備えている。典型的なマシンは、有用な（例えば、Ｐｅｎｔｉｕｍクラス）ハードウェア、オペレーティングシステム（例えば、Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓ、ＯＳ−Ｘ等）、アプリケーションのランタイム環境（例えば、Ｊａｖａ、．ＡＳＰ）、所定のシステムあるいはサブシステムの機能を提供するアプリケーションあるいはプロセスのセット（例えば、プラットホームに応じたＪａｖａアプレットあるいはサーブレット、リンク可能なライブラリ、ネイティブコード等）を動作させるネットワークベースのサーバである。前述したように、サーバはスタンドアロンで使用してもよく、あるいは分散したマシンセットに実装してもよい。通常、サーバは、所望の実施環境に応じて、
公のインターネット、会社のイントラネット、プライベートネットワーク、あるいはこれらの組み合わせに接続される。

ホストサーバは、効率的にスケールするように設計された複数のサーバクラスタ環境で実施してもよい。各サーバは、第１および第２の一連のタスクで設計されている。１のサーバが動的にマスタサーバに設定され、これにより、サーバが総てのサーバにより実行される第２のタスクを判断する。総てのサーバは、データベース内のインスタンスをアップデートし、サーバは、協同でいずれのサーバがマスタサーバであるか判断する。クラスタのサーバは、マスタサーバにより（ログのインポートおよびイベント処理などの）タスクが割り当てられる。

本発明を説明したが、我々は、添付の請求の範囲に記載された発明を請求する。

図１は、本発明のブランド統合技術プラットホームを実施するサービスプロバイダのインフラストラクチャのブロック図である。 図２は、本発明の基本的なロギングサービスを示しており、アプリケーションインスタンスが実行され、利用データセットを提供し、遠隔のロギングサーバに送信する。 図３は、ソフトウェア開発プロセスにおいて、ホストサービスを用いて、どのようにフィードバックを開発者に提供するのかを示している。 図４は、より詳細なホストサービスの実施例を示している。 図５は、どのようにしてリモートノードがロギングサーバと交信するかを示す簡単な処理フロー図である。 図６は、本発明の典型的なロギングサーバの構成を示している。 図７は、ユーザが追跡機能を実行したときの典型的な処理フローを示している。 図８は、ファイルを送信するためのＨＴＭＬフォームの典型的なＨＴＭＬコードの一部を示している。 図９は、ログファイルを生成するのに利用する典型的なロギングコードである。 図１０は、バイナリファイル形式で表わされた典型的なログファイルである。

Claims (18)

1. 一組のアプリケーションインスタンスとして展開されたアプリケーションを追跡する方法であって、前記アプリケーションインスタンスそれぞれが、ログファイルを生成するように実装されており、
   所定のログファイルが、一組のアプリケーションの機能の実行、失敗、および誤りに関するデータを備えており、前記一組のアプリケーションインスタンスから前記ログファイルを受信するウェブベースのホスト型サービスを提供するステップと、
   前記ログファイルを集めるステップと、
   許可されたエンティティが前記集められたログファイルにアクセスし表示できるようにするステップとを備えることを特徴とする方法。
2. 請求項１に記載の方法において、前記アプリケーションは、サーバベースのアプリケーション、ウェブベースのアプリケーション、およびリッチインターネットアプリケーションのうちの１つであることを特徴とする方法。
3. 請求項１に記載の方法において、前記ログファイルは、ｈｔｔｐトランスポートを介して前記ウェブベースのホスト型サービスで受信されることを特徴とする方法。
4. 請求項１に記載の方法において、前記ログファイルの所定の情報は、圧縮データ構造に符号化され、前記ログファイルのサイズを低減することを特徴とする方法。
5. 請求項１に記載の方法において、前記ログファイルのデータは、前記アプリケーションの機能の実行、失敗、および誤りに関する一組のメッセージを備え、当該一組のメッセージは、前記アプリケーションの機能の実行、失敗、および誤りの発生順に書き込まれることを特徴とする方法。
6. 請求項５に記載の方法において、前記一組のメッセージのうちの少なくとも最初および２番目のメッセージそれぞれがタイムスタンプを有し、前記２番目のメッセージのタイムスタンプは、前記最初のメッセージのタイムスタンプと関連することを特徴とする方法。
7. 請求項１に記載の方法において、前記許可されたエンティティは、前記アプリケーションのプロバイダおよび第三者のいずれかであることを特徴とする方法。
8. 請求項１に記載の方法において、前記アプリケーションインスタンスがパブリックネットワークに展開され、前記ログファイルは、前記パブリックネットワーク中に位置するエンドユーザから受信されることを特徴とする方法。
9. 請求項１に記載の方法において、前記ログファイルは、エンドユーザのマシンで生成されることを特徴とする方法。
10. 請求項１に記載の方法において、前記ログファイルは、前記ウェブベースのホスト型サービスに関連するゲートウェイサーバで生成されることを特徴とする方法。
11. 広域ネットワークに展開されたウェブアプリケーションを追跡する方法であって、前記ウェブアプリケーションがローカルエンドユーザのウェブブラウザ環境で使用され、
    各ローカルエンドユーザのウェブブラウザ環境における前記ウェブアプリケーションの使用により発生する所定の機能情報を受信するウェブベースのホスト型サービスを提供するステップと、
    前記所定の機能情報を集めるステップと、
    許可されたエンティティが前記集められた機能情報にアクセスし表示できるようにするステップとを備えることを特徴とする方法。
12. 請求項１１に記載の方法において、前記ウェブアプリケーションは、ブラウザに対応したスクリプトを有するウェブページおよびリッチインターネットアプリケーションのいずれかであることを特徴とする方法。
13. 請求項１１に記載の方法において、前記所定の機能情報は、ｈｔｔｐトランスポートを介して前記ウェブベースのホスト型サービスで受信されることを特徴とする方法。
14. 請求項１１に記載の方法において、前記所定の機能情報は、圧縮データ構造に符号化され、前記所定の機能情報のサイズを低減することを特徴とする方法。
15. 請求項１１に記載の方法において、前記所定の機能情報は、機能の実行、機能の失敗、および機能の誤りのうちの１つであることを特徴とする方法。
16. 請求項１１に記載の方法において、前記許可されたエンティティは、前記アプリケーションのプロバイダおよび第三者のいずれかであることを特徴とする方法。
17. 請求項１に記載の方法のステップを実行するコンピュータ実行可能な命令を有するコンピュータ可読媒体。
18. プロセッサと、請求項１に記載の方法のステップを実行するコンピュータ実行可能な命令を有するコンピュータ可読媒体とを備えるサーバ。

Images