ヘッダーをスキップ
Oracle Fusion Middleware Oracle TopLink開発者ガイド
11gリリース1（11.1.1）
B56246-01
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

15 プロジェクトの概要

TopLinkプロジェクトは、マッピング・メタデータとデータ・ソース・アクセス情報（関連する場合）の両方をカプセル化します。プロジェクトは、TopLinkが実行時に使用するプライマリ・オブジェクトです。デプロイされたアプリケーションの各セッション（セッション・ブローカを除く）は、1つのプロジェクトを参照します。

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

15.1 TopLinkプロジェクト・タイプ

表15-1は、TopLinkで利用できるプロジェクト・タイプを示します。それぞれが基本または詳細タイプに分類され、それぞれの作成方法を示します。

表15-1 TopLinkプロジェクト・タイプ

プロジェクト・タイプ 説明 Oracle JDeveloper
 TopLink Workbench Java

リレーショナル（第18章「リレーショナル・プロジェクトの概要」を参照）

Java Database Connectivity（JDBC）を使用してアクセスするリレーショナル・データベースまたはオブジェクト・リレーショナル・データ・タイプ・データベースに対するJavaオブジェクトのトランザクション永続性を可能にするプロジェクト。TopLinkの問合せおよび式をサポートします。

 サポートされている
 サポートされている
 サポートされている

EIS（第71章「EISプロジェクトの概要」を参照）

Java EE Connector Architecture（JCA）アダプタおよびサポートされるあらゆるEISレコード（索引付き、マップ済またはXMLを含む）タイプを使用してアクセスされる非リレーショナル・データ・ソースに対するJavaオブジェクトのトランザクション永続性を可能にするプロジェクト。TopLinkの問合せおよび式をサポートします。

 サポートされている
 サポートされている
 サポートされている

XML（第47章「XMLプロジェクトの概要」を参照）

Java Architecture for XML Binding（JAXB）を使用して、JavaオブジェクトとXMLスキーマ（XSD）ベースの文書間で、非トランザクション型の、永続化を行わない（インメモリー）変換を行うために使用するプロジェクト。TopLinkの問合せおよび式をサポートしません。

 サポートされている
 サポートされている
 サポートされている

詳細は、次を参照してください。

15.2 プロジェクトの概念

この項では、次の内容を含む、TopLinkプロジェクトに固有の概念について説明します。

15.2.1 プロジェクト・アーキテクチャ

選択するプロジェクト・タイプにより、使用できるディスクリプタおよびマッピングのタイプが決まります。TopLinkがサポートするデータ・ソース・タイプごとに、対応するプロジェクト・タイプがあります。

表15-2は、プロジェクト、ディスクリプタ、マッピングの関係をまとめたものです。

表15-2 プロジェクト、ディスクリプタおよびマッピングのサポート

プロジェクト ディスクリプタ マッピング

リレーショナル（第18章「リレーショナル・プロジェクトの概要」を参照）

次を決定します。

次を決定します。

EIS（第71章「EISプロジェクトの概要」を参照）

EIS（74.1項「EISディスクリプタの概念」を参照）

EIS（17.7項「EISマッピング」を参照）

XML（第47章「XMLプロジェクトの概要」を参照）

XML（50.1項「XMLディスクリプタの概念」を参照）

XML（17.6項「XMLマッピング」を参照）

15.2.2 リレーショナルおよび非リレーショナル・プロジェクト

TopLinkは、リレーショナル・プロジェクトと非リレーショナル・プロジェクトを両方ともサポートします。

リレーショナル・プロジェクトは、Javaオブジェクトをリレーショナル・データベースに永続化します。

非リレーショナル・プロジェクトは、別の（非リレーショナル）タイプのデータ・ソースにJavaオブジェクトを永続化するか、または非永続データへの変換を行います（15.2.3項「永続および非永続プロジェクト」を参照）。たとえば、JCAアダプタを使用してEISデータ・ソースにJavaオブジェクトを永続化するには、EISプロジェクトを使用します。JavaオブジェクトとXML要素間の非永続（インメモリー）変換を実行するには、XMLプロジェクトを使用します。

15.2.3 永続および非永続プロジェクト

TopLinkでは、Javaオブジェクトの永続性ストレージを必要とするアプリケーションに使用できるプロジェクトがサポートされています。たとえば、リレーショナル・データベースにJavaオブジェクトを永続化するために使用できるリレーショナル・プロジェクトや、JCAアダプタを介してEISデータ・ソースにJavaオブジェクトを永続化するために使用できるEISプロジェクトがあります。

TopLinkでは、非永続（インメモリー）データへの変換のみを必要とするアプリケーション用に使用できるプロジェクトもサポートされています。たとえば、JavaオブジェクトとXML要素間の非永続（インメモリー）変換の実行に使用できるXMLプロジェクトがあります。

15.2.4 プロジェクトおよびログイン

プロジェクトに関連付けられたログイン（存在する場合）により、TopLinkランタイムがプロジェクトのデータ・ソースに接続する方法が決まります。

ログインには、認証、接続プールの使用、および外部トランザクション・コントローラの使用などのデータ・ソース・アクセスの詳細が含まれます。ログインにはプラットフォーム情報が含まれます。

プラットフォームには、バインディング、ネイティブSQLの使用、バッチ書込みの使用、順序付けなどの、特定のデータ・ソースに固有のオプションが含まれます。プラットフォームの詳細は、15.2.5項「プロジェクトおよびプラットフォーム」を参照してください。

データ・ソースに永続化しないプロジェクトの場合、ログインは必要ありません。データ・ソースに永続化するプロジェクトの場合、ログインは常に必要です。

TopLink Workbenchでは、プロジェクト・タイプに応じて、プロジェクトで使用されるログインのタイプが決まります。

ログインは様々なロールで使用できます。ログインのロールにより、ログインを作成する場所と方法が決まります。選択するログインのロールは、作成対象のプロジェクトのタイプやログインの使用目的によって異なります。

15.2.4.1 POJOセッション・ロール

コンテナ管理の永続性（CMP）を使用しないTopLinkアプリケーションに対して、sessions.xmlファイルにセッション・ログインを作成します。

通常、sessions.xmlファイルからセッションをロードすると、TopLinkランタイムにより、プロジェクトがインスタンス化されます（第90章「実行時のセッションの取得と使用」を参照）。sessions.xmlファイル内の情報に基づいて、ログインとそのプラットフォームもインスタンス化されます。

TopLinkランタイムでは、POJO TopLinkアプリケーションのセッションを使用して永続性操作を実行する場合は常にセッション・ログインの情報が使用されます。

この場合、デプロイ・ログインは構成しません（15.2.4.2項「CMPデプロイ・ロール」を参照）。

TopLink Workbenchを使用していて、ログインがリレーショナル・データベース・プラットフォームをベースにしている場合は、デプロイ・ログインも構成する必要があります（15.2.4.3項「開発ロール」を参照）。

sessions.xmlファイルにログインが含まれる場合は、その他のログイン定義はこのログインでオーバーライドされます。

データ・ソースに永続化するプロジェクト・タイプごとに、独立したセッション・ログイン・タイプがあります。利用可能なログイン・タイプの完全な一覧については、96.1.2項「データ・ソース・ログインのタイプ」を参照してください。

セッション・ログインの構成の詳細は、89.3項「セッション・ログインの構成」を参照してください。

15.2.4.2 CMPデプロイ・ロール

TopLink対応のCMPアプリケーションに対して、project.xmlファイル（toplink-ejb-jar.xmlファイルとも呼ばれる）にデプロイ・ログインを作成します。

TopLink対応のCMPアプリケーションをそのtoplink-ejb-jar.xmlファイルとともにデプロイする場合、ビジネス・ロジックがコンテナ管理の永続性を備えたエンティティBean内から永続化の操作を実行する際には常に、アプリケーション・サーバーまたはEJBコンテナはデプロイ・ログイン内の情報を使用します。

この場合、セッション・ログインは構成しません（15.2.4.1項「POJOセッション・ロール」を参照）。実際のところ、session.xmlファイルというものは存在しません（9.1.2.4項「CMPアプリケーションおよびセッション・メタデータ」を参照）。

TopLink Workbenchを使用していて、ログインがリレーショナル・データベース・プラットフォームをベースにしている場合は、デプロイ・ログインも構成する必要があります（15.2.4.3項「開発ロール」を参照）。

デプロイ・ログインの作成の詳細は、20.5項「開発ログインおよびデプロイ・ログインの構成」を参照してください。

15.2.4.3 開発ロール

TopLink Workbenchを使用していて、プロジェクトがリレーショナル・データベース・プラットフォームをベースにしている場合、TopLink Workbenchプロジェクト・ファイルに開発ログインを作成します。

TopLink Workbench内からデータ・ソースへの操作を実行するとき（たとえば、アプリケーション開発中にスキーマ情報をデータ・ストアから読み取ったりデータ・ストアに書き込むとき）には、TopLink Workbenchでは必ず開発ログインの情報が使用されます。開発ログインの情報がsessions.xmlまたはproject.xmlファイルに書き込まれることはありません。

開発ログインは、アプリケーションをデプロイするときに使用されることはありません。sessions.xmlファイル（15.2.4.1項「POJOセッション・ロール」を参照）またはproject.xmlファイル（15.2.4.2項「CMPデプロイ・ロール」を参照）によってオーバーライドされます。

開発ログインの作成の詳細は、20.5項「開発ログインおよびデプロイ・ログインの構成」を参照してください。

15.2.5 プロジェクトおよびプラットフォーム

プロジェクトに関連付けられたプラットフォーム（存在する場合）は、プロジェクトが使用する特定のデータ・ソース・タイプをTopLinkランタイムに通知します。

プラットフォームには、バインディング、ネイティブSQLの使用、バッチ書込みの使用、順序付けなどの、特定のデータ・ソースに固有のオプションが含まれます。

ログインには、認証、接続プールの使用、および外部トランザクション・コントローラの使用などのデータ・ソース・アクセスの詳細が含まれます。ログインにはプラットフォーム情報が含まれます。ログインの詳細は、15.2.4項「プロジェクトおよびログイン」を参照してください。

データ・ソースに永続化しないプロジェクトの場合、プラットフォームは必要ありません。データ・ソースに永続化するプロジェクトの場合、プラットフォームは常に必要です。

TopLink Workbenchでは、プロジェクト・タイプに応じて、プロジェクトで使用されるプラットフォームのタイプが決まります。

データ・ソースに永続化するプロジェクト・タイプごとに、独立したプラットフォーム・タイプがあります。利用可能なプラットフォーム・タイプの完全な一覧については、96.1.3項「データ・ソース・プラットフォームのタイプ」を参照してください。

15.2.6 プロジェクトおよび順序付け

オブジェクト・アイデンティティ（102.2.1項「キャッシュ・タイプおよびオブジェクト・アイデンティティ」を参照）を保持する上で重要なのは、順序付けです。つまり、インスタンスを区別するために一意の値の割当てを管理することです。

プロジェクトには、そのプロジェクトのタイプに応じて異なる順序付けの要件があります。

  • リレーショナル・プロジェクトの場合、通常、オブジェクト識別子の値を管理する専用の独立した順序表（またはデータベース・オブジェクト）からオブジェクト識別子の値を取得します（18.2項「リレーショナル・プロジェクトにおける順序付け」を参照）。

  • EISプロジェクトの場合、通常、EISデータ・ソースによって管理されるオブジェクト識別子の値を取得するために、リターン・ポリシー（119.27項「リターン・ポリシーの構成」を参照）を使用します。

  • XMLプロジェクトの場合、単にオブジェクトとXML文書間のトランスフォーメーションを実行しているにすぎないので、順序付けは問題になりません。

順序付けを構成するには、次のものを構成する必要があります。

使用する順序付けのタイプおよびアプリケーションのアーキテクチャに応じて、シーケンス接続プールの使用を検討できます。詳細は、96.1.6.4項「シーケンス接続プール」を参照してください。

15.2.6.1 順序値の取得方法の構成

TopLinkの順序値取得方法を決定するには、作成しているプロジェクトのタイプに応じて、プロジェクト・レベルまたはセッション・レベルでTopLink順序付けを次のように構成します。

  • CMPプロジェクトの場合、セッションは直接構成しません。この場合、順序をプロジェクト・レベルで構成する必要があります（20.3項「プロジェクト・レベルでの順序付けの構成」を参照）。

  • POJOプロジェクトの場合、セッションは直接構成できます。この場合、セッション・レベル順序構成を使用するのは、プロジェクト・レベルの順序構成のかわりとするためでも、またはプロジェクト・レベルの順序構成をセッション単位でオーバーライドするためでもかまいません（98.4項「セッション・レベルでの順序付けの構成」を参照）。

15.2.6.2 順序値の書込み場所の構成

ディスクリプタの参照クラスのインスタンスが作成される際に順序値を書き込む表および列をTopLinkに指示するには、TopLinkの順序付けをディスクリプタ・レベルで構成します（23.3項「ディスクリプタ・レベルでの順序付けの構成」を参照）。

15.2.7 XMLネームスペース

http://www.w3.org/TR/REC-xml-names/で定義されているように、XMLネームスペースは名前のコレクションであり、URI参照によって特定され、XML文書内で要素タイプおよび属性名として使用されます。再利用性およびモジュール性を向上させるには、XML文書構成に世界共通の名前が必要です。その世界共通名のスコープは、その名前を含んでいる文書を超えたものです。XMLネームスペースは、これを実現しているメカニズムです。

XMLネームスペースは、XMLスキーマを参照するプロジェクト、つまり、XMLレコードを使用するEISプロジェクト（72.2項「XMLレコードを使用するEISプロジェクトの作成」を参照）およびXMLプロジェクト（47.1項「XMLプロジェクトの概念」を参照）に適用できます。

詳細は、15.4項「XMLネームスペースの概要」を参照してください。

15.3 プロジェクトAPI

この項の内容は次のとおりです。

15.3.1 プロジェクトの継承階層

プロジェクトのタイプはoracle.toplink.sessions.Projectの1つのみ存在します。

15.4 XMLネームスペースの概要

http://www.w3.org/TR/REC-xml-names/で定義されているように、XMLネームスペースは名前のコレクションであり、URI参照によって特定され、XML文書内で要素タイプおよび属性名として使用されます。再利用性およびモジュール性を向上させるには、XML文書構成に世界共通の名前が必要です。その世界共通名のスコープは、その名前を含んでいる文書を超えたものです。XMLネームスペースは、これを実現しているメカニズムです。

XMLネームスペースは、XMLスキーマを参照するプロジェクト、つまり、XMLレコードを使用するEISプロジェクト（72.2項「XMLレコードを使用するEISプロジェクトの作成」を参照）およびXMLプロジェクト（47.1項「XMLプロジェクトの概念」を参照）に適用できます。

Oracle JDeveloperまたはTopLink Workbenchを使用して、プロジェクトのXMLスキーマ・ネームスペースを構成できます。

この項の内容は次のとおりです。

15.4.1 TopLink Workbenchのネームスペース解決

TopLink Workbenchを使用して、プロジェクトに対するXMLスキーマのネームスペースを構成できます。詳細は、5.6.5項「XMLスキーマ・ネームスペースの構成方法」を参照してください。

15.4.2 要素および属性形式オプション

xsd:schema要素は、要素および属性をネームスペースによって修飾する方法の指定に使用できる属性を提供します。

この項では、次の要素および属性形式の組合せの構成結果について説明します。

15.4.2.1 デフォルト修飾された要素形式およびデフォルト修飾されない属性形式

例15-1は、ターゲット・ネームスペースが設定されるXMLスキーマを示しています。elementFormDefaultをqualifiedに設定し、attributeFormDefaultをunqualifiedに設定してコーディングされています。つまり、すべての要素は修飾されたネームスペースにし、グローバルに宣言された属性は修飾されたネームスペースにして、ローカルに定義された属性は修飾されたネームスペースにしないでください。

例15-1 デフォルト修飾された要素形式およびデフォルト修飾されない属性形式による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>

例15-2は、このXMLスキーマに一致するXML文書を示しています。

例15-2 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>

例15-3は、このスキーマ構成が、デフォルト・ルート要素およびマッピングに対して指定するXPathにどのような影響を与えるかを示すために、CustomerクラスXMLDescriptorのJavaコードおよびその属性に対するXMLマッピングを示します（詳細は、第52章「XMLディスクリプタの構成」および第54章「XMLマッピングの構成」を参照）。

例15-3 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);

15.4.2.2 デフォルト修飾されない要素および属性形式

例15-4は、ターゲット・ネームスペースが設定されるXMLスキーマを示しています。elementFormDefaultおよびattributeFormDefaultをunqualifiedに設定してコーディングされています。つまり、グローバルに定義されたノードは修飾されたネームスペースにし、ローカルに定義されたノードは修飾されたネームスペースにしないでください。

例15-4 デフォルト修飾されない要素および属性形式による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>

例15-5は、このXMLスキーマに一致するXML文書を示しています。

例15-5 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>

例15-6は、このスキーマ構成が、デフォルト・ルート要素およびマッピングに対して指定するXPathにどのような影響を与えるかを示すために、CustomerクラスXMLDescriptorのJavaコードおよびその属性に対するXMLマッピングを示します（詳細は、第52章「XMLディスクリプタの構成」および第54章「XMLマッピングの構成」を参照）。

例15-6 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);

15.4.2.3 デフォルト修飾された要素および属性形式

例15-7は、ターゲット・ネームスペースが設定されるXMLスキーマを示しています。elementFormDefaultおよびattributeFormDefaultをqualifiedに設定してコーディングされています。つまり、すべてのノードが修飾されたネームスペースである必要があります。

例15-7 デフォルト修飾された要素および属性形式による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>

例15-8は、このXMLスキーマに一致するXML文書を示しています。

例15-8 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>

例15-9は、このスキーマ構成が、デフォルト・ルート要素およびマッピングに対して指定するXPathにどのような影響を与えるかを示すために、CustomerクラスXMLDescriptorのJavaコードおよびその属性に対するXMLマッピングを示します（詳細は、第52章「XMLディスクリプタの構成」および第54章「XMLマッピングの構成」を参照）。

例15-9 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);

15.4.3 TopLinkランタイムのネームスペース解決

一般的に、XML文書では1つ以上のネームスペースを含めます。TopLinkは、そのNamespaceResolverを使用してこれをサポートします。ネームスペース・リゾルバは、対になったネームスペースの接頭辞とUniform Resource Identifier（URI）を保持します。TopLinkは、XMLレコードへのEISマッピングおよびXMLマッピングで指定するXPath文とともに、これらの接頭辞を使用します。

TopLinkは（該当する場合に）マッピングのためXPath文でネームスペースの接頭辞を取得しますが、同じネームスペースの接頭辞の使用に入力ドキュメントは必要ありません。例15-9で示すように、新規ドキュメントの作成の際、TopLinkはマッピングで指定されたネームスペースの接頭辞を使用します。

図15-1 TopLinkにおけるネームスペース

図15-1の説明が続きます
「図15-1 TopLinkにおけるネームスペース」の説明

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引