| Oracle TopLink開発者ガイド 10g（10.1.3.1.0） B31861-01 |
|
 戻る |
 次へ |
TopLinkプロジェクトは、マッピング・メタデータとデータ・ソース・アクセス情報（関連する場合）の両方をカプセル化します。プロジェクトは、TopLinkが実行時に使用するプライマリ・オブジェクトです。デプロイされたアプリケーションの各セッション（セッション・ブローカを除く）は、1つのプロジェクトを参照します。
この章の内容は次のとおりです。
表17-1は、TopLinkで利用できるプロジェクト・タイプのリストです。それぞれが基本または詳細タイプに分類され、それぞれの作成方法を示しています。
表17-1 TopLinkプロジェクト・タイプ
| プロジェクト・タイプ | 説明 | タイプ | TopLink Workbench | Java |
|---|---|---|---|---|
|
|
Java Database Connectivity（JDBC）を使用してアクセスするリレーショナル・データベースまたはオブジェクト・リレーショナル・データベースに対するJavaオブジェクトのトランザクション永続性を可能にするプロジェクト。TopLinkの問合せおよび式をサポートします。 |
基本 |
 |
|
|
|
J2EE Connector Architecture（J2C）アダプタおよびサポートされるあらゆるEISレコード（索引付き、マップ済またはXMLを含む）タイプを使用してアクセスされる非リレーショナル・データ・ソースに対するJavaオブジェクトのトランザクション永続性を可能にするプロジェクト。TopLinkの問合せおよび式をサポートします。 |
詳細 |
|
|
|
|
Java Architecture for XML Binding（JAXB）を使用して、JavaオブジェクトとXMLスキーマ（XSD）ベースの文書間で、非トランザクション型の、永続化を行わない（インメモリー）変換を行うために使用するプロジェクト。TopLinkの問合せおよび式をサポートしません。 |
詳細 |
|
|
詳細は、次を参照してください。
この項では、次の内容を含む、TopLinkプロジェクトに固有の概念について説明します。
選択するプロジェクト・タイプにより、使用できるディスクリプタおよびマッピングのタイプが決まります。TopLinkがサポートするデータ・ソース・タイプごとに、対応するプロジェクト・タイプがあります。
表17-2は、プロジェクト、ディスクリプタ、マッピングの関係をまとめたものです。
TopLinkは、リレーショナル・プロジェクトと非リレーショナル・プロジェクトを両方ともサポートします。
リレーショナル・プロジェクトは、Javaオブジェクトをリレーショナル・データベースに永続化します。
非リレーショナル・プロジェクトは、別の（非リレーショナル）タイプのデータ・ソースにJavaオブジェクトを永続化するか、または非永続データへの変換を行います（「永続および非永続プロジェクト」を参照）。たとえば、J2Cアダプタを使用してEISデータ・ソースにJavaオブジェクトを永続化するには、EISプロジェクトを使用します。JavaオブジェクトとXML要素間の非永続（インメモリー）変換を実行するには、XMLプロジェクトを使用します。
TopLinkでは、Javaオブジェクトの永続性ストレージを必要とするアプリケーションに使用できるプロジェクトがサポートされています。たとえば、リレーショナル・データベースにJavaオブジェクトを永続化するために使用できるリレーショナル・プロジェクトや、J2Cアダプタを介してEISデータ・ソースにJavaオブジェクトを永続化するために使用できるEISプロジェクトがあります。
TopLinkでは、非永続（インメモリー）データへの変換のみを必要とするアプリケーション用に使用できるプロジェクトもサポートされています。たとえば、JavaオブジェクトとXML要素間の非永続（インメモリー）変換の実行に使用できるXMLプロジェクトがあります。
プロジェクトに関連付けられたログイン（存在する場合）により、TopLinkランタイムがプロジェクトのデータ・ソースに接続する方法が決まります。
ログインには、認証、接続プールの使用、および外部トランザクション・コントローラの使用などのデータソース・アクセスの詳細が含まれます。ログインにはプラットフォーム情報が含まれます。
プラットフォームには、バインディング、ネイティブSQLの使用、バッチ書込みの使用、順序付けなどの、特定のデータ・ソースに固有のオプションが含まれます。プラットフォームの詳細は、「プロジェクトおよびプラットフォーム」を参照してください。
データ・ソースに永続化しないプロジェクトの場合、ログインは必要ありません。データ・ソースに永続化するプロジェクトの場合、ログインは常に必要です。
TopLink Workbenchでは、プロジェクト・タイプに応じて、プロジェクトで使用されるログインのタイプが決まります。
ログインは様々なロールで使用できます。ログインのロールにより、ログインを作成する場所と方法が決まります。選択するログインのロールは、作成対象のプロジェクトのタイプやログインの使用目的によって異なります。
コンテナ管理の永続性（CMP）を使用しないTopLinkアプリケーションに対して、sessions.xmlファイルにセッション・ログインを作成します。
通常、sessions.xmlファイルからセッションをロードすると、TopLinkランタイムにより、プロジェクトがインスタンス化されます（第75章「実行時のセッションの取得と使用」を参照）。sessions.xmlファイル内の情報に基づいて、ログインとそのプラットフォームもインスタンス化されます。
TopLinkランタイムでは、CMP以外のTopLinkアプリケーションのセッションを使用して永続性操作を実行する場合は常にセッション・ログインの情報が使用されます。
この場合、デプロイ・ログインは構成しません（「CMPデプロイ・ロール: デプロイ・ログイン」を参照）。
TopLink Workbenchを使用していて、ログインがリレーショナル・データベース・プラットフォームをベースにしている場合は、デプロイ・ログインも構成する必要があります（「開発ロール: 開発ログイン」を参照）。
sessions.xmlファイルにログインが含まれる場合は、その他のログイン定義はこのログインでオーバーライドされます。
データ・ソースに永続化するプロジェクト・タイプごとに、独立したセッション・ログイン・タイプがあります。利用可能なログイン・タイプの完全な一覧については、「データ・ソース・ログインのタイプ」を参照してください。
セッション・ログインの構成の詳細は、「セッション・ログインの構成」を参照してください。
TopLink対応のCMPアプリケーションに対して、project.xmlファイル（toplink-ejb-jar.xmlファイルとも呼ばれる）にデプロイ・ログインを作成します。
TopLink対応のCMPアプリケーションをそのtoplink-ejb-jar.xmlファイルとともにデプロイする場合、ビジネス・ロジックがコンテナ管理の永続性を備えたエンティティBean内から永続化の操作を実行する際には常に、アプリケーション・サーバーまたはEJBコンテナはデプロイ・ログイン内の情報を使用します。
この場合、セッション・ログインは構成しません（「CMP以外のセッションのロール: セッション・ログイン」を参照）。実際のところ、session.xmlファイルというものは存在しません（「CMPアプリケーションおよびセッション・メタデータ」を参照）。
TopLink Workbenchを使用していて、ログインがリレーショナル・データベース・プラットフォームをベースにしている場合は、デプロイ・ログインも構成する必要があります（「開発ロール: 開発ログイン」を参照）。
デプロイ・ログインの作成の詳細は、「開発ログインおよびデプロイ・ログインの構成」を参照してください。
TopLink Workbenchを使用していて、プロジェクトがリレーショナル・データベース・プラットフォームをベースにしている場合、TopLink Workbenchプロジェクト・ファイルに開発ログインを作成します。
TopLink Workbench内からデータ・ソースへの操作を実行するとき（たとえば、アプリケーション開発中にスキーマ情報をデータ・ストアから読み取ったりデータ・ストアに書き込むとき）には、TopLink Workbenchでは必ず開発ログインの情報が使用されます。開発ログインの情報がsessions.xmlまたはproject.xmlファイルに書き込まれることはありません。
開発ログインは、アプリケーションをデプロイするときに使用されることはありません。sessions.xmlファイル（「CMP以外のセッションのロール: セッション・ログイン」を参照）またはproject.xmlファイル（「CMPデプロイ・ロール: デプロイ・ログイン」を参照）によってオーバーライドされます。
開発ログインの作成の詳細は、「開発ログインおよびデプロイ・ログインの構成」を参照してください。
プロジェクトに関連付けられたプラットフォーム（存在する場合）は、プロジェクトが使用する特定のデータ・ソース・タイプをTopLinkランタイムに通知します。
プラットフォームには、バインディング、ネイティブSQLの使用、バッチ書込みの使用、順序付けなどの、特定のデータ・ソースに固有のオプションが含まれます。
ログインには、認証、接続プールの使用、および外部トランザクション・コントローラの使用などのデータソース・アクセスの詳細が含まれます。ログインにはプラットフォーム情報が含まれます。ログインの詳細は、「プロジェクトおよびログイン」を参照してください。
データ・ソースに永続化しないプロジェクトの場合、プラットフォームは必要ありません。データ・ソースに永続化するプロジェクトの場合、プラットフォームは常に必要です。
TopLink Workbenchでは、プロジェクト・タイプに応じて、プロジェクトで使用されるプラットフォームのタイプが決まります。
データ・ソースに永続化するプロジェクト・タイプごとに、独立したプラットフォーム・タイプがあります。利用可能なプラットフォーム・タイプの完全な一覧については、「データ・ソース・プラットフォームのタイプ」を参照してください。
オブジェクト・アイデンティティ（「キャッシュ・タイプおよびオブジェクト・アイデンティティ」を参照）を保持する上で重要なのは、順序付けです。つまり、インスタンスを区別するために一意の値の割当てを管理することです。
プロジェクトには、そのプロジェクトのタイプに応じて異なる順序付けの要件があります。
リレーショナル・プロジェクトの場合、オブジェクト識別子の値を管理する専用の独立した順序表（またはデータベース・オブジェクト）からオブジェクト識別子の値を通常、取得します（「リレーショナル・プロジェクトにおける順序付けの概要」を参照）。
EISプロジェクトの場合、EISデータ・ソースによって管理されるオブジェクト識別子の値を取得するために、ReturningPolicy（「ReturningPolicyの構成」を参照）を通常、使用します。
XMLプロジェクトの場合、単にオブジェクトとXML文書間のトランスフォーメーションを実行しているにすぎないので、順序付けは問題になりません。
順序付けを構成するには、次のものを構成する必要があります。
順序値の取得方法（「順序値の取得方法の構成」を参照）
ディスクリプタの参照クラスのインスタンスが作成される際の順序値の書込み場所（「順序値の書込み場所の構成」を参照）
使用する順序付けのタイプおよびアプリケーションのアーキテクチャに応じて、シーケンス接続プールの使用を考慮対象にできます。詳細は、「シーケンス接続プール」を参照してください。
TopLinkの順序値取得方法を決定するには、作成しているプロジェクトのタイプに応じて、プロジェクト・レベルまたはセッション・レベルでTopLink順序付けを構成します。
CMPプロジェクトの場合、セッションは直接構成しません。この場合、順序をプロジェクト・レベルで構成する必要があります（「プロジェクト・レベルでの順序付けの構成」を参照）。
CMP以外のプロジェクトの場合、セッションは直接構成できます。この場合、セッション・レベル順序構成を使用するのは、プロジェクト・レベルの順序構成のかわりとするためでも、またはプロジェクト・レベルの順序構成をセッション単位でオーバーライドするためでもかまいません（「セッション・レベルでの順序付けの構成」を参照）。
ディスクリプタの参照クラスのインスタンスが作成される際に順序値を書き込む表および列をTopLinkに指示するには、TopLinkの順序付けをディスクリプタ・レベルで構成します（「ディスクリプタ・レベルでの順序付けの構成」を参照）。
http://www.w3.org/TR/REC-xml-names/で定義されているように、XMLネームスペースは名前のコレクションであり、URI参照によって特定され、XML文書内で要素タイプおよび属性名として使用されます。再利用性およびモジュール性を向上させるには、XML文書構成に世界共通の名前が必要です。その世界共通名のスコープは、その名前を含んでいる文書を超えたものです。XMLネームスペースは、これを実現しているメカニズムです。
XMLネームスペースは、XMLスキーマを参照するプロジェクトに適用できます。つまり、XMLレコードを使用するEISプロジェクト（「EISプロジェクト」を参照）およびXMLプロジェクト（「XMLプロジェクト」を参照）です。
詳細は、「XMLネームスペースの概要」を参照してください。
従来型のリレーショナル・データベース（「リレーショナル・データベース用リレーショナル・プロジェクトの作成」を参照）または、オブジェクト・ストレージに特化されたデータ・タイプをサポートするオブジェクト・リレーショナル・データベース（「オブジェクト・リレーショナル・データベース用リレーショナル・プロジェクトの作成」を参照）に対するJavaオブジェクトのトランザクション永続性を実現するために、リレーショナル・プロジェクトを使用します。これらのデータベースは両方ともJDBCを使用してアクセスされます。
|
注意: TopLink Workbenchを使用している場合、TopLink WorkbenchクラスパスにJDBCドライバを追加する必要があります。TopLink WorkbenchおよびXMLタイプへ直接マッピング（「XMLタイプへ直接マッピング」を参照）を使用している場合、TopLink WorkbenchクラスパスにOracleデータベースxdb.jarファイルを追加する必要があります。
詳細は、「TopLink Workbench環境の構成」を参照してください。 |
リレーショナル・プロジェクトでは、TopLinkの問合せおよび式を十分に活用できます（第93章「TopLink問合せの概要」を参照）。
TopLink Workbenchは、JDBCを使用してアクセスされる従来型のリレーショナル・データベースにJavaオブジェクトをマップするリレーショナル・プロジェクトの作成を完全にサポートします。
表17-3は、リレーショナル・データベース用リレーショナル・プロジェクトのコンポーネントを示しています。
表17-3 リレーショナル・データベース用リレーショナル・プロジェクトのコンポーネント
| コンポーネント | サポートされているタイプ |
|---|---|
|
データ・ソース |
詳細は、次を参照してください。 |
|
ディスクリプタ |
詳細は、「リレーショナル・ディスクリプタ」を参照してください。 |
|
マッピング |
詳細は、次を参照してください。 |
TopLink Workbenchは、現在、オブジェクト・リレーショナル・データベース用リレーショナル・プロジェクトをサポートしていません。オブジェクト・リレーショナル・データベース用リレーショナル・プロジェクトはJavaで作成する必要があります。
Javaを使用して、オブジェクト・ストレージ用に特化されたデータ・タイプをサポートする、JDBCを使用してアクセスされるオブジェクト・リレーショナル・データベースに対するJavaオブジェクトのトランザクション永続性を可能にする、リレーショナル・プロジェクトを作成できます。
TopLinkを使用してオブジェクト・リレーショナル・データベース用リレーショナル・プロジェクトを作成する場合、次のことに注意します。
構造型（Struct/object-type）ごとにJavaクラスとTopLink ObjectRelationalDescriptorを作成する必要があります。
TopLinkがサポートするのは、基本タイプの配列（Varrays）または構造型（Struct/object-type）の配列のみです。
TopLinkは、Refsの配列、ネストした表の配列はサポートしません。
TopLinkは、Refsのネストした表のみサポートします。
TopLinkは、基本タイプ、構造型または配列タイプのネストした表はサポートしません。
オブジェクト・リレーショナル・データベース用リレーショナル・プロジェクトを作成する際の一般的な開発プロセスは、次のとおりです。
データベースに構造型のオブジェクト・タイプを定義します。
データベースに構造型のオブジェクト・タイプの表を定義します。
構造型のオブジェクト・タイプにマップするJavaクラスを定義します。
リレーショナル・プロジェクトを作成します（「プロジェクトの作成」を参照）。
各Javaクラスに対して、オブジェクト・リレーショナル・ディスクリプタを作成します（「オブジェクト・リレーショナル・ディスクリプタの作成」を参照）。
各Javaクラスの永続フィールドからそれに対応するオブジェクト・タイプおよびオブジェクト・タイプ表へのオブジェクト・リレーショナル・マッピングを作成します（第47章「オブジェクト・リレーショナル・マッピングの構成」を参照）。
表17-4は、オブジェクト・リレーショナル・データベース用リレーショナル・プロジェクトのコンポーネントを示しています。
表17-4 オブジェクト・リレーショナル・データベース用リレーショナル・プロジェクトのコンポーネント
| コンポーネント | サポートされているタイプ |
|---|---|
|
データ・ソース |
詳細は、次を参照してください。 |
|
ディスクリプタ |
詳細は、「オブジェクト・リレーショナル・ディスクリプタ」を参照してください。 |
|
マッピング |
詳細は、次を参照してください。 |
EISプロジェクトを使用すると、J2EE Connector Architecture（J2C）アダプタおよびEISレコードを使用してアクセスされる非リレーショナル・データ・ソースへの、Javaオブジェクトのトランザクション永続性が実現します。
J2Cにより、非リレーショナルEISにアクセスするためのCommon Client Interface（CCI）APIが提供されます。このAPIにより、JDBCによってリレーショナル・データ・ソースへのアクセスに提供されるインタフェースに類似した、非リレーショナル・データ・ソースへのインタフェースが実現されます。このAPIは、マップ済レコードおよび索引レコードを含む、複数の非リレーショナル・レコード・タイプを定義します。XMLはデータ交換の標準形式として登場し、主要なJ2Cアダプタ・プロバイダの大部分はXMLデータ・レコードを定義するためにCCI APIを拡張してきました。
TopLink EISとともにJCAアダプタを使用するには、JCAアダプタがJCA CCIインタフェースをサポートしている必要があります。実行時に、JCAアダプタおよびJava connector.jarファイル（このファイルにTopLink EISが使用するjavax.resource.cciおよびjavax.resource.spiインタフェースが含まれる）は、アプリケーションまたはアプリケーション・サーバーのクラスパス上に存在している必要があります。
TopLink Workbenchを使用している場合、TopLink WorkbenchクラスパスにJCAアダプタを追加する必要があります。デフォルトでは、TopLink Workbenchにより、そのクラスパスは、<TOPLINK_HOME>/j2ee/home/libにあるJava 1.5 connector.jarファイルを含むように更新されます。このバージョンのconnector.jarファイルが環境と互換性を持たない場合、<TOPLINK_HOME>/binのworkbench.cmdまたはworkbench.shファイルを編集して、このファイルへのパスを変更します。詳細は、「TopLink Workbench環境の構成」を参照してください。
EISには、レガシー・データ・ソース、エンタープライズ・アプリケーション、レガシー・アプリケーションおよびその他の情報システムが含まれます。これらのシステムにはCustomer Information Control System（CICS）、Virtual Storage Access Method（VSAM）、Information Management System（IMS）、ADABASEデータベースおよびフラット・ファイルなどのソースが含まれます。
EISプロジェクトを使用して、レガシーまたは非リレーショナルのデータ・ソースとTopLinkを統合することをお薦めします。EISデータ・ソースにアクセスするその他の方法には、次のものがあります。
EISシステムがリレーショナル・データベースであるかのようにEISシステムに接続できる特別なJDBCドライバを使用します。これらのドライバを使用して、TopLinkリレーショナル・プロジェクトを使用できます（「リレーショナル・プロジェクト」を参照）。
Oracleデータベースなどのリレーショナル・データベースにあるEISデータとリンクまたは統合します。
プロプラエタリのAPIを使用してEISシステムにアクセスします。この場合、J2C CCIインタフェースでAPIをラップして、TopLink EISプロジェクトとともに使用できるようにすることもできます。
TopLinkにより、第XII部「EISマッピング」で説明されるTopLinkマッピングを使用して、J2Cを介して、EISのマップ済レコード、索引レコードおよびXMLレコードへのJavaオブジェクトのマッピングがサポートされます。
特定のEISレコード形式を使用するようにTopLink EISディスクリプタを構成します（「レコード形式の構成」を参照）。TopLink EISマッピングは、EISディスクリプタでのレコード形式の構成を使用して、EISレコードへのJavaオブジェクトのマップ方法を決定します。
XMLレコードを使用する場合、TopLinkランタイムは1つ以上のXMLスキーマに基づいてXMLデータ変換を行います。XMLレコードを使用するEISプロジェクトでは、TopLink WorkbenchがデプロイXMLのスキーマを直接参照し、指定したスキーマに関して構成されたマッピングをエクスポートします。XMLスキーマによるTopLink Workbenchの使用方法の詳細は、「XMLスキーマの使用」を参照してください。TopLinkでのXMLネームスペースのサポートの詳細は「XMLネームスペース」を参照してください。
表17-5は、EISプロジェクトのコンポーネントを示しています。
表17-5 EISプロジェクトのコンポーネント
| コンポーネント | サポートされているタイプ |
|---|---|
|
データ・ソース |
詳細は、次を参照してください。 |
|
ディスクリプタ |
詳細は、「EISディスクリプタ」を参照してください。 |
|
マッピング |
詳細は、次を参照してください。 |
TopLink Workbenchにより、EIS XMLレコードを使用できるようにするためのEISプロジェクトを作成できます（「XMLレコードを使用するEISプロジェクトの作成」を参照）。または、サポートされている任意のEISレコード・タイプを使用できるようにするための、JavaでのEISプロジェクトを作成できます（「索引レコードまたはマップ済レコードを使用するEISプロジェクトの作成」を参照）。
EISプロジェクトでは、EISインタラクション（「企業情報システム（EIS）インタラクション」を参照）で、TopLinkの問合せを完全活用できます（第93章「TopLink問合せの概要」を参照）。ただし、TopLink式はEISとともに使用できません。EISプロジェクトでは、インタラクションが式に取ってかわるためです。
TopLink Workbenchは、EIS XMLレコードにJavaオブジェクトをマップするEISプロジェクトの作成を完全にサポートします。
TopLink Workbenchを使用すると、J2CアダプタおよびEIS XMLレコードを使用してアクセスされる非リレーショナル・データ・ソースに対するJavaオブジェクトのトランザクション永続性を可能にする、EISプロジェクトを作成できます。
TopLinkランタイムは、1つ以上のXMLスキーマに基づいてXMLデータ変換を行います。EISプロジェクトでは、TopLink WorkbenchはデプロイXMLのスキーマを直接参照しませんが、そのかわりに特定のスキーマと一致するように構成されたマッピングをエクスポートします。
EIS問合せはXMLInteractionを使用します。詳細は、「EISインタラクションの使用」を参照してください。
TopLink Workbenchは、現在、非XML EISプロジェクトをサポートしていません。非XML EISプロジェクトはJavaで作成する必要があります。
Javaを使用すると、J2Cアダプタおよびサポートされる任意のEISレコード・タイプ（索引付き、マップ済またはXML）を使用してアクセスされる非リレーショナル・データ・ソースに対するJavaオブジェクトのトランザクション永続性を可能にする、EISプロジェクトを作成できます。
XMLレコードを使用する場合、TopLinkランタイムは1つ以上のXMLスキーマに基づいてXMLデータ変換を行います。JavaでEISプロジェクトを作成する場合、これらのスキーマに関するマッピングを構成しますが、TopLinkランタイムはこれらのスキーマを直接参照しません。
問合せを、サポートされているEISインタラクションであるIndexedInteraction、MappedInteraction（QueryStringInteractionを含む）またはXMLInteraction（XQueryInteractionを含む）に基づいて作成することができます。詳細は、「EISインタラクションの使用」を参照してください。
XMLプロジェクトを使用すると、JAXBを使用して、JavaオブジェクトとXML文書間で、非トランザクション型の、永続化を行わない（インメモリー）変換を行うことができます（「TopLinkによるJava Architecture for XML Binding（JAXB）のサポート」および「JAXBの検証」を参照）。TopLink Workbenchは、XMLプロジェクトの作成を完全にサポートします。
TopLinkランタイムは、1つ以上のXMLスキーマに基づいてXMLデータ変換を行います。XMLプロジェクトでは、TopLink Workbenchが配布XMLのスキーマを直接参照し、指定したスキーマに関して構成されたマッピングをエクスポートします。XMLスキーマによるTopLink Workbenchの使用方法の詳細は、「XMLスキーマの使用」を参照してください。TopLinkでのXMLネームスペースのサポートの詳細は「XMLネームスペース」を参照してください。
表17-6は、XMLプロジェクトのコンポーネントを示しています。
表17-6 XMLプロジェクトのコンポーネント
| コンポーネント | サポートされているタイプ |
|---|---|
|
データ・ソース |
なし |
|
ディスクリプタ |
詳細は、「XMLディスクリプタ」を参照してください。 |
|
マッピング |
詳細は、次を参照してください。 |
XMLプロジェクトでは、TopLinkの問合せおよび式を使用しません。
JAXBは、標準JavaオブジェクトとXMLの間の変換用APIを提供します。詳細は、http://java.sun.com/xml/jaxb/index.htmlを参照してください。
TopLinkは、JAXBの上部に追加の機能レイヤーを提供します。このレイヤーにより、JAXBオブジェクト・モデルを再コンパイルしなくても、既存のオブジェクト・モデルからマッピングを作成し、それを引き続き操作できるようになります。
この機能の中核的コンポーネントは、TopLink JAXBコンパイラです。TopLink JAXBコンパイラを使用すると、TopLink XMLプロジェクトとJAXB準拠のオブジェクト・モデル・クラスの両方をXMLスキーマから生成できます。
TopLink JAXBコンパイラは、必要なJAXBファイル（「JAXB固有の生成ファイルの概要」を参照）とTopLinkファイル（「TopLink固有の生成ファイルの概要」を参照）の両方をXMLスキーマ（XSD）ドキュメントから自動生成する（「XMLスキーマからのXMLプロジェクトの作成」を参照）ことにより、TopLinkを使用したJAXBアプリケーション開発を容易にします。
TopLink JAXBコンパイラが生成するJAXBおよびTopLinkに固有のファイルの使用の詳細は、「TopLink JAXBコンパイラ生成ファイルの実行時での使用」を参照してください。
TopLink JAXBコンパイラは、XSDから次のようなJAXB固有のファイルを生成します。
JAXBランタイムは、これらのファイルをJAXB仕様で規定されているとおりに使用します。
すべてのJAXB固有ファイルは、定義した出力ディレクトリ、および定義したターゲット・パッケージ名によって暗黙的に定義されるサブディレクトリに生成されます。TopLink JAXBバインド・コンパイラ・オプションの詳細は、「XMLスキーマからのXMLプロジェクトの作成」を参照してください。
生成されたクラスをコンパイルする前に、<ORACLE_HOME>\lib\xml.jarを含むよう統合開発環境（IDE）クラスパスを構成してください。たとえば、第6章「統合開発環境の使用」を参照してください。
すべてのインタフェースは、XSDで定義されたコンテンツ、要素または実装のname属性に従って名前を付けられます。
すべての実装クラスは、XSDで定義されたコンテンツ、要素または実装のname属性、および接尾辞のImplを使用して名前を付けられます。
生成される実装クラスは、単純なドメイン・クラスです。各JAXBプロパティにはprivate属性を持ち、属性値を返したり設定するpublicのgetおよびsetメソッドを持ちます。
ObjectFactoryクラスは、コンテンツと要素の各インタフェースに対してインスタンス・ファクトリ・メソッドを提供します。たとえば、要素インタフェースItemsImplに対しては、次のシグネチャを持つインスタンス・ファクトリ・メソッドがObjectFactoryクラスにあります。
public ItemsImpl createItemsImpl() throws javax.xml.bind.JAXBException
ObjectFactoryクラスは、次のシグネチャを持つ動的インスタンス・ファクトリ・アロケータも提供します。
public static Object newInstance(Class javaContentInterface)
throws javax.xml.bind.JAXBException
JAXBプロパティ・ファイルはjaxb.propertiesという名前であり、JAXBContextのTopLink実装の完全修飾名と等しい値でjavax.xml.bind.context.factoryプロパティを定義した単一のエントリを含みます。
javax.xml.bind.context.factory=oracle.toplink.ox.jaxb.JAXBContextFactory
TopLink JAXBコンパイラは、XSDから次のようなTopLink固有のファイルを生成します。
これらのファイルを使用して、生成されたJAXB固有オブジェクトに対応するTopLinkメタデータをカスタマイズします。
すべてのTopLink固有ファイルは、指定した出力ディレクトリのサブディレクトリtoplinkに生成されます（「XMLスキーマからのXMLプロジェクトの作成」を参照）。
toplinkサブディレクトリは、図17-1に示すように編成されます。
生成されたsessions.xmlファイルでは、name要素がコンテキスト・パスの名前であり、project-xml要素が生成されたプロジェクトXMLファイルの名前です。
例17-1では、代表的なsessions.xmlファイルが示されています。ここではコンテキスト・パスはexamples.ox.modelです。
例17-1 生成されるsessions.xmlファイルの代表例
<?xml version="1.0" encoding="US-ASCII"?>
<toplink-sessions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="file://xsd/sessions_10_0_3.xsd" version="0">
<session xsi:type="database-session">
<name>customer_example</name>
<primary-project xsi:type="xml">purchaseOrder.xml</primary-project>
<login xsi:type="xml-login">
<platform-class>oracle.toplink.ox.platform.SAXPlatform</platform-class>
</login>
</session>
</toplink-sessions>
このTopLinkセッションは、他のTopLinkプロジェクト内での場合と同様に、TopLink XML APIへのプライマリ・ファサードになっています（「TopLink JAXBコンパイラ生成ファイルの実行時での使用」を参照）。
プロジェクトXMLファイルには、XSDと同じファイル名とファイル拡張子xmlが付けられます。図17-1では、生成されたプロジェクトXMLファイルの名前はpurchaseOrder.xmlです。
プロジェクトXMLファイルには、ディスクリプタ、ならびにそのディスクリプタへの各コンテンツ、要素および実装クラスのマッピングが含まれます。
TopLink Workbenchプロジェクトは、図17-1に示されているサブディレクトリに書き込まれます。このサブディレクトリには、XSDと同名だがファイル拡張子がmwpのTopLink Workbenchプロジェクト・ファイルが含まれ、必須のclassおよびdescriptorサブディレクトリを伴います。図17-1では、TopLink WorkbenchプロジェクトにはpurchaseOrder.mwpという名前が付けられています。
あるいは、このTopLink Workbenchプロジェクトを使用して、生成されたディスクリプタおよびマッピングをカスタマイズし、プロジェクトXMLファイルを再エクスポートすることもできます。
任意の実装クラスに、型保証列挙へのマッピングが含まれる場合、TopLink JAXBコンパイラは、DescriptorAfterLoadsという名前の単一クラスを生成します（「マッピングおよびJAXB型保証列挙」を参照）。
TopLink JAXBコンパイラは、型保証列挙へのマッピングを含む実装クラスごとにamend<ImplementationClassName>という名前のディスクリプタ修正メソッドを使用して、このDescriptorAfterLoadsクラスを更新します。修正メソッドは、その実装クラス内の型保証列挙へのマッピングごとに、JAXBTypesafeEnumConverterのインスタンスを設定します。
TopLink JAXBコンパイラが作成するTopLink Workbenchプロジェクト（「TopLink Workbenchプロジェクト」を参照）は、この修正メソッドを使用して実装クラス・ディスクリプタを構成します。生成されたTopLink Workbenchプロジェクトを開いて、配布XMLを再生成しても、この機能のサポートは失われません。
実行時に、TopLink JAXBコンパイラ生成ファイルにアクセスできます。
TopLinkにより提供されるXMLContextクラスを使用して、TopLink XMLMarshaller、XMLUnmarshallerおよびXMLValidatorのインスタンスを作成できます。
XMLContextはスレッド・セーフです。たとえば、同じXMLContextオブジェクトにアクセスする複数のスレッドがXMLMarshallerをリクエストする場合、各スレッドが専用のXMLMarshallerインスタンスを受け取り、このため、そのXMLMarshallerが保持する状態はいずれもそのプロセスにかぎられたものとなります。同じことがXMLUnmarshallerおよびXMLValidatorのインスタンスにも当てはまります。
XMLContextの使用により、Webサービスのバインド層などのマルチスレッド・アーキテクチャでTopLink XMLを使用できます。
TopLink XMLContextを使用するには、次のように行います。
アプリケーション・クラスパスを構成して、ドメイン・オブジェクト・クラス・ファイル（「JAXB固有の生成ファイルの概要」を参照）とTopLinkランタイムを含めます。
セッション・マネージャを取得します（「セッション・マネージャの取得」を参照）。
TopLink JAXBコンパイラで生成したsessions.xmlファイルを使用し、セッション・マネージャを使用して、XMLセッションを取得します（「セッション・マネージャからのセッションの取得」を参照）。
セッションからXMLプロジェクト・インスタンスを取得します。
Project myProject = session.getProject();
プロジェクトを使用してTopLink XMLコンテキスト・インスタンスを作成します。
XMLContext context = new XMLContext(myProject);
XMLContextを使用して、TopLink XMLMarshaller、XMLUnmarshallerおよびXMLValidatorを作成します。
XMLMarshaller marshaller = context.createMarshaller();
marshaller.marshal(myObject, outputStream);
marshaller.setFormattedOutput(true);
XMLUnmarshaller unmarshaller = context.createUnmarshaller();
Employee emp = (Employee)unmarshaller.unmarshal(new File("employee.xml"));
XMLValidator validator = context.createValidator();
boolean isValid = validator.validate(emp);
例17-2に示すように、生成ファイル用に選択したターゲット・パッケージ名をコンテキスト・パスとして使用して、JAXBContextのインスタンスを作成できます（「JAXB固有の生成ファイルの概要」を参照）。この例では、ドメイン・オブジェクト・クラス・ファイルが含まれるようにアプリケーション・クラスパスを構成しているものとします。
JAXBContextはスレッド・セーフです。
TopLinkは、実装クラスを生成するために使用されたXMLスキーマに対して、完全なオブジェクト・ツリーとサブツリーの両方を検証できます。さらに、TopLinkは、オブジェクトの実装クラスを生成するために使用されたスキーマに対して、ルート・オブジェクト（XML文書のルート要素に対応するオブジェクト）と非ルート・オブジェクトの両方を検証できます。
オブジェクト・ツリーを検証する場合、TopLinkは次のチェックを（順に）実行します。
要素が文書内の指定された場所にあるかをチェックします。
maxOccursまたはminOccursが指定されている場合、要素の数をチェックします。
タイプが指定されている場合、要素の値がタイプ制約を満たしているかをチェックします。
固定値が指定されている場合、要素の値がそれに一致しているかをチェックします。
制約（長さ、パターン、列挙など）が指定されている場合、要素の値がそれを満たしているかをチェックします。
validateRoot操作に対してIDタイプが指定されている場合、IDの値が文書内で一意であるかをチェックします。
validateRoot操作に対してIDREFタイプが指定されている場合、参照されるIDが文書内に存在しているかをチェックします。
検証エラーが発生した場合、JAXB仕様に従って、TopLinkはオブジェクト・ツリーの検証を中止し、ValidationEventオブジェクトを作成します。エラーがサブオブジェクト内で発生した場合は、TopLinkはオブジェクトのそのサブツリーより下を検証しません。
TopLink XMLを使用した検証の詳細は、「TopLink JAXBコンパイラ生成ファイルの実行時での使用」を参照してください。
JAXBおよび検証の詳細は、http://java.sun.com/xml/jaxb/のJAXB仕様を参照してください。
リレーショナル・プロジェクトでは、アプリケーションの永続オブジェクトは、インスタンス化されたオブジェクトのクラスを表すデータベース表に格納します。図17-2に示されるように、VEHICLE_POOL表の各行は、そのクラスからのインスタンス化されたオブジェクトを表し、VEH_ID列には各オブジェクトの主キーが保持されます。
プロジェクト・レベルまたはセッション・レベルでTopLinkの順序付けを構成し（「プロジェクト・レベルでの順序付けの構成」または「セッション・レベルでの順序付けの構成」を参照）、主キー列の値を取得する方法、つまり使用する順序付けのタイプ（「順序付けタイプ」を参照）をTopLinkに指示します。
ディスクリプタ・レベルでTopLinkの順序付けを構成し（「ディスクリプタ・レベルでの順序付けの構成」を参照）、ディスクリプタの参照クラスのインスタンスが作成される際に順序値を書き込む表および列をTopLinkに指示します。
この項の内容は次のとおりです。
TopLink WorkbenchまたはJavaの（両方ではなく）いずれかを使用して、順序付けを構成できます。
TopLink Workbenchを使用して、順序付けが必要なすべてのディスクリプタに適用される単一の事前割当てサイズで1つの順序を作成します。表の順序付け（「表の順序付け」を参照）またはネイティブ順序付け（「Oracleデータベース・プラットフォームによるネイティブ順序付け」を参照）を構成できます。表の順序付けを選択する場合、デフォルトの表名と列名を使用するか、または独自に指定することができます（「デフォルト表対カスタム順序表」を参照）。順序付けを構成するにはTopLink Workbenchの使用をお薦めします。TopLink Workbenchを使用すると、ほとんどのアプリケーションに適用できる順序付けオプションを簡単に構成できます。詳細は、「プロジェクト・レベルでの順序付けの構成」または「セッション・レベルでの順序付けの構成」を参照してください。
Javaを使用する場合、TopLinkがサポートしている任意の順序タイプを構成できます（「順序付けタイプ」を参照）。プロジェクトごとに順序を任意の数および組合せで作成できます。明示的に順序オブジェクトを作成することや、プラットフォームのデフォルト順序を使用することが可能です（「デフォルトの順序付け」を参照）。同じ順序を複数のディスクリプタに関連付けるか、異なる順序（および異なる順序タイプ）を様々なディスクリプタに関連付けることができます。各ディスクリプタの順序に別個の事前割当てサイズを構成できます。詳細は、「Javaの使用」を参照してください。
TopLinkでは次の順序タイプをサポートします。
表の順序付けを使用する場合、プロジェクトの1つ以上の順序付けされたオブジェクトに関する順序付け情報を含む、単一のデータベース表を作成します。TopLinkでは、この表を維持してこれらのオブジェクト・タイプの順序番号を追跡します。
図17-3に示すように、表は順序付けを使用する1つ以上のクラスに関する順序付け情報を含む場合があります。デフォルトの表は、SEQUENCEという名前で、次の2つの列で構成されます。
SEQ_NAME: 選択された行が参照するクラス・タイプを指定します。
SEQ_COUNT: 選択された行で表されるオブジェクトに現在割り当てられている最も大きい順序番号を指定します。
SEQUENCE表の行は、それぞれの順序オブジェクトを表します。つまり、順序付けにかかわる各クラスに対する順序オブジェクト、または同じ事前割当てプールを活用できるように複数のクラスにまたがる単一の順序オブジェクトです。ディスクリプタ・レベルで順序付けを構成する際（「ディスクリプタ・レベルでの順序付けの構成」を参照）、クラスに対してSEQ_NAMEを指定します。その名前の行をSEQUENCE表に追加し、SEQ_COUNT列の値を0に初期化します。
新しいクラスのインスタンスが登録されるたびに、TopLinkは必要な順序値を取得します。効率性を高めるため、TopLinkでは事前割当てを使用して、順序値の取得に必要な表へのアクセス数を削減します（「順序付けと事前割当てサイズ」を参照）。
次の2つのいずれかの方法で、データベースにSEQUENCE表を作成できます。
表の作成には、TopLink Workbenchを使用します。詳細は、「データベースでの表の生成」を参照してください。
TopLinkの表作成機能を使用し、手動で表を作成および更新します。詳細は、「SQL作成スクリプトの生成」を参照してください。
TopLink WorkbenchまたはJavaを使用して、表の順序付けを構成できます。TopLink Workbenchを使用することをお薦めします。表の順序付けの構成の詳細は、「プロジェクト・レベルでの順序付けの構成」または「セッション・レベルでの順序付けの構成」を参照してください。
表の順序付けと類似していますが（「表の順序付け」を参照）、単一列表の順序付けでは、プロジェクトの順序付けされたオブジェクトそれぞれに対して別個の順序表を作成します。
図17-4に示すように、順序付けの情報は、順序付けを使用する単一のクラスの表に表示されます。表には任意に名前を付けることができますが、1列のみ（デフォルトで）SEQUENCEという名前を付けられたものを含む必要があります。
ディスクリプタ・レベルで順序付けを構成する際に、クラスに対して順序名を指定します。これは、単一列表順序表の名前です。図17-4は、Employeeクラスに対する単一列表順序を示しています。Employeeクラス・ディスクリプタは、単一列表順序表の名前と一致するようにEMP_SEQの順序名を使用して構成されます（「ディスクリプタ・レベルでの順序付けの構成」を参照）。TopLinkはこの表に1行追加し、SEQUENCE列の値を1に初期化します。
新規クラスが作成されるたびに、TopLinkはそのクラスに対応する単一列順序表の単一行から必要な順序値を取得します。効率性を高めるため、TopLinkでは事前割当てを使用して、順序値の取得に必要な表へのアクセス数を削減します（「順序付けと事前割当てサイズ」を参照）。
次の2つの方法のうちいずれかで、データベースに単一列表順序表を作成できます。
表の作成には、TopLink Workbenchを使用します。詳細は、「データベースでの表の生成」を参照してください。
TopLinkの表作成機能を使用し、手動で表を作成および更新します。詳細は、「SQL作成スクリプトの生成」を参照してください。
BEA WebLogic CMPアプリケーションからOC4JおよびTopLinkの永続性に移行する場合（「BEA WebLogic永続性のOC4J TopLink永続性への移行」を参照）、TopLink移行ツールを使用しても、BEA WebLogicの単一列順序表はTopLinkの単一列順序表に移行されません（「単一列表の順序付け」を参照）。当初、アプリケーションがBEA WebLogicの単一列順序表を使用していた場合は、移行後はTopLinkの単一列順序表を使用するようにプロジェクトを手動で構成する必要があります。
現在は、UnaryTableSequenceクラスを使用してJavaで単一列表順序付けの構成のみが可能です（詳細は、「Javaの使用」を参照）。
問合せの順序付けにより、カスタム読取り（ValueReadQuery）およびカスタム更新（DataModifyQuery）、および自分で指定する事前割当てサイズを使用して、順序リソースにアクセスできます。これにより、ストアド・プロシージャを使用して順序付けを実行できるようになり、TopLinkが提供する他の順序付けタイプではサポートされない順序リソースにアクセスできるようになります。
現在は、QuerySequenceクラスを使用してJavaで問合せの順序付けの構成のみが可能です（詳細は、「問合せの順序付けの構成」を参照）。
ログインに所有されるプラットフォームは、そのプラットフォーム・タイプに対して適切なデフォルト順序インスタンスを提供する役割を担っています。たとえば、デフォルトでは、DatabasePlatformにより、デフォルトの表および列名を使用して表の順序が提供されます（「表の順序付け」を参照）。
このデフォルト順序には、DatasourceLoginメソッドgetDefaultSequenceを使用して直接、またはDefaultSequenceクラス、プラットフォームのデフォルト順序のラッパーを使用して間接的にアクセスできます。
存在しない順序にディスクリプタを関連付けると、TopLinkランタイムはDefaultSequenceのインスタンスを作成し、このディスクリプタの順序付けを提供します。詳細は、「プラットフォームのデフォルト順序の構成」を参照してください。
DefaultSequenceの主な用途は、プロジェクトのデフォルトとは異なる事前割当てサイズを順序で使用可能にすることです。
現在は、Javaでのデフォルト順序付けの使用のみ可能です（詳細は、「プラットフォームのデフォルトの順序の使用」を参照）。
Oracleデータベースによるネイティブ順序付けに対するTopLinkのサポートは、表の順序付けと同様です（「表の順序付け」を参照）が、TopLinkで表がデータベースに保持されない点が異なります。かわりに、データベースには、順序付けされたオブジェクトの現在の最大番号および事前割当てサイズが格納される順序オブジェクトが含まれます。ディスクリプタ・レベルで構成された順序名は、ディスクリプタの参照クラスに対して順序付けの値を提供する役割を担う順序オブジェクトを識別します。
TopLink WorkbenchまたはJavaを使用して、ネイティブ順序付けを構成できます。TopLink Workbenchを使用することをお薦めします。表の順序付けの構成の詳細は、「プロジェクト・レベルでの順序付けの構成」または「セッション・レベルでの順序付けの構成」を参照してください。
OracleのSEQUENCEオブジェクトは、TopLinkの順序付けと非常に似た方法を実装します。つまり、TopLinkの事前割当てサイズに相当するINCREMENT構成メンバー、および表の順序付けにおけるTopLinkのSEQUENCE表のSEQ_COUNTフィールドに相当するsequence.nextval構成メンバーを実装します。この実装により、TopLinkでは、OracleのSEQUENCEオブジェクトをTopLinkのSEQUENCE表のように使用でき、TopLinkで表の作成および保持をする必要性はなくなります。
表の順序付けと同様に、TopLinkは、OracleのSEQUENCEオブジェクトにsequence.nextvalを増やして、その結果を返すように要求し、使用可能な番号のプールを作成します。Oracleは、値INCREMENTをsequence.nextvalに加算し、TopLinkはその結果を使用して順序付けプールを作成します。
このプロセスと、表の順序付けにおけるプロセスとの主な相違点は、TopLinkがSEQUENCEオブジェクトのINCREMENT構成メンバーを認識していないことです。TopLinkの順序付けおよびOracleのSEQUENCEオブジェクトは独立して動作します。アプリケーションでの順序付けエラーを回避するには、TopLinkの事前割当てサイズおよびOracleのSEQUENCEオブジェクトのINCREMENTを同じ値に設定します。TopLinkが次の順序値を取得する際、前の事前割当てサイズの値を持っているとみなすため、Oracle順序オブジェクトの開始値は事前割当てサイズと等しい必要があります。
データベース管理者（DBA）は、アプリケーションが必要とする順序付けのシリーズごとに、データベースにSEQUENCEオブジェクトを作成する必要があります。アプリケーションのすべてのクラスに独自の順序が必要な場合、DBAはクラスごとにSEQUENCEオブジェクトを作成します。複数のクラスに1つの順序を共有させる場合、DBAはこれらのクラスに対してSEQUENCEオブジェクトを1つのみ作成する必要があります。
たとえば、図17-5では、3つのスタイルのテニス・ラケットを製造しているスポーツ用品メーカーの場合を考えてみます。これらのスタイルのラケットのデータは、次のようにデータベースに格納されています。
各スタイルのラケットには、独自のクラス表があります。
製造されるラケットはそれぞれ1つのオブジェクトで、クラス表の1行で表されます。
システムにより、順序付けを使用して、シリアル番号がラケットに割り当てられます。
製造メーカーは、次のいずれかを行うことができます。
ラケットのスタイルごとに異なる順序付けを使用する: DBAは、ATTACK_SEQ、VOLLEY_SEQおよびPROX_SEQといった名前の3つの異なるSEQUENCEオブジェクトを作成します。異なるラケットの系列はそれぞれ独自のシリアル番号のシリーズを持ち、系列間ではシリアル番号の重複が発生することもあります（3つのスタイルすべてにシリアル番号1234のラケットがあるなど）。
1つの順序のシリーズをすべてのラケットに対して使用する: DBAは、RACQUET_SEQといった名前のSEQUENCEオブジェクトを1つ作成します。メーカーは、ラケットのスタイルに関係なく、製造したラケットにシリアル番号を割り当てます。
データベースには、データベース管理システムによって順序番号が生成される、一種のネイティブ順序付けをサポートするものがあります。
ネイティブ順序付けを使用するクラスについてデータベース表を作成する際は、主キー列を含め、次のように列のタイプを設定します。
Sybase SQL ServerおよびMicrosoft SQL Serverデータベースの場合、主キー・フィールドをタイプIDENTITYに設定します。
IBM Informixデータベースの場合、主キー・フィールドをタイプSERIALに設定します。
|
注意: TopLinkでは、IBM DB2データベースのネイティブ順序付けをサポートしません。 |
新規オブジェクトを表に挿入する場合、TopLinkは、そのオブジェクトを表に挿入する前に移入しますが、順序番号を含めません。データベースが、そのオブジェクトを表に挿入するときに、前のオブジェクトの主キーに1を加えた値を主キー・フィールドに自動的に移入します。
この時点で、トランザクションが終了する前に、TopLinkは、TopLinkのキャッシュにあるアイデンティティを持つように、新規オブジェクトの主キーを読み取りなおします。
|
注意: このタイプの順序付けは事前割当てをサポートしないため、事前割当てサイズを1に設定する必要があります。順序の事前割当ての利点を活用するには、これらのデータベースにはネイティブ順序付けではなく表の順序付けの使用をお薦めします。 |
データベースがネイティブ順序付けを提供していても、TopLinkがそれを直接サポートしない場合は、問合せ順序およびストアド・プロシージャを使用してネイティブ順序オブジェクトにアクセスできる場合があります。詳細は、「問合せの順序付け」を参照してください。
TopLink WorkbenchまたはJavaを使用して、ネイティブ順序付けを構成できます。TopLink Workbenchを使用することをお薦めします。表の順序付けの構成の詳細は、「プロジェクト・レベルでの順序付けの構成」または「セッション・レベルでの順序付けの構成」を参照してください。
順序付けの効率性を高めるため、TopLinkでは順序番号を事前に割り当てることができます。事前割当てにより、TopLinkでは、新規オブジェクトが作成され、データベースに挿入されるときに割り当てられる使用可能な順序番号のプールを作成できます。TopLinkは、プールが空になるまで、順序プールから番号を割り当てます。
事前割当てサイズは、使用可能な番号のプールのサイズを指定します。事前割当てにより、順序付けに必要なデータベースへのアクセス回数が大幅に減少し、順序付けの効率は高まります。デフォルトでは、TopLinkは事前割当てサイズを50に設定します。事前割当てサイズはTopLink Workbenchで、またはセッション・ログインの一部として指定できます。
事前割当てサイズの構成は、表の順序付けおよびOracleネイティブ順序付けに適用されます。Oracleネイティブ順序付けでは、順序の事前割当てサイズはOracle順序オブジェクトの増分サイズと一致する必要があります。他のデータベースでは自動割当て順序列を使用するため、他のデータベースでのネイティブ順序付けには事前割当てを利用できません。事前割当てを使用できるようにするため、Oracle以外のデータベースでは表の順序付けの使用をお薦めします。
表の順序付けの場合、TopLinkは順序付けされたクラスごとに事前に割り当てられた値のプールを保持します。TopLinkは、この値のプールが空になると、次のように新しい値のプールを確保します。
TopLinkはデータベースにアクセスし、（SEQ_NAMEによって識別される）特定のクラスに対するSEQ_COUNTを事前割当てサイズだけ増やし、その結果を返すように要求します。
たとえば、図17-3のSEQUENCE表を考えてみます。新しい発注書が作成され、TopLinkの順序番号のプールが空になった場合、TopLinkはSQL文を実行し、SEQ_PURCH_ORDERのSEQ_COUNTを事前割当てサイズ（この場合、TopLinkのデフォルトの50）だけ増やします。データベースはSEQ_PURCH_ORDERのSEQ_COUNTを1600に増やし、この数値をTopLinkに返します。
TopLinkは、新しい順序番号のプールについて最大値および最小値を計算し、値のプールを作成します。
TopLinkは、オブジェクト・シーケンス属性にプールの最初の番号を移入し、オブジェクトをクラス表に書き込みます。
新しいオブジェクトがクラス表に追加されると、TopLinkはプールが空になるまで、プールから値を割り当て続けます。プールが空になると、TopLinkは再び新しい値を表に要求します。
TopLink Workbenchを使用する場合、プロジェクト・レベルまたはセッション・レベルで順序付けのタイプを選択する際に、事前割当てサイズを指定します。事前割当てサイズは、すべてのディスクリプタに適用されます。
Javaを使用すると、作成するそれぞれの順序に別個の事前割当てサイズを指定できます。
事前割当てサイズの構成の詳細は、「プロジェクト・レベルでの順序付けの構成」または「セッション・レベルでの順序付けの構成」を参照してください。
コンテナ管理の永続性を備えたエンティティBeanに対する順序付けを実装するには、表の順序付けやOracleネイティブ順序付けなどの事前割当てを実装する方法を使用します。事前割当てにより、エンティティBeanの主キーはejbPostCreateメソッドで必ず使用できます。Oracle以外のネイティブ順序付けを使用する場合（たとえば、Sybase、Microsoft SQL ServerまたはInformixデータベースのネイティブ順序付け）、次の点に注意してください。
Oracle以外のネイティブ順序付けは、オブジェクトを作成するトランザクションがコミットされるまで、作成されたオブジェクトの主キーを初期化しないため、厳密にはEJB仕様に準拠していません。3.0より前のEJB仕様では、主キーがejbPostCreateメソッドで使用できると想定しています。
IBM WebSphere Application Serverに対するTopLink CMP統合では、Oracleネイティブ順序付け以外のネイティブ順序付けはサポートしません。
OC4JおよびBEA WebLogic Serverでは、ネイティブ順序付けをサポートします。ただし、この種のネイティブ順序付けは、オブジェクトが作成されるトランザクションがコミットされるまで、作成されたオブジェクトの主キーを割り当てたり、返すことをしません。このため、ネイティブ順序付けを使用する場合は、ejbCreateメソッドのコール後すぐにトランザクションをコミットし、TopLinkのキャッシュおよびコンテナにあるオブジェクト・アイデンティティに関する問題を回避するようにします。
IBM WebSphere Application ServerとのTopLink CMP統合
IBM WebSphere Application ServerとのTopLink CMP統合では、ejbCreateメソッドのコール後、主キーは自動指定されません。IBM WebSphere Application Serverにデプロイする場合、明示的に主キーをejbCreateメソッドに設定します。例17-3に、WebSphere統合でのこのコールを示します。
例17-3 IBM WebSphereでの主キーの設定
public Integer ejbCreate() throws CreateException {
oracle.toplink.ejb.cmp.was.SessionLookupHelper.getHelper().getSession(this)
.getActiveUnitofWork().assignSequenceNumber(this);
return null
}
この例では、TopLinkのSessionLookupHelperを使用して、適切なセッションが検索され、そのセッションを使用してBeanに順序番号が割り当てられます。
OC4JおよびBEA WebLogic ServerとのTopLink CMP統合
OC4JおよびBEA WebLogic ServerとのTopLink CMP統合では、TopLinkにより、主キー・フィールドがBeanに自動設定されます。キーの値を、パラメータとしてcreateメソッドに渡すことも、createメソッドに設定することも必要ありません。例17-4に、WebLogic統合でのこのコールを示します。
例17-4 OC4JおよびBEA WebLogicでの主キーの設定
public Integer ejbCreate() throws CreateException {
return null;
}
BEA WebLogic CMPアプリケーションからOC4JおよびTopLink永続性に移行する場合（「BEA WebLogic永続性のOC4J TopLink永続性への移行」を参照）、BEA WebLogicのアプリケーションでもともと単一列の順序表を使用していた場合は、TopLink移行ツールは単一列表の順序付けを使用するようプロジェクトを自動的に構成します（「単一列表の順序付け」を参照）。
http://www.w3.org/TR/REC-xml-names/で定義されているように、XMLネームスペースは名前のコレクションであり、URI参照によって特定され、XML文書内で要素タイプおよび属性名として使用されます。再利用性およびモジュール性を向上させるには、XML文書構成に世界共通の名前が必要です。その世界共通名のスコープは、その名前を含んでいる文書を超えたものです。XMLネームスペースは、これを実現しているメカニズムです。
XMLネームスペースは、XMLスキーマを参照するプロジェクトに適用できます。つまり、XMLレコードを使用するEISプロジェクト（「EISプロジェクト」を参照）およびXMLプロジェクト（「XMLプロジェクト」を参照）です。
この項の内容は次のとおりです。
TopLink Workbenchを使用して、プロジェクトに対するXMLスキーマのネームスペースを構成できます。詳細は、「XMLスキーマ・ネームスペースの構成」を参照してください。
xsd:schema要素は、要素および属性をネームスペースによって修飾する方法の指定に使用できる属性を提供します。
この項では、次の要素および属性形式の組合せの構成結果について説明します。
例17-5は、ターゲット・ネームスペースが設定されるXMLスキーマを示しています。elementFormDefaultをqualifiedに設定し、attributeFormDefaultをunqualifiedに設定してコーディングされています。つまり、すべての要素は修飾されたネームスペースにし、グローバルに宣言された属性は修飾されたネームスペースにして、ローカルに定義された属性は修飾されたネームスペースにしないでください。
例17-5 デフォルト修飾された要素形式およびデフォルト修飾されない属性形式によるXMLスキーマ
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns="urn:namespace-example"
targetNamespace="urn:namespace-example">
<xsd:element name="customer" type="customer-type"/>
<xsd:complexType name="customer-type">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element ref="date-of-birth"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:integer"/>
</xsd:complexType>
<xsd:element name="date-of-birth" type="xsd:date"/>
</xsd:schema>
例17-6は、このXMLスキーマに一致するXML文書を示しています。
例17-6 XML文書
<?xml version="1.0" encoding="UTF-8"?> <ns:customer xmlns:ns="urn:namespace-example" id="1"> <ns:name>Jane Doe</ns:name> <ns:date-of-birth>1975-02-21</ns:date-of-birth> </ns:customer>
例17-7は、このスキーマ構成が、デフォルト・ルート要素およびマッピングに対して指定するXPathにどのような影響を与えるかを示すために、CustomerクラスXMLDescriptorのJavaコードおよびその属性に対するXMLマッピングを示しています（詳細は、「XMLディスクリプタの構成」および第63章「XMLマッピングの構成」を参照）。
例17-7 XMLディスクリプタおよびマッピング
NamespaceResolver namespaceResolver = new NamespaceResolver();
namespaceResolver.put("ns", "urn:namespace-example");
XMLDescriptor customerDescriptor = new XMLDescriptor();
customerDescriptor.setJavaClass(Customer.class);
customerDescriptor.setDefaultRootElement("ns:customer");
customerDescriptor.setNamespaceResolver(namespaceResolver);
XMLDirectMapping idMapping = new XMLDirectMapping();
idMapping.setAttributeName("id");
idMapping.setXPath("@id");
customerDescriptor.addMapping(idMapping);
XMLDirectMapping nameMapping = new XMLDirectMapping();
nameMapping.setAttributeName("name");
nameMapping.setXPath("ns:name/text()");
customerDescriptor.addMapping(nameMapping);
XMLDirectMapping birthDateMapping = new XMLDirectMapping();
birthDateMapping.setAttributeName("birthDate");
birthDateMapping.setXPath("ns:date-of-birth/text()");
customerDescriptor.addMapping(birthDateMapping);
例17-8は、ターゲット・ネームスペースが設定されるXMLスキーマを示しています。elementFormDefaultおよびattributeFormDefaultをunqualifiedに設定してコーディングされています。つまり、グローバルに定義されたノードは修飾されたネームスペースにし、ローカルに定義されたノードは修飾されたネームスペースにしないでください。
例17-8 デフォルト修飾されない要素および属性形式によるXMLスキーマ
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified"
attributeFormDefault="unqualified"
xmlns="urn:namespace-example"
targetNamespace="urn:namespace-example">
<xsd:element name="customer" type="customer-type"/>
<xsd:complexType name="customer-type">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element ref="date-of-birth"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:integer"/>
</xsd:complexType>
<xsd:element name="date-of-birth" type="xsd:date"/>
</xsd:schema>
例17-9は、このXMLスキーマに一致するXML文書を示しています。
例17-9 XML文書
<?xml version="1.0" encoding="UTF-8"?> <ns:customer xmlns:ns="urn:namespace-example" id="1"> <name>Jane Doe</name> <ns:date-of-birth>1975-02-21</ns:date-of-birth> </ns:customer>
例17-10は、このスキーマ構成が、デフォルト・ルート要素およびマッピングに対して指定するXPathにどのような影響を与えるかを示すために、CustomerクラスXMLDescriptorのJavaコードおよびその属性に対するXMLマッピングを示しています（詳細は、「XMLディスクリプタの構成」および第63章「XMLマッピングの構成」を参照）。
例17-10 XMLディスクリプタおよびマッピング
NamespaceResolver namespaceResolver = new NamespaceResolver();
namespaceResolver.put("ns", "urn:namespace-example");
XMLDescriptor customerDescriptor = new XMLDescriptor();
customerDescriptor.setJavaClass(Customer.class);
customerDescriptor.setDefaultRootElement("ns:customer");
customerDescriptor.setNamespaceResolver(namespaceResolver);
XMLDirectMapping idMapping = new XMLDirectMapping();
idMapping.setAttributeName("id");
idMapping.setXPath("@id");
customerDescriptor.addMapping(idMapping);
XMLDirectMapping nameMapping = new XMLDirectMapping();
nameMapping.setAttributeName("name");
nameMapping.setXPath("name/text()");
customerDescriptor.addMapping(nameMapping);
XMLDirectMapping birthDateMapping = new XMLDirectMapping();
birthDateMapping.setAttributeName("birthDate");
birthDateMapping.setXPath("ns:date-of-birth/text()");
customerDescriptor.addMapping(birthDateMapping);
例17-11は、ターゲット・ネームスペースが設定されるXMLスキーマを示しています。elementFormDefaultおよびattributeFormDefaultをqualifiedに設定してコーディングされています。つまり、すべてのノードが修飾されたネームスペースである必要があります。
例17-11 デフォルト修飾された要素および属性形式によるXMLスキーマ
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="qualified"
xmlns="urn:namespace-example"
targetNamespace="urn:namespace-example">
<xsd:element name="customer" type="customer-type"/>
<xsd:complexType name="customer-type">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element ref="date-of-birth"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:integer"/>
</xsd:complexType>
<xsd:element name="date-of-birth" type="xsd:date"/>
</xsd:schema>
例17-12は、このXMLスキーマに一致するXML文書を示しています。
例17-12 XML文書
<?xml version="1.0" encoding="UTF-8"?> <ns:customer xmlns:ns="urn:namespace-example"ns:id="1"> <ns:name>Jane Doe</ns:name> <ns:date-of-birth>1975-02-21</ns:date-of-birth> </ns:customer>
例17-13は、このスキーマ構成が、デフォルト・ルート要素およびマッピングに対して指定するXPathにどのような影響を与えるかを示すために、CustomerクラスXMLDescriptorのJavaコードおよびその属性に対するXMLマッピングを示しています（詳細は、「XMLディスクリプタの構成」および第63章「XMLマッピングの構成」を参照）。
例17-13 XMLディスクリプタおよびマッピング
NamespaceResolver namespaceResolver = new NamespaceResolver();
namespaceResolver.put("ns", "urn:namespace-example");
XMLDescriptor customerDescriptor = new XMLDescriptor();
customerDescriptor.setJavaClass(Customer.class);
customerDescriptor.setDefaultRootElement("ns:customer");
customerDescriptor.setNamespaceResolver(namespaceResolver);
XMLDirectMapping idMapping = new XMLDirectMapping();
idMapping.setAttributeName("id");
idMapping.setXPath("@ns:id");
customerDescriptor.addMapping(idMapping);
XMLDirectMapping nameMapping = new XMLDirectMapping();
nameMapping.setAttributeName("name");
nameMapping.setXPath("ns:name/text()");
customerDescriptor.addMapping(nameMapping);
XMLDirectMapping birthDateMapping = new XMLDirectMapping();
birthDateMapping.setAttributeName("birthDate");
birthDateMapping.setXPath("ns:date-of-birth/text()");
customerDescriptor.addMapping(birthDateMapping);
一般的に、XML文書では1つ以上のネームスペースを含めます。TopLinkは、そのNamespaceResolverを使用してこれをサポートします。ネームスペース・リゾルバは、対になったネームスペースの接頭辞とUniform Resource Identifier（URI）を保持します。TopLinkは、XMLレコードへのEISマッピングおよびXMLマッピングで指定するXPath文とともに、これらの接頭辞を使用します。
TopLinkは（該当する場合に）マッピングのためXPath文でネームスペースの接頭辞を取得しますが、同じネームスペースの接頭辞の使用に入力ドキュメントは必要ありません。図17-6で示すように、新規ドキュメントの作成の際、TopLinkはマッピングで指定されたネームスペースの接頭辞を使用します。
