概要
コンポーネント・ベースのプログラミングは、かつてないほど普及している。今日、何らかの形でコンポーネントを利用しないアプリケーションはほとんどない。アプリケーションがより高度になるにつれて、リモート・マシンに分散されたコンポーネントを活用する必要性も高まっている。.
コンポーネントベースのアプリケーションの例として、エンドツーエンドのeコマースソリューションがあります。Webファーム上に存在するeコマースアプリケーションは、バックエンドのエンタープライズリソースプランニング（ERP）アプリケーションに注文を送信する必要があります。多くの場合、ERPアプリケーションは異なるハードウェア上に存在し、異なるオペレーティングシステム上で実行されます。.
マイクロソフトの分散コンポーネント・オブジェクト・モデル（DCOM）は、 アプリケーションが別のサーバーにインストールされたコンポーネント・オブジェクト・モデル（COM）コンポーネントを呼び出すことを可能にする分散オブジェクト・インフラストラクチャであり、Windows以外のプラットフォームにも数多く移植されている。しかし、DCOMはこれらのプラットフォームで広く受け入れられることはなかったため、WindowsとWindows以外のコンピュータ間の通信を促進するために使用されることはほとんどない。ERPソフトウェアベンダーは、Windowsプラットフォーム用に、独自のプロトコルを介してバックエンドシステムと通信するコンポーネントを作成することが多い。.
eコマース・アプリケーションが利用するサービスの中には、データセンター内にまったく存在しないものもある。例えば、eコマース・アプリケーションが、顧客が購入した商品のクレジット・カード決済を受け付ける場合、顧客のクレジット・カード情報を処理するために、マーチャント・バンクのサービスを引き出す必要がある。しかし、DCOMや、CORBAやJava RMIなどの関連技術は、実用上、企業のデータセンター内にインストールされたアプリケーションやコンポーネントに限定される。その2つの主な理由は、デフォルトでこれらの技術はプロプライエタリなプロトコルを活用し、これらのプロトコルは本質的に接続指向であることである。.
インターネットを介してサーバーと通信するクライアントは、サーバーと通信する際に多くの潜在的な障壁に直面する。世界中のセキュリティ意識の高いネットワーク管理者は、インターネットを介したあらゆる種類の通信を実質的に許可しないように、企業のルーターやファイアウォールを導入している。ネットワーク管理者が最低限以上のポートを開放するためには、しばしば不可抗力が必要となる。.
運良くネットワーク管理者がサービスをサポートするために適切なポートを開いてくれたとしても、クライアントはそれほど幸運ではないかもしれない。その結果、DCOM、CORBA、Java RMIで使用されているようなプロプライエタリなプロトコルは、インターネットのシナリオでは実用的ではない。.
もうひとつの問題は、申し上げたように、これらのテクノロジーは本質的に接続指向であるため、ネットワークの中断を優雅に扱うことができないということだ。インターネットはあなたの直接のコントロール下にないため、接続の品質や信頼性についていかなる仮定もすることができない。ネットワークが中断すると、クライアントが次にサーバーにかける電話は失敗するかもしれない。.
また、これらの技術の接続指向の性質は、高いスケーラビリティを達成するために必要な負荷分散されたインフラを構築することを困難にしている。クライアントとサーバー間の接続が切断されると、次のリクエストを単純に別のサーバーにルーティングすることはできない。.
と呼ばれるモデルを活用することで、開発者はこれらの制限を克服しようとしてきた。 ステートレス プログラミング, しかし、この技術はかなり重く、遠隔地との接続を再構築するにはコストがかかるため、その成功は限られている。.
顧客のクレジットカードの処理はインターネット上のリモート・サーバーによって行われるため、DCOMはeコマース・クライアントとクレジットカード処理サーバー間の通信を促進するのに適していない。ERPソリューションと同様に、サードパーティのコンポーネントがクライアントのデータセンター内にインストールされることが多い（この場合、クレジットカード処理ソリューション・プロバイダーによって）。このコンポーネントは、Eコマース・ソフトウェアとマーチャント・バンク間の通信を独自のプロトコルで促進するプロキシに過ぎない。.
ここにパターンがあるだろうか？コンピューター・システム間の通信を容易にする既存のテクノロジーには限界があるため、ソフトウェア・ベンダーはしばしば独自のインフラ構築に頼ってきた。つまり、ERPシステムやクレジットカード処理システムの機能向上に使えたはずのリソースが、独自のネットワーク・プロトコルの作成に費やされているのだ。.
このようなインターネット・シナリオをよりよくサポートするために、マイクロソフトは当初、クライアントとリモート・コンポーネントの間にポート80を介したDCOM接続を確立できるCOMインターネット・サービス（CIS）など、既存の技術を補強する戦略を採用した。さまざまな理由から、CISは広く受け入れられることはなかった。.
新しいアプローチが必要であることは明らかだった。そこでマイクロソフトは、ボトムアップでこの問題に取り組むことにした。このソリューションが成功するために満たすべき要件をいくつか見てみよう。.
- 相互運用性 リモート・サービスは、他のプラットフォームのクライアントが利用できなければならない。.
- インターネットへの対応 このソリューションは、インターネットからリモート・サービスにアクセスするクライアントをサポートするのにうまく機能するはずである。.
- 強い型付きインターフェイス リモートサービスとの間で送受信されるデータの型については、あいまいであってはならない。さらに、リモートサービスによって定義されたデータ型は、ほとんどの手続き型プログラミング言語によって定義されたデータ型にうまく対応しなければならない。.
- 既存のインターネット標準を活用する能力 リモートサービスの実装は、できる限り既存のインターネット標準を活用し、すでに解決済みの問題に対する解決策の再発明を避けるべきである。広く採用されているインターネット標準に基づいて構築されたソリューションは、その技術のために作成された既存のツールセットや製品を活用することができる。.
- あらゆる言語に対応 ソリューションは、特定のプログラミング言語と緊密に結合すべきではない。たとえばJava RMIは、Java言語と緊密に結合している。Visual BasicやPerlからリモートJavaオブジェクトの機能を呼び出すのは難しいだろう。クライアントは、そのクライアントが書かれたプログラミング言語に関係なく、新しいWebサービスを実装したり、既存のWebサービスを利用したりできるべきである。.
- あらゆる分散コンポーネント・インフラをサポート ソリューションは、特定のコンポーネント・インフラと緊密に結合すべきではない。実際、新しいリモートサービスを構築したり、既存のサービスを利用したりするためだけに、分散オブジェクト基盤を購入、インストール、維持する必要はないはずだ。基礎となるプロトコルは、DCOMやCORBAのような既存の分散オブジェクト基盤間の基本レベルの通信を容易にするものでなければならない。.
本書のタイトルを考えれば、マイクロソフトが開発したソリューションが次のようなものであることは驚くにはあたらないだろう。 ウェブサービス. .Webサービスは、クライアントに代わって特定のアクティビティを呼び出すためのインターフェイスを公開します。クライアントは、インターネット標準を使用してWebサービスにアクセスすることができます。.
Webサービス・ビルディング・ブロック
次の図は、2つのアプリケーション間のリモート通信を容易にするために必要な、中核となるビルディング・ブロックを示している。.
これらの各構成ブロックの目的について説明しよう。多くの読者はDCOMに精通しているので、各構成ブロックのDCOMに相当するものについても言及する。.
- ディスカバリー ウェブサービスによって公開された機能へのアクセスを必要とするクライアントアプリケーションは、リモートサービスの場所を解決する方法を必要とする。これは、一般的に ディスカバリー. .ディスカバリは、集中型ディレクトリを使用する方法と、よりアドホックな方法で行う方法がある。DCOMでは、サービスコントロールマネージャ（SCM）がディスカバリサービスを提供する。.
- 説明 特定のWebサービスのエンドポイントが解決されると、クライアントはそのWebサービスと適切に対話するために十分な情報を必要とする。Webサービスの記述は、クライアントアプリケーションによって消費されるインターフェイスに関する構造化されたメタデータと、使用例を含むWebサービスに関する文書化された文書を含んでいる。DCOM コンポーネントは、型ライブラリ（typelib）を介して、そのインターフェイスに関する構造化されたメタデータを公開する。コンポーネントの typelib 内のメタデータは、独自のバイナリ形式で保存され、独自のアプリケーションプログラミングインタフェース（API）を介してアクセスされる。.
- メッセージ形式 データを交換するためには、クライアントとサーバーはメッセージをエンコードしフォーマットする共通の方法に合意しなければならない。データをエンコードする標準的な方法は、クライアントによってエンコードされたデータがサーバーによって適切に解釈されることを保証する。DCOMでは、クライアントとサーバーの間で送信されるメッセージは、DCOM Object RPC（ORPC）プロトコルで定義されたとおりにフォーマットされる。.
メッセージをフォーマットする標準的な方法がなければ、開発者を基礎となるプロトコルから抽象化するツールセットを開発することは不可能に近い。開発者と基礎となるプロトコルの間に抽象化レイヤーを作成することで、開発者は目の前のビジネス問題に集中することができ、ソリューションの実装に必要なインフラに集中する必要がなくなる。.
- エンコーディング クライアントとサーバー間で送信されるデータは、メッセージ本体にエンコードされる必要がある。DCOMは、クライアントとサーバーの間で交換されるパラメーターに含まれるデータをシリアライズするために、バイナリーエンコーディングスキームを使用します。.
- 輸送 メッセージがフォーマットされ、データがメッセージ本体にシリアライズされると、メッセージは何らかのトランスポートプロトコルを介してクライアントとサーバー間で転送されなければならない。DCOMは、TCP、SPX、NetBEUI、NetBIOS over IPXなど、多くのネットワークプロトコルにバインドされた多くの独自プロトコルをサポートしている。.
ウェブサービス設計の決定
これらのウェブ・サービスの構成要素の背後にある設計上の決定について説明しよう。.
転送プロトコルの選択
まず、クライアントとサーバーがどのように通信するかを決定する必要がありました。クライアントとサーバーは同じLAN上に存在する場合もありますが、クライアントがインターネット経由でサーバーと通信する可能性もあります。したがって、トランスポートプロトコルは、LAN環境とインターネット環境の双方に等しく適したものでなければなりません。.
先ほど述べたように、DCOM、CORBA、Java RMI といった技術は、インターネットを介したクライアントとサーバー間の通信をサポートするには不向きです。ハイパーテキスト転送プロトコル（HTTP）や簡易メール転送プロトコル（SMTP）といったプロトコルは、実績のあるインターネットプロトコルです。 HTTPは、リクエストを送信し、それに対応するレスポンスを受け取るためのリクエスト／レスポンス型のメッセージングパターンを定義しています。SMTPは、非同期通信のためのルーティング可能なメッセージングプロトコルを定義しています。ここで、HTTPとSMTPがなぜインターネットに適しているのかを検討してみましょう。.
HTTP ベースの Web アプリケーションは、本質的にステートレスです。クライアントとサーバー間の継続的な接続に依存しません。このため、HTTP はファイアウォールなどの高可用性構成に最適なプロトコルとなっています。クライアントからの最初のリクエストを処理したサーバーが利用できなくなった場合でも、クライアントがそれを認識したり気にかけたりすることなく、後続のリクエストは自動的に別のサーバーに転送されます。.
ほぼすべての企業には、SMTPをサポートするインフラが整備されています。SMTPは非同期通信に非常に適しています。サービスに障害が発生した場合でも、メールインフラが自動的に再送信処理を行います。HTTPとは異なり、SMTPメッセージをローカルのメールサーバーに渡すことで、そのサーバーが代わりにメールの配信を試みてくれます。.
HTTPとSMTPのもう1つの大きな利点は、その普及度の高さです。従業員は電子メールとWebブラウザの両方に依存するようになっており、ネットワーク管理者もこれらのサービスのサポートに高い習熟度を持っています。 ネットワークアドレス変換（NAT）やプロキシサーバーといった技術により、本来は孤立している企業内LANからでも、HTTPを介してインターネットにアクセスできるようになります。管理者は、ファイアウォール内に設置されたSMTPサーバーを外部に公開することがよくあります。このサーバーに送信されたメッセージは、インターネットを経由して最終的な宛先へとルーティングされます。.
クレジットカード決済処理ソフトウェアの場合、注文をERPシステムに送信すべきかどうかを判断するために、加盟店銀行からの即時の応答が必要となります。リクエスト／レスポンスのメッセージパターンを採用するHTTPは、このタスクに非常に適しています。.
ほとんどのERPソフトウェアパッケージは、eコマースアプリケーションから発生する可能性のある大量の注文を処理する能力を備えていません。さらに、注文をリアルタイムでERPシステムに送信する必要は必ずしもありません。したがって、SMTPを活用して注文をキューに入れ、ERPシステムで順次処理できるようにすることができます。.
ERPシステムが分散トランザクションに対応している場合、Microsoft Message Queue Server（MSMQ）を活用するという選択肢もあります。eコマースアプリケーションとERPシステムが同じLAN内にあれば、インターネット以外のプロトコルによる接続はそれほど問題にはなりません。 MSMQがSMTPに比べて持つ利点は、トランザクションの範囲内でキューへのメッセージの追加やキューからのメッセージの削除が可能であることです。キューから取り出されたメッセージの処理に失敗した場合、トランザクションが中止されると、そのメッセージは自動的にキューに戻されます。.
エンコーディング方式の選択
HTTP および SMTP は、クライアントとサーバー間でデータを送信するための手段を提供します。しかし、いずれもメッセージ本文内のデータをどのようにエンコードすべきかについては規定していません。マイクロソフトは、クライアントとサーバー間でやり取りされるデータをエンコードするための、標準的でプラットフォームに依存しない方法を必要としていました。.
インターネットベースのプロトコルを活用することが目的であったため、拡張マークアップ言語（XML）が当然の選択肢となりました。XMLには、クロスプラットフォーム対応、共通の型システム、業界標準の文字セットへの対応など、多くの利点があります。.
DCOM、CORBA、Java RMIなどで使用されるバイナリ符号化方式は、異なるハードウェアプラットフォーム間の互換性の問題に対処する必要があります。たとえば、ハードウェアプラットフォームによって、マルチバイト数値の内部的なバイナリ表現は異なります。 Intelプラットフォームでは、マルチバイト数値のバイト順序をリトルエンディアン方式で指定しますが、多くのRISCプロセッサでは、マルチバイト数値のバイト順序をビッグエンディアン方式で指定します。.
XMLは、標準の文字セットを活用したテキストベースのエンコーディング方式を採用しているため、バイナリエンコーディングに関する問題を回避できます。また、SMTPなどの一部の転送プロトコルでは、テキストベースのメッセージしか扱えない場合があります。.
DCOM や CORBA で採用されているようなバイナリ形式のエンコード方式は扱いが煩雑であり、開発者が詳細を気にすることなく利用できるようにするための支援インフラが必要となります。一方、XML は、標準的なテキスト解析技術を用いて作成・利用することができるため、はるかに軽量で扱いやすいものです。.
さらに、事実上すべての最新プラットフォームにおいて、XMLドキュメントの作成や利用をさらに簡素化するためのさまざまなXMLパーサーが利用可能です。XMLは軽量であり、優れたツールサポートも備えているため、XMLエンコーディングを採用することで、事実上あらゆるプラットフォーム上のあらゆるクライアントがWebサービスと通信できるようになり、驚くほど広範なリーチを実現できます。.
書式設定のルールを選ぶ
メッセージの本文に追加のメタデータを含める必要がある場合がよくあります。たとえば、トランザクションへの参加やルーティング情報など、リクエストを処理するためにWebサービスが提供すべきサービスの種類に関する情報を含めたい場合などです。XMLには、メッセージの本文とそれに関連するデータを区別するための仕組みは用意されていません。.
HTTP などのトランスポートプロトコルは、ヘッダーデータに対して拡張可能なメカニズムを提供していますが、メッセージに関連付けられたデータの中には、そのトランスポートプロトコルに固有ではないものもあるかもしれません。たとえば、クライアントが、場合によっては異なるトランスポートプロトコルを介して、複数の宛先にルーティングされる必要があるメッセージを送信することがあるでしょう。 もしルーティング情報をHTTPヘッダーに格納した場合、SMTPなどの別のトランスポートプロトコルを介して次の中継サーバーに送信する前に、その情報を変換しなければならないことになります。ルーティング情報はトランスポートプロトコルではなくメッセージ固有のものであるため、メッセージの一部として扱うべきです。.
Simple Object Access Protocol（SOAP）は、ヘッダー情報をメッセージの本文に関連付けるための、プロトコルに依存しない手段を提供します。すべてのSOAPメッセージは、エンベロープを定義する必要があります。エンベロープには、メッセージのペイロードを含む「ボディ」と、メッセージに関連するメタデータを含めることができる「ヘッダー」があります。.
SOAPでは、メッセージ本文のフォーマット方法について何の制限も設けていません。データのエンコード方法に一貫性がないと、基盤となるプロトコルからユーザーを抽象化するツールセットの開発が困難になるため、これは潜在的な懸念事項となります。 その結果、目の前のビジネス上の課題を解決する代わりに、Webサービスのインターフェースを習得するためにかなりの時間を費やさなければならない可能性があります。.
必要とされていたのは、リモートプロシージャコール（RPC）メッセージのフォーマット方法と、そのパラメータリストのエンコード方法を標準化することでした。SOAP仕様の第7節は、まさにこれを規定しています。同節では、プロシージャ指向のメッセージに関する標準的な命名規則とエンコード方式について説明しています。.
SOAP は、データを XML メッセージにシリアル化するための標準フォーマットを提供しているため、ASP.NET や Remoting などのプラットフォームでは、その詳細を抽象化して処理することができます。.
記述メカニズムの選択
SOAPは、Webサービスとクライアントの間でやり取りされるメッセージの形式を規定する標準的な方法を提供します。しかし、クライアントがリクエストを適切にシリアル化したり、レスポンスを解釈したりするには、追加の情報が必要となります。XMLスキーマは、メッセージの内容を記述するために使用できるスキーマを作成する手段を提供します。.
XMLスキーマには、メッセージの内容を記述するために使用できる、組み込みのデータ型の中核となるセットが用意されています。また、独自のデータ型を作成することも可能です。例えば、投資銀行は、クレジットカードの支払い依頼を送信するために使用されるメッセージの本文の内容や構造を記述するための複合データ型を作成することができます。.
スキーマには、データ型および要素の定義の集合が含まれています。Webサービスでは、メッセージ内に含まれることが想定されるデータの型を伝えるだけでなく、送受信されるメッセージの妥当性を検証するためにも、このスキーマを使用します。.
しかし、スキーマだけでは、Webサービスを効果的に記述するのに十分な情報は得られません。スキーマには、クライアントとサーバー間のメッセージのやり取りに関する記述が含まれていないからです。例えば、クライアントは、ERPシステムに注文が送信された際にレスポンスが返ってくるかどうかを知る必要があります。また、Webサービスがどのトランスポートプロトコルでリクエストを受信する予定なのかについても、クライアントは把握しておく必要があります。 最後に、クライアントは、Webサービスにアクセスできるアドレスを知る必要があります。.
この情報は、Webサービス記述言語（WSDL）ドキュメントによって提供されます。WSDLは、特定のWebサービスを完全に記述したXMLドキュメントです。ASP.NETのWSDL.exeやRemotingのSOAPSUDS.exeなどのツールは、WSDLを読み込み、開発者のためにプロキシを自動的に生成することができます。.
ソフトウェアの構築に使用される他のコンポーネントと同様、Webサービスについても、そのWebサービスを利用してプログラミングを行う開発者向けに、文書化されたドキュメントを用意すべきです。このドキュメントには、Webサービスの機能、公開されているインターフェース、および使用方法の例が記載されている必要があります。特に、Webサービスがインターネットを介してクライアントに公開される場合は、質の高いドキュメントが極めて重要となります。.
証拠開示手続きの選択
Webサービスを開発し、ドキュメント化したら、見込み客はどのようにそのサービスを見つけられるのでしょうか？もしそのWebサービスが、開発チームのメンバーが利用することを想定して設計されているのであれば、数席離れた同僚にWSDLドキュメントのURLを共有するといった、かなりカジュアルなアプローチでも構いません。 しかし、潜在的なクライアントがインターネット上にいる場合、Webサービスを効果的に宣伝することは、まったく別の話になります。.
必要なのは、Webサービスを公開するための共通の方法です。 ユニバーサル・ディスクリプション、ディスカバリー、アンド・インテグレーション（UDDI）は、まさにそのような仕組みを提供します。UDDIは、Webサービスの公開や検索に使用できる、業界標準の集中型ディレクトリサービスです。UDDIを利用すれば、ユーザーは会社名、カテゴリ、Webサービスの種類など、さまざまな検索条件を用いてWebサービスを検索することができます。.
Webサービスは、DISCOを介して公開することも可能です。DISCOは、Microsoftによって定義された独自のXMLドキュメント形式であり、Webサイトが提供するサービスを公開することを可能にします。DISCOは、リソースを特定するためのハイパーリンク形式を容易にするためのシンプルなプロトコルを定義しています。 DISCOの主な利用先はMicrosoft Visual Studio.NETです。開発者は特定のWebサーバーをターゲットとして指定し、そのサーバーが公開しているさまざまなWebサービスを閲覧することができます。.
Webサービスには何が欠けているのか？
お気づきかもしれませんが、分散コンポーネント・インフラストラクチャに含まれる重要な要素の中には、Webサービスによって定義されていないものがあります。特に顕著な欠落点として挙げられるのは、Webサービスの作成および利用のための明確に定義されたAPIと、分散トランザクションのサポートなど一連のコンポーネント・サービスです。ここでは、これらの欠けている要素についてそれぞれ検討していきましょう。.
- Webサービス固有のAPI ほとんどの分散コンポーネントインフラストラクチャでは、ランタイムの初期化、コンポーネントのインスタンス作成、コンポーネントを記述するために使用されるメタデータの反映といったタスクを実行するためのAPIが定義されています。ほとんどの高水準プログラミング言語はCとのある程度の相互運用性を備えているため、このAPIは通常、Cのメソッドシグネチャの単純なセットとして公開されます。 RMIはさらに一歩進んで、そのAPIを単一の高水準言語であるJavaと密結合させています。.
Webサービスがプログラミング言語に依存しないものとなるよう、マイクロソフトは、Webサービスのサポートを特定のプラットフォームに紐づけるかどうかについては、個々のソフトウェアベンダーの判断に委ねています。本書の後半では、.NETプラットフォーム向けの2つのWebサービス実装、すなわちASP.NETとRemotingについて解説します。.
- コンポーネントサービス このWebサービスプラットフォームは、リモートオブジェクトのライフサイクル管理、オブジェクトプーリング、分散トランザクションのサポートなど、分散コンポーネントインフラストラクチャに一般的に見られるサービスの多くを提供していません。これらのサービスの実装は、分散コンポーネントインフラストラクチャに委ねられています。.
分散トランザクションのサポートなど、一部の機能は、技術が成熟した段階で後から導入することも可能です。一方、オブジェクトプーリングや、場合によってはオブジェクトのライフサイクル管理などは、プラットフォームの実装上の詳細と見なすことができます。たとえば、Remoting ではオブジェクトのライフサイクル管理をサポートするための拡張機能が定義されており、Microsoft Component Services ではオブジェクトプーリングのサポートが提供されています。.
概要
コンポーネントベースのプログラミングは、開発者の生産性を大幅に向上させることが実証されていますが、一部のサービスは、クライアントのデータセンター内に存在するコンポーネントではカプセル化することができません。 DCOM、CORBA、Java RMI といったレガシー技術は、クライアントがインターネット経由でサービスにアクセスすることを可能にするには不向きであるため、マイクロソフトは一からやり直し、リモートサービスにアクセスするための業界標準の方法を構築する必要があると判断しました。.
ウェブサービス これは、アプリケーション間の最低限の相互運用性を実現するために使用される、業界標準のプロトコルやサービスの集合体を指す総称である。Webサービスが受けた業界からの支持は、かつてないほど大きなものである。これほど多くの大手テクノロジー企業が、実行されるプラットフォームを問わず、アプリケーション間の相互運用性を促進する標準規格を支持するために一丸となったことは、かつてなかった。.
Webサービスの成功要因の一つは、XMLやHTTPといった既存のインターネット標準に基づいて構築されている点にあります。その結果、テキストを解析し、標準的なインターネット転送プロトコルを介して通信できるシステムであれば、どのようなシステムでもWebサービスと通信することができます。また、企業はこれらの技術に対してすでに投じた投資を活かすことも可能です。.