この章では、XMLプロジェクトとそのコンポーネントの概要について説明します。
この章の内容は次のとおりです。
複数のタイプのTopLinkプロジェクトに共通のプロジェクトの概念と機能の詳細は、第15章「プロジェクトの概要」を参照してください。
XMLプロジェクトを使用すると、JAXBを使用して、JavaオブジェクトとXML文書間で、非トランザクション型の、永続化を行わない(インメモリー)変換を実行できます(47.1.1項「TopLinkによるJava Architecture for XML Binding(JAXB)のサポート」および47.1.2項「JAXBの検証」を参照)。Oracle JDeveloper TopLinkエディタとTopLink Workbenchはどちらも、XMLプロジェクトの作成を完全にサポートします。
TopLinkランタイムは、1つ以上のXMLスキーマに基づいてXMLデータ変換を行います。XMLプロジェクトでは、TopLink Workbenchが配布XMLのスキーマを直接参照し、指定したスキーマに関して構成されたマッピングをエクスポートします。XMLスキーマによるTopLink Workbenchの使用方法の詳細は、5.6項「XMLスキーマの使用」を参照してください。TopLinkでのXMLネームスペースのサポートの詳細は、15.4項「XMLネームスペースの概要」を参照してください。
表47-1は、XMLプロジェクトのコンポーネントを示します。
表47-1 XMLプロジェクトのコンポーネント
| コンポーネント | サポートされているタイプ |
|---|---|
|
データ・ソース |
なし |
|
ディスクリプタ |
詳細は、50.1項「XMLディスクリプタの概念」を参照してください。 |
|
マッピング |
詳細は、次を参照してください。 |
|
注意: XMLプロジェクトでは、TopLinkの問合せおよび式を使用しません。 |
JAXBは、XMLへのJavaオブジェクトのマッピングを制御するための注釈を定義しますが、マッピングのデフォルト・セットも定義します。このデフォルトを使用して、TopLinkはオブジェクトのセットをXMLにマーシャリングし、XML文書をオブジェクトにアンマーシャリングできます。JAXBは、標準JavaオブジェクトとXMLの間の変換用APIを提供します。詳細は、http://java.sun.com/xml/jaxb/index.htmlを参照してください。
TopLinkは、JAXBの上部に追加の機能レイヤーを提供します。このレイヤーにより、JAXBオブジェクト・モデルを再コンパイルしなくても、既存のオブジェクト・モデルからマッピングを(TopLinkランタイム・プロジェクトまたはTopLink Workbenchプロジェクトの形式で)作成し、それを引き続き操作できるようになります。
この機能の中核的コンポーネントは、TopLink JAXBコンパイラです。TopLink JAXBコンパイラを使用すると、TopLink XMLプロジェクトとJAXB準拠のオブジェクト・モデル・クラスの両方をXMLスキーマから生成できます。
TopLink JAXBコンパイラは、必要なJAXBファイル(47.1.1.2項「JAXB固有の生成ファイルの使用」を参照)とTopLinkファイルの両方をXMLスキーマ(XSD)ドキュメントから自動的に生成する(48.2項「XMLスキーマからのXMLプロジェクトの作成」を参照)ことにより、TopLinkを使用したJAXBアプリケーション開発を容易にします。
JAXBおよびTopLinkに固有のランタイム・クラスの使用の詳細は、47.1.1.3項「TopLink JAXBコンパイラ生成ファイルの実行時での使用」を参照してください。
JAXBによるPOJOのマーシャリングの詳細は、http://www.oracle.com/technology/products/ias/toplink/preview/how-to/JAXBwithPOJOs.htmlを参照してください。
TopLink JAXBコンパイラは、表47-2に記載されているJAXBの注釈を使用して、TopLinkプロジェクトおよびXMLスキーマを生成します。
表47-2 TopLinkでサポートされているJAXBの注釈
| 注釈 | 説明 | レベル |
|---|---|---|
|
|
クラスをスキーマ内のルートレベルの要素にマップすることを指定します。 ルート要素名およびネームスペースは、この注釈内で指定します。 |
クラス |
|
|
Javaクラスの特定の属性をスキーマ内のXML要素にマップすることを指定します。 この要素の名前およびネームスペースは、この注釈で指定できます。 |
フィールド |
|
|
Java属性をスキーマ内のXML属性にマップすることを指定します。 名前およびネームスペースを指定する必要があります。 |
フィールド |
|
|
別の要素または属性のラッパー要素を指定します。 この注釈を使用して、コレクションに関するグループ化要素を作成できます。 |
フィールド |
|
|
コレクションのプロパティを、XML内のスペースで区切られたリストにマップすることを指定します。 |
フィールド |
|
|
クラスに対して複合型を定義します。 この注釈の |
クラス |
|
|
特定のフィールドに対してマッピングを生成しないことを指定します。 これはマーカー注釈です。 |
フィールド |
|
|
スキーマに対するターゲット・ネームスペースを指定します。 また、この注釈を使用して、 |
パッケージ |
|
|
ネームスペース接頭辞のマッピングを指定するために、 |
パッケージ |
|
|
属性を、親クラスの下のテキスト・ノード(Xpathの"text( )"など)にマップします。 また、所有クラスを |
フィールド |
|
|
JDK 1.5の ベース・スキーマ・タイプは、この注釈内で指定します。 |
フィールド |
|
|
スキーマ内で使用する列挙のファセットがJava内で指定されたEnum定数の文字列値と異なる場合は、スキーマ内で使用する列挙のファセットを指定できます。 |
フィールド |
|
|
クラスの属性の処理方法を指定します。 有効な値は、次のとおりです。
|
パッケージまたはクラス |
|
|
処理するプロパティの順序を指定します。 有効な値は、次のとおりです。
|
パッケージまたはクラス |
|
|
プロパティ・レベルで指定する場合は、スキーマの生成で使用するスキーマ・タイプを指定することになります。
|
プロパティまたはパッケージ |
|
|
|
パッケージ |
|
|
|
フィールド |
詳細は、http://jcp.org/aboutJava/communityprocess/pfd/jsr222/index.htmlのJAXB 2.0の仕様の第8章を参照してください。
|
注意: TopLinkプロジェクトは、リレーションシップ、コレクションスタイルのマッピング、およびJDK 1.5の列挙をサポートする、注釈付きのJavaクラスのコレクションから生成されます。スキーマは、リレーションシップをサポートする、注釈付きのJavaクラスのセットから生成されます。 |
TopLink JAXBコンパイラは、XSDから次のようなJAXB固有のファイルを生成します。
JAXBランタイムは、これらのファイルをJAXB仕様で規定されているとおりに使用します。
すべてのJAXB固有ファイルは、定義した出力ディレクトリ、および定義したターゲット・パッケージ名によって暗黙的に定義されるサブディレクトリに生成されます。TopLink JAXBバインド・コンパイラ・オプションの詳細は、48.2項「XMLスキーマからのXMLプロジェクトの作成」を参照してください。
生成されたクラスをコンパイルする前に、IDEクラスパスに<ORACLE_HOME>\lib\xml.jarを含むよう構成してください。たとえば、第7章「統合開発環境の使用」を参照してください。
すべての実装クラスは、XSDで定義されたコンテンツ、要素または実装のname属性に従って名前が付けられます。
生成される実装クラスは、単純なドメイン・クラスです。各JAXBプロパティにはprivate属性を持ち、属性値を返したり設定するpublicのgetおよびsetメソッドを持ちます。
実行時には、次のようにTopLink JAXBコンパイラ生成ファイルにアクセスできます。
TopLink XMLContextの使用による(47.1.1.3.1項「TopLink XMLコンテキストの使用方法」を参照)
TopLink XMLBinderの使用による(47.1.1.3.3項「TopLink XMLBinderの使用方法」を参照)
TopLink JAXBContextの使用による(47.1.1.3.4項「JAXBContextの使用方法」を参照)
TopLinkにより提供されるoracle.toplink.ox.XMLContextクラスを使用して、TopLink XMLMarshaller、XMLUnmarshaller、XMLBinder(47.1.1.3.3項「TopLink XMLBinderの使用方法」を参照)、およびXMLValidatorのインスタンスを作成できます。
XMLContextはスレッド・セーフです。たとえば、同じXMLContextオブジェクトにアクセスする複数のスレッドがXMLMarshallerをリクエストする場合、各スレッドが専用のXMLMarshallerインスタンスを受け取り、このため、そのXMLMarshallerが保持する状態はいずれもそのプロセスにかぎられたものとなります。XMLContextの使用により、Webサービスのバインド層などのマルチスレッド・アーキテクチャでTopLink XMLを使用できます。
次の例に示すように、XMLContextを作成するには、sessions.xmlファイルで定義されたセッション名をコンストラクタ・メソッドに渡します。
XMLContext context = new XMLContext("mysession");
また、複数のセッションからXMLContextを作成するには、次の例に示すように、セッション名をコロンで区切ったリストを使用します。
XMLContext context = new XMLContext("session1:session2:session3");
TopLink XMLMarshaller、XMLUnmarshaller、XMLBinderおよびXMLValidatorを作成するには、XMLContextを次のように使用します。
XMLMarshaller marshaller = context.createMarshaller();
marshaller.marshal(myObject, outputStream);
marshaller.setFormattedOutput(true);
XMLUnmarshaller unmarshaller = context.createUnmarshaller();
Employee emp = (Employee)unmarshaller.unmarshal(new File("employee.xml"));
XMLBinder binder = context.createBinder();
Address add = (Address)binder.unmarshal(myElement);
XMLValidator validator = context.createValidator();
boolean isValid = validator.validate(emp);
XMLContext getDocumentPreservationPolicyメソッドを使用して、このコンテキストの文書保存ポリシーをDocumentPreservationPolicyオブジェクトの形式で取得できます。このオブジェクトのAPIにより、ノード要素への新規追加位置を指定し、新規要素の追加を無効にできます。
TopLink XMLMarshallerおよびXMLUnmarshallerを、特別なイベント・コールバックを処理するリスナーに登録することにより、実行時にこれら2つに追加機能を提供できます。これにより、XMLにおいてオブジェクトの書込みまたは読取りが行われる直前または直後に、ビジネス・オブジェクトに対する追加処理が可能になります。
2つの異なる方法で処理できる、次の2種類のイベント・コールバックがあります。
リスナーベースのコールバックを処理するには、XMLMarshalListenerやXMLUnmarshalListenerなど、必要なインタフェースを実装するXMLMarshallerまたはXMLUnmarshallerのインスタンス上にイベント・ハンドラを設定します。これらのイベントは、マーシャリングまたはアンマーシャリングされるクラスがある場合に、マーシャラまたはアンマーシャラのリスナー上でトリガーされます。
クラス特有のコールバックを処理するには、ビジネス・オブジェクトに対する必要なコールバック・メソッドを提供する必要があります。
|
注意: リスナーおよびビジネス・オブジェクトのコールバックを両方指定すると、クラス特有のメソッドがリスナー・イベントの前に起動されます。 |
例47-1はカスタム・イベント・リスナーの作成方法を示します。
例47-1 TopLink XMLMarhsalListenerおよびXMLUnmarhsalListenerインタフェースの実装
public class EmployeeMarshalListener implements XMLMarshalListener {
public void beforeMarshal(Object target) {
// do something
}
public void afterMarshal(Object target) {
// do something
}
)
public class EmployeeUnmarshalListener implements XMLUnmarshalListener {
public void beforeUnmarshal(Object target, Object parent) {
// do something
}
public void afterUnmarshal(Object target, Object parent) {
// do something
}
)
XMLBinderは、アンマーシャリングした文書を保存し、アンマーシャリングしたオブジェクトを使用して任意の時点でその文書を再同期するためのランタイム・クラスです。
|
注意: この機能は、JAXBバインダAPI(javax.xml.bind.Binder<XmlNode>)に基づいています。これは、文書保護のデザインタイム・メソッドを補足するものです。 |
XMLBinderがXMLノードをマッピング・オブジェクトにアンマーシャリングし、次に更新操作を実行すると、要素の順序のみでなく、キャッシュ値を使用して元のXML文書のコメントも保存されます。これにより、返されたノードとキャッシュされたノードが同一のものになり、保存された文書を反映します。新しい要素を追加すると、TopLink XMLBinderは、これらの要素をノード内で(マップされている他のコンテンツに対して)適正な位置に配置します。
マップされていないコンテンツのみを含む文書をアンマーシャリングし、値を設定してからマーシャリングすると、XMLBinderにより、コメントや処理命令などの既存のマップされていないデータの前に新しい要素が追加されます。
例47-4は、XMLBinderのインスタンスを使用して文書をアンマーシャリングする方法を示します。
例47-4 XMLBinderを使用した文書のアンマーシャリング
XMLContext conext = new XMLContext(myProject); XMLBinder binder = context.createBinder(); Employee emp = (Employee) binder.unmarshal(myDocument);
前述の例では、empは提供された文書からアンマーシャリングしたルート・オブジェクトです。バインダにより、元のXML文書とアンマーシャリング操作によって生成されたオブジェクトへの参照先が保持されます。
例47-5は、XMLBinderのインスタンスを使用して、オブジェクト(Employee)を変更し、XML文書を更新する方法を示します。
前述の例で、updateXMLメソッドはバインダのキャッシュされたノードを更新します。キャッシュされたノードでは、次の例のように、コメントも含めて文書が保持されることに注意してください。
<employee>
<!--comment1 -->
<name>John Smith </name>
<phone-number>123-4567</phone-number>
<!--comment2 -->
</employee>
例47-6は、XMLBinderのインスタンスを使用して、Employeeのサブオブジェクト(Address)について関連ノードを取得する方法を示します。
例47-6 XMLBinderを使用した関連ノードの取得
... Address addr = emp.getAddress(); Node addressNode = binder.getXMLNode(addr);
前述の例では、返されたノード(addressNode)はこの従業員のAddressオブジェクトの構築に使用された元のXML文書内にあるXMLノードです。
例47-7は、XMLBinderのインスタンスを使用して、XMLノードを変更し、Employeeのオブジェクト(Address)を更新する方法を示します。
例47-7 XMLBinderを使用したXMLノードの変更とオブジェクトの更新
...
addressNode.setAttribute("apt-no", "1527");
Address updatedAddressNode = binder.updateObject(addressNode);
前述の例では、バインダ操作から返されたアドレスは、アンマーシャリング操作で作成された元のアドレス・オブジェクトですが、ここでは、XML文書の情報から更新されたアパート番号が含まれています。
XMLにバインドされるクラスのコレクションからJAXBContextのインスタンスを作成できます。このインスタンスを実行すると、前述のクラスからTopLinkプロジェクトが動的に生成されます。
例47-8に示すように、JAXBContextのインスタンスを使用して、MarshallerおよびUnmarshallerのインスタンスを取得し、これらのクラスを操作できます。この例では、ドメイン・オブジェクト・クラス・ファイルが含まれるようにアプリケーション・クラスパスを構成していると仮定していることに注意してください。
Class[] classes = {Employee.class, Address.class, Department.class};
JAXBContext jaxbContext = JAXBContext.newInstance(classes);
Marshaller marshaller = jaxbContext.createMarshaller();
marshaller.marshal(myEmployee, myOutput);
|
注意: JAXBContextオブジェクトはスレッド・セーフです。 |
TopLinkでは、JAXBElement型に対してマーシャリングおよびアンマーシャリングできます。javax.xml.bind.JAXBElementクラスでは、XML要素の次の基本プロパティを使用できます。
XML要素の修飾名。{target namespace}と{name}で構成されます。
XML要素の値。XML要素の{type definition}のJavaクラス・バインディングのインスタンスです。
要素のコンテンツが{nillable}かどうか。
TopLinkは、Marshallerで定義される次のJAXB要素のmarshal APIをサポートしています。
marshal(java.lang.Object jaxbElement, java.io.Writer writer)
marshal(java.lang.Object jaxbElement,
java.io.OutputStream os)
marshal(java.lang.Object jaxbElement,
org.xml.sax.ContentHandler)
marshal(java.lang.Object jaxbElement,
javax.xml.transform.Result)
marshal(java.lang.Object jaxbElement, org.w3c.dom.Node)
marshal(java.lang.Object jaxbElement,
javax.xml.stream.XMLStreamWriter writer)
|
注意: 最初のパラメータがJAXBElementでない場合は、マーシャル操作により、oracle.toplink.exceptions.XMLMarshalException.MARSHAL_EXCEPTIONがスローされます。 |
TopLinkは、Unmarshallerで定義される次のJAXB要素のunmarshall APIの実装を提供しています。
<T> JAXBElement<T> unmarshal(
org.w3c.dom.Node node, Class<T> declaredType)
<T> JAXBElement<T> unmarshal(
javax.xml.transform.Source source,
Class<T> declaredType)
<T> JAXBElement<T> unmarshal(
javax.xml.stream.XMLStreamReader streamReader,
Class<T> declaredType)
<T> JAXBElement<T> unmarshal(
javax.xml.stream.XMLEventReader eventReader,
Class<T> declaredType)
TopLinkは、実装クラスを生成するために使用されたXMLスキーマに対して、完全なオブジェクト・ツリーとサブツリーの両方を検証できます。さらに、TopLinkは、オブジェクトの実装クラスを生成するために使用されたスキーマに対して、ルート・オブジェクト(XML文書のルート要素に対応するオブジェクト)と非ルート・オブジェクトの両方を検証できます。
オブジェクト・ツリーを検証する場合、TopLinkは次のチェックを(順に)実行します。
要素が文書内の指定された場所にあるかをチェックします。
maxOccursまたはminOccursが指定されている場合、要素の数をチェックします。
タイプが指定されている場合、要素の値がタイプ制約を満たしているかをチェックします。
固定値が指定されている場合、要素の値がそれに一致しているかをチェックします。
制約(長さ、パターン、列挙など)が指定されている場合、要素の値がそれを満たしているかをチェックします。
validateRoot操作に対してIDタイプが指定されている場合、IDの値が文書内で一意であるかをチェックします。
validateRoot操作に対してIDREFタイプが指定されている場合、参照されるIDが文書内に存在しているかをチェックします。
検証エラーが発生した場合、JAXB仕様に従って、TopLinkはオブジェクト・ツリーの検証を中止し、Validationオブジェクトを作成します。エラーがサブオブジェクト内で発生した場合は、TopLinkはオブジェクトのそのサブツリーより下を検証しません。
TopLink XMLを使用した検証の詳細は、47.1.1.3項「TopLink JAXBコンパイラ生成ファイルの実行時での使用」を参照してください。
JAXBおよび検証の詳細は、http://java.sun.com/xml/jaxb/のJAXB仕様を参照してください。