![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
e-business サービスは、インターネットを介してコミュニケーションする疎結合のコンピューティング・タスクであり、企業間取引 (B2B) の相互作用において、ますます重要な役割を果たすようになってきています。企業では、データベース・アクセスや商用トランザクション・システムなどの 従来型コンピューティング・タスクをソフトウェア・サービスとしてラッパーに取り込み、速いペースでそれらをインターネットに接続しています。同時に、各企業は、コンピューター化オークションや e-marketplace などの新しいタスクも、ビジネス・サービスとして導入しています。簡単に言うと、e-business はサービス指向モデルに基づいて構築される傾向にあります。
各サービスが簡単に、柔軟に、かつ協調して機能するようにするには、それらのサービスを共通の編成方式に基づくものにしなければなりません。この編成方式は、Web Services を支えるアーキテクチャー概念であるサービス指向アーキテクチャー (SOA) を構成しているものです。ここで、"サービス指向" という用語は、サービスの動的な自動検出・使用をサポートするための サービスの記述方法や編成方法に重点を置くアーキテクチャーに使用されます。当記事では、手作業でシステムに組み込まれた相互作用(EDI システムなどで使用される)に基づくサービスは扱いません。
適切なサービスの動的自動検出機能を実用的なものにするためには、利用可能なサービスの集合を、コンピューター・アクセス可能な階層カテゴリーに編成する必要があり、これはある種の分類学といえるものです。そして、この編成は、各カテゴリーのサービスが何を行い、またどのようにして起動するかということに基づいている必要があります。このような分類は、Yahoo! や Netscape Open Directory のようなカテゴリー化サービス、つまり仲介者によって維持され、提供されて行くものと考えます。Yahoo の成長を例にできるとすれば、カテゴリー・サーバーの設置は、それ自体ひとつのビジネス・チャンスをもたらすでしょう。このようにして、B2B 分野の起業家は、各種の B2B サービスや他のさまざまな業界向けに カテゴリー化サービスを実現するものと思われます。
サービス指向アーキテクチャーの各コンポーネントは、以下の 3 つの役割のうちの 1 つ (またはそれ以上) を果たすことになると思われます。
- サービス提供者: サービスが利用可能であることを公開。
- サービス仲介者: 公開されたサービスを登録、カテゴリー化し提供。
- サービス要求者: 仲介者サービスを使って必要なサービスを検索し、そのサービスを利用。
これらの役割間のコラボレーション (共同作業) は、標準化されたネットワーク・プロトコルによってサポートされます。各サービスには、標準の XML 形式によるサービス記述 が関連付けられています。これらのサービス記述は、各役割にとって重要な情報です。というのは、この記述に基づき e-business サービスのカテゴリー化、選択、および起動が行われるからです
当記事では、e-business サービスの広範囲にわたる利用可能性と相互作用の意味するものを探ります。ここでは、設計時の e-business サービスの編成や実行時の編成上の課題を取り上げ、またサービス提供者、サービス要求者、サービス仲介者などの間の相互作用によって示されるビジネス・モデルの経済学についても触れます。
無数の e-business サービスがインターネットを介して接続し、コラボレーションする世界が急速に現実のものになろうとしています。B2B サービスの相互作用は、非常に硬直化した EDI のポイント間相互作用から、Chemdex、eSteel、eBay などのオープンな Web オークションまで、さまざまな方式ですでに存在しています。すでに数千の企業が、自社 IT サービスの一部をカスタマーやパートナーが Web で利用できるようにしています。このようなサービスの大半は、ブラウザーからの利用が前提となっていますが、これら Web 対応サービスの多くも、webMethods の WIDL (「参考文献」を参照) などのテクノロジーを利用すれば、B2B コラボレーションに参加することができます。
株価速報や製品カタログのような一部の e-business サービスは、単に情報の提供しか行いません。また、B2B でのオフィス用備品の購入のような 小規模の商取引を可能にする e-business サービスや、PC 製造会社での数百万ドル規模の CPU チップ購入のような重要な業務にかかわる B2B 商取引トランザクションを可能にする e-business サービスもあります。この他にも、さまざまな e-business サービスによって、いろいろな基本的ビジネス・モデルが表現されています (「参考文献」を参照)。
現在は、包括的なビジョン、すなわちアーキテクチャーもない状態で、サービスのコラボレーションが行われています。B2B コラボレーションの技法は各ケースで異なっています。e-business の参加者が、サービス・コラボレーションのための共通のアーキテクチャーに 合意するために、公式的な尽力をするか否かにかかわらず、試行錯誤の中から一貫性があり広く理解された規約が導き出されるだろうということは間違いありません。しかし、試行錯誤は煩雑であり、骨が折れ、しかも遅々として進みません。一方、一般に認められている統一的なアーキテクチャーには、さまざまなサービスを一体として機能させる方法を、IT 設計者やビジネス・システム設計者に明確に示すことができます。各企業は、このアーキテクチャーを受け入れることが求められています。
サービス・アーキテクチャーに関する提案を行った大企業もあります。有名なものは、Microsoft の Biztalk (または SOAP、あるいはこれらの両方) の構想、HP の e-speak、Sun の Jini などがあります。これらの試みには、サービスに関する世界的なコミュニティーを、一つに まとめ上げるだけの普遍性が十分ではなかったと思います。これらのベンダーは、いずれも自社テクノロジーを利用して、世界中でサービスの相互作用を実現する構想を打ち立てています。しかし、世界はいまだマルチベンダー、マルチ言語、マルチ OS というのが現状です。
当記事では、特定のプログラム言語やオペレーティング・システムに依存しない サービス・コラボレーションの観点から話を進めます。ただし、当記事は、インターネットや HTTP などの既存のトランスポート・テクノロジーや、XML などの業界標準データ・コード化技術を基本にしています。当記事で統一を提案している要素は、サービスを記述しカテゴリー化する方法です。これらの記述は、サービス提供者によって作成・公開され、作業に特化した仲介者サービスによってカテゴリー化・調査され、サービスの要求者によってサービス起動のために検索・参照されます。このように、サービス提供者、サービス要求者、サービス仲介者という 3 つの役割があります。これら 3 つの役割の関係を、図 1 に示します。
図 1. サービスの役割と相互作用
コラボレーティング・サービスは、劇作品の上演のようなものです。しかるべき台本を選んだ後、配役を決め、舞台セットを設計し、リハーサルを行い、俳優をステージに上げてそれぞれの役を演じさせます。同様に、コラボレーティング B2B サービスにおいても、求める結果を手に入れるには、まず注意深く脚本を書きます。それから、サービスを演じる配役を選び、リハーサルを行う (つまり、OK が出るまで試験と変更を行う) 必要があります。そして最後に一般公開します。それぞれの検討項目は、ある程度独立に検討しなければなりません。
実際の公演の基本的な筋書きは、主にビジネス・ニーズによって決定されます。IT アーキテクトと設計者がその筋書きを練り上げ、配役を決める (静的な設計の場合) か、あるいは 配役を選ぶルールを決めます (サービスが実行時に動的に選択される場合)。最終的に、お客様の依頼に応じ、サービスが実際に役割を演じます。サービス指向アーキテクチャーの目標は、サービス・コラボレーションのための筋書きを設計する際や、それらの筋書きを 実行する際に守られるべき規約とやり方を定めることです。コラボレーターの仕様を定める時に用いられるメカニズム/やり方を、SOA は明らかにします。つまり、実行時にどのタイプのサービスがどのような役割を果たすのか、および各役割に適合しているサービスの検索方法を、明らかにします。アーキテクチャーは、選択されたサービスが、実行時に実際にコラボレーションを行うメカニズム (すなわち適切な結果を得るためにコミュニケーションやネゴシエーションを行うための)を示すはずです。
インターネットは、ビジネス・モデルの刷新を加速化し、軍備拡張競争 を 生み出した新しい基本的要因です。軍備拡張競争は、正のフィードバック・ループであるという点に特徴があります。軍備 自体が問題を引き起こし、その解決策は"さらに軍備を増強すること" というループを作り出します。市場に一番乗りすることで必ずしも成功が約束されるわけではありませんが、企業が新しいビジネス・モデルとその技術的基盤を採用するスピードを高めることが、成功の重要な要因になっていることは間違いありません。サービス指向アーキテクチャーの詳細次第で、B2B サービスをどの程度柔軟性を持ったものにできるか、B2B サービスをどの程度迅速に変更できるか、つまり、e-business の軍拡競争で B2B サービスがどの程度強力な要因になるのかが決まります。他の条件がすべて同じであると仮定した場合、われわれは、最大の柔軟性と迅速な変更を推進するアーキテクチャーを採用したいと思います。
これから、実行時に B2B サービスのコラボレーションを確立する仕方について、3 つのシナリオを検討します。
- 設計時に組み込まれたバインド : コラボレーティング・サービスの内容は、設計時に組み込まれているので、アプリケーションはそのサービスを正確に認識しています。したがって、アプリケーションは、そのサービスとの相互作用の仕方についても正確に把握しています。
- 静的に選択されたコラボレーターへの動的バインド: アプリケーションは、適格なコラボレーティング・サービスを仲介者に求める方法を把握しています。なぜならば、設計者が、仲介者に渡す特定の照会をコード化しているからです。ただし、トランスポート・プロトコルの選択や認証といった、相互作用の詳細は、実行時に仲介者によって戻されるサービス記述によって決まります。
- コラボレーターの動的選択: アプリケーションは、使用するサービスのセマンティクスや API を把握していますが、サービス提供者に関しては、検索パターンを使って仲介者に照会を行い、選択可能なリストを入手します。アプリケーションは、実行時にこのリストから選択を行います。
B2B サービスの成長初期段階にあるということが大きな理由なのですが、現時点では、サービス指向アーキテクチャーの提唱者の多くは、最初の 2 つの選択肢に注目しています。要するに、現在 B2B サービスの使用や提供を考えている人は、未知の世界への飛躍で手一杯であり、完全に動的なモデルへの対応までは、手を出さないというのが現状です。しかし、柔軟性と適合性が最も高いのは、3 番目の方法です。われわれは、サービス指向アーキテクチャーがこれらの 3 つのすべての方法を サポートしなければならないと考えています。
Web 上でのコラボレーティング・サービスは、オブジェクト指向 (OO)システムでのコラボレーティング・オブジェクと類似しています。特に分散 OO システムと類似しています。したがって、過去 20 年にわたる OO システムの経験から得られた教訓は、コラボレーティング・サービス・システムを理解する上での一助となります。
OO が急速に普及しつつあった 1980 年代後半、オブジェクト指向などとはとても言えないようないくつかの言語が、オブジェクト・ベース であると主張して、オブジェクト という装いを確保しようとする動きがありました。そのような言語の支持者たちは、自分たちの言語こそがメッセージ送信に似た使い方ができること、また自分たちの言語こそがカプセル化の 1 つの方法を提供しているのだ、と主張していました。しかし、経験によって明らかにされたところでは、機能を完備した OO システムのメリットの大半は、クラス階層の編成能力によってもたらされたものであり、カプセル化やメッセージ送信から得られたものではありません。適切に要素分解されたクラス・ライブラリーを利用することで、OO 開発者はシステムの設計、構築、および保守をより容易に行えるようになりました。クラスや継承に頼らなければ、オブジェクトの働きについての理解は非常に難しくなります。こういった OO 編成方式が、まさにオブジェクト・ベースのシステムに欠落していた部分であったため、オブジェクト・ベースであることを主張する声は、当然のことながら、すぐに消えてしまいました。
オブジェクト・ベース・システムの失敗から学ばなければならない教訓は、潜在ユーザーがサービスを記述、編成、および指定する方法や、インターネットの混乱状態の中でサービス見つけ出す方法が、B2B サービスの成否を決定するということです。このような理由から、われわれは、サービス指向 という用語を、次のようなアーキテクチャーに対して 使用したいと思います。そのアーキテクチャーとは、実行時におけるサービスの動的検出をサポートするための、サービスの記述方法や編成方法に重点を置くものです。
他方、サービス間のメッセージ・プロトコルや、さまざまなサーバー間のコミュニケーション方法 (内容ではなく) の詳細に重点を置くアーキテクチャーは、サービス・ベース と呼ぶ必要があります。この呼び方は、サービス・ベースのアーキテクチャーには価値がないと言っているわけではありません。システム全体が 1 つのグループによって制御されている単独の企業システムにおいては、サービス・ベースのアプローチを使って、過度に硬直化したレガシー・システムをコラボレーティング・サービスに分割して、柔軟性や保守容易性を劇的に高めることができます。ただし、サービス・ベースの技法は、それ単独では、サービスの意味論的な定義を明確にし管理するアーキテクチャーの制御範囲を超えて、拡張することはありません。この範囲は、通常、1 つの企業の外側に及ぶことはありません。
サービスのセマンティクス (つまりサービスが行う 処理、および サービスが操作するデータ・エレメントが意味する もの) は、重要な検討項目です。ビジネスの価値は、正しい処理を行う B2B コラボレーションによって生み出されます。誤った処理が行われると、大きな損害がもたらされるおそれがあります。では、どうすれば、サービスが実際に使用される前に、正しい処理が行われると確信できるのでしょうか。また、どうすれば、そのような判断をインターネットの世界の速度で行うことができるのでしょうか。
小規模な OO システムでは、通常、インターフェースに互換性があるということは、セマンティクスにも互換性があることを暗示しています。つまり、正しいタイプの引数を備えた正しいメッセージ・セットをインプリメントしたオブジェクトは、"正しい処理" を行う可能性が高いということです。これは本当です。1 つの理由として、小規模なシステムは、小規模なグループのプログラマーがシステムの操作方法について の理解を共有しながら構築することが多いことがあげられます。また、もう 1 つの理由として、小規模システムには、あいまいさの残る余地が少ないことがあげられます。しかし、大規模な OO システムでは、特定のクラスによって提供されるセマンティクスを、メッセージ・インターフェースだけから正しく推断することはできません。数千の企業がそれぞれ異なるアジェンダで、膨大な数のサービスを提供している インターネットの世界では、ある特定のメッセージのセットに基づいて判断を下すのでは、そのサービスのセマンティクスを推論するのには不十分であることは明らかです。
ここで使用しているセマンティクス という用語は、人間およびビジネスの立場から見たサービスの意味、引数、副作用、および結果を指します。理論的には、e-business サービスのあるカテゴリーのセマンティクスが、自然言語テキストで完全に説明しきれないほど複雑な場合がよくあります。幸いなことに、ビジネスでは、ある程度のあいまいさがあることで、快適になる面もありますが。人工知能に関する長い間の研究にもかかわらず、予知できる未来の範囲では、「どのような種類のセマンティクスであっても、それを判定、解読できるのは、人間だけである」 というのが答えのようです。ソフトウェアのバグが一向になくならないことは、人間でさえ完璧には仕事をこなせないということ示しています。その上、人間の仕事は非常にゆっくりとしています。e-business サービスがコラボレーションできる、秒以下の時間の世界では、マシンの増強が必要です。解決策の 1 つは、どのサービスのインスタンスを他のどのサービスのインスタンスとコミュニケーションさせるかを、人間に決定させるというものです。言い換えれば、設計時点でコラボレーションを静的に決定するということです。その場合でも、サービスが実施すべき事柄、つまりハッキング、スプーフ、転送などの妨害を防止するということが、引き続き確実に実施されるようにしなければならないという問題があります。2 番目の解決策は、セマンティクスを判別できるカテゴリーに、サービスをソートして分類するというものです。人間は、このカテゴリーを作成し、渡されたサービスがそのカテゴリーに属していることを 宣言しなければなりません。そうすることで、コンピューターは、インターネットのスピードでカテゴリーを検索して、適切なサービスを見つけ出すことができます。ここでは、まず最初に、カテゴリー化の方法について検討します。なぜならば、B2B e-services のビジネス上の価値は、実行時に行われる late binding と、コラボレーション相手を選択する柔軟性によって決まるからです。
したがって、ここで行う提案の目的は、カテゴリーとそのカテゴリーに属するサービスのセマンティクスの保全性を向上させることです。渡されたサービスによって、機能性においてどのようなカテゴリーを提供するかを最終的に決定するのは、人間の判断です。しかし、我々がここで提案するのは、自動化 B2B 相互作用を可能にするメカニズムです。そのメカニズムは、B2B 相互作用に必要な速度で、妥当な正確さを保証して、人間によって行われたカテゴリー化を利用できるものでなければなりません。
単独の組織では、自力でコラボレーティング・サービスを設計したり監視したりできません。サービスは、そのサービスを提供したり使用したりするさまざまな企業に対して、経済上の重要な影響力を持つ場合があります。コラボレーティング・サービスの各パートナーは、機密データを保護する必要があります。パートナーは、無許可の探索に対しては、サービスの存在さえ隠す必要がある場合があります。その上で、パートナーは、コラボレーティング・トランザクションを実行できなければなりません。したがって、SOA は、認証、アクセス制御、暗号化、否認防止、許可などの問題に取り組む必要があります。
コラボレーティング・サービスの組織は、多数のサービス提供者と多数のサービス要求者で構成されています。この組織が精強なものとなるには、以下のことが必須です。すなわち、設計時と実行時に編成の方式と構造を提供して、全体的なコンピューティング・プロセスを、個々人やそれを取り込む必要のある 社会的ビジネス・グループにとって、理解しやすいものにすることです。
設計は、人間系での検討項目でもあり、コンピュータ系の検討事項でもあります。つまり、編成方式を技術面から検討すると同時に、この技術的な編成方式をもとに人間がシステムを考えるとき、理解し易いものにする工夫が必要です。たとえば、サブルーチンの発明 (後に、関数の概念に一般化されました) によって、はじめてプログラムを機能単位に分割することが可能になりました。この技術革新から、機能分解のための方法論、分析手法、設計技法が生まれました。関数とデータをまとめてカプセル化するソフトウェア・オブジェクトの概念は、クラス、継承、ポリモアフィズムなどの新しい技術の成立に寄与しました。これらの革新によって、新しい OO 方法論、分析手法、および設計技法が生まれました。当初、OO 作業は、機能分解の作業と同様のことを行い、呼び方だけが新しいという傾向がありました。しかし、結局、OO 設計は根本的に違うものであることが明らかになりました。OO の作業とは、既存のクラス・ライブラリーをうまく活用することでした。クラスは、適切に要素分解されたクラス階層に編成される必要がありましたし、また、OO 設計者やプログラマーが、容易にクラス・ライブラリーにアクセスできるようにするため、クラス・ライブラリーをブラウズするためのツールが必要とされました。
サービスは、さらに新しい編成方式を必要とする別の新規コンピューティング形式を描き出します。個々のサービスは、個々の関数やオブジェクトとは異なり、他の編成からのアプリケーションやサービスとコラボレーションを行う間、個々の編成のビジネス・アジェンダを満たすように設計されています。したがって、サービスの編成は、単一企業内の技術専門家よりもはるかに多くの人々を満足させなければなりません。さらに、集合体としてのサービスは、次の点から、関数からもオブジェクトからも大幅にかけ離れたものになります。すなわち、インターネットで提供されているサービス群は、設計のフェーズを通過したことも、初期状態から起動されたことなく、また将来とも、設計し直されることも再起動されることもないという点です。インターネットで提供される世界規模のサービス群は、有機的に成長と展開を続けています。使用可能なサービスを単純に記述するというのは、現実的ではありません。それは、1 つには、インターネットの規模が膨大であり、到底記述尽くせないことと、1 つには、使用可能なサービス群が日単位で、いや分単位で変化しているからです。サービスの動的な使用が、個人ベースでもグループ・ベースでも、設計者の理解し得る範囲を大きく超えている場合は、サービスに関連する編成上の大きな問題は、サービスの編成・検索方法です。API 機能に有効なアプローチは、セマンティクスの自然言語記述を使用して、呼び出しと引数タイプを文書化することです。OO システムに有効なアプローチは、クラス階層をブラウズすることをベースにしています。B2B サービスを念頭において考えると、これらのアプローチでは、API とクラス・ライブラリーに対する人間の介入と中央制御が許容範囲を超えています。
使用可能な B2B サービス群のスケールとダイナミズムが、Web のスケールとダイナミズムに類似しているため、Web ページの編成と検索の問題について類似点を調べる必要があります。そこで、この問題を処理するために登場したのが、カテゴリー化サービス、クローラー、および検索エンジンです。類推により、われわれは、B2B サービスのための編成を提供するという問題の解決策は、サービスの編成とカテゴリー化それ自体を、複数の競合サービス提供者から提供されるようにすることです。 それぞれのカテゴリー化サービスは、その分類法を選択したことのメリット、そのリストの更新の正確性、および補足情報 (サービス品質データなど) の点で競合します。競合するこれらのカテゴリー化サービスは、経済的または社会的なマーケットから生まれます。その生まれ方は、Yahoo! などの競合検索エンジンやカテゴリー化サイトが、Web ページを編成するために登場してきた場合と似ています。また、現在のような、Yahoo! や Excite といった Web 検索サイトのマーケット資本投入が行われれば、B2B サービスの資本投入を行うことにより大金をもうけることは間違いありません。
これらのカテゴリー化サービスは、図 1 に示されている仲介者によって提供されます。サービス提供者は、提供するサービスを 1 つまたは複数の仲介者を経由して公開またはリストします。サービス提供者は、サービスのセマンティクスを知っていますので、それを仲介者分類の "適切な" カテゴリーに入れて公開します。サービス要求者は、必要なサービスのカテゴリーを知っていますので、そのカテゴリーのサービスのリストを仲介者に求めます。
サービスに関する公開、要求、およびカテゴリー化は、サービス記述 で行われます。サービス記述は、サービスのセマンティクスとメッセージ API を記述する XML 文書です。サービスの API を記述するのは比較的簡単です。つまり、XML、名前付きメソッド呼び出し、名前付き引数、および型付き引数を使用します。セマンティクスの記述は、サービスの振る舞いに関する人間が読んで理解できる記述で始まります。この人間が理解できる記述と API 定義は、そのサービスが、カテゴリー化サービスの分類階層の、どこに格納されているかをガイドします。このようにしてサービスを入れると、今度は、サービスのセマンティクスが定義されて、他のサービスがそれを自動検索して使用できるようになります。
各仲介者が作成した分類を、B2B サービスの基本的な編成機能として役立てるには、その分類が人間による使用とマシンによる使用のための要件を満たす必要があります。
- 分類学では、上位のものが下位のものの共通性を反映するような階層になっており、生物学の分類法ではまさにそのようになっていますが、サービスの種類をカテゴリー化するのにはいくつかの方法があり、したがって、分類方法も 1 つに限らない可能性があります。最初は、二者択一による分類法では、振る舞いに関して様々の要素分解をもたらすかも知れません。この場合、サービスは、異なる階層の異なる場所に公開または登録しなければなりません。時間の経過とともに、より高い共通性を持ったサービスへの収束が期待できます。しかし、新規のサービス・カテゴリーが恒常的に発生し、古くなったサービスの廃棄も行われますので、分類法によるカテゴリー化について、常に、小規模な (時には、大掛かりの) 編成し直しが必要になります。
- 分類法に基づくカテゴリーは、Yahoo や Netscape の Open Directory のように人間工学的なものになっていて、カテゴリー化されたサービスのセマンティクスを反映するものでなければなりません。それぞれのカテゴリーは、セマンティクス (サービスが行う 内容) と API (サービスを起動する方法) を定義していなければなりません。カテゴリー内のすべてのサービスは、同じセマンティクスをインプリメントする必要があります。ただし、これらのサービスは、それ以外のことも行えるし、より効率的、より迅速に、かつより費用をかけず 行うこともできます。カテゴリーの記述には、人間が理解できる情報とマシン解析可能な情報が含まれていなければなりません。また、セキュリティーや認証の前提事項などの非機能的要件や、そのカテゴリー内のすべてのサービスに共通であると考えられる他の前提条件も 記述していなければなりません。
- それぞれのカテゴリーは、その上位のカテゴリーと関連付けられていなければなりません。しかし、渡されたサービスのセマンティクスは、重要なやり方で、その上位のカテゴリーと異なっていなければならない場合があります。つまり、階層内の次の下位レベルにあるサービスの特化は、同じ verb をインプリメントすることができますが、実際にインプリメントする場合は、異なる引数と異なる戻り結果を使用した、非常に異なった方法で行います。したがって、カテゴリーは、自分のサービスが階層内の親カテゴリーや兄弟カテゴリーのサービスと どのように異なっているかを記述しなければなりません。
- サービスは複数のカテゴリーに登録できます。ただしその場合、サービスは各カテゴリーで正しく機能できなければなりません。
サービス記述は、サービスを公開して使用できるようにする場合や、サービスをカテゴリー化し、要求を満たすためにサービスを検出する場合に、重要な役割を果たします。言い換えれば、サービス記述は、公開、検索、およびバインドをサポートする情報交換メディアです。サービス記述の高レベル要件は、次のとおりです。
- サービス記述は、XML でインプリメントする必要があります。サービス記述は、人間が理解可能で、かつマシンで解析可能でなければなりません。また、サービス記述は、拡張可能でなければなりません。なぜならば、e-business サービスの展開については、信頼性のある予測ができないからです。
- サービス記述は、サービス要求者が、そのサービスが自分の要件を満たしてくれるものであるかどうかを判別したり、また仲介者がカテゴリー化するために必要な すべてのセマンティック情報を提供するものでなければなりません。
- サービス記述は、非機能的な要件も指定していなければなりません。非常に重要な問題が 2 つ有り、そのうちの 1 つは、セキュリティー、認証、およびプライバシーの問題で、サービスを完了するために必要な情報の交換に関係するものです。もう 1 つは、サービス提供者と要求者間の法的または契約上の問題です (たとえば、事業パートナー契約書 (Trading Partner Agreements) と関係する問題。これは、サービス記述によってサービスに統合されるか、またはサービス記述によってポイントされます)。
サービスの市場は絶えず変化していますので、仲介者は、時々、カテゴリーの作成や破棄を行ったり、正規のサービス記述をカテゴリーに合わせ変更したりする必要があります。これらの変更を関係者に通知し、カテゴリーに関する適切なバージョン管理を行うのは、仲介者の責任です。変更やバージョン管理を行うための技法は徐々に進展しています。1 つのアプローチは、カテゴリーに廃棄 のマークを付けて、これらのカテゴリーの使用者に、適切な時期に新規のカテゴリーへ切り替わるように通知することです。仲介者、サービス提供者にもこの変更を通知する必要があります。サービス提供者は、カテゴリーの変更に応じて、サービスとサービス記述を保守する必要があります。もちろん、サービス提供者は、サービスを未変更のままにしておき、他のカテゴリー化サービスを使用することもできるし、廃棄のマークが付いているカテゴリーを使用することもできます。
要求者も、カテゴリーだけでなく、サービス記述さえもが変更される可能性があることに対処しておく必要があります。要求者は、希望のサービス記述のコピーを保管することができます。そのコピーは、実行時に実際のサービス記述と対比して調べることができます。変更が見つかったときは、システムの保守担当者に知らせることができます。同様に、カテゴリーに廃棄 のマークが付けられていることが実行時に分かった場合は、メッセージを出して、システム設計者や保守担当者が設計を更新できるようにする必要があります。
実行時とは、入念に筋書きされリハーサルされた、さまざまなサービス間のコラボレーションの手順を最後まで演ずる時のことを言います。サービス要求者は、1 つまたは複数の他のサービスの正しいインスタンスを検索し、それにバインドしてから、ジョブを実行するために必要なダイアログを実行する必要があります。これらのサービスは、逆に、他のサーバーの他のサービスを利用する必要があります。価値を提供するのは、任意の 1 つのマシンの振る舞いではなく、コラボレーションそれ自体です。
この 10 年ほどの間に、コンピューティングの一般的な概念が、"コンピューティングが 1 つの CPU で実行されている" から "ネットワークはコンピューターである" に変わってきました。われわれはこれまで、リモート・メソッド呼び出しを介してコミュニケーションする分散オブジェクト・システムと、マーシャルまたはデマーシャルされたオブジェクト (たとえば、CORBA) に基づくアーキテクチャーを見てきました。このアプローチは、もともと、コラボレーティング・コンピューターの煩雑さを和らげたいという、設計者の側からの願いから生まれたものです。すなわち、この煩雑さを、ごく馴染みの深い問題、つまり、複数のオブジェクト・システムが単一のコンピューターで実行されているように 見せようとしました。これらのシステムは、各種のリモート・オブジェクトによってサポートされている API を指定する方法を提供しますが、セマンティクスを指定する方法は提供しません。システム設計者が共通の前提事項を遵守できるような比較的小規模のアプリケーションでは、これらのシステムは成功します。抑制されていないインターネットの巨大な混沌の中での、コラボレーティング・サービスは、全く別の大きな問題です。
サービス指向コンピューティングに適したコミュニケーション・アーキテクチャーについて考察する場合は、それと類似したコミュニケーションの複雑性を持ったシステムを研究する必要があります。社会システムや経済システムは必要な複雑性を持っていますが、これらのシステムは人間の判断によって円滑化されます。自動化 B2B 相互作用の類似ケースを探すなら、人間による入力データに依存しないケースを考える必要があります。生物学的多細胞コミュニケーション・ストラテジーは、最良の類似性を提供します。事実、単一 CPU コンピューティングからネットワーク・コンピューティングへ遷移する場合、多くの局面で、単細胞有機体から多細胞有機体への遷移に類似しているように思われます。
多細胞有機体が解決しなければならなかった最初の問題の 1 つは、これらの細胞がどのようにして効果的なコミュニケーションとコラボレーションを行うか、ということでした。多細胞コミュニケーション・ストラテジーは、10 億年以上もの間、試行錯誤によって進化してきました。その進化の過程で、どれほどの数のコミュニケーション・メカニズムが試行され、不足と判明したか、われわれには知る術もありませんし、また、これらの失敗したメカニズムのコミュニケーション原則がどんなものであったかも分かりません。しかしわれわれは、生き残った成功した技法を調べることにより、有効な類推を行うことができます。
今日の多細胞有機体の細胞は、主として、分子メッセージを介して相互にコミュニケーションし合っています。つまり、各細胞は、これらのメッセンジャー分子をブロードキャストする (たとえば、循環系を介して) か、またはメッセンジャー分子を隣接細胞へ直接渡す (「参考文献」を参照) かしています。ニューロンはメッセージを体に沿って電気インパルスで伝達しますが、このニューロンでさえ、シナプスと呼ばれる細胞間の狭いすき間を通して神経伝達物質分子を送信することにより、神経回路内の隣のニューロンにメッセージを送り込んでいます。
分子は、一酸化窒素ほどの大きさしかありませんが、メッセンジャーとしての機能を果たすことができます。しかし、複雑な選択式のメッセージには、長いチェーンのサブユニットでできている複雑なメッセンジャー分子が必要です。発展的に、2 つの非常に異なる種類のチェーン分子に決着しました。つまり、アミノ酸のチェーンであるタンパク質と、ヌクレオチドのチェーンである DNA または RNA です。どちらの種類も、多くの情報をできるほどの複雑性を備えています。しかし、それらは、細胞 CPU との関連の仕方により、非常に異なった生物学的役割を果たしています。タンパク質は、細胞マシンのさまざまな構造的・動的部分を構成しており、DNA または RNA の遺伝子シーケンスは、各セルの機械部分を扱う基本プログラミング・コードを提供します。したがって、遺伝子物質の転送は、事実上、受け取る側の細胞をプログラミングし直すことです。他のすべての種類のメッセンジャー分子を転送することは、逆に、ポリモアフィック・メッセージとして働くことになります。それは、どのような応答が適切であるかを決定するのは、送る側の細胞ではなく、受け取る側の細胞だからです。
バクテリアのような単細胞有機体の場合は、遺伝子物質を DNA または RNA の形式で、直接、細胞間転送するのが、通常の、しかも強力な情報転送手段です。この方法を使用すれば、成功した突然変異を大きな集団のバクテリアに急速に広げることができます。たとえば、DNA の直接転送が、抗生物質に対する抵抗力をバクテリアの種に広める原因の 1 つになっています。しかし、健全な多細胞有機体は、非常に特殊な状況の有性生殖の場合にしか DNA を転送しません。遺伝子物質を細胞間で運搬するウィルスは、この規則を破って、ウィルスに感染した有機体に損傷を与えます。遺伝子転送に反対する規則が、多細胞有機体であまりに一般的に順守されているため、Loewenstein は、それを「遺伝情報の細胞間転送のタブー」と呼んでいます。
単一 CPU コンピューティングから複数マシン・コンピューティングへの進化は、異種コンピューティング環境で行われました。その結果、われわれは、ユニバーサル・データ (XML フォーマット) とユニバーサル・コード (Java) を開発しました。原則として、どちらでも B2B コミュニケーションのベースにすることができます。しかし、われわれは、多細胞進化の教訓を、ポリモアフィック XML データ・メッセージへの強力な賛成票であり、実行可能コード (Java や ActiveX など) からなるメッセージへの強力な反対票であると 考える必要があります。Web でコンピューター・ウィルスを経験すると、先端をいく B2B パイオニアたちも同様な結論に落ち着きます。セキュリティーが重要な問題になっている多くの官庁や企業では、マシン間で実行可能コードを自動転送することをすでに禁止しています。B2B を率先して使用する人たちの多くは、メッセージのさまざまな部分に使用するフォーマットとして XML を考えています。要求したサービスに必要なデータや、サービスから戻されたデータがその例です。
事態は悪い方へ進んでいます。特に、インターネット規模のサービス・ネットワークの場合にそれが言えます。メッセージ交換が非常に効率的に行われている場合、つまり、単一システムや、高速 LAN のファイアウォールの場合は、呼び出しおよびエラー戻り方式は満足のいく働きをします。しかし、サービスが戻るのに長い時間や予測できないような時間を必要とする場合は、単にエラー戻りを待っているだけでは不満です。この場合は、より優れた例外イベント・モデルが必要になります。このモデルでは、サービスの分類法と大きく異なる例外の分類法が必要になります。サービス記述は、例外を API インターフェースに指定する必要があります (おそらくは、Java と同様なやり方で)。
e-business サービスの使用は、ユーザーのシステムが果たす役割 (つまり、サービスの提供、サービスの使用、他のサービスへの仲介者など) に応じていろいろな局面を見せます。
e-business サービスの提供は、ユーザー内部の IT 環境を外部世界へ公開して、カスタマー、サプライヤー、パートナーなどとユーザー・ビジネスとをより緊密に関連付けることです。それぞれのビジネスは、どのサービスを公開するか、セキュリティーと可用性をどのようにトレードオフするか、サービスの価格設定をどのように行うか (あるいは、無料の場合は、他の価値を得るためにサービスをどのように活用するか) を決定しなければなりません。各企業は、一定の仲介者サービスの場合に、サービスをどのカテゴリーにリストするか、サービスを使用するためには、どのような種類の Trading Partner Agreement が必要であるかも決定する必要があります。
サービスは、結合レガシー機能にすることも、サービスとしての新規ソフトウェアにすることもできます。しかしながら、新規ソフトウェアが、内部または外部に提供される他のサービスのコラボレーションを記述したものとほとんど同じである 場合があります。つまり、サービスの経済圏の登場とともに、既存のいくつかのサービスを統合したサービスや、そのままのサービスでほとんど足りるような新規のサービスが登場するチャンスが生まれます。
企業は、1 つまたは複数の仲介者にリストされた新規のサービスをすぐに入手して、それを適切な相手に公示し販売したいと考えます。こういった共通の問題を解決するための一助となるサービスを提供するビジネス・チャンスが 到来するものと思われます。
一般に、e-services を使用するビジネス上の理由は、IT を使用する理由と同じくらい変化に富んでいます。今日の e-business サービスのためのキラー・アプリケーションは、サプライ・チェーン統合です。このほかのアプリケーションも登場します。われわれが期待しているのは、e-services の市場が、一枚板のアプリケーションで現在行われている処理の一部を、アウトソーシングする機会を 開いてくれることです。もう一つの注目すべきアプリケーションとしては、一枚板の社内アプリケーションをいくつかのサービスに分割して、より容易に特化できるようにするものがあります。この種の事象は、高トラフィックの Web サイトで、既によく見られるます。
サービスの利用者にとって 1 つの重要な問題は、実行時に動的に選択されるサービスと比べ、設計者によって静的に選択されるサービスがどのくらいあるかということです。サービスの動的選択が終局のゴールであるので、アーキテクチャーは、サービスの完全に動的なエコロジーをサポートするものでなければなりません。最初の使用の大部分が静的なものであっても、動的選択が一旦使用されると、どのようにして最良のサービス提供者を選択するか、またどのようにしてサービスの品質を評価するか、という検討項目を提起します。もう 1 つの検討項目は、どのようにすればサービスの利用者が、サービス提供者の失敗に遭遇するリスクを査定できるか、ということです。また、こういったリスクを減らすために、どのような技法が生まれるか、という問題もあります。
サービス仲介者は、分類しそれを管理するサービスを提供し、サービスを評価・登録し、その情報に関心を示す人々に、迅速に検索する手段を提供します。
e-business サービスのエコノミーは、いくつもの種類の仲介者を提供します。仲介者によっては、選択できるリストの豊富さを特色とします。また、他の仲介者は、リストしたサービスの高レベルの信頼性を売り物とするでしょう。広範なサービスを網羅する仲介者もあれば、特定の業界内に焦点を合わせる仲介者もあるでしょう。もちろん、他の仲介者のカタログを作成するだけの仲介者も生まれます。ビジネス・モデルに応じ、仲介者は、検索要求数、リストの数、またはリストの正確度の最大化を試みるでしょう。また仲介者は、各社の分類法の素晴らしさを競います。それは最適に要素分解された 階層を実現することで、求めるサービスの検索を最大限に容易にするという 形をとります。
最新のWebspeak の用語を使えば、仲介者の主要な検討項目は、どのようにしてサービスを貨幣化 するかということです。仲介者が、基本仲介サービスの料金を請求できるとは思われません。少なくとも、仲介者の初期の発展段階では、実際上、新規参入を阻害するものがあるとは思われません。仲介サービスを立ち上げるのは容易なため、多くの競争者が台頭します。中でも、検索サービスを無料で提供して、Yahoo! モデルをまねる競争者が多数現れます。特別のサービスを提供する仲介者は、その情報の料金を請求することができるかもしれません。特別のサービスには、サービスの信頼性に関する保証が含まれます。たとえば、信用調査、各付けサービス、カスタマー・フィードバック収集 (サービス・トランザクションの両端での)、などがそれです。しかし、この 5 年間にわたる Web の歴史では、使用料金を徴収するほとんどの試みはユーザーから敬遠されました。その上、ある程度の規模のある仲介者の場合は、ネットワーク効果 (つまり、"勝者独り占め" ダイナミック) があります。リストが豊富であれば、それだけ仲介者を使用するサービス要求者も多くなります。このため、その仲介者にリストされた新規サービスがもつ価値も増加します。このポジティブ・リターン・ダイナミックは、新規参入者に、収益を犠牲にしてマーケット・シェア を追求するよう働きかけます。このようなマーケットで仲介サービスを有料にすることは、自殺行為です。
しかし、サービスの提供者と要求者を釣り合わせることから生じた 副産物としての仲介者は、サービスの需要と供給に関するデータを収集することができます。サービスの使用に関するこのデータは、それ自体でマーケット価値を持つ場合があります。仲介者は、潜在サービス提供者や要求者に販売可能な マーケティング・データを入手できる比類ない立場にいます。仲介者は、顧客が求めているサービスの種類、および各サービスを求めている顧客を認識しています。カテゴリー別のトラフィックは、一般化と対比した場合の、特殊化の価値についての予測も行います。仲介者は、サービス・コストと QOS 間における要求者のトレードオフを予測できる立場にいます。仲介者は、リストからヒストリー・データを抽出して他の特性を予測することもできます。たとえば、成功したサーバーやサービスの相違点、サービスが "勝者独り占め" カテゴリーであるか、日用品カテゴリーであるか、など。これらの種類の情報は、有料で提供することも、コンサルティング・サービスの一部として提供することもできます。確かに Yahoo! は、名目上は無料のカテゴリー化サービスから価値を引き出すという創造性を示しました。イエロー・ページのようなインターネット前の類似製品も、このサービスの創始者が予見できなかったような新しいビジネス利点を見せてくれました。
サービス要求者に関しての設計時の問題は、後になって検索され、頻繁に使われるようになるためにサービスのタイプや特定のサービスの特性を選択しなければならないことです。仲介者の設計時の問題は、サービスを配置する分類カテゴリーを選択および編成することです。仲介者は、サービスが所定のカテゴリーに含まれていること、また、おそらくは、ランク・サービスが同一カテゴリーに含まれていることも確認しなければなりません。サービス提供者の場合の問題は、どのサービスに、どの API を付けて提供するか、また、それらのサービスを分類上のどこに登録するかということです。これらの 3 つの役割の場合、それぞれの問題を処理するための最善の技法の選択は、一部、他の人たちがどれを選択するかによって異なってきます。各プレイヤーは、それぞれの技法を改良しますので、様相が変わり、他のプレイヤーはそれに対応しなければなりません。こうして、技法、分類法、およびサービスが、時間の経過とともに共進化していきます。
"勝者独り占め" の傾向を持つ仲介者マーケットが、競合仲介者とその分類を、一定のマーケット内の 1 人の勝者仲介者に向けて、急速に収束させる傾向にあるということに留意する必要があります。分類法を無料でコピーできれば、このような勝者仲介者への独占力の付与はありません。しかし、この問題は、知的所有権 (IP) 法にかかわる可能性があります。分類法 IP に関係する電話のイエロー・ページやホワイト・ページがどのような IP を所有しているか、ということについて決定が下されました。
サービス提供者もサービス要求者も、1 人の仲介者の人質にはなりたくないので、できることなら、仲介者にオープンな分類法を提供してもらいたいと願っているのは、多くの関係者のためを思ってのことなのです。言い換えれば、彼らは、速度や品質、適時性、その他補助サービスなどについて競争しますが、分類法そのものを所有しようとはしていません。このゴールを達成するために、GPL やウィルス・ライセンスにならってモデル化されたオープン・ソース著作権ライセンス を奨励することは可能かもしれません。このアプローチが普及しない場合は、サービス要求者は、単一ソース仲介者を慎重に拒否しながら、少なくとも 2 仲介者のサービスを要求するようなやり方をとることもできるでしょう。サービス要求者は、独占仲介者から明らかな利益を得ることはありませんので、このような習慣には協力してくれるはずです。
ここまで、われわれはあるエコロジーについて述べてきました。つまり、サービス提供者、サービス要求者、サービス仲介者、分類法、サービスをオペレーションに組み入れるビジネス、などから構成されたエコロジーです。それにもちろん、このエコロジーを開発し保守するためのソフトウェアやハードウェア、サービスなどを提供するビジネスについても述べてきました。すべての経済エコロジーについて言えることですが、エコロジーが成熟してくると、それらは堅固になり、利益を生み出す数多くのニッチを作り出します。しかし、それらは初期の段階では非常に壊れやすいものです。
明示的な努力を一切行わなくてもエコロジーは良好に形成されるものですが、それをあえて作り上げようと一生懸命になっているのは、十分に成長したエコロジーから利益をあげるためにたゆまず努力を続けている企業 (もちろん、IBM も含まれます) のためを思ってのことなのです。初期の段階では、エコロジーに活を入れ、成長を促すための手助けのために、できるだけ、他の重要なプレイヤーに参加してもらう必要があります。
このエコロジーに活を入れるようとするすべての企業は、こうした自分たちの努力から得られる長期の価値が、短期利益のためにエコロジーにバイアスを掛けることによって得られる短期の価値よりも、はるかに重要であると考えることが肝要です。利益のためにエコロジーを早まって活用しようとするのは、無益な結果に終わる公算が大きくなります。特に、鍵となる知的所有権 (たとえば、初期分類法) やフォーマットの権利 (たとえば、サービス記述)、エコロジーに必要なビジネス・プロセスの権利などを独占しようとすれば、サービスを提供したいと考えていた企業や、提供されたサービスを使用することでビジネスを築こうとしていた企業などは、怖くなって逃げ出してしまうこと請け合いです。
- WIDL は、webMethods の B2B ソリューションの一部です。.
-
The Touchstone of Life、Werner Loewenstein 著、Oxford University Press, December, 2000 (ISBN: 0195140575) をお読みください。
Dr. Burbeck 氏は、1995 年 1 月、オブジェクト・テクノロジー担当のシニア・コンサルタントとして IBM に入社しました。1997 年に IBM 研究所に移り、そこで 1 年間、適応および自己構成システムを研究しました。1998 以降、今日まで、IBM Software Group のシニア・テクニカル・スタッフ・メンバーとして、最新テクノロジーの研究に専念しています。現在の興味の対象は、オープン・ソース・ソフトウェア、Web Services、およびピアツーピア・コンピューティングです。
IBM に入社する前、Dr. Burbeck は、Linus Pauling Institute of Science and Medicine で、コンピューティングと統計学を指導し、IBM PC/AT 用の Smalltalk を開拓するための新規企業を共同創立し、Apple Computer で 2 年間、オブジェクト指向開発ツールのプロダクト・マーケティング・マネージャーとして勤めた後、Knowledge Systems Corporation (オブジェクト指向設計およびコンサルティングを専門とするソフトウェア・ツール およびコンサルティングの会社) で 4 年間、開発およびオペレーション担当副社長を務めました。彼の電子メール・アドレスは、sburbeck@us.ibm.com です。
