コンポーネント戦争から学ぶこと: XML に関しての声明

コンポーネント戦争から学ぶこと: XML に関しての声明

Don Box
DevelopMentor

September 1999
日本語版最終更新日 2000 年 1 月 24 日

概要: この記事では、コンポーネント テクノロジーがどのように進化したか、そしてソフトウェア コンポーネントの相互運用に際して、自立した異種システム間のゲートウェイとしての役目を果たす手段としての XML (eXtensible Markup Language: 拡張可能なマーク付け言語) がどのように広く使用されるようになるかを述べます。

内容

• Lesson 1: 私の糊は、あなたの糊よりよい
• Lesson 2: その言語でプログラムするなんて信じられない
• なぜ XML なのか？
• まとめ
• その他の資料

コンポーネント ソフトウェアの主な目的は、ソフトウェア開発組織間の共同作業と協力を可能にすることにあります。しかし、過去 10 年間、コンポーネント テクノロジーは多くの議論、意見の相違、そして討論の原因となってきました。このような、コンポーネントによって引き起こされた摩擦は、次のような 2 つの要因に帰することができます。

• さまざまな組織と会社が、コンポーネント インフラストラクチャの標準的な提供者になりたいと考えています。
• コンポーネント テクノロジーは、さまざまなプログラミング文化が相互運用する機会を増やします。

この 2 つの要因の詳細な調査から学ぶべき教訓は少なくありません。この記事では、コンポーネント テクノロジーがどのようにして XML に進化したかを調べていきます。XML を知るためには、その前身をも知る必要があります。

Lesson 1: 私の糊はあなたの糊よりよい

結局、コンポーネント テクノロジーの主な機能は、複数のソフトウェア間の糊の役目を果たすことです。これは、Component Object Model (COM) についても、Java についても言えることです。また、Common Object Request Broker Architecture (CORBA) もそうです。この 3 つのテクノロジーはすべて、独立した組織によって書かれたソフトウェア コンポーネントを統合するためのインフラストラクチャを提供します。10,000 フィートの上空から見ると、この 3 つのテクノロジーは、多かれ少なかれ同じです。しかし、近寄ってみると、それぞれのテクノロジーが目的達成のために使用している技術とプログラミング スタイルは、根本的に異なっています。

コンポーネント テクノロジーの解剖

コンポーネント テクノロジーは、相互運用しようとしています。それぞれのコンポーネント テクノロジーがどの程度の相互運用を可能にしようとしているのかを見ると面白いと思います。このような相互運用の程度は、次のような階層モデルに従って捉えることができます。

図 1. 4 段階のコンポーネントの相互運用

メモリ内の相互運用

メモリ内での複数のコンポーネントの混在は、可能な限り最も深いレベルの相互運用です。すべてのコンポーネントが準拠しなければならないメモリ内表現を標準化することによって、コンポーネント テクノロジーは優れたパフォーマンスを提供することができます。さらに、標準化されたメモリ内表現を持つことによって、サポート ランタイムは、より幅広いコンポーネント管理サービスをかなり低いコストで提供することができます。

COM は、単純な C++ スタイルの仮想関数テーブルに基づいて、オブジェクト参照のメモリ内表現を標準化しています。これにより、あらゆるプラットフォームでのインプロセス COM のサポートが非常に容易になります (Netscape は、同社のクロスプラットフォーム Web ブラウザのために、まさにこれを行いました)。 Java は、コンポーネント コードの表現を標準化し、それぞれの仮想マシンは、独自のメモリ内オブジェクト表現を定義します。このアプローチの利点は、共通のコンポーネント形式に基づきながら、それぞれの仮想マシンの実装者が自由に改良できる点です。このアプローチの不利な点は、コンポーネントが相互運用するためには、同じ仮想マシン上で実行しなければならないことであり、それはバージョン対応の関係上、つねに可能というわけではありません。また、CORBA の本来の目的はオブジェクト ベースのリモート プロシージャ コール (RPC) システムを提供することだったので、CORBA 仕様はメモリ表現を断念しています。

ソース コードの相互運用

コンポーネント テクノロジーでは、しばしば、開発者はある種のアプリケーション プログラミング インターフェイス (API) に対して明示的にプログラムする必要があります。コンポーネント サービスにアクセスするための API を標準化することによって、ソース レベルでの相互運用が可能になり、コンポーネントのソース コードを別のベンダーによる実装に対して再コンパイルすることが可能になります (fork() や CreateFile()) などの OS 固有のシステム呼び出しシーケンスを除く)。

COM は、COM ライブラリと Co API (CoCreateInstance や CoInitializeEx など) を介して、サービスを公開しています。 Co API のかなりの部分は、複数のプラットフォーム (たとえば、Windows NT、Windows 95、Solaris、および Linux) にまたがって一貫しており、COM ソース コードを複数のプラットフォームで再コンパイルすることが可能です。CORBA 仕様は、CORBA 準拠と見なされるために ORB ベンダーがサポートしなければならない標準インターフェイスのセットを定義しています。このインターフェイスのセットは最低限と見なされ、ほとんどの ORB ベンダーは標準 CORBA API に独自の拡張を加えています。ほとんどの Java ベースのコンポーネント サービスは、言語に組み込まれており、必ずしも明示的な API を持っているわけではありません。このため、Java は、コンポーネントに関してはかなりトランスペアレントです。しかし、Java を批判する人は、ソフトウェアのすべてを Java プログラミング言語に移植しなければならず、基本的に、ソース コード全体を Java テクノロジーに縛り付けることになるという事実をしばしば引き合いに出します。

型情報の相互運用

コンポーネントが適切に統合されるためには、そのコンポーネントを利用するプログラマと下層のコンポーネント システムに対してコンポーネントを正しく説明する必要があります。3 つのコンポーネント テクノロジーはすべて、開発者とサポート インフラストラクチャによる利用のための型情報を表現する標準手段を提供します。

CORBA は、プログラミング言語に中立な方法でオブジェクトを記述できるテキスト ベースのインターフェイス定義言語 (IDL) を提供します。パブリックにアクセス可能なすべてのデータ型を IDL で定義することによって、ORB サポートを備えた任意のプログラミング言語から CORBA オブジェクトにアクセスすることが可能です。CORBA IDL は、ほとんどの CORBA 製品に統合する必要があります。COM も、多かれ少なかれ CORBA IDL に似たテキスト ベースの IDL を備えています (COM IDL の方が多くのデータ型をサポートしますが、CORBA IDL の方が作成と解析が容易です)。 Microsoft がいちはやく指摘しているように、COM IDL は技術的にはオプションです。しかし、ほとんどの COM ベースの開発プロジェクトで使用されています。COM と CORBA IDL は両方とも作成面では優れていますが、相互運用とその交換については、それほどではありません。テキスト ベースであるため、IDL 対応のツールとインフラストラクチャは、C プリプロセッサへの依存性や慎重を要する文法規則を持つ、かなりリッチな言語を解析しなければなりません。

この問題を解決するために、COM は、タイプ ライブラリと呼ばれるバイナリ形式の型情報も提供します。タイプ ライブラリは、COM IDL ファイルが持つ大部分の (すべてではありません) 情報を、システム付属のタイプ ライブラリ パーサーで容易に解析できる表現で含んでいます (詳細については、LoadTypeLib を参照)。すべての Java コンポーネントは標準の自己記述的なクラス ファイル形式に準拠しているので、追加の型情報サポートは不要です。Java 1.1 では、すべての Java 仮想マシンによって公開されるリフレクションサービスを使用して、コンポーネントのパブリック インターフェイスを参照することが可能です。

回線上での相互運用

コンポーネント テクノロジーの聖杯 (最終目的) は、分散コンピューティングです。コンポーネントは、しばしば、分散アプリケーションの構築を容易にする基盤技術と見なされます。この目的を達成する試みとして、コンポーネント テクノロジーは、しばしば、コンポーネントがホスト マシン間で通信できるように新しいネットワーク プロトコルを定義します。

Windows NT は Open Software Foundation の分散コンピューティング環境 (Distributed Computing Environment: DCE) RPC メカニズムを指向しているので、COM はフレーミングとトランスポートのために DCE RPC プロトコルを利用し、パラメータ コーディングには Network Data Representation (NDR) を使用します。分散 COM (DCOM) プロトコルは、オブジェクトの起動、強制型変換、およびライフ サイクル管理のための一握りの DCE RPC インターフェイスを定義しているだけです。本質的に、DCOM はもう 1 つの DCE RPC アプリケーションでもあります。

CORBA はさまざまなプロトコルをサポートしていますが、相互運用については Internet Inter-ORB Protocol (IIOP) が最も一般的なプロトコルです。 IIOP は、TCP の上で単純なフレーミングと会話管理を行い、パラメータ コーディングには共通のデータ表現 (Common Data Representation: CDR) を使用します。 Java は、ネイティブのリモート メソッド呼び出し (Remote Method Invocation: RMI) プロトコルである JRMP だけでなく、IIOP と CDR の両方をサポートします。JRMP は、おおむね Java シリアライゼーション形式に基づき、通常の TCP または HTTP で動作します。

コンポーネント テクノロジーと世界支配 !?

これまでの説明から明らかなように、ソフトウェア コンポーネントを統合するには、有効なアプローチがいろいろあります。上記の 3 つのテクノロジーには、それぞれ忠実で献身的な信奉者がいて、自分が選んだテクノロジーにかなりの資産を注ぎ込んでいます。この点だけを見ても、この 3 つのテクノロジーのいずれかが、近い将来、開発風景から姿を消すようなことはありそうもありません。

しかし、この 3 つのテクノロジーのいずれかがインターネットを独占することもありそうにありません。この 3 つのテクノロジーが使用するネットワーク プロトコルは、正しく機能するためには少なからぬ量のランタイム サポートを必要とする傾向があります。皮肉なことに、Microsoft と Object Management Group (OMG) がインターネットは DCOM または CORBA で動作するようになるかどうかを議論している間に、Hypertext Transfer Protocol (HTTP) が支配的なインターネット プロトコルになりました。他の多くの成功したインターネット プロトコルと同様、HTTP は単純で、テキスト ベースであり、適切な動作のためにランタイム サポートを必要とすることがほとんどありません。さらに、多くの企業は DCOM と CORBA トラフィックをファイヤウォールでブロックしていますが、HTTP パケットが自分たちの保護されたネットワークに入ってくるのは許しています。そして最後に、HTTP サーバー (たとえば、Internet Information Server (IIS) や Apache) をスケーラブルで、信頼性が高く、管理しやすくするために注ぎ込んでいる技術的労力を考えると、HTTP テクノロジーを使用してソフトウェア コンポーネントを公開しない理由を見つけるのは難しいでしょう。

Lesson 2: その言語でプログラムするなんて信じられない

プログラマがコンポーネント テクノロジーやオペレーティング システムに基づいて自分を分類することはめったにありません。同様に、プログラマが問題領域に基づいて自分を分類することもめったにありません。その代わりに、プログラマはプログラミング言語に基づいて自分を分類してきました。「私は UNIX プログラマだ」という言い方をしないわけではありませんが、「私は C++ プログラマだ」とか、「私は VB プログラマだ」と言う方が一般的です。結局、プログラマは自分が選んだプログラミング言語に入れ込むものであり、自分の問題領域やサポート テクノロジーで経験を積むことを犠牲にすることも少なくありません。

これまでの 6 年間を「COM プログラマ」として過ごしてきた者として、私はさまざまなプログラマを見てきましたが、誰もが COM を自分のコンポーネント モデルとして採用していました。COM のように言語中立なコンポーネント モデルによる標準化は、他のプログラミング環境に対するプログラマの心を広くすると思われるかもしれませんが、これまでの私の経験では、まったく反対です。

COM は他のプログラマとの共同作業や協力の可能性を広げますが、それは意見の食い違いも増えることを意味します。多くの C++ 開発者は、多くの Visual Basic (VB) ショップの信条となっている「突っ立ってないで、何かを送り出せ」という倫理にぞっとしています。それと対照的に、多くの VB 開発者は、多くの C++ プログラマが 3 関数 API にさらにもう 1 つのテンプレート ベースの汎用ラッパーを書き込むときに見せる構文への没頭を面白がっています。このような、カルチャー ショックは、それぞれのプログラミング環境が提供する COM サポートの程度の違いによって悪化するばかりです。C++ プログラマは、VB で任意のポインタと配列がサポートされないことを制約と感じます。逆にVB プログラマは、バージョニング、グローバル一意識別子 (GUID) の管理、インターフェイスとイベントのサポートに関して、自分たちだけの不満が書かれたリストを持っています。

私が長年の間に気づいた中で最も興味深い衝突の 1 つは、型指定が強いシステムと型指定が弱いシステムの間の緊張です。C++ 開発者は、最初から強い型指定を好むように訓練されます。これは、「コンパイル時エラーの方がランタイム エラーより好ましい」という Bjarne Stroustrup (C++ の発明者) の呪文にまで溯ることができます。VB プログラマは、型指定が弱いシステムを好む傾向があります。おそらくこれは、(現在の Variant データ型に現れているように) 元々のBASIC 言語には型指定された変数のサポートがなかったことが原因です。あるいは、この傾向は、Visual Basic プロジェクトは一般に期間が短く、強力な型指定の時間 (または必要性) がないからかもしれません。

強い型指定の方が弱い型指定より優れているという清教徒的なソフトウェア エンジニアリング姿勢を取り、その戒律を犯しているといって VB プログラマを糾弾することは簡単です。しかし、VB プログラマが作成するアプリケーションの多くは、弱い型指定に適しています。特に、使い捨てや短期間しか使われないコードについては、このことが言えます。企業内の開発部門 (VB の主な要塞) によって開発されるアプリケーションの多くは、2 名以上または 2 年以上の使用を目的としたものではありません。そうではなく、一時的なものであることが多い目前のビジネス ニーズを満たすためにコードが書かれます。現在の Web 開発の大半も、このカテゴリに分類されます。ほとんどの商用 Web サイトは、消費者の注意を引きつけておくために、また、より新しい Web テクノロジー (たとえば、Dynamic HTML (DHTML)) を利用するために、毎月のように変更されているからです。

VB プログラマが弱い型指定を好むということは、彼らが ActiveX Data Objects (ADO) レコードセットを愛用するという事実に端的に現れています。ADO レコードセットは、汎用性と拡張性を備えた自己記述的なデータ構造であり、ほとんどの VB プログラマが VB そのものと同じぐらい、それに依存するようになっています。ADO レコードセットは、もともと API をデータベースに提示するために作られましたが、データベースが使用されない場合でも役立つ汎用のデータ構造に進化しました。VB プログラマがコンポーネント インターフェイスを主にレコードセットとして定義するのは、きわめて一般的なことです。レコードセットは値によって容易に整列できるので、VB プログラマが利用できる他のどのオブジェクト ベースのソリューションよりも、効率的なデータ転送が可能です。また、レコードセットが使用するスキーマは、コンパイル時ではなく実行時に定義されるので、レコードセットは COM 形式のインターフェイス バージョニングを必要としない、インターフェイスの進化のための「裏口」を提供します。このスタイルの進化は、デメリットがないわけではありません。レコードセット スキーマを変更するには、バージョン ネゴシエーションをアプリケーション レベルにおいて手動で行う必要があるからです。しかし、一部の開発状況では、これは問題ではありません。

なぜ XML か？

多くの人は、XML を 4 番目のコンポーネント統合テクノロジーと見なしています。XML は、もともと HTML に拡張機能を追加するためのソリューションとして設計されましたが、たちまち、異種混合のコンポーネント ベース システムを統合するためのテクノロジーとして選ばれるようになりました。それは、以下のような理由によります。

XML は最小のコンポーネント標準である

前述した相互運用の 4 つのレベルを思い出してください。上記の図 1 で示したように、XML は基本的に、データとメッセージを交換するために必要な最低限の回線上の表現を定義します。これはコンポーネントがコミュニケーションするために必要な最低限のレベルの標準化です。コア XML 仕様は、非常に単純です。妥当 (valid) な XML メッセージを形成するための構文的な基本原則を定めているだけです。World Wide Web Consortium (W3C) は XML の上に次々と追加の標準を重ねていますが (XLink や XML スキーマなど)、基本の XML 構文はかなり安定しています。基本の XML 構文は、柔軟性に富み、多くのアプリケーションに適用可能であることが実証されており、その階層的な性質にもかかわらず、XML は非階層的なデータ型にも適しています。

XML は、それ自体では型情報表現を義務化していません。XML には、文書型定義、すなわち DTD (Document Type Definition) と呼ばれる、XML データ ストリームを記述するための標準メカニズムが用意されています。DTD は、妥当性を検証する XML パーサーの構築に役立ちますが、いくつかの問題があります。1 つには、DTD は、読んだり、書いたりするのが非常に難しいということです。DTD の構文は XML ではなく、XML に似た (同じではありません) DTD 固有の文法だからです。DTD 自体は妥当な XML ではないので、インフラストラクチャおよびツール ベンダーは、2 組のパーサー、エディタ、および API を開発する必要があります。1 組は XML 用、もう 1 組は DTD 用です。さらに悪いことに、DTD は範囲指定と名前空間の処理が苦手なので、いろいろと面白い状況でそれらを使用することができません。現在、多くの XML ベースのシステムは、独自の型情報表現を XML ボキャブラリーとして定義しているにすぎません。Microsoft などによって提案された XML データ仕様は、このようなボキャブラリーの一例でもあります。

コンポーネント統合テクノロジー

XML は、メモリ内のコンポーネントまたはオブジェクト表現を解決しようとはしません (XML データ ストリームは解析の前にメモリに読み込むことができるという事実を除いて)。W3C は、Document Object Model (DOM) と呼ばれる API 勧告の作業を進めていますが、この API は勧告にすぎず、アプリケーションまたはシステムで XML をホストするために必要なものではありません。

XML はプラットフォームであり、言語であり、ベンダーに寛容である

プラットフォーム ベンダーやオープン ソース信者の願いにもかかわらず、コンピューティングの世界はこれからも、さまざまなプログラミング言語、オペレーティング システム、およびコンピューティング ハードウェアで構成されていくことでしょう。XML は単なる回線上の表現にすぎないので、1 つのオペレーティング システム、プログラミング言語、あるいはハードウェア アーキテクチャに特別な親和性を持つことはありません。2 つのシステムが XML メッセージを交換できる限り、システムに違いがあっても、相互運用できる可能性があります。XML は API やメモリ内表現を義務化していないので、アプリケーションで XML をホストするのは、かなり単純です。ほとんどの (すべてではありません) プログラミング言語に対応した XML パーサーを自由に入手することができます。XML を解析するための標準化されたプログラマティックなインターフェイスがいくつかありますが (W3C、DOM、SAX など)、他の XML ベースのシステムと相互運用するために、どうしてもAPI をサポートしなければならないということはありません。

XML はとっつきやすい

XML は、信じられないほど、わかりやすく、読みやすく、書きやすいです。このとっつきやすさが、XML の急速な普及の鍵でした。DCOM、CORBA、または Java/RMI などのバイナリ プロトコルと違って、XML メッセージは単純なテキスト エディタやスクリプティング言語を使用して作成することができます。多くの XML パーサーはウエルフォームド形式 (整形式) の XML を生成するための機能を提供していますが、自分の使い慣れたプログラミング言語の標準的な文字列操作機能を使用して XML を生成することも可能です。このような、単純なテキスト ベースという XML の性質は、分散アプリケーションのデバッグと監視も容易にします。そして、ネットワーク監視ツールを使用すれば、すべてのコンポーネント間メッセージを読むこともできます。

XML は拡張可能である

拡張性のないシステムは、悪ければ失敗、よくても月並みに終わる運命にあります。XML は、任意の関係者が特定の XML データ ストリームを拡張するための、かなりエレガントなメカニズムを提供します。XML 名前空間は、Uniform Resource Identifier (URI) 名前空間を利用して、任意の属性と要素を既存の XML ボキャブラリーに追加することを可能にします。たとえば、次のような単純な XML コードがあるとします。

<order orderno="33512">
    <customer custno="4462" />
    <item itemno="3352" />
    <item itemno="1829" />
</order>

このコードは、顧客番号 4462 が品目 3352 と 1829 を注文していることを示しています。このコードの送り手と受け手の双方が、この意味を理解しているのであれば、何も言うことはありません。しかし、メッセージの送り手がこのメッセージに追加情報で注釈を付けたい場合はどうでしょうか (たとえば、この注文に識別番号を追加して、より大きな金融取引に関連付ける)。送り手は次のような属性を追加すればよいと思う人もいるかもしれません。

<order orderno="33512" transid="55291">
    <customer custno="4462" />
    <item itemno="3352" />
    <item itemno="1829" />
</order>

しかし、メッセージの受け手は、送り手のアプリケーションとは別に開発されたかもしれないので、いくつか潜在的な問題があります。1 つには、受け手は、追加の属性または要素をメッセージに追加することを許すかもしれないし、許さないかもしれません。受け手がこの属性の存在を解析エラーと見なした場合、要求は失敗します。この問題を解決するために、新しい XML 記述テクノロジー (Microsoft XML Data など) では、XML ボキャブラリーをオープンまたはクローズドのいずれかとして定義できるようになっています。クローズド ボキャブラリーは、ベース ボキャブラリー スキーマでの記述を超えて拡張することはできません。オープン ボキャブラリーは拡張が可能ですが、受け手のアプリケーションが拡張された要素と属性の解釈の仕方を知っている必要があります。アプリケーションによっては、認識できないボキャブラリー拡張は無視されます。

前述の注文メッセージがオープンな XML ボキャブラリーの一部であれば、transid 属性を追加しても問題はないはずです。しかし、要求の受け手もボキャブラリーを拡張したい場合はどうでしょうか。特に、受け手が注文を低レベルのデータベース トランザクションに関連付けるための新しい属性を定義していたとしたら？ 受け手が transid を属性の名前として選んでいた場合、送り手の金融取引 ID は低レベル データベース トランザクション ID と誤解されるでしょう。この問題を解決するために、W3C は XML に名前空間を追加しました。

XML 名前空間は、URI による属性と要素の範囲指定を可能にします。次の XML の断片は、XML 名前空間を使用すると、注文要求に transid 属性をあいまいにならないように追加できることを示しています。

<order orderno="33512"
       xmlns:fin="http://money.org/FinancialXML/ns"
       fin:transid="55291" >
    <customer custno="4462" />
    <item itemno="3352" />
    <item itemno="1829" />
</order>

受け手がこの XML の断片を解析するとき、transid 属性は名前空間 http://money.org/FinancialXML/ns によって範囲指定されていて、データベース トランザクションを表すための transid 属性とは違うものであることを検出できます (名前空間 URI が違うので)。実際、XML 名前空間を使用すれば、同じ要求の中に両方の transid 属性があっても、あいまいさは生じません。

<order orderno="33512"
       xmlns:fin="http://money.org/FinancialXML/ns"
       xmlns:db="urn:xmltpc:XMLTransactions"
       fin:transid="55291"
       db:transid="46722" >
   <customer custno="4462" />
    <item itemno="3352" />
    <item itemno="1829" />
</order>

今でも XML ベースの型記述には大きな努力が傾けられていますが、XML 名前空間は、今までに W3C から出された基本 XML に対する拡張として最も有力です。

XML は、望みどおりの強さの型指定が可能である

オープン ボキャブラリーと名前空間の使用により、XML は弱い型指定のコミュニケーションをサポートすることができます。強い型指定には多くの利点がありますが (そして、DTD などの使用によって XML でサポートされていますが)、XML を使用して、弱い型指定システムを構築するのは非常に簡単です。このため、XML は、汎用のアプリケーション フレームワーク、データドリブン型アプリケーション、および迅速な開発シナリオ (たとえば、使い捨てや一時的な Web ベース アプリケーション) に対してきわめて柔軟に対応できます。このような線に沿って、多くの ADO レコードセット マニアは、クロスプラットフォームという利点だけでなく、表形式以外のデータに対する優れたサポートという点でも、レコードセットに代わるデータ転送メカニズムとして Microsoft XML パーサー (MSXML) を使用しています。

XML は独自の相互運用性問題を解決できる

コンポーネント統合テクノロジーとして XML を採用するだけで、相互運用性問題が完全に解決されるわけではありません。特に、業界の大半が XML を相互運用性テクノロジーとして歓迎しているとしても、これは相互運用性問題を 1 つ上のレベルに押し上げるにすぎません。たとえ業界全体が一夜にして XML に移行したとしても、それだけでは意味がありません。異なる組織が異なる XML ボキャブラリーを使用して、まったく同じ情報を表現する可能性があるからです。当然ながら、領域固有の XML ボキャブラリーを標準化しようという業界規模のイニシアチブはあります (BizTalk、FinXML、OASIS など)。しかし、これらの努力が特定のアプリケーション領域で 100 パーセントの普及率を達成できるかどうかはまだわかりません。

幸い、標準化ボキャブラリーの欠如は、XML テクノロジーを使用して解決することができます。特に、2 つの競合するボキャブラリーが存在する場合、アプリケーション レベルのゲートウェイは、要求をボキャブラリー "A" からボキャブラリー "B" に変換するでしょう。XML 変換には、さらに有望なソリューションが存在します。XML 変換により、変換規則を指定することによって(もちろん XML で)、ある XML ボキャブラリーを別の XML ボキャブラリーに変換することができます。XML 変換は、もともと XML を HTML にマップするために考案されましたが、現在では、はるかに興味深い多様なシナリオで応用されています。

まとめ

毎年のように、コンピュータ業界は新しいテクノロジーをソフトウェア開発の「聖杯」として選定しています。業界紙は派手に書き立てて、その道の権威に従った雄大なテクノロジー ビジョンを概説した勅令を伝えるように管理職を動かします。XML も、このばか騒ぎの犠牲になるのは間違いありません。

このような誇大宣伝にもかかわらず、XML はあなたの問題のすべてを解決するわけではありません。XML は、ソフトウェア開発期間の短縮に役立つかもしれないし、役立たないかもしれません。XML が C++ や Java などのプログラミング言語に取って代わることはありません。XML が COM や Java などのプログラミング テクノロジーに代わることもないでしょう。しかし、XML は、ソフトウェア コンポーネントが相互運用するための手段として広く使用されるようになり、自律した異種システム間のゲートウェイの役目を果たすようになるでしょう。この役割こそが、XML が本当に卓越しているものなのです。

その他の資料

• Extensible Markup Language (XML) 1.0 (W3C Recommendation)
• Namespaces in XML (W3C Recommendation)
• RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax
• RFC2068: Hypertext Transfer Protocol - HTTP/1.1
• XML-Data (W3C Note)
• XML-Schema Part 1: Structures (W3C Working Draft)
• XML-Schema Part 2: Datatypes (W3C Working Draft)
• XML In Action, by William J. Pardi, Microsoft Press
• John Lam および Aaron Skonnard 著「Architecting Your Web Applications」(Microsoft Internet Developer (MIND) 1999年9月号) を参照。