このシリーズの第1回では、どんな場合にXMLのデータ・バインディングを使用するかについて説明し、そしてデータ・バインディングのために利用できるいくつかのJavaフレームワークの概要を示しました。第2回では、サンプル文書を使用することにより、そのうちのいくつかのフレームワークのパフォーマンスを調べました。この第3回では、優れたテスト・スコアを示す新しいJiBXフレームワークについて詳しく説明します。まず、第2回で紹介したJiBXの基本的な点を改めて説明することにします。

JiBXは、もともとJavaテクノロジーにおけるXMLデータ・バインディングのパフォーマンスの限界を試すという私の実験から生まれたものです。それが実験の段階を超えたものになったため、私がJava中心 方式と呼ぶものの実験台として、それを利用することにしました。Java中心方式は、XMLの文法からオブジェクト・モデルを生成するために使用されるXML中心 方式とは逆のアプローチです。そのため、JiBXは、既に確立されているデータ・バインディング用フレームワークとはいくつかの点で意図的に異なるものになっています。

それらの相違点の中心になるのは、文書のアンマーシャリング時に使用される構文解析の技術です。既存のフレームワークは、いずれも広く使用されているSAX2のプッシュ型パーサーAPIに基づいています。JiBXは、新しいプル型パーサーAPIを使用しています。それにより、文書中の要素の列を処理するためのさらに自然なインターフェースが提供されます。このように、使用するAPIが違っているため、JiBXでは、アンマーシャリングを処理するコードとして比較的シンプルなものを使用することが可能です。

アンマーシャリングのためのコードがシンプルであることが、JiBXと他のフレームワークとの間の主な相違点の2番目です。つまり、他のフレームワークの場合には、独自のデータ・クラスを生成するか (アプリケーションではそれらのクラスを使用することが必要になる)、あるいはJava仮想マシン (JVM) にとって既知のクラス情報を使用してデータへの間接ランタイム・アクセスを提供するリフレクションと呼ばれるテクニックを使用するか、のいずれかになります。JiBXでは、既存のクラスに追加されるコードを使用します。それは、Javaコンパイラーの生成するバイナリー・クラス・ファイルと直接連動することになります。これにより、高速なデータの直接アクセスが実現され、しかもプログラマーが制御可能なクラスで動作するという柔軟性が保たれます。

JiBXの相違点の3番目は、このように既存のクラスを使用するということと関係があります。JiBXはバインディング定義ファイルを読んで、クラスに追加されるコードによるインスタンスとXMLとの間の変換方法を制御します。このような方式を採用しているデータ・バインディング・フレームワークはJiBXだけではなく、たとえばCastorもこの方式を使用していますが、JiBXは独自クラスとXML文書の間の関係を変更できるという点で他のフレームワークよりも大きく前進しています。

この記事の残りの部分では、上記の3点について詳しく説明します。実際のプロジェクトで別のフレームワークを使用するとしても、JiBXについてのこの説明を読めば、有益なヒントを得られることでしょう。

データ・バインディングの用語

以下は、この記事で使っている用語のミニ辞典です。

マーシャリングとは、メモリー内のオブジェクトのXML表現を生成する処理のことです。それには、元のオブジェクトからリンクされているオブジェクトも含まれることがあります。

アンマーシャリングとは、マーシャリングの逆の処理であり、XML表現からメモリー内にオブジェクトを (場合によってはリンク先オブジェクトのグラフ構造も) 生成します。

マッピングとは、オブジェクトとXML文書との間のマーシャリング/アンマーシャリングに使用する一連の規則です。文法に基づくコード生成を使用するデータ・バインディング方式では、生成されるオブジェクトに暗黙のマッピングが組み込まれていますが、JiBX (および他のいくつかのフレームワーク) では、明示的なバインディング定義を使用してマッピングを制御します。

文法とは、XML文書群の構造を定義した規則集です。XML仕様で定められている文書型定義 (DTD) 形式は、そのような文法の一種です。さらに、W3CのXML Schema形式 (以降「Schema)」も、文法として徐々に定着しつつあります。

上に戻る

プル方式によるパフォーマンス向上

JiBXと他のデータ・バインディング・フレームワークとの最も大きな違いは、入力XML文書の処理方法です。Java言語のためのXMLパーサーのほとんどには、アプリケーション・プログラムで使用するためのSAX2 APIが実装されています。このAPIは年月をかけて磨き上げられてきたものであり、数多くのパーサーの実装においてサポートされています。その中には、現在利用可能なもののうち最も機能豊富なものも含まれています。

SAX2 APIは広く使用されてはいますが、多くのXML処理に関していくつかの大きな欠点があります。それらは、SAX2に実装されているインターフェースのスタイル、つまりプッシュ構文解析方式によるものです。プッシュ構文解析では、パーサーAPIによって定義されるインターフェースを実装するメソッドをコード内に定義します。そして解析対象の文書と共に、それらのメソッドを (ハンドラーの形で) パーサーに渡します。パーサーは文書のテキストを読んでいき、XMLの規則に従ってそれを解釈し、文書のコンポーネント (要素や文字データ内容など) が出現したなら、ハンドラー・メソッドを呼び出すことによって報告します。パーサーが入力文書の処理を終了すると、アプリケーションに制御が戻りますが、その時点でもパーサーは制御を得たままです。

VBの変数を使用する方法

この方式の問題点は、今パーサーが文書のどこを解析しているのかをハンドラー・コードが常に認識していなければならず、それに応じてコンポーネントを解釈しなければならない、ということにあります。最も基本的なレベルにおいて、単純なテキスト値を内容とする要素は、3つ (またはそれ以上) の別個のコンポーネントとして報告されることになります。つまり、最初に開始タグ、次にテキスト (複数の部分に分かれる場合がある)、最後に終了タグという3つのコンポーネントです。一般にハンドラーでは、終了タグが報告されるまでテキストを蓄積しておき、終了タグが報告された段階でテキストに対して何らかの処理を実行することになります。その「何らかの処理」は、開始タグの属性などの他の要因によって影響を受けることがあるため、それらを含めて多くの情報を保持しなければなりません。その結果、プッシュ型構文解析のハンドラー・コードでは、たくさんのString を要素名と比較するためのif ステートメント (あるいはそれに相当するjava.util.Hashtable) が延々と続くことがよくあります。これは、コーディングの点でも保守の点でも面倒であり、効率が悪いことは言うまでもありません。

プル型構文解析では、構文解析イベントの報告方法を逆にしています。つまり、パーサーがハンドラーのメソッドを呼び出して文書コンポーネントを報告するのではなく、プログラムからパーサーを呼び出すことによって、各コンポーネントを順番に取得していくのです。それによりパーサーは、実質的に文書コンポーネントの間を移動するための反復子ということになります。この方法でコーディングするなら、状態情報はコード内に自然な形で保たれることになります。一例として、テキストを内容とする要素について考えてみましょう。その場合、処理する要素の内容がテキストであることを前提とし、単にそれを直接処理するようにコーディングすることもできます。つまり、開始タグを取り出すために1回、内容を取り出すために 1回、そして終了タグを取り出すために1回呼び出す、ということです。

しかし、もっとうまい方法として、テキスト値を内容とする任意の 要素を処理する1つのメソッドをコーディングし、期待される要素名をパラメーターとしてそのメソッドを呼び出して、そのメソッドからテキスト内容が戻されるようにすることができます。期待される要素がないならエラーが戻されるようにします。この方法は、XMLからオブジェクトを生成 (つまりアンマーシャリング) する場合に特に便利です。XML文書のほとんどでは子要素の順序が固定されているため、特定の要素の子を処理することは、単にこのメソッドを何度も呼び出すだけの処理になります。これは、SAX2のようなハンドラー方式に比べて、シンプルかつ高速です。

上に戻る

コンテキストを見失うことがない

JiBXでは、単一メソッドによる複数のパーサー操作を組み合わせるというこの方式を大幅に採用しています。内部プル型パーサー・インターフェースを、要素や属性のさまざまなアクセス方式を定義するアンマーシャリング・コンテキスト・クラスでラップしています。それらのメソッドでは、構文解析を処理すると共に、データをプリミティブ型に変換する処理も実行します。さらに、固有識別子によるオブジェクトのトラッキングなど、特殊化された操作もそれらのメソッドで実行されます。それらのメソッドには、たとえば次のものがあります。

• parsePastStartTag(ns, name) -- 文字データを除いて次に来るべき構文解析コンポーネントとして、要素の開始位置の直後までを構文解析します。構文解析の位置は、その開始タグの直後になります。
• attributeText(ns, name) -- 現在の開始タグから、必要とされる属性のテキスト値を取得します。
• attributeInt(ns, name, dflt) -- 現在の開始タグから、オプション属性のint 値 (その属性が指定されていないならデフォルト値) を取得します。
• parseContentText(ns, name) -- 現在の要素の終了位置の直後までを構文解析します。そこに含まれる内容は、文字データだけでなければなりません。その内容を戻します。
• parseElementText(ns, name) -- 次の要素を構文解析します。そこに含まれる内容は、文字データだけでなければなりません。その内容を戻します。

パーサーをアンマーシャリング・コンテキスト内にラップすることにより、最小限のコードで実にさまざまな種類のアクセス方式を定義できます。さらに、実際に使用されるパーサーからの独立性をもたらすことになります。そのため、生成されてクラスに追加されることになるコードは、特定のパーサーに固有のものではなく、特定の種類のパーサーに固有のものでさえありません。将来のことを考えた場合、この点は非常に重要です。現在のところ、アンマーシャリング・コンテキストは、プル型構文解析の分野の一部の主導的開発者たちによって定義されている非公式の標準規格XMLPull を実装するパーサーを使用するようにコーディングされています。将来、プル型パーサーのJavaテクノロジーの規格が確立されることになるでしょう。それが確立された時、JiBXなら、アンマーシャリング・コンテキスト・コードにほんの少し変更を加えるだけで、その標準規格を使用できます。

JiBXでは、コンテキストのもう1つ種類として、マーシャリング・コンテキストを使用しています。これは、マーシャリング時にXML文書を作成するためのものです。アンマーシャリング・コンテキストがパーサーをラップし、アンマーシャリングのために特殊化されたさまざまな便利なメソッドを提供するのと同じく、マーシャリング・コンテキストは出力ストリームをラップし、独自の便利なメソッド群を提供します。それらのメソッドは、出力文書生成のために使用できる、コンポーネントごとに処理するインターフェースを提供します。基本的なメソッドの簡単なリストを以下に示します。

コストベースのクエリを実行する方法

• startTag(nsi, name) -- 属性なしで開始タグを生成します。
• startTagAttributes(nsi, name) -- 属性を追加した開始タグを生成します。
• attribute(nsi, name, value) -- 現在の開始タグに属性を追加します (値はString またはプリミティブ型)。
• closeStartEmpty() -- 内容のない要素として開始タグを閉じます (空要素)。
• closeStartContent() -- この後に指定される内容を追加してから、開始タグを閉じます。
• textContent(value) -- 現在の要素に文字データ内容を追加します (String またはプリミティブ)。
• endTag(nsi, name) -- 要素の終了タグを生成します。

XML生成のためのこのインターフェースは、他の多くのフレームワークで使用されているものよりもずっとシンプルです。これは、手作業でコーディングしたコードではなく、JiBXフレームワークによって追加されるコードによって使用されることを主に意図したものなので、状態チェックなどの安全機能は備えていません。特殊エスケープ文字はテキスト中の実体と同じように正しく処理しますが、それ以外の点でインターフェースを正しく使用することは、呼び出し側プログラムの責任です。

このインターフェースのここに示した形式では、名前空間を指定できるようになっています。マーシャリング・コンテキストでは、名前空間接頭語の内部配列が保持されているため、出力生成時には、その配列のインデックスを指定するだけで接頭語を検索できます。(名前空間の実際のURIが渡された場合にはマッピング操作が必要ですが、この方式ならそのようなことはありません。)この方法は、柔軟性を犠牲にすることなく処理を単純化するための妥協策です。このインターフェースの初期バージョンでは、要素や属性の限定名 (必要に応じて名前空間接頭語を付けたもの) を静的に構築することが必要でした。それはテキスト出力生成ではうまく動作したものの、他の形式の出力 (文書のDOM表記構築のための構文解析イベント・ストリームなど) に変換することは困難です。このインターフェースの新しい形式では、変換がずっと楽になっています。

上に戻る

Java中心方式とXML中心方式

Java言語プログラムのデータ・バインディング・フレームワークの多くは、W3C XML Schemaの文法に基づくコード生成に焦点を当てています。その方法では、文書を処理するためにまずSchema文法から始め、データ・バインディング・フレームワークの一部であるプログラムを使用することにより、Schemaに対応する一連のクラス (オブジェクト・モデル) のJava言語ソース・コードを生成します。多くのアプリケーション、特にSchema文法が前もって定義されていて、プロジェクトが進展しても変更されることがない場合には、これでうまくいきます。そのようなアプリケーションの場合、Schemaから構成されるオブジェクト・モデルによって、非常に短期間で文書の作業を開始するための手段が提供されます。

オブジェクト・モデル生成方式の大きな欠点は、コーディングするコードが、XML文書の構造に直接結びついているという点です。そのため、私はこれをXML中心方式と呼んでいます。オブジェクト・モデル生成の場合、作成するアプリケーション・コードは、文書に含まれるデータに関してアプリケーションで予期している構造ではなく、XMLの構造を反映するインターフェースを使用しなければなりません。そのため、XMLとアプリケーションの間に独立性がありません。XML文書構造 (Schema) が何らかの重要な点において変更されると、オブジェクト・モデルを生成し直し、それに合わせてアプリケーション・コードを変更する必要があります。

JiBXを含むいくつかのデータ・バインディング・フレームワークでは、別の方式が採用されています。それは、一般にマップ・バインディングと呼ばれるものです。私は、それをJava中心方式と呼んでいます。生成される一連のクラスの使用が強制されることはなく、アプリケーション内で定義するクラスと連動します。これは開発者にとっては便利ですが、フレームワークの処理は複雑になります。フレームワークは、特定の固定モデルに従うようアプリケーション・クラスを強制することなく、アプリケーション・クラスとの間で、何らかの形で一貫性のある方法によりデータをやり取りすることが必要になります。これは、JiBXと他のデータ・バインディング・フレームワークとのもう1つの相違点です。

リフレクションとパフォーマンス

フレームワークでJava言語のさまざまなクラスとの間でデータをやり取りすることが必要な場合、そのための一般的な方法はリフレクションを使用することです。これは、たとえばCastorのマップ・バインディング・サポートで採用されている手法であり、実行時にJava言語クラスに関する情報にアクセスするための1つの手段です。これは、あるクラスのインスタンスに含まれるフィールドやメソッドにアクセスするために使用でき、それにより、複数のクラスの間でソース・コードをリンクすることなく、実行時にそれらのクラスを動的に結合する手段が提供されます。

リフレクションは、Javaクラスと連動するさまざまなフレームワークの強力な基礎となっていますが、データ・バインディングのために使用する場合に関しては欠点があります。1つの点は、一般にリフレクションが正しく動作するためには、クラスの公開 (public) フィールドまたはメソッドを使用することが必要、ということです。そのため、本来バインディング・フレームワーク以外からはアクセスされるべきでない内部状態情報についても、公開するAPIの一部としてアクセス可能にしなければなりません。また、リフレクションは、コンパイル済みコードで直接にメソッドを呼び出したりフィールドにアクセスしたりする場合に比べると、パフォーマンスの点でも不利です。

それらの制限のため、私は、JiBXでのデータ・バインディングにリフレクションを使いたくありませんでした。Javaデータ・オブジェクト (JDO) の仕様の開発者たちも、Java言語オブジェクトとデータベースとの間でのデータ移動に関して同じような問題に直面しました。彼らの場合は、フレームワークに直接アクセスを提供するために、クラス・ファイルに直接手を加え、コンパイラーの生成するクラスにコードを追加することにより、リフレクションを回避しました。JiBXに関して私は、それと同じ手法を使用することにしました。

上に戻る

クラス・ファイルの拡張

javaのリスト内のNULL値をチェックする方法

JDOのチームは、コンパイラーの生成したクラス・ファイルに変更を加える (munging、参考文献を参照) 処理を記述するのに、「バイト・コード拡張」というすごい用語を考え出しました。確かに、クラス・ファイルの「マングル (ぶち壊し)」とか「埋め込み」とか言う語よりも、ずっといい響きがしますよね。私は、それ以上に適切な用語を考え出せるとは思えないので、厚かましくもJiBXフレームワークでも同じ語を採用することにしました。

クラス・ファイルの実際の修正作業は、バインディング・コンパイラーというJiBXコンポーネントによって実行されます。バインディング・コンパイラーは、プログラムのアセンブリー時に実行されます。つまり、Javaソース・コードをコンパイルしてクラス・ファイルにしてから、それらのクラス・ファイルをパッケージ化または実行するまでの間に実行されます。バインディング・コンパイラーは、1つ以上のバインディング定義文書を読みます (「バインディング定義」を参照)。バインディング・コンパイラーは、バインディングのいずれかに含まれる各クラスごとに、適切なマーシャリング用コードまたはアンマーシャリング用コードを追加します。

一般に、バインド後のクラス・ファイルには、そのクラスを含むマーシャリング・バインディングまたはアンマーシャリング・バインディングのそれぞれについて、一組のメソッドが追加されることになります。それには、いくつかの例外があります。それぞれのバインディングがいずれも同一のメソッド群を再利用する複数バインディングとまったく同じようにクラスが扱われる場合、バインディング操作によっては、追加するメソッドの数が違ってきます。しかし多くの場合、1つのバインディングについて4つのメソッドになります (マーシャリング用が2つ、アンマーシャリング用が2つ)。

バインディング・コンパイラーは、追加されるメソッドに付随してさらにいくつかのサポート・クラスを追加生成します。基本的に、バインディングに含まれるクラスごとに1つのヘルパー・クラスが追加され、さらにバインディングごとに1つの別個のクラスが追加されます。ID値によって識別されるオブジェクトへの下方参照をアンマーシャリングする特殊な場合については、下方参照されるオブジェクトがアンマーシャリングされた時点でその値を設定するため、小さな内部クラスに相当するものも生成されます。

通常、追加されるクラスの総数と追加されるコードの合計サイズは、わずかなものです。JiBXのサイトからダウンロードできるサンプルには、第2回のテスト・コードに基づく1つの例が含まれています (参考文献を参照)。その例の場合には、5個のクラスの関係するバインディングを処理するために、6個の追加クラスと23個の追加メソッドが生成され、追加される合計サイズは9 KBになります。これは大きく感じられるかもしれませんが、これを、図1 に示す、文法からのコード生成に基づく他の方法の場合と比べてみてください。この図には、JiBXの場合の基底クラスと追加されたバインディング用コードの両方を含む合計コード・サイズと、他のフレームワークの場合に生成される合計コード・サイズとが示されています。コード・サイズの点でJiBXに勝るのは、Quickだけです。

上に戻る

バインディング定義

前のセクションで説明したバインディング・コンパイラーは、指定されたバインディング定義に基づいて動作します。バインディング定義は、それ自体XML文書であり、そのDTD文法はダウンロードの中に含まれています。他の多くのデータ・バインディング・フレームワークとは異なり、JiBXでは、任意の数のバインディング定義を組み合わせて使用できます。たとえば、1つのバインディングを使用して文書をアンマーシャリングし、変更を加えてから、別のバインディングによってデータ・オブジェクトをマーシャリングして、出力文書にすることができます。

バインディング定義を使用することにより、あるクラスの特定のシンプル・プロパティー (プリミティブ値やString など) をXMLの要素または属性にマップするかどうかや、その要素または属性の名前など、さまざまな基本的な情報を指定できます。さらに、そのプロパティーへのアクセス方法、つまりフィールド (任意のアクセス限定子が可能) としてアクセスするか、それともgetメソッドとsetメソッドを伴うJavaBean式のプロパティーとしてアクセスするかを、JiBXに対して指定することもできます。さらには、値をオプションとして指定したり、単純な値とテキストの間の変換を実行するフォーマッターを定義したりすることさえ可能です。

しかし、JiBXには、このような単純な形式のマッピングを超える機能があります。一般に他のデータ・バインディング・フレームワークでは、複雑な内容 (属性または子要素) を伴う各XML要素をそれぞれ別個のオブジェクトと対応付ける必要があるため、オブジェクト・モデルはXML文書のレイアウトと直接に一致するものでなければなりません。JiBXはもっと柔軟です。オブジェクトのプロパティーのサブセットを使用して子要素を定義することができ、参照されるオブジェクトのプロパティーを、現在の要素の単純な子要素または属性として直接含めることができます。それにより、あるクラスに対応するXML文書を変更することなくそのクラスの構造に任意の変更を加えたり、あるXML文書に対応するクラスを変更することなくそのXML文書の構造に任意の変更を加えたりすることが可能です。

上に戻る

構造マッピング

このようなマッピングでは、XML要素とJava言語オブジェクトとの間に直接的な対応付けがありません。私はそれを構造マッピングと呼んでいます。JiBXではそれがどのように実行されるかを示す簡単な例として、次のXML文書をご覧ください。

                    John Smith  12345 Happy Lane Plunk WA 98059 888.555.1234  

多くのデータ・バインディング・フレームワークでは、この文書からクラスのインスタンスへのマッピングが、次のようにしてサポートされています。

                  public class Customer { public Name name; public String street1; public String city; public String state; public String zip; public String phone; } public class Name { public String firstName; public String lastName; }  

多くのフレームワークでは、フィールドの名前を変更することも可能です。たとえば、name の代わりにcustomerName を使用したり、firstName の代わりにfirst を使用したりできます。また、フレームワークによっては、ここに示すような公開 (public) フィールドではなく、get/setメソッドを使用していますが、原理は同じです。

多くのフレームワークでできない のは、name 要素内に含まれる値を、customer 要素に対応するオブジェクトに入れることです。つまり、上記のXMLを下記のクラスにマップすることはできません。

                  public class Customer { public String firstName; public String lastName; public String street1; public String city; public String state; public String zip; public String phone; } 

また、前述のXMLを次のような2つのクラスにマップすることもできません。

                  public class Customer { public String firstName; public String lastName; public Address address; public String phone; } public class Address { public String street1; public String city; public String state; public String zip; }  

JiBXでは、このようなマッピングも可能です。ですから、オブジェクトの構造がXMLの構造によって縛られることはありません。外部で転送のために使用するXMLの形式を変更することなく、オブジェクト・クラスの構造を変更できます。それについては、このシリーズの次回の記事で詳しく説明します (上記の例の場合のマッピング・ファイルも示します)。

上に戻る

結論

JiBXの基本的なアーキテクチャーは、Javaアプリケーション用の他のXMLデータ・バインディング・フレームワークとは大きく異なっています。JiBXと他のフレームワークとを比較した場合、それぞれに利点と欠点があります。JiBXの利点としては、動作が高速であり、ランタイムがコンパクトで、XML文書形式とJava言語オブジェクト構造の間の独立性が高いということがあります。欠点としては、そのパーサー・テクノロジーの実績はまだ十分とは言えず、他のいくつかのフレームワーク (特にJAXB) で提供されているような柔軟な検証はサポートされていません。

JiBXと他のフレームワークの間の相違点のうち、それ以外の点はそれほど明確ではありません。たとえば、クラス・ファイル拡張のためのJiBXのテクニックには、ソース・コードをクリーンに保つ (バインディング・コードがコンパイル後に追加されるため、それに直接手を加える必要はまったくない) という利点がありますが、一方でビルド処理に余分のステップが加わり、マーシャリングまたはアンマーシャリング中にアクセスされるコードに含まれる問題のトラッキングが複雑になるという欠点もあります。そのどちらがより重要かは、ユーザーやアプリケーションごとに違います。

このシリーズの第4回では、アプリケーションでJiBXを使用する方法について詳しく説明します。その使い方を説明した後で、再びJiBXの弱点に話を戻し、将来それを改善する方法としていくつかの案を提示します。JiBXの話の残りの部分をお伝えする第4回をどうぞお見逃しなく。

参考文献

• マップ・バインディングのための新しいJiBX フレームワークについて調べてください。
• データ・バインディングに関するこの連載の第1回では、どんな場合にXMLのデータ・バインディングを使用するかについて、またデータ・バインディング用の各種Javaフレームワークの概要について説明されています。第2回では、新しいJiBXフレームワークを含む、さまざまなデータ・バインディング・フレームワークのパフォーマンスを比較しています (developerWorks、2003年1月)。
• 著者の以前の記事「Castorによるデータ・バインディング」をお読みください。Castorによるマッピング方式のデータ・バインディング技法を取り上げています (developerWorks、2002年4月)。
• XMLの予備知識が必要な方は、developerWorks のチュートリアル「Introduction to XML」(2002年8月) をご覧ください。
• 著者による以前のdeveloperWorks 記事で、Java文書モデルのパフォーマンス (performance)(2001年9月)、および使用方法 (usage) (2002年2月) の比較を検討してください。
• XMLのプッシュ型構文解析のために現在広く使用されているSAX2パーサーAPI については、sourceForgeのサイトをご覧ください。
• プル型パーサーの主導的研究者たちの開発した、高速かつ柔軟なXmlPullパーサーAPI について調べてください。
• Streaming API forXML (StAX) については、Java Specification Requestの進展に注目してください。
• Brett McLaughlin氏のQuick関連記事「QuickによるJavaオブジェクトとXMLの変換」をお読みください。Quickフレームワークを使って、Javaデータを簡単にXML文書に変換する方法を取り上げています。その場合は、他のデータ・バインディング・フレームワークとは違って、クラス生成セマンティクスは必要ありません (developerWorks、2002年8月)。

• Java Architecture for XML Binding (JAXB) の詳細をお調べください。これは、Javaプラットフォームのデータ・バインディングに関する新しい規格です。
• Castor フレームワークの詳細をご覧ください。このフレームワークは、マッピング方式とコード生成方式の両方のデータ・バインディングをサポートしています。
• Quick フレームワークの開発作業は、JavaプラットフォームやXMLよりも前にさかのぼります。これは、JavaプラットフォームでXMLを処理するための非常に柔軟なフレームワークです。
• Zeus の詳細をご覧ください。Quickと同じように、XML文書のDTD記述にモードついてコードを生成しますが、Quickよりも操作が簡単で、機能が限られています。

著者について

Dennis Sosnoskiはシアトル地域にあるJava技術のコンサルティング会社、Sosnoski Software Solutions, Inc.の創立者で、主席コンサルタントでもあり、またXMLやWebサービスに関するトレーニングやコンサルティングの専門家でもあります。彼のプロとしてのソフトウェア開発経験は30年以上に渡り、ここ数年はサーバー側のXML技術やJava技術に注力しています。Dennisは、全米各地で行われる会議で頻繁に講演を行っています。また、Javaクラスワーキング技術を基に構築された、オープンソースの JiBX XML Data Binding フレームワークの中心開発者でもあります。

この記事を評価する

コメント

上に戻る