はじめに

インターネットを介したDirect Stream Digital (DSD) サウンド変換ソフトウェアへのアクセス権を販売するという新しい収益チャネルの調査は、サウンド変換ソフトウェアを音楽CDのメーカー向けに販売しているTrumpet Companyという架空の会社の事業目的となっています。

TrumpetのITスタッフが、料金制Webサービスの展開を巡る何層かの技術的な問題をはぎ取るにつれて、いくつかの重要な問題が表面に浮上してきました。各種の収益モデルで、ソフトウェア・サービスの展開にはどのようなソフトウェアを使用することができるでしょうか?今日、このような作業を容易にするための開発ツールは、どのベンダーから入手することができるのでしょうか?Trumpetは、さまざまな使用形態を多様なサービス利用者に供給するシステムを、どのように構築するのでしょうか?

これらの疑問が提示されたことによって、この架空の会社は、利益を生むWebサービスを展開するにあたってまだ未解決の問題があることに気が付きました。TrumpetのITスタッフは、自分たちのソフトウェア・サービスを展開し、ホスティングするためには、単なるWebアプリケーション・サーバーでは不十分であり、自分たちのビジネス・プロセスが収益を得られるようにするために、各種のアプリケーション・ソフトウェア・コンポーネントを利用する必要があると結論付けました。

このコラムの前回の2回の記事では、料金制Webサービスの採用に影響を与える、いくつかの抑制要因について説明しました ( 参考文献 を参照)。今回の記事では、この新しい収益チャネルを速やかに開始するために不可欠な、いくつかの促進剤を採り上げます。

上に戻る

イネーブリング・サービス

サービス利用者の観点から見ると、ユーティリティー・サービスは、商品化されたソフトウェアの日用品です。しかし、サービス・プロバイダーの観点からは、この日用品は、多数の異なるソフトウェア・コンポーネントの寄せ集めです。これらのコンポーネントの中には、WSDLのような結合用の言語を基礎にした、公開済みのサービス・インターフェースを備えたものもありますが、より従来型の、密結合のインターフェースを必要とするものもあります。サービス・プロバイダーの観点から見ると、構成単位がより小さく、Webサービス展開環境の必要を満たすソフトウェア・サービスの集合体が存在します。こうしたWebサービスの促進剤をイネーブリング・サービスと呼ぶことにします。このカテゴリーは、料金制Webサービスの構築ブロックからなります。これらの構築ブロックもソフトウェア・サービスの1つの形態にすぎません。

一般に、イネーブリング・サービスという用語は、サービス・プロバイダーが料金制Webサービスを使用可能にするために必要な、ソフトウェア・コンポーネントの集合を指すのに使用されます。たとえば、ソフトウェア資産所有者は、サービス・プロバイダーにWebサービスの展開とホスティングを行なわせる前に、サービス・プロバイダーが請求書作成、課金、およびプロビジョニングなどの機能をサポートできるインフラストラクチャーを提供できることを確認したいと思うはずです。サービス・プロバイダーとしては、リモートから使用可能なサービスへのアクセスばかりでなく、ローカルにインストールされたイネーブリング・サービスのセットを含むインフラストラクチャーを提供したいと考えています。

図1 に示すように、イネーブリング・サービスは、コア、インフラストラクチャー、アプリケーション、およびドメイン・サービスの、4つの異なるカテゴリーのソフトウェア・サービスが概念的に積み重なったものと考えることができます。イネーブリング・サービスの例をいくつか 表1 に示します。

コア・サービスは、分散エンタープライズ・アーキテクチャーの重要なコンポーネントである、Webサービスです。このカテゴリーに属するサービスには、セキュリティーおよび信頼管理、イベント通知、データ管理およびトランザクション調整サービスが含まれます。

インフラストラクチャー・サービスは、e-businessインフラストラクチャーの特定部分を対象とした、よりハイレベルな機能を提供します。これには、商用トランザクション、ブローカー・サービス、データウェアハウジング、管理されたワークフロー、およびライセンス交付をインプリメントするためのサービスが含まれます。

この層構造ダイアグラムのこのレベルまでは、一般にサービス・プロバイダーのホスティング環境でローカルに提供される、イネーブリング・サービスのカテゴリーを説明してきました。基本的に、これらのインストール可能サービスは、展開環境の一部となるか (つまりユーティリティー・サーバー)、あるいは個別に購入し、インストールすることができます。いずれの場合にも、ホスティング環境内においてローカルで置かれます。

アプリケーション・サービスは、コアおよびインフラストラクチャーの両方の層によって提供される機能を活用する、より目的の限定された機能を提供するソフトウェア・サービスを表します。たとえば、住所録サービスは、セキュリティー、データ、およびトランザクション管理サービスを基礎にして構築されます。あるいは、言語翻訳サービスは、より低位レベルの変換およびライセンス交付サービスを基礎に構築されます。

インストール可能サービスは、ベンダーにソフトウェアの新規チャネルを提供し、リモート・サービスは、リモート利用のための別の価格設定モデルを活用して、より大きな収益を得る機会をベンダーに提供します。イネーブリング・サービスの最後のカテゴリーであるドメイン・サービスは、インストール可能サービスとして展開することも、リモート・サービスとして展開することもできます。これらのドメイン・サービスは、これらのサービスまたはサービスの組を、金融サービスや旅行サービスなどの特定のアプリケーションまたは業務の分野に応じて分類します。

ここに示した分類方法は、説明して理解してもらうためのものです。ここで読者にお伝えしたい要点は、イネーブリング・サービスがソフトウェア・ベンダーにビジネス機会を提供するものであり、料金制Webサービスの市場を開拓するために必要な基準の重要な一部である、ということです。要するに、イネーブリング・サービスがより広く普及すると、サービス・プロバイダーが、既存の、緩やかに結合されたソフトウェア・サービスを基に、ホスティング環境を構築しやすくなります。サービスとしてソフトウェアの販売が行なわれるようにするには、近い将来、料金制Webサービスをサポートするサービス・プロバイダーが増加する必要があります。イネーブリング・サービスはそうした努力を促進する可能性があります。

上に戻る

展開プラットフォーム

前に、架空のビジネス・エンティティーであるTrumpet Companyの必要性を説明するために採り上げたユーティリティー・サーバーは、料金制Webサービスの進化を促進するための、もう1つの重要な要素です。

基本的に、料金制Webサービスの公開に関心を持つ企業は、今日、収益を得るためのサービスの展開および管理について、次の3つのうちのいずれかの方法を取る必要があります。

• 独自の環境を構築する。
• すぐに利用できる展開環境、すなわちユーティリティー・サーバーを提供するベンダーを探す。
• ソフトウェア資産モール (SAM) にアカウントを開設し、ソリューションを実現するための特定の形態のユーティリティー・サーバーを使用する。

ただし、サービス・プロバイダーもソフトウェア資産モールも、今のところ、新しいソフトウェア販売チャネルを利用しようとしている資産所有者の要求を満たす機能を備えていないことが、普及の妨げになっています。

ユーティリティー・サーバーは、利用量に応じた料金を徴収する方式によるソフトウェア販売をサポートするフレームワークを提供します。これは、ソフトウェア資産所有者が料金制Webサービスの展開、実行、および管理を行なうための基礎となる、ホスティング環境です。独立サービス・プロバイダーおよびソフトウェア資産モールは、こうしたサーバーを利用することができます。このようなサーバーは、いくつかのカテゴリーのイネーブリング・サービスを含んでいて、サービス・プロバイダーおよびサービス利用者が料金制ソフトウェア・サービスを展開、管理、登録、および利用するために必要な、すべての必須機能を指定しています。また、最小限の収益モデルのセットもサポートし、カスタマイズされた収益モデルをサポートするための柔軟性を備えているものもあります。

ユーティリティー・サーバーの基本的なユース・ケースを一通り眺めてみると、 図2 に示す概念が分かりやすくなります。この図では、ユース・ケースに関連する5種類の関係者を紹介します。

1. サービス・プロバイダー管理者
2. サービス利用者
3. 資産所有者
4. 認証局
5. システム

上に戻る

Webサービスの構成

このユース・ケース・シナリオは、資産所有者用のサーバー環境の構成を表しています。ここで示す構成の明細は、ソフトウェア資産をアプリケーション・サーバーにインストールまたは展開する際に扱う構成の範囲を超えています。特に、このユース・ケースは、資産所有者のプロファイルの作成、およびマイクロフロー (サービスの呼び出しを実行するために必要な中間ステップ) の定義を扱っています。たとえば、システム・プロバイダー管理者は、資産所有者がリモートから自分のソフトウェア資産にアクセスし、ソフトウェア資産を要求者に使えるようにすることができるように、資産所有者プロファイルを作成し、準備する必要があります。管理者の作業を単純化するために、プロファイル作成ウィザードを作成するのも一法です。また、視覚化ツールがあると、認証、課金、および請求などの活動に関するマイクロフローの定義に便利です。

資産インストール

このユース・ケースの目的は、サービス・プロバイダー管理者が、資産所有者の実際のソフトウェア資産をホスティング環境へインストールできるようにすることです。アプリケーション開発ツールは、読者の典型的なアプリケーション・サーバーの一部であると考えられ、このユース・ケース・シナリオに対応しています。資産所有者プロファイルを作成するための前提条件のほかに、サービス・プロバイダーは、ソフトウェア資産を実行するために必要な、すべてのソース・コードおよびバイナリー・コードも受け取る必要があります。これには、WSDLファイルやSOAP展開記述ファイルなどが含まれます。ユーティリティー・サーバー自体は、実際のソフトウェア資産を送達するためのメカニズムには必要ありません。ただし、ソフトウェアのシームレスなインストールと妥当性検査には対処する必要があります。

認証要求

資産所有者とサービス利用者は、ユーティリティー・サーバーの2種類のユーザーを表しています。ユーティリティー・サーバー用に選択されたセキュリティー・モデルによっては、システムのこれらのユーザーにはディジタル証明書が必要になることがあります。相互の認証局の前提条件を満たした後で、両方のユーザーは、システムの機能にアクセスするための証明書を要求できるようになります。このユース・ケースの目的は、ユーティリティー・サーバーによってサポートされるタスクのポートフォリオに認証要求を組み込むことです。

Webサービスのプロビジョニング

ユーティリティー・サーバーが登場するようになり、プロビジョニングの領域が担う機能はかなり異なったものになる可能性があります。このユース・ケース・シナリオの目的は、サポートされる料金制の収益モデルのリストから資産所有者が選択を行なえるようにし、それぞれのモデルごとに、システムによってホストされるそれぞれの資産で許される使用ポリシーを記述し、関連付けることです。資産所有者は、このユース・ケース・シナリオから、利用単位の定義および単位当たりの価格や、収益モデルに依存するその他のデータ・エレメントを得ることができます。サービス・プロバイダー管理者が、ユーティリティー・サーバーを使用することにより、どの収益モデルがサポートされるのかを制御したり、サポートされるモデルのリストを拡張したりできるようになることは、よくあります。

利用者の登録

このユース・ケースの目的は、潜在的なサービス利用者が、ホストされるWebサービスの利用を登録できるようにすることです。これは、基本的には、使用に関する合意を扱うものです。理論的には、この業界はプログラムを用いた使用に関する合意に向かう傾向がありますが、初期の、無難なステップは、手作業の (オンライン) 登録によって同じ結果、つまり、資産所有者とサービス利用者との間の契約に基づいた合意が得られるようにすることです。ユーティリティー・サーバーは、必要な登録フォーム情報を記入するためのブラウザーUIを提供することができます。それぞれの資産所有者ごとに固有のURL (myServicesページなど) を用意することも、そのサーバーによってホストされるすべてのサービスを集めることもできます。利用者は、登録プロセスによってアカウントを作成した後で、利用したいそれぞれのホストされるサービスごとに契約を作成します。この反復プロセスにより、サービス利用者は、資産所有者によって提供されている利用ポリシーのリストから、希望するそれぞれのソフトウェア・サービスのためのポリシーを選択することができます。これにより、特定のWebサービス操作に関する資産所有者およびサービス利用者のアカウントに関連した、許可レコードが得られます。この許可レコードには、選択された利用ポリシー、およびその利用に関する条件が組み込まれた、固有の契約が含まれています。

サービスの利用

このユース・ケースでは、サービスの実際の利用が記述されます。これは、要求側アプリケーションからサービス・プロバイダーへの、基本的なSOAPベースのRPC呼び出しにほかなりません。ただし、料金制Webサービスの場合、呼び出されたサービスは大抵、認証や許可から課金や会計まで、さまざまな範囲の活動の集合を表します。したがって、ユーティリティー・サーバーは、個々のWebサービスを公開できるだけにとどまらず、利用のワークフローを表すサービス・インターフェースを公開できるようになっている必要があります。このインターフェースは、資産所有者およびサービス・プロバイダーの要件およびガイドラインによって定義されます。このワークフロー (またはマイクロフロー) は、ユーティリティー・サーバーによって解釈され、監査されます。

請求書の提示

このユース・ケースの目的は、サービス・プロバイダーからサービス利用者に請求者を送達できるようにすることです。資産所有者のプロファイルで定義された頻度を基にして、システムはプロファイルを繰り返し、請求書の作成および送信を行なうための要求を「請求書の提示」サービスに実行依頼します。この「請求書の提示」サービス自体が、サービス・プロバイダーによって利用される料金制Webサービスとなっていることがあります。

上に戻る

要約

要約すると、前の2回のコラムでは、料金制Webサービスを採用する際の抑制要因をいくつか示しました。供給と需要の問題を解決するために、開発者は必要十分な量のソフトウェア・サービスを提供しなければなりません。そのための最も迅速な方法は、ISVから提供される再利用可能な資産、およびさまざまな層の企業内のレガシー・ソフトウェアを活用することです。その進行を極限まで加速するには、開発者が、ソフトウェア・サービスのビジネスを記述するための共通言語を設定することも必要です。さらに、ビジネス・エンティティーは、価格設定の方法やカスタマー・サポートの体系など、新しいビジネスのやり方を定義し、受け入れるように、文化的な変化を遂げることができる必要があります。サービス・プロバイダーに対する自社のソフトウェア・サービスのホスティングを延期しようとする企業は、顧客関係のためのすべてのリンクを綿密に管理し、顧客の「所有者」であり続ける必要があります。

最後に、料金制Webサービスに関するトピックを扱った、この最後のコラムで2つのタイプの促進剤を紹介しました。これらの促進剤は、料金制Webサービスの展開を成功させるための鍵となります。つまり、ここで述べたユーティリティー・サーバーなどの、料金制Webサービスのプロビジョニング、実行、および管理を行う展開プラットフォームと、サービス・プロバイダーによる展開環境の作成を容易にするイネーブリング・サービスの2つです。

したがって、架空の会社Trumpet Company、および料金制Webサービスを使用するこの新しい収益チャネルを探ろうとするビジネス・エンティティーのために、先導役となってこのマーケットを立ち上げようとしているいくつかの新規参入企業に頑張っていただきたいと思います。次のものが求められます。

• Webベースのソフトウェア・サービスのための共通の収益モデルのセットをサポートする、汎用展開環境を販売するベンダー。
• ソフトウェア資産モールの概念に基づくビジネス機会の有効性を証明できる、1つ以上の企業体。

参考文献

• 料金制Webサービスを巡る用語 の理解を深めてください。
  
  
• 料金制Webサービスを妨げる要因 について学んでください。
  
  
• Web Servicesの計量および課金 について読んでください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• イネーブリング・サービス
• 展開プラットフォーム
• Webサービスの構成
• 要約
• 参考文献
• 著者について
• コメント