Web Services価格設定モデルの必要性

業界でWeb Servicesが進展するのに伴い、商業ベースのWeb Servicesプロバイダーのビジネス・モデルが、高まる関心と議論の的になります。現在公開されているWeb Servicesは基本的に無料であり、このため、その価値については計量されません。しかし、支払処理など、より価値の高いサービスが使用可能になるとすぐに、サービス・リクエスターによって起動されたWeb Servicesを効率的に計量するモデルの必要性が生じます。このサービスはブラウザーに依存しないため、この状況では広告収入が多かれ少なかれ役に立たなくなっており、代わりのモデルと置き換えなければなりません。

上に戻る

Web Servicesとそのアーキテクチャーの概要

Web Servicesは、単一のエンティティーとしてパッケージされ、他のプログラムで使用するために公開される機能の集合で、ブラウザーを使用した手動開始トランザクションの代わりにプログラム開始トランザクションを使用します。Web Servicesは、分散環境での動的な記述、公開、検出、および起動が可能です。つまり、Web Servicesは完全にインターネット標準に基づいて構築されます。

Web Servicesの背後にあるアーキテクチャーの概念は、サービス指向アーキテクチャー (SOA) です。このアーキテクチャーは、以下の3つの基本的な役割を記述します。

• サービス・プロバイダー
• サービス・ブローカー
• サービス・リクエスター

これらの役割 (図1 を参照) は、find、bind、およびpublish/unpublish オペレーションを通して相互作用します。

サービス・プロバイダーは、レジストリーを介してサービスを提供し、サービスを公開します。サービス・ブローカーは、サービスを公開および検出するためのサービスを提供します。そしてサービス・リクエスターは、サービス・ブローカーを介して必要なサービスを検出し、サービス・プロバイダーを介してサービスをバインドします。

上に戻る

Web Services価格設定モデル作成への挑戦

現行のWeb Serviceイニシアチブの発展にはすばらしいものがありますが、以下のような技術上の難問が山積しています。

• 信頼性とセキュリティー
• トランザクションとスケーラビリティー
• 会計責任とテスト、など

この記事で概説しているソリューションは、Web Servicesの課金に関する問題の領域に焦点を当てています。特に、サービス・プロバイダーのビジネス管理と、サービスに対する有効な課金方法について詳しく検討しています。

上に戻る

計量・課金モデル

計量・課金モデルは、特にWeb Servicesのために設計されているもので、IPアドレス間のトラフィックの計量や、送信されたEメールの数のカウント、特定ユーザー用のストレージ使用量の記録などよりも高いレベルのアプローチを取ります。このモデルはWeb Servicesテクノロジーを使用するサービス・プロバイダーをサポートするように設計されてはいますが、各プロバイダーは、異なる種類のWeb Servicesをそれぞれのシステムで実行することができます。この記事で検討する事柄は、大体、次のようなものです。

• 単純なサービス。サービス品質保証がなく、無料で提供される株式相場サービスや気温情報サービスなど。
• クライアントがビジネス・トランザクションで使用するサービス。ここでは、サービス品質が重要な役割を果たしますが、おそらく、サービスの無料提供は行われません。

後者のサービスの場合、サービス・プロバイダーは、サービスの使用状況を監査し、それを請求する必要があります。一般に、この処理は定期的に行われ、計量・課金モデルはここで使用されます。

このモデルは、サービス・レベル・アグリーメント (SLA) または同等の合意書を介して高価値のWeb Servicesを契約するという基本的な前提事項に基づいて操作され、これは両者がこの契約に合意することを意味します。この契約は、利用するサービスを計量するための基礎になります。つまりこの契約は、サービス慣行のすべての属性を網羅し、またプロバイダーやリクエスターがそれらの属性を使用する方法を規定します。この契約には、Web Serviceを利用するための環境上の前提条件も含めることができます。

リクエスター (またはクライアント) がプロバイダーと契約 (または登録) すると、リクエスターはプロバイダーとサービス・メーターに認識されたことになります。この確認は、Web serviceの利用に関する電子署名付き契約書および証明書を介して行われます。

契約書には、以下の各項に関する詳細情報が盛り込まれています。

• 契約のタイプ: 長期、臨時、限定期間、無期限、など。
• 契約の開始日および終了日。
• 使用する時間モデル: 毎日、月曜 ～ 金曜、など。
• 量モデル。提供するサービスの量に対する制限を規定。
• セキュリティー: 暗号化および認証のための署名または証明書。

計量・課金サービスは、これらの証明書を内部で使用して、契約書に規定されているリクエスターとプロバイダー間の関係を保管します。これが請求書作成発行の上で特に重要であるのは、サービス・リクエスターに不正確な請求をしないようにするためです。サービス・リクエスターは、契約したサービスの利用に際して署名付きSOAPメッセージを使用しなければなりません。

契約書を使用しても、動的に別途公開されたWeb Servicesとの関係がなくなるわけではありませんので注意してください。つまり、契約書の使用は単に該当する使用モデルを採用する必要があるということを示すだけです。

メーターの機能性は、以下のようないくつかのビジネス・モデルに支援を提供することができます。

• クリック単位支払いモデル / 使用量に応じた支払いモデル
• サブスクリプション・モデル
• リース・モデル

異なる収益モデルの詳細については、『参考文献』のセクションを参照してください。

上に戻る

使用法と機能性

計量・課金Web Servicesは、基本的には、Web Servicesのリソース・カウンターとして働きます。また、以下のものに対して入力データを提供します。

• サービス・プロバイダーの格付けモデルに従った請求書作成発行 (たとえば、Common Billing Interface)
• 支払いおよび税処理
• 以下のような機能や課金数値の定義:
  • サービスxyzのユーザー開始時刻の記録
  • サービスxyzのユーザー終了時刻の記録
  • 特定ユーザーによるリソースの総使用量の報告
  • リクエスター当たりの使用済みサービス統計データの報告
  • サービス・リクエスター (SR) アカウント (臨時課金 & 契約) の作成
  • サービス・プロバイダー (SP) アカウントの作成
  • 要求したサービスID (契約エレメント) に対してユーザーIDが許可されている場合の照会への応答
  • IPDR.org準拠XML使用レコードの作成

計量サービスを利用すれば、標準形の使用データをXMLファイルとして検索できます。このデータは、バッチに似たモデルで使用できます。つまり、標準準拠入力データの処理をサポートする製品を使用して請求書作成発行を行うのです。

上に戻る

概念上のアーキテクチャーの計量

図2 は、Web Serviceとしてインプリメントされたリソース・カウンターの概念上のアーキテクチャーを示しています。サービス・リクエスター (クライアント) は、サービス・プロバイダーのサーバーでサービスを実行します。契約書があり、呼び出したサービスが無料でない場合、サービス・プロバイダーは、"ユーザー開始時刻の記録" 要求を計量サービスに送ります。この要求には、サービス・リクエスターのユーザーIDが含まれており、計量サービスではこのユーザーIDをキーにして、課金モデルとこのユーザーの現行計量データを検出します。提案している概念は、計量サービスを、SOAPメッセージを使用してアクセスするWeb Serviceとしても定義します。このため、サービス・プロバイダーは、自分のロケーションでインプリメントしたローカル・サービスとして計量を行うこともできますし、このサービスを提供する使用可能なWeb Serviceプロバイダーを使用することもできます。

計量サービスは、さまざまな課金モデルを自分のデータベースに保持しています。これらの課金モデルは、サービス・リクエスターとサービス・プロバイダーの間で交わされた契約書の課金に関する部分を反映しています。契約書のこの部分では、クライアントがサービスを使用できるようになる時間、1日または1か月当たりのサービス使用の最大量などを指定できます。このほか、時間別、呼び出し数別、他の何らかのモデル別、サービス課金別の指定なども可能です。

"ユーザー開始時刻の記録" への応答として、クライアントが要求したサービスが現在使用できないこと、あるいは最大使用量を超えたことなどを、計量サービスで示すことができます。肯定応答では、サービス・プロバイダーは要求されたサービスを実行し、それが完了するとメーターに対し、"ユーザー終了時刻の記録" 要求を通知します。

サービス・プロバイダーは、請求書作成発行のためにクライアントの課金データをいつでも要求することができます。

上に戻る

ソリューションのコンポーネント

図3 は、計量サービス・プラットフォームを構築するために必要なコンポーネントを示しています。サービス・プロバイダー同士は、SOAPを使用しHTTPを介して接続されています。計量サービスは、Webサーバー・プラットフォームにインプリメントされることが前提になっています。WebsphereなどのWebアプリケーション・サーバー、およびSOAPサーバーは、Webアプリケーション・サーバー・プラットフォームで使用できる標準コンポーネントです。計量サービスをインプリメントするためには、このほかに2つのコンポーネントが必要になります (これについては後述)。

リソース・カウンター・サービス・コンポーネントは、サービス・プロバイダーから送られてきた要求を受け取り、要求されたサービスを提供し、応答を戻します。このコンポーネントは、XML拡張機能 (たとえばXMLエクステンダーを備えたDB2) を使用してリレーショナル・データベースに接続され、指定されたサービス・リクエスターの課金モデルと現行課金レコードを検索します。課金モデルがこのサービスの実行を除外していなければ、リソース・カウンター・サービス・コンポーネントは、現行データを更新し、肯定応答をサービス・プロバイダーに渡し、サービス・プロバイダーはこのサービスの実行を開始します。

契約済みのWeb Servicesコンポーネントは、送られてきたSOAP要求を認証します。契約書はサービス・リクエスターが使用できるものでなければなりません。さもないと、この要求は拒否されます。

上に戻る

使用シナリオ

図4 のシーケンス・ダイアグラムは、認証済みサービス・リクエスターが請求可能なサービスを要求する様子を示しています。サービス・リクエスターは、サービス・プロバイダーとの有効な契約書を持っています。サービス・プロバイダーは、フィルターを使ってリクエスターの権限をチェックしたり、計量サービス・プロバイダーと対話したりします。このフィルターは次に、ディジタル署名をSOAP RPC呼び出しに組み込みます。(この例については、『参考文献』のセクションを参照してください。)

以下のステップは、上図に示されているプロセスで実行されます。

1. サービス・プロバイダーによってホストされたWeb Serviceに対するSOAPバインド要求
2. サービス・プロバイダー・フィルターは、提供された署名を使ってサービス・リクエスターの認証をチェックし、認証がなければ、SOAPフォールト応答を与えます。
3. SOAP要求を計量サービス・プロバイダーに送って、Web Serviceの計量を要求すると、計量サービス・プロバイダーは、サービス・プロバイダーの要求を契約の詳細内容に照らして妥当性検査し、計量を開始します。
4. サービス・プロバイダーはサービスを実行します。
5. Web Serviceが完了します。
6. カウントを停止させるためのSOAP要求メッセージがリソース・カウンターに送られます。
7. サービスが完了し、結果が戻されたことを示すSOAP応答メッセージがサービス・リクエスターに送られます。

説明を簡単にするために、細かい対話 (つまり、エラー状態や、署名の妥当性検査を必要とする認証権限など) は省いています。

上に戻る

パイロット・インプリメンテーション

わたしたちはメーターの使用法を示すためのプロトタイプをインプリメントしました。IBM Web Services ToolKit (IBM Alphaworksから提供されています。『参考文献』を参照) から抜粋したコードをGourmet2Goデモ・アプリケーションに組み込みました。

図5 は、Gourmet2Goデモと登録済みサービスを使用しているユーザーが、いくつかのセッションを行っているときに収集したデータを示しています。これらのサービスには、デモのために、別のタイプの使用モデルが割り当てられています (後述参照)。

上に戻る

結論

エンタープライズ・ビジネス・トランザクションに組み込まれる高価値のWeb Servicesは、サービス・プロバイダーがどのようにしてサービスの使用に対する請求を行うことができるかを示すモデルを必要とします。この記事では、この問題に対するソリューションを示しました。

このサービスを使用してWeb Servicesの使用量を計測するサービス・プロバイダーは、まず、計量サービスで使用できるWeb Servicesを登録します。サービス・プロバイダーのサービスの1つを使用することに決定した (たとえば、UDDIレジストリーを探した後で) サービス・リクエスターは、その使用に加入し契約します。この契約の一部として、事前定義使用モデルの選択と、X509.v3などの証明書標準についての合意があります。これは、リクエスターがSOAPメッセージに署名するために必要なものであり、またプロバイダーが正しいリクエスターを計量するために必要なものです。一般にプロバイダーは、契約したリクエスターに請求するために、定期的に計量サービスを使用して請求書作成発行データを作成します。

わたしたちが提案するモデルは、Web Serviceそのものとしてインプリメントされます。サービス・プロバイダーは、同様のモデルを直接自分のサービス・プロバイダー・プラットフォームに組み込むことができますが、動的な展開が可能なWeb Servicesの利点のいくつかがなくなるという不利益が生じます。

参考文献

• Web Serviceアーキテクチャー について参照ください。
  
  
• Web Servicesと収入モデルの価値提案の説明については、「Web Servicesアーキテクト (第2回): ダイナミックe-businessのモデル」を参照してください。
  
  
• 「IBM Web Services Toolkit at the IBM Alphaworks」ページを見つけてください。
  
  
• ここでは、IPDR.org イニシアチブに関するすべての詳細情報が見つかります。
  
  
• ホワイトペーパー「Dynamic e-business and with DB2 and Web services」は、DB2がDB2 XML Extenderを使用してWeb Servicesをサポートしている様子を示しています。
  
  

著者について

Dietmar Kueblerは、IBM Boeblingen Labのソフトウェア設計者です。彼は、さまざまな環境におけるアーキテクチャー開発とソフトウェア開発の幅広い経験をバックに、開発、テクニカル・マーケティング、およびプロジェクト管理の各分野でいろいろなポジションを果たしてきました。彼の技術専門領域には、OOテクノロジー、Java、WebSphere、およびミドルウェア・テクノロジーが含まれます。

Wolfgang Eibach は、IBM Boeblingen Labの開発とアーキテクチャーの分野でいろいろなポジションを果たしてきました。彼のソフトウェア設計者としての専門的な経験分野としては、大型ホスト・ベースのソフトウェア・システム、OOテクノロジー、MQSeries、ワークフローおよびバンキング・アプリケーションなどがあります。
DietmarとWolfgangは、現在、IBM Boeblingen LabでWeb Serviceイニシアチブに取り組んでいます。

この記事を評価する

コメント

上に戻る

目次

• Web Services価格設定モデルの必要性
• Web Servicesとそのアーキテクチャーの概要
• Web Services価格設定モデル作成への挑戦
• 計量・課金モデル
• 使用法と機能性
• 概念上のアーキテクチャーの計量
• ソリューションのコンポーネント
• 使用シナリオ
• パイロット・インプリメンテーション
• 結論
• 参考文献
• 著者について
• コメント