|
|
以下の節では、XML データを処理する Java アプリケーションを作成する場合のプログラミング上の最良の方法について説明します。
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 ドキュメントの検証を行う必要がある場合、DocumentBuilderFactory または SaxParserFactory の setValidating() メソッドを使用するのではなく、データを受信または解析するときに検証する独自のカスタム コードを記述することで、アプリケーションのパフォーマンスを改善できる場合があります。
SAX または DOM で XML ドキュメント解析中の検証をオンにした場合、パーサはユーザが実際に必要とするより多くの検証を行うことがあり、その結果、アプリケーションの全体的パフォーマンスが低下します。XML ドキュメントが有効であるかをチェックする場合は、ドキュメントの解析中に適切なポイントを選択し、それらのポイントに独自の Java コードを追加することを検討してください。
たとえば、WebLogic XML Streaming API により XML 発注書を処理するアプリケーションを書くと仮定します。ドキュメントの最初の要素は <purchase_order> でなければならないことがわかっているので、ストリームから最初の要素を取り出してその名前をチェックすることで、そのドキュメントが一見して有効なのかどうかを迅速に検証できます。もちろん、このチェックは XML ドキュメント全体が有効であることを保証するものではありませんが、ストリームから要素を取り出しながら、既知の要素についてさらにチェックを続けることができます。このようなクイック チェックは、標準の setValidating() メソッドを使用する場合に比べてはるかに高速です。
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 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 コードを使用して、新しいドキュメントを書き出します。
  
|