6 XMLプログラミングのベスト・プラクティス

この章では、XMLデータを処理するJavaアプリケーションを作成する場合に使用するプログラミング上の最良の方法について説明します。

この章の内容は以下のとおりです。

• DOM、SAX、StAX APIを使用する場合

• XML検証のパフォーマンスの改善

• XMLスキーマまたはDTDを使用する場合

• パフォーマンスを最大にする外部エンティティ解決の構成

• SAX InputSourceの使用

• 変換のパフォーマンスの向上

DOM、SAX、StAX APIを使用する場合

DOM、SAX、StAX APIによりXMLドキュメントを解析できます。この節では、各APIの長所および短所について説明します。

DOM APIは、小さなドキュメント、すなわち要素数が1000個以下のドキュメントに向いています。DOMはXMLデータのツリーを構成するので、要素の追加または削除によりXMLドキュメントの構造を編集するには理想的です。

DOM APIでは、処理を開始する前に、まずXMLドキュメント全体を解析し、DOMツリーに変換します。このコストは、ドキュメント全体にアクセスする必要のあることがわかっている場合には有意義です。XMLドキュメントの一部にしかアクセスする必要のない場合には、アプリケーションのパフォーマンスが低下するだけで、何のメリットもないことがあります。そのような場合は、SAXまたはStAX APIが適しています。

SAX APIは最も軽いAPIです。ユニークな要素名の入った浅いドキュメント(要素のネストがあまりないドキュメント)の解析に理想的です。SAXでは、コールバック構造が使用されます。つまり、APIでXMLドキュメントの読取りを行っている間に、プログラマ側でイベントの解析を処理します。これは、比較的効率的で迅速な解析方法です。

ただし、SAXのコールバックの性質上、XMLデータの構造を変更する場合に必ずしも最良のAPIが使用されるとは限りません。また、コールバックを処理するアプリケーションのプログラミングは、わかりやすい直感的なものではありません。

StAX APIはSAXをベースにしているので、SAXを使用する理由はすべてStAX APIにも当てはまります。さらに、プログラマはイベント発生時にイベントに対応するのではなく、イベントを請求するので、StAX APIの方がSAXを使用するより直感的です。StAX APIは、パラメータとしてXMLドキュメント全体を渡す場合にも最適です。入力ストリームを渡す方が、SAXイベントを渡すよりも簡単だからです。最後に、StAX APIは、元々XMLデータをJavaオブジェクトにバインドするために設計されたものです。

XML検証のパフォーマンスの改善

パーサー検証問題によりXMLアプリケーションのパフォーマンスが低下した状況で、XMLドキュメントの検証を行う必要がある場合、DocumentBuilderFactoryまたはSaxParserFactoryのsetValidating()メソッドを使用するのではなく、データを受信または解析するときに検証する独自のカスタム・コードを記述することで、アプリケーションのパフォーマンスを改善できる場合があります。

SAXまたはDOMでXMLドキュメント解析中の検証をオンにした場合、パーサーはユーザーが実際に必要とするより多くの検証を行うことがあり、その結果、アプリケーションの全体的パフォーマンスが低下します。XMLドキュメントが有効であるかをチェックする場合は、ドキュメントの解析中に適切なポイントを選択し、それらのポイントに独自のJavaコードを追加することを検討してください。

たとえば、WebLogic XML Streaming APIによりXML発注書を処理するアプリケーションを書くと仮定します。ドキュメントの最初の要素は<purchase_order>でなければならないことがわかっているので、ストリームから最初の要素を取り出してその名前をチェックすることで、そのドキュメントが有効に見えるかどうかを迅速に検証できます。もちろん、このチェックはXMLドキュメント全体が有効であることを保証するものではありませんが、ストリームから要素を取り出しながら、既知の要素についてさらにチェックを続けることができます。このようなクイック・チェックは、標準のsetValidating()メソッドを使用する場合に比べてはるかに高速です。

XMLスキーマまたはDTDを使用する場合

XMLドキュメントの構造の記述方法には、DTDおよびXMLスキーマの2種類があります。

最近は、スキーマによりXMLドキュメントを記述する傾向にあります。スキーマは、XML要素を記述するために利用できるデータ・タイプのセットがDTDよりはるかに豊富で、DTDより表現力があり、XMLドキュメントで何が有効であるかを詳しく記述できます。また、SOAPメッセージではスキーマのみを使用でき、DTDは使用できません。SOAPはWebサービスで使用される主要なメッセージング・プロトコルであり、Webサービスに対する入力パラメータまたは出力パラメータとして使用されるXMLドキュメントを記述するには、スキーマを使用することを検討してください。

DTDにもいくつかの利点があります。DTDは、急速に変化しつつあるスキーマより広い範囲でサポートされています。DTDはスキーマほどの表現力がないので、作成や管理が簡単です。

Oracleでは、XMLドキュメントの記述にはスキーマを使用することをお薦めします。

パフォーマンスを最大にする外部エンティティ解決の構成

外部エンティティは、いつもネットワークから取得するのではなく、可能な限りローカルに格納しておくことを強くお薦めします。エンティティをネットワーク接続を介して探すよりも、WebLogic Serverと同じマシン上で探す方がはるかに高速であるため、ローカルに格納することでアプリケーションのパフォーマンスが向上します。

WebLogic Serverの外部エンティティ解決の構成の詳細は、「外部エンティティの構成タスク」を参照してください。

SAX InputSourceの使用

SAX APIによりXMLドキュメントを解析する場合、まずXMLドキュメントからInputSourceオブジェクトを作成し、そのInputSourceオブジェクトをparse()メソッドに渡します。InputSourceオブジェクトは、XMLデータに基づいて、java.io.InputStreamオブジェクトまたはjava.io.Readerオブジェクトから作成できます。

可能な限り、java.io.InputStreamオブジェクトからInputSourceを作成することをお薦めします。InputStreamオブジェクトが渡されると、SAXパーサーは、XMLデータの文字エンコーディングを自動検出し、正しい文字エンコーディングを使用して、InputStreamReaderオブジェクトを自動的にインスタンス化します。つまり、ユーザーにかわってパーサーが文字エンコーディングのすべての作業を行うので、文字エンコーディングをユーザー自身が指定する場合より、実行時のエラーが大幅に減少します。

変換のパフォーマンスの向上

XSLTは、XMLドキュメントを、別のXMLドキュメント、HTML、WMLなど、異なるフォーマットに変換するための言語です。XSLTを使用するには、入力XMLドキュメントの各要素を出力ドキュメントでどのように変換するかを定義するスタイルシートを作成します。

XSLTは強力な言語ですが、複雑な変換のためのスタイルシートの作成は非常に煩雑になることがあります。また、実際の変換には大量のリソースが必要であり、アプリケーションのパフォーマンスが低下することがあります。

したがって、変換が複雑な場合は、XSLTスタイルシートを使用するのではなく、アプリケーションで独自の変換コードを書くことを検討してください。また、DOM APIの使用も検討してください。まず、XMLドキュメントを解析し、結果のDOMツリーを必要に応じて操作し、それを最終フォーマットに変換するためのカスタムJavaコードを使用して、新しいドキュメントを書き出します。