この連載の第3回では、JiBXデータ・バインディング・フレームワークのアーキテクチャーの概要を示しました。そこでは、JiBXが採用しているJava中心 のデータ・バインディング方式を簡単に概説しました。これは、他のほとんどのデータ・バインディング・フレームワークが使用しているXML中心 方式と対照をなすものです。第4回では、このJava中心のデータ・バインディング方式が持つ能力を、アプリケーションの中で使用する方法を説明します。

Java言語用の他のほとんどのデータ・バインディング・フレームワークの場合、文書用のDTDまたはXML Schema文法を用意した上で、その文法からクラスのコレクションを生成する必要があります。こうしたフレームワークを使用するには、生成されたそれらのクラスを使って作業する必要がありますが、たいていの場合、クラスを制御することはほとんど、あるいはまったくできません。基本的に、それらのクラスは、単純なデータ構造と追加されたフレームワーク・コードとを包む、JavaBeanタイプのラッパーです。生成されるこのようなクラスにとって大切なことは、XML文書のデータを処理するためのインターフェースを提供することです。

JavaBeanラッパー方式は、データにアクセスするのにget/setメソッドを使用するため、オブジェクト指向 と紹介されることもありますが、実際にはデータ・オブジェクトの拡張性が欠けているので、真のオブジェクト指向開発とはかけ離れています。真のオブジェクト指向プログラミングとは、オブジェクトが自分の内部状態を隠蔽し、その状態情報を処理するための独自の振る舞いを実装することを意味します。コード生成方式では、これは普通不可能なことです。

JiBXの場合、XMLへのバインディングはクラスの主な目的としてではなく、クラスにあてはまる1つのアスペクト として扱われます。したがって、各自のアプリケーションに適したオブジェクト指向設計を使用することができます。またJiBXなら、バインディングされるXML文書の構造を変更せずに、クラスをリファクタリングできます。このアスペクト指向の方式なら、同一のクラスに対して複数のバインディングを使用するよう定義することさえできるので、コードを変更することなく、複数の入力または出力XML文書構造を処理できます。

XMLのバインディング

JiBXのアスペクト指向のバインディング方式の中核を成すのは、JavaオブジェクトとXML文書の間で変換を行う方法を制御するためにバインディング定義を使用するということです。これがどのように機能するかを考えるために、XML文書をツリー構造とみなしてみてください。ここで、要素のネストはツリーの枝を定義します。データ・バインディングによって、このようなXMLツリーからオブジェクトのツリーへ、あるいはその逆方向へ変換が行われます (あるいは、オブジェクトのグラフとの間で変換が行われる場合もあります。これは、ツリー構造の枝をさかのぼったり横切るリンクを持つ構造です)。JiBXのバインディング定義は3番目のツリーであり、XMLツリーとオブジェクト・ツリー (これはJiBXでは異なる場合もある) とを組み合わせた構造を表します。この組み合わせ構造は、XMLツリーからオブジェクト・ツリーへ、あるいはその逆方向への変換をどのように行うかを、JiBXに指示します。

図1 は、JiBXフレームワークでバインディング定義がどのように使用されるかを示す簡単な例です。この場合、XML文書が使用する構造と、バインディングされるクラスが使用する構造は同一です。すなわち、 customer には name という子があり、 name には一対の簡単なテキスト値という子があります。バインディング定義はこの構造をそのまま複製し、XML要素をそれに対応するオブジェクト・プロパティーに関連付けるのに必要な情報を、各レベルで指定します。

バインディングのコンポーネント

バインディング定義の中では何種類かの要素が使用されます。各要素の目的と、その中に含めることのできる子要素のタイプについて、表1に示します。

binding 要素は、必ずバインディング定義のルート要素となります。子として、 namespace 、 format 、および mapping 要素をもつことができます。これらの要素は、この順序に従わなければなりません (最初の2つのタイプはオプションです)。各 mapping 要素そのものも、上記の同じタイプの要素を子として持って、ネストした定義とすることができます。その後には、XMLとJavaクラスの間の関係を詳細に定義する、 value 、 structure 、および collection 要素が続きます。

value 要素は、XML文書の単純な値の要素を表します。これは、属性、単純な子要素 (テキストの内容のみ)、テキスト、またはCDATAとすることができます。 structure 要素はもっと複雑です。最も一般的なケース (図1 の場合のように) の場合、 structure 要素は、複雑な内容を持つ子要素 (例では name 要素) を、Javaオブジェクトのオブジェクトと値のプロパティー (Customer オブジェクトのname フィールド) と関連付けます。とはいえ、関係の両側を必ず指定しなければならないわけではありません。そのおかげで、 structure 要素を使って、対応するオブジェクトのないXML要素を定義することや、対応する要素のないオブジェクトを定義することが可能になります。これがどのように機能するかについては、続く例で説明します。

単純なバインディング

第3回では、JiBXによって構造マッピングがいかに柔軟になるかを示す例をいくつか挙げました。今回の記事では、バインディング定義そのものについて説明します。図2 に最初の例を示します。これは、XML文書の構造とJavaオブジェクトの間の直接対応を示しています。これは、図1 で使用した同じ文書とクラス構造を、そのまま完全なバージョンにしたものです。リスト1 に、この対応のための完全なバインディング定義を示します。

                
<binding>
  <mapping name="customer" class="Customer">
    <structure name="name" field="name">
      <value name="first-name" field="firstName"/>
      <value name="last-name" field="lastName"/>
    </structure>
    <value name="street1" field="street1"/>
    <value name="city" field="city"/>
    <value name="state" field="state"/>
    <value name="zip" field="zip"/>
    <value name="phone" field="phone"/>
  </mapping>
</binding>

定義を短縮化する

リスト1 には、完全な形のバインディング定義を示しました。とは言え、バインディングを指定する方法はこれだけではありません。JiBX (Beta 2以降) は、必要に応じて、指定されていないJavaオブジェクトのシンプル・プロパティーを自動的にマップしてくれます。マップされるプロパティーは、フィールドの形式か、JavaBeanスタイルのget/setメソッドの形を取ることができます。このデフォルトのマッピングを利用すると、リスト1の定義の代わりに、(ずっと短い)リスト2 が使えるようになります。

                
<binding auto-link="fields">
  <mapping name="customer" class="Customer">
    <structure name="name" field="name"/>
  </mapping>
</binding>

この短縮型の方式にはいくらかの制限があります。自動生成されるプロパティーのバインディングは、必ず明示的な定義の後に実行され、定義された順番に従って実行されます。図1 のバインディングの場合は、これこそまさに必要としていたことでした。つまり、 name 要素は customer 要素の最初の子であり、Name クラスとCustomer クラスのそれぞれの中にあるフィールド定義は、対応するXML子要素と順序が同じです。JavaデータとXML構造の対応がこれと同じほど緊密である場合には、自動生成したバインディングを使うと、バインディング定義が非常にシンプルになります。

JiBXには、プロパティー・バインディングの自動生成をカスタマイズするための特殊なオプションがあります。これにより、対応するXML要素または属性名を生成するときにフィールドまたはJavaBeanプロパティー名から除去する接頭語や接尾語を指定したり、XML名のスタイルを制御したり、自動生成に含まれるフィールドまたはメソッドのアクセス・レベルを設定したりすることができます。自動生成に含める、あるいは除外するフィールド名やプロパティー名を具体的にリストすることさえできます。しかし、この記事の残りの例では、バインディングの対象となる値を明確かつ厳密に示すため、完全なバインディング定義の形式を使って話を続けます。

ツリーを平坦化する

実際には、単純なバインディングの例では、JiBXの柔軟性を公平に評価できません。第3回では、XML文書と、バインディングされるJavaクラスとの間の構造上の相違を処理する、構造マッピングの一対の例も挙げました。図3 はこのタイプの最初の例です。同じXML文書構造を単一のクラス (先の例のように一対のクラスではない) にバインディングします。

図3 の例に挙げたJavaクラスの構造は、XML文書を平坦化したバージョンです。XMLの name 要素に含まれている値のために別々のクラスを使用するのでなく、親である customer 要素に対応するクラスにそれらの値をそのまま含めています。リスト3 に、この構造マッピングの完全なバインディング定義を示します。

                
<binding>
  <mapping name="customer" class="Customer">
<structure name="name">
      <value name="first-name" field="firstName"/>
      <value name="last-name" field="lastName"/>
    </structure>
    <value name="street1" field="street1"/>
    <value name="city" field="city"/>
    <value name="state" field="state"/>
    <value name="zip" field="zip"/>
    <value name="phone" field="phone"/>
  </mapping>
</binding>

リスト1 とリスト3 を比較すると、この平坦化されたマッピングのバインディング定義に加えられた変更が些細なものであることに気付くでしょう。違っているバインディング定義の行は1行だけです。すなわち、オリジナル・バージョンから field 属性が除去されています。こうして、カレント・オブジェクトのいくつかのプロパティーにマップする1つのXML要素が、バインディング定義の structure 要素によって ( name 属性によって示されているとおりに) 定義される、ということがJiBXに知らされます。

ツリーをねじ曲げる

図4 に、2番目の構造マッピングの例を示します。この例では、Javaクラスの構造は一対のクラスを使用していますが、データ値の分け方はXML文書の構造に対応していません。XML文書の customer 要素のデータ値は2つのクラスに分割され、 name 子要素の値は、その親要素に対応するクラスにそのまま含められています。

リスト4 は、図4 のバインディングのための、完全な形式のバインディング定義です。リスト3 のバインディング定義との唯一の違いは、新しいAddress クラスに対応する structure 要素が追加されていることです。この structure 要素には、 field 属性は含まれていますが、 name 属性は含まれていません。こうして、対応する要素をXML文書に持たないオブジェクト・プロパティーが structure 要素によって定義される、ということがJiBXに知らされます。

                
<binding>
  <mapping name="customer" class="Customer">
    <structure name="name">
      <value name="first-name" field="firstName"/>
      <value name="last-name" field="lastName"/>
    </structure>
<structure field="address">
      <value name="street1" field="street1"/>
      <value name="city" field="city"/>
      <value name="state" field="state"/>
      <value name="zip" field="zip"/>
</structure>
    <value name="phone" field="phone"/>
  </mapping>
</binding>

締めくくりをつける

JiBXバインディング定義には、ここまでに扱ったものだけでなく、さらに多くのオプションが用意されています。その一部は、バインディング定義の要素のリストの中でそれとなく言及されています。たとえば、 format 要素を使ったカスタム直列化と非直列化、および namespace 要素を使った簡単な名前空間の処理などです。他のオプションは、バインディング定義要素の属性によって制御されます。そうしたオプションとしては、オプション値のデフォルト、オブジェクトのマーシャリング前またはアンマーシャリング後に呼び出すメソッド、および参照オブジェクトのID値などがあります。

JiBXには、カスタム・マーシャリング・メソッド定義およびカスタム・アンマーシャリング・メソッド定義の形による、汎用拡張フックも含まれています。これにより、JiBXコンテキスト・クラスによって定義された低レベルのメソッドを直接に処理して、マーシャリングまたはアンマーシャリング・プロセスを完全に制御することができます。この種の低レベルの操作は、一般的な使用を意図したものではありませんが、JiBXアドオンに興味深い可能性をもたらすことは確かです。使用法の可能性の1つは、文書の一部と文書モデル (DOM、JDOM、またはdom4j) との間でマップを行えるようにすることです。これにより、特殊なケース (XML文書に組み込まれたXHTMLフラグメントなど) を簡単に処理できるかもしれません。

上に戻る

バインディングのコンパイル

バインディング定義を準備したら、これを実際にクラス・ファイルにコンパイルする必要があります。JiBXには、この目的でバインディング・コンパイラーが用意されています。これを使用するには、JiBXディストリビューションに含まれているjarファイルと、読者自身のクラスがJVMからアクセスできるよう、Javaクラス・パスをセットアップしてから、引数として1つ以上のバインディング定義ファイルのパスを指定して、org.jibx.binding.Compile プログラムを実行するだけです。

バインディング・コンパイラーは、JiBXバインディング・コードをクラス・ファイルに追加し、JiBXランタイムで使用できるようにします。バインディング・コンパイラーは、これをスマートな方法で行います。同じ追加コードが複数のバインディングから必要とされている場合、バインディング・コンパイラーはコードを1回しか生成しません。その上、変更されたバインディング定義を指定してコンパイラーを再実行すると、古いバインディングのために追加されたメソッドは置き換えられます。単に新しいメソッドが追加されるのではありません。使用されなくなったバインディング用にかつて追加されたメソッドとクラスまで除去されます。さらに、コンパイラーは、実際に変更が加えられたクラス・ファイルにしか書き込みを行いません。そのおかげで、一部のJavaソース・コード・ファイルを変更 (およびコンパイル) した後、Javaソース・ファイルすべて を再コンパイルすることなく、安全にバインディング・コンパイラーを再実行できます。

上に戻る

バインディングの実行

バインディング・コンパイラーでJavaクラス・ファイルを変更したなら、JiBXランタイムを使用して文書のマーシャリングとアンマーシャリングをする準備ができたことになります。しかし、障害が1つだけあります。つまり、Javaソース・コードをコンパイルしてクラス・ファイルにし、JiBXバインディング・コンパイラーを実行するまでは、実際のバインディング・コードが追加されないのです。したがって、ソース・コードの中でこのバインディング・コードに直接にアクセスすることはできません。その代わりに、使用中のバインディング定義を追跡して実行時に正しいコードへと導く、JiBXランタイムの一部を介して作業しなければなりません。

これは、JiBXランタイムjarに含まれているorg.jibx.runtime.BindingDirectory クラス、および作成したコードと同じパッケージ (コードが複数のパッケージにまたがる場合は、JiBXが修正した最初のクラス・ファイルと同じパッケージ) の中にJiBXが生成するクラスを使用します。しかし、生成されたこのクラスにアクセスする方法の詳細を心配する必要はありません。それどころか、バインディングのグローバル・マッピング (ルート binding 要素の子であるマッピング) で定義されたクラスの1つをBindingDirectory に渡せば、これにアクセスできます (複数のバインディングをコードにまとめた場合は、使用するバインディングの名前を渡す必要もあります)。コードは簡単です。

IBindingFactory bfact = BindingDirectory.getFactory(Customer.class);

ここで、Customer は、バインディングのグローバル・マッピングにあるクラスの名前です。org.jibx.runtime.IBindingFactory インターフェースが返されると、マーシャリングとアンマーシャリングのコンテキストを構成するためのメソッドが提供されます。これによって、次に、実際のマーシャリングとアンマーシャリング操作が可能になります。ここで、アンマーシャリングの例を示します。

    IUnmarshallingContext uctx = bfact.createUnmarshallingContext();
    Object obj = uctx.unmarshalDocument
        (new FileInputStream("filename.xml"), null);

これは、アンマーシャリングの呼び出しのいくつかのバリエーションの1つに過ぎません。この場合、ファイルfilename.xml の中のXML文書がアンマーシャリングされます。文書データのソースとして、ストリームの代わりにリーダーを渡すことができます。また、文書のエンコード方式も指定できます (詳細については、JiBXサイトのJavaDocsをご覧ください)。返されるオブジェクトは、バインディングのグローバル・マッピングで定義されたクラスのうちの1つのインスタンスです。 instanceof を使用してタイプをチェックすることもできますし、これが何であるかが分っているのなら、そのオブジェクト・タイプに直接キャストすることもできます。

マーシャリングも同様に簡単です。例を示します。

    IMarshallingContext mctx = bfact.createMarshallingContext();
    mctx.setIndent(4);
    mctx.marshalDocument(obj, "UTF-8", null,
        new FileOutputStream("filename.xml"));

アンマーシャリングの例の場合と同様、これはマーシャリングの呼び出しのために使用できるいくつかのバリエーションの1つに過ぎません。この例では、最初に出力XMLの字下げを、ネスト・レベルごとに4つのスペースに設定しています。次に、オブジェクトをXML文書にマーシャリングし、これをファイルfilename.xml に、UTF-8 文字エンコード方式 (XMLの最も一般的な選択肢) で書き込みます。他のバリエーションと同様、ストリームの代わりにライターを渡すことができます。ここでも、詳細については、JiBXサイトのJavaDocsをご覧ください。マーシャリングされるオブジェクトは、バインディングのグローバル・マッピングで定義されたクラスのインスタンスでなければなりません。

上に戻る

今後の方向性

Javaアプリケーションで使用可能な他のXMLデータ・バインディング・フレームワークと比べて、JiBXには数々の利点があります。その中には、動作が高速であること、ランタイム・ディストリビューションがコンパクトであること、XML文書形式とJava言語オブジェクト構造の間の独立性が高いということがあります。JiBXの最初の実動リリースは近づいており、多くのアプリケーションにとって優れた代替手段になりそうです。

JiBXにも、いくつかの弱点があるのは事実です。その1つは、現在のところ、XML文法からのコード生成をサポートしていないことです。XML中心のコード生成方式の持つ制限について先に書いたことからすると、これは驚くべきコメントと思えるかもしれません。しかし、JiBXはこうした制限を回避するための手段を確かに備えています。もしもXML文法を使ってクラスとそれに対応するバインディング定義の初期セットを生成できるなら、作業コードをすばやく準備する上で大きな利点となることでしょう。同時にユーザーは、コードまたは文法のいずれかを独立的にリファクタリングしつつ、バインディング定義に変更を加えて、すべてが協調性を持って働けるようにするという、長期に渡る柔軟性も引き続き持てることでしょう。

あったらとても便利なフィーチャーをもう1つ挙げるとすれば、バインディング定義をXML文法に照らして検査するツールでしょう。文法は、バインディング定義が目的の文書を実際に正しく処理するかどうかを判断するのに必要な大部分の情報を提供します。実際に組み合わせの互換性をチェックするツールがあれば、テストやデプロイメントの際に生じ得る驚きを未然に防ぐ上で役に立つでしょう。

バイト・コードを拡張するという現在の方式 (コンパイル済みクラスにバインディング・フレームワークのメソッドを追加する方法) も、さらに柔軟性が加わるなら便利になるであろう分野の1つです。バイト・コードを拡張する方法には、ソース・コードをクリーンに保つという利点がありますが、一方でビルド処理に余分のステップが加わり、マーシャリングまたはアンマーシャリング中にアクセスされるコードに含まれる問題のトラッキングが複雑になるという欠点もあります。欠点が利点を上回る場合のための代替手段が用意されれば、言うことなしでしょう。

この問題については、比較的に簡単な解決策があるように思います。JiBXが追加したコードをソース・コードへとデコンパイルし、これをオリジナルのJava言語のソース・ファイルにマージするのは非常に簡単なはずです。いったんこれを行えば、JiBXが必要とするメソッドは自動的にコンパイルして組み込まれます。そして、JiBXによって追加されたコードをユーザーがいじらない限り、バインディング定義を変更するまで、バインディング・コンパイラーを再実行する必要はなくなります。筆者は現在、この種の操作のサポートをJiBXに追加するための調査を行っていますが、調査が最初の実動リリースの後まで続くということはおそらくないでしょう。

制限に関する最後の注釈として、JiBXは現在のところ、他のデータ・バインディング・フレームワークの多くに比べて検証サポートが劣っています。これは将来、変わってくる可能性があります。JiBXには、オブジェクトがマーシャリングされる前、あるいはオブジェクトがアンマーシャリングされた後にメソッドを呼び出すサポートが含まれています。ほとんどの形の検証は、こうしたメソッドを使って処理できるかもしれません。多くのXMLアプリケーションにとって、完全な検証のサポートは、XML文書のデータへの高速で便利なアクセスという主な目標に比べると、2次的なものです。そして、この主な目標について言えば、JiBXはすでに優れた代替手段を提供しているのです。

上に戻る

結論

今回の記事では、JiBXデータ・バインディング・フレームワークによる作業の基本的な点を示しました。個人的には、JiBXにはいろいろな可能性があるように思います (あまり驚くことでもありません、筆者はJiBXの作成者なのですから!)。特に、既存のオブジェクト構造をXMLに適用しなければならないアプリケーションや、コードをXML構造そのものと切り離す必要のあるアプリケーションにとっては、役に立ちます。しかし、JiBXは断じて、JavaアプリケーションのXMLの要件すべてに対するソリューションではありません。

XMLの使用目的はさまざまです。そして、JavaアプリケーションでXMLを処理するツールの数が増え続ける一方であるということは、目的が異なれば必要なツールも異なるという事実を反映しています。XMLの処理の最も困難な部分は、単に特定のアプリケーションにとって最適のツールを見つけること、という場合もしばしばです。JiBXは、XML文書をデータとして解釈し、そのデータをメモリーの中で処理する必要のあるアプリケーションに合わせて設計されています。XML文書そのものよりも、そのデータをアプリケーションで使用することに、より重点が置かれています。

JiBXがご自分の必要にかなっているように思えるなら、現行のディストリビューションをダウンロードして、試しに使ってみるようにお勧めします。BSDスタイルのライセンスによるオープン・ソース・プロジェクトなので、ご自分の要件に合わせて自由にコードを変更できますし、その変更を公開する必要もありません。もちろん筆者は、大勢の方々がJiBXの便利さに気付いて、拡張機能や追加ツールを提供してくださる こと、こうして将来プロジェクトが成長していくことを希望しています。

次回の記事では、データ・バインディングに関するこの連載の締めくくりとして、最近リリースされたJAXBデータ・バインディングの標準と、リファレンスとなるインプリメンテーションについて調べます。JAXBが備えているカスタマイズ・オプションの試験も含みます。JAXBは、JiBXが弱点としている点をまさに得意分野としているので、この最終回は、ツールとテクニック一式を網羅してきたこの連載記事のまとめとしてふさわしいものとなるでしょう。

参考文献

• マップ・バインディングのための新しいJiBX フレームワークについて調べてください。
  
  
• データ・バインディングに関するこの連載の第1回では、どんな場合にXMLのデータ・バインディングを使用するかについて、またデータ・バインディング用の各種Javaフレームワークの概要について説明されています。第2回では、新しいJiBXフレームワークを含む、さまざまなデータ・バインディング・フレームワークのパフォーマンスを比較しています (developerWorks、2003年1月)。第3回では、JiBXのアーキテクチャーを紹介するとともに、JiBXが特定の方式を採用している理由を説明しています (developerWorks、2003年4月)。
  
  
• この著者の以前の記事「Castorによるデータ・バインディング」をお読みください。Castorによるマッピング方式のデータ・バインディング技法を取り上げています (developerWorks、2002年4月)。
  
  
• XMLの予備知識が必要な方は、developerWorks のチュートリアル「Introduction to XML」(2002年8月) をご覧ください。
  
  
• この著者による以前のdeveloperWorks 記事で、Java文書モデルのパフォーマンス (2001年9月)、および使用方法 (2002年2月) の比較を検討してください。
  
  

• Java Architecture for XML Binding (JAXB) の詳細をお調べください。これは、Javaプラットフォームのデータ・バインディングに関する新しい規格です。
  
  
• Castor フレームワークの詳細をご覧ください。このフレームワークは、マッピング方式とコード生成方式の両方のデータ・バインディングをサポートしています。
  
  

• JavaテクノロジーとXML の相互作用の詳細をお読みください。
  
  
• JSR 31 - the XML Data Binding Specification をお調べください。
  
  
• この記事で扱ったテクノロジーの詳細を、developerWorks のXML とJava technology の各ゾーンでお調べください。
  
  
• IBM WebSphere Studio（日本語サイト） は、Javaと他の言語の両方でXML開発を自動化するツールのスイートを提供します。WebSphere Application Server と密接に統合されていますが、他のJ2EEサーバーと一緒に使用することもできます。
  
  

著者について

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

この記事を評価する

コメント

上に戻る

目次

• XMLのバインディング
• バインディングのコンパイル
• バインディングの実行
• 今後の方向性
• 結論
• 参考文献
• 著者について
• コメント