![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
XMLベースの新しいテクノロジーがいかに実用的であるかを論じる連載の第1回の記事にようこそ。この連載では、あるXMLテクノロジーを紹介し、それを実用的なシステムに配置しようとする試みを示します。配置に関するレポートとともに、ちょっとしたユーモアも含めるつもりです。読者が豊富な予備知識を持っていることは想定していませんが、XMLやHTTPといったWebの標準的な基礎知識があれば理解しやすいでしょう。
ビギナーのために、最初のいくつかの記事では、Webサービスという鍋物の中にふんだんに盛り込まれている略語という食材の1つ、BEEPについてご紹介します。今回の記事の目的は、BEEPプロトコル・フレームワークについて紹介し、どんな分野にこれを適切に使用できるかを示唆することです。
BEEPはBlocks Extensible Exchange Protocol (ブロック拡張可能交換プロトコル) の略ですが、単にBEEP と言ってもほとんど意味は変わりませんし、その方がブザーのようでおもしろく聞こえます。しかし、XMLユーザーにとってはExtensible (拡張可能) という言葉が気に掛かるでしょう。実際、BEEPの価値を高めているのはこの拡張性です。詳しくは後で述べるとして、まずはBEEPがどんな問題を解決してくれるか見てみましょう。
あなたがネットワーク・アプリケーションを書いているとしましょう。プログラムのインスタンスにTCP/IPを介して通信させるとします。ここで、アプリケーションの論理そのものに取りかかる前に、プログラムがどのように接続し、相互に認証し、メッセージを送受信し、エラーを報告するかを考えなければなりません。こうしたことに費やす累積時間は、アプリケーション論理そのものに費やす時間より多いかもしれません。一言で言うと、BEEPはこの問題を解決してくれます。BEEPは新しいネットワーク・プロトコルの作成環境を改善するいわば「衛生要因」を実装しますから、開発者がこうしたことを心配する必要はありません。
ここで読者は、CORBA/IIOP、SOAP、XML-RPCなどがあるのに、なぜ分散コンピューティング・プロトコルがもう1つ必要なのかと疑問に思うかもしれません (それも無理はありません)。その答えは、BEEPがそれらとは異なるレベルにあるからです。BEEPはフレームワークです。BEEPの上にSOAPを首尾よく実装することができます。BEEPはメッセージのTCP/IPレベルでの接続、認証、パッケージ化を担当しますが、SOAPはこれらを意図的に避けています。BEEPは実際にHTTPと同じレベルで競い合います。
最近のアプリケーション・プロトコルの設計者たちはHTTPに注目し、その便利さを実感してきました。確かにHTTPはかなり便利です。Windowsの「ネット・フォルダー」機能の基礎となっているプロトコルWebDAVでも、分散オーサリングを可能にするためのverbをいくつかHTTPに追加しました。Internet Printing Protocolでは、HTTP/1.1の機能を利用するためのHTTPヘッダーがいくつか発明されましたし、SOAPをHTTPにバインドしても同様の機能が得られます (HTTPのこれら3つの使用形態については、参考文献を参照してください)。
おおまかに言って、これらは適切な動きです。どこにでもある普及したHTTPプロトコルが、効果的に再利用されているのです。しかし残念な結果もいくつか見られています。第1に、ポート80の過負荷です。Webページ要求だけでなく、セキュリティーを重視するビジネス要求までもが今や80ポートを通して送られていますから、より一層の注意が必要になりました。ポート80に影響を与える、Webキャッシュその他のデバイスとの頻繁な対話を考慮に入れる必要が出てきました。これらの問題は別の個所で詳しく扱われていますから (参考文献を参照)、この記事では詳細に述べません。
HTTP再利用の第2の結果は、HTTPの対話モデルに拘束されることです。HTTPはステートレスで要求 / 応答指向のプロトコルです。応答を伴わない要求は存在せず、要求を伴わない応答もありません。さらに、複数の要求の間で状態が保持されません。残念ながら、いくつもの対話方式においてこれは不便です。非同期、ステートフルな対話、ピアツーピア通信などを排除してしまうからです。こうした問題はHTTPの上に層を築くことで回避可能であり、実際にそうされてきましたが、このような解決策は使いにくいものとなっています。
経験豊富なプログラマーであれば、ここでリファクター すること、つまりシステムの責任を適切なレベルに設定し、共通の機能を抽象化することを提案するでしょう。BEEPはまさにそれを行います。最近のインターネット・アプリケーション・プロトコルに共通する要件をサポートするために、過負荷状態のHTTPをリファクターします。
前置きはもう十分でしょう。BEEPにはどんな機能があるか、どんなふうに利用できるのかを検討します。
BEEP仕様の作成者Marshall Rose氏によると (参考文献を参照)、BEEPがターゲットとする「市場」は以下のようなアプリケーションです。
- 接続指向: BEEPを使ってデータを受け渡しするアプリケーションは、接続し、ビジネス取引を行い、そして切断します。このため通信は順序を持ち、信頼性が高く、輻輳 (ふくそう) をきめ細かに扱うという特性を持ちます。(IPレベルで並列化することにより、多くの点でUDPよりもむしろTCPと同じ特性を持ちます。)
- メッセージ指向: BEEPを使ってデータを受け渡しするアプリケーションは、構造化データの定義済みバンドルを使って通信します。つまり、相互に通信している複数のアプリケーションは疎結合され、互いのインターフェースについて詳細に知っている必要がありません。
- 非同期: HTTPとは異なり、BEEPは要求と応答の特定の順序付けに制限されません。非同期によってピアツーピア形式の通信が可能になりますが、従来のクライアント / サーバー通信を排除するわけでもありません。
これらの特性は潜在的にかなり広範囲のアプリケーションを包含します (たとえばHTTP、FTP、SMTP、およびさまざまなインスタンス・メッセージング・プロトコルの再実装が可能です)。その一方で、BEEPの有効範囲に入らないアプリケーションも数多くあります。この範疇に属するのは、DNSルックアップのような単発的な交換です (DNSルックアップの場合、BEEP導入のコストは得られる利益と釣り合いません)。または、NFSのような密結合のRPCプロトコルもこれに該当します。
アプリケーションがこの「ターゲット市場」に当てはまる場合、BEEPはどんな機能を提供するのでしょうか。主な機能は次のとおりです。
- 1つのメッセージを次のメッセージから分離する (フレーミング)
- メッセージをエンコードする
- 複数の非同期要求を可能にする
- エラーを報告する
- 暗号化をネゴシエーションする
- 認証をネゴシエーションする
開発者はこれらの機能について心配する必要がないので、他のさまざまな機能をネットワーク・アプリケーションに自由に付け加えることができます。たとえば、メッセージのタイプや構造を考慮できるでしょう。
BEEPはピアツーピア・プロトコルであり、HTTPのようなクライアント / サーバーの概念がありません。しかし口論や恋愛と同じく、誰かが最初のきっかけを作らなければなりません。説明のために、接続を開始するピアをイニシエーター、接続を受け入れる側のピアをリスナー と呼ぶことにします。両者の間で接続が確立されたとき、BEEPセッションが作成されます。
図1. BEEPセッション、チャネル、およびプロファイル
セッションのすべての通信は、1つまたは複数のチャネル 内で行われます (図1を参照)。2つのピアはただ1つのIP接続を必要とし、それが多重使用されて複数のチャネルを形成します。特定のチャネルの中でどんな通信が可能であるかは、チャネルのサポートするプロファイル によって決定されます (各チャネルごとに、1つまたは複数のプロファイルがあります)。
最初のチャネルchannel 0には特別な目的があります。このチャネルは、後続のチャネルのセットアップをネゴシエーションするためのBEEP管理プロファイルをサポートします。サポートされているプロファイルは、特定のチャネル内で2つのピアが行う対話を厳密に決定します。BEEPを使用したプロトコルの定義とは、結局のところプロファイルの定義です。
セッションが確立された後、イニシエーターは必要な特定のプロファイル (またはプロファイルのセット) 用のチャネルを開始するよう要求します。リスナー側がその (それらの) プロファイルをサポートしていれば、チャネルが作成されます。プロファイルそのものは、初期調整用、またはデータ交換用の2つの形式のいずれかです。
調整プロファイルは通信の開始時にセットアップされ、そのセッションの残りの部分に影響を与えます。たとえばTLSプロファイルを要求すると、Transport Layer Securityを使って各チャネルが暗号化されるようになります。その他の調整プロファイルは、認証などのステップを実行します。
データ交換プロファイルは、チャネルにおいて2つのピアの間でどんな交換が許可されるかを設定します。これは、対話するオブジェクト間でどんなメソッドが使用できるかを設定するJavaインターフェースに似ています。XMLネームスペースと同様に、プロファイルはURIで識別されます。たとえば、BEEP Javaツールの "Echo" プロファイルのURIはhttp://xml.resource.org/profiles/NULL/ECHOです。
BEEPは、チャネルでやり取りできるデータの種類に制限を設けていません。BEEPは任意のタイプのペイロードをサポートするためにMIME規格を使用します。SOAPメッセージ内部でXML文書やバイナリー・ファイルをどのように送るかというSOAPの問題は、この方法によってうまく回避されます。
この記事の冒頭で、BEEPはXMLを利用していると私は述べましたが、読者はこの点をすでに忘れてしまったか、あるいは一体どこでXMLを利用しているのかと不思議に思っていることでしょう。実際、チャネル開始を担当するBEEP管理プロファイルはXML DTDとして定義されます (管理プロファイル定義のポインターについては、参考文献を参照してください)。XMLとBEEPはこの点で深いつながりがあるのです。BEEPはプロトコルのインフラストラクチャーを担当し、XMLはデータ構造を担当します。したがって、BEEPプロファイルでメッセージ構文を定義するとき、自然にXMLを選択することになります (ただし、上記のように任意のMIMEタイプをプロファイルで使用できます)。
チャネル管理プロファイルのほかにも、さまざまな新しいBEEPアプリケーション・プロファイルがXMLを使ってメッセージをエンコードします。これは歓迎すべきことです。XML文書を使って定義された既存のすべてのメッセージ交換標準は、比較的簡単にBEEPプロファイルにマップされるからです。
この記事では、BEEPを使用すべき基本的理由は何か、BEEPはどんなアプリケーション分野をターゲットとしているかについて簡単に述べました。BEEPの対話のしくみを、きわめて簡潔に説明しました。次回の記事では、チャネルやプロファイルを使ってどのように通信が行われるかを詳細に説明し、Javaでの実装例を示します。
-
beepcore.org はBEEP仕様の本家であり、さまざまなツールをWebに公開しています。
- この記事でご紹介したBEEPコアはRFC 3080 に定義されています。
-
xml-dist-app メーリング・リストには、HTTP再利用の利点その他に関する非常に多数の討論が掲載されています。
- Keith Moore氏によるInternet DraftOn the use of HTTP as a Substrate for Other Protocols は、HTTPの適切な再利用について推奨しています。
- developerWorksのWeb servicesゾーンには、SOAPおよび関連テクノロジーに関する情報が多数紹介されています。
-
WebDAV.org はWebDAVについてより詳しく紹介しています。
-
Internet Printing Protocol はInternet Printing Protocol (IPP) の背景を詳細に説明しています。
Edd Dumbill氏はXML.com の編集長であり、XMLデベロッパーのためのニュース・サイトXMLhack の編集者兼発行者でもあります。Programming Web Services with XML-RPC (O'Reilly) の著者の1人であり、生命科学の知的財産を交換するPharmalicensing の共同設立者兼アドバイザーです。EddはXML Europe コンファレンスのプログラム司会者でもあります。
