Cloud Software Group, Inc. EBX®

ドキュメント>開発者ガイド>はじめに

ナビゲーションモードドキュメント>開発者ガイド>はじめに

Java へのマッピング

Java からデータにアクセスする方法
トランザクションと並行処理
データ型のマッピング
- 単純なデータ型
- 複合データ型
Java バインディング
- 利点
- XML 宣言

Java からデータにアクセスする方法

読み取りアクセス

データは、主に Adaptation と ValueContext などのさまざまな汎用 Java クラスから読み取ることができます。これらのクラスの getter メソッドは、セクションデータ型のマッピングで説明されているマッピングルールに従って型指定されたオブジェクトを返します。

書き込みアクセス

データの更新は、適切に管理されたコンテキストで実行する必要があります。

プロシージャ実行のコンテキストでは、インターフェイス ValueContextForUpdate のメソッド setValue... を呼び出すか、または
ユーザー入力の検証中に、クラス ValueContextForInputValidation のメソッド setNewValue を呼び出します。

可変オブジェクトの変更

データ型のマッピングセクションで説明されているマッピングによると、アクセスされる Java オブジェクトの一部は可変オブジェクトです。これらは、リスト、日付または任意の JavaBean のインスタンスです。したがって、これらのオブジェクトは、独自のメソッドによってローカルに変更できます。ただし、上記の setter のいずれかが呼び出され、現在のトランザクションが正常にコミットされない限り、このような変更は返されたオブジェクトに対してローカルのままになります。

トランザクションと並行処理

並行処理

データスペースレベル

1 つのデータスペースでは、1 つの読み書き可能な Procedure と、複数の同時実行可能な ReadOnlyProcedure の実行をサポートしています。任意の Procedure 以外の同時アクセスもサポートしています。

リポジトリレベル

リポジトリレベルでは、同時実行性は特定の操作に対してのみ制限されます。例（網羅的ではないリスト）：

データモデルの公開では、多くの操作が除外されています。
データスペースのマージでは、マージに関係する 2 つのデータスペースに対する書き込み操作は除外されます。

クエリスナップショット分離

次の表は、クエリの分離に関連するプロパティを定義しています。クエリ結果は、QueryResult または RequestResult のいずれかの Java API によって表されることに注意してください。

Procedure 以外のクエリ

クエリ結果のフェッチ時にデータがフリーズされます。より正確には、クエリ結果は、この結果をフェッチする時点で最後にコミットされたトランザクションの時点でコミットされたデータのみにアクセスします。この結果の内容は、後で変更されることはありません。

Procedure 外部のクエリは、自己完結型の ReadOnlyProcedure と見なすことができます。

Procedure の基になるデータスペースと同じデータスペース内の Procedure 内のクエリ

クエリ結果は、プロシージャが開始される前に最後にコミットされた状態と、クエリ結果のフェッチ前にプロシージャで発生した変更を反映します。プロシージャで何が起こっても、それ以降に、この結果の内容が変更されることはありません。

別のデータスペースの Procedure 内のクエリ

一貫性はリポジトリレベルで保証されるため、クエリ結果はプロシージャが開始される前に最後にコミットされた状態を反映します。この結果の内容は、リポジトリ全体で何が起こっても、クエリがフェッチされた後に変更されることはありません。

適応オブジェクト

Java では、永続データセットまたは永続レコードは両方とも Adaptation クラスのインスタンスによって表されます。

次の表は、Adaptation オブジェクトに関連するプロパティを定義しています。

不変性

Adaptation オブジェクトインスタンスは不変です。

したがって、クライアントコードは、Adaptation オブジェクトを長期間 (特にトランザクションの境界を超えて) 「保持」しないでください。ただし、メソッド Adaptation.getUpToDateInstance を呼び出すことは可能です。

フェッチ

Adaptation が QueryResult からフェッチされる場合、前のセクションで説明したスナップショット分離ルールが適用されます。それ以外の場合、実行中の Procedure から Adaptation がフェッチされると、Procedure が開始する前に最後にコミットされた状態が反映されます。それ以外の場合、QueryResult または実行中の Procedure の外部では、Adaptation はレコードの状態をフェッチ時に反映します。

以下も参照してください。

データ型のマッピング

このセクションでは、XML スキーマの型定義とエレメント宣言を Java 型にマッピングする方法について説明します。

単純なデータ型

単純なデータ型の基本ルール

各 XML スキーマの単純型は Java クラスに対応します。マッピングは、XML スキーマに組み込まれた単純型の表に記載されています。

以下も参照してください。

SchemaNode.createNewOccurrence

単純なエレメントの複数のカーディナリティ</g1>

属性 maxOccurs が 1 より大きい場合、エレメントは集約リストであり、Java の対応するインスタンスは java.util.List のインスタンスです。

リストのエレメントは、単純型のマッピングから決定されるJavaクラスのインスタンスです (前のセクションを参照)。

複合データ型

クラス宣言のない複雑な型の定義

デフォルトでは (属性 osd:class なし)、複合型のターミナルノードは内部クラスを使用してインスタンス化されます。このクラスは、汎用の JavaBean 実装を提供します。ただし、カスタムクライアント Java コードがこれらの値にアクセスする必要がある場合は、カスタム JavaBean を使用してください。これを行うには、次のセクションで説明する osd:class 宣言を使用します。

メソッド SchemeNode.createNewOccurrence、SchemaNode.executeRead、および SchemaNode.executeWrite を呼び出すことにより、属性 osd:class の有無にかかわらず、マップされた Java オブジェクトを透過的にインスタンス化、読み取り、変更できます。

複合型のカスタム JavaBeans へのマッピング

XML スキーマ複合型をカスタムJavaクラスにマップできます。これは、属性 osd:class を複合ノード定義に追加することによって行われます。エレメントに xs:maxOccurs> 1 がない限り、ノードをターミナルノードと見なすには属性 osd:access も指定する必要があります。エレメントが xs:maxOccurs> 1 の場合、自動的にターミナルと見なされます。

カスタム Java クラスは、JavaBean プロトコルに準拠している必要があります。これは、複合型の各子がクラスの JavaBean プロパティに対応している必要があることを意味します。さらに、各 JavaBean プロパティは読み取り/書き込みプロパティである必要があり、その実装では、setter メソッドによって設定された値が getter メソッドによってそのまま返されるようにする必要があります。これらのメソッドでは、コンテキスト計算は許可されていません。

例

この例では、Java クラス com.carRental.Customer は、メソッド getFirstName() および setFirstName(String) を定義する必要があります。

JavaBean は、UIBeanEditor を使用して、TIBCO EBX® 内にカスタムユーザーインターフェイスを持つことができます。

<xs:element name="customer" osd:access="RW">
  <xs:complexType name="subscriber" osd:class="com.carRental.Customer">
	<xs:sequence>
	  <xs:element name="firstName" type="xs:string"/>
	  ...
	</xs:sequence>
  </xs:complexType>
</xs:element>

複雑なエレメントの複数のカーディナリティ

属性 maxOccurs が 1 より大きい場合、Java の対応するインスタンスは次のとおりです。

集約リストの java.util.List のインスタンス。リスト内のすべてのエレメントは、単純型のマッピングによって決定される Java クラスのインスタンスです。
プロパティ osd:table が指定されている場合、AdaptationTable のインスタンス。

Java バインディング

Java バインディングは、データモデルの構造を反映するJavaタイプの生成をサポートします。 Java コードの生成は、ユーザーインターフェイスで実行できます。 Java バインディングの生成を参照してください。

利点

XML スキーマ構造と Java コードの間のリンクを確保することには、いくつかの利点があります。

開発支援： IDE でサポートされている場合、パラメーターへのアクセスパスを入力するとオートコンプリートされます。
アクセスコードの検証：パラメーターへのすべてのアクセスは、コードのコンパイル時に検証されます。
影響の検証：データモデルを変更するたびに、コードのコンパイル状態に影響があります。
相互参照： IDEの参照ツールを使用すると、パラメーターが使用されている場所を簡単に確認できます。

したがって、Java バインディングを使用することを強くお勧めします。

XML 宣言

データモデルから生成される Java タイプの仕様は、メインスキーマに含まれています。

各バインディングエレメントは、生成ターゲットを定義します。 XPath 表記では、xs:schema/xs:annotation/xs:appinfo/ebxbnd:binding に配置する必要があります。ここで、プレフィックス ebxbnd は名前空間への参照です。 URI urn:ebx-schemas:binding_1.0 で識別されます。世代ターゲットが異なる場合は、いくつかのバインディングエレメントを定義できます。

エレメント ebxbnd：binding の属性 targetDirectory は、Java タイプの生成に使用されるルートディレクトリを定義します。通常、これはプロジェクトのソースコード src を含むディレクトリです。相対パスは、XML スキーマではなく、VM の現在のランタイムディレクトリに基づいて解釈されます。

バインディング XML スキーマを参照してください。

XML バインディングの例

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:ebxbnd="urn:ebx-schemas:binding_1.0">
	<xs:annotation>
		<xs:appinfo>
			<!-- The bindings define how this schema will be represented in Java.
			Several <binding> elements may be defined, one for each target. -->
			<ebxbnd:binding
				targetDirectory="../_ebx-demos/src-creditOnLineStruts-1.0/">
				<javaPathConstants typeName="com.creditonline.RulesPaths">
					<nodes root="/rules" prefix="" />
				</javaPathConstants>
				<javaPathConstants typeName="com.creditonline.StylesheetConstants">
					<nodes root="/stylesheet" prefix="" />
				</javaPathConstants>
			</ebxbnd:binding>
		</xs:appinfo>
	</xs:annotation>
	...
</xs:schema>

Java 定数は、XML スキーマパスに対して定義できます。これを行うには、ルートノード/ を含むスキーマノードから1つ以上のインターフェイスを生成します。この例では、2つの Java パス定数インターフェイスを生成します。1 つはノード /rules から、もう 1 つはスキーマのノード /stylesheet から生成します。インターフェイス名は、属性 typeName を持つエレメント javaPathConstants によって記述されます。関連するノードは、属性 root を持つエレメント nodes によって記述されます。

ドキュメント>開発者ガイド>はじめに