前へ     目次     索引     DocHome     次へ     
iPlanet Trustbase Transaction Manager 2.2.1 開発者ガイド



第 2 章   プレゼンテーションロジック


iPlanet Trustbase Transaction Manager システムは、メッセージを受信すると、そのメッセージを適切なサービスに配信します。配信先のサービスが直接そのメッセージを処理できない場合は、iPlanet Trustbase Transaction Manager が接続マネージャコンポーネントを使用してメッセージを適切に処理します。



概要


iPlanet Trustbase Transaction Manager のプレゼンテーションコンポーネントは、一連のプロトコルハンドラ、メッセージリーダ、およびメッセージライタから構成されています。プロトコルハンドラは、トランスポート固有のヘッダおよびフッタの抽出、MIME タイプおよびメッセージタイプの判別、およびメッセージ内容の適切なメッセージハンドラへの転送を行います。

メッセージハンドラは、プロトコルハンドラが判別した MIME タイプおよびメッセージタイプに基づいて選択されます。iPlanet Trustbase Transaction Manager には、次の種類のメッセージをそれぞれ処理する 2 つのデフォルトのメッセージハンドラがあります。

  • Identrus XML メッセージ

  • HTML メッセージ

Identrus XML メッセージの場合は、適切な Identrus ネットワーク処理が実行されます (詳細はこの章で後述)。

図 2-1    プレゼンテーション層コンポーネント

  

HTML メッセージの場合は、メッセージリーダが HTML フォームのすべてのフィールドを XML 構造に変換します。この XML 構造は、一連の DOM ノードによって表されます。

XML または HTML のどちらの場合でも、ルータへの出力はセッション情報によって iPlanet Trustbase Transaction Manager メッセージにラップされます。その後、iPlanet Trustbase Transaction Manager メッセージは、ルータによって適切なサービスに送信されます。

サービスは、iPlanet Trustbase Transaction Manager メッセージを適切に変換または構築し、ルータに返します。ルータは、その iPlanet Trustbase Transaction Manager メッセージを適切なメッセージライタに送信します。HTML メッセージライタの場合は、このメッセージの DOM 値がメッセージタイプに基づく HTML テンプレートに抽出されます。テンプレートには、フォームデータの条件付き構築または再帰的構築のための一連の指示が含まれていることもあります。



プロトコルハンドラ


プラットフォームがメッセージを受信すると、受信メッセージの MIME タイプに基づいてプロトコルハンドラが選択されます。このコンポーネントは、次のアプリケーションプロトコル情報を判別します。

  • メッセージタイプ

  • コンテキスト ID

各 MIME タイプ、したがってプロトコルハンドラは、メッセージのクラス (application/OCSP など) を表します。クライアントは、適切な MIME タイプを生成する能力を備えている必要があります。クライアントが Web ブラウザの場合は、一般に MIME タイプ「application/x-www-form-url-encoded」が生成されます。iPlanet Trustbase Transaction Manager には、この MIME タイプを処理するデフォルトのプロトコルハンドラが組み込まれています。このプロトコルハンドラのデフォルトアクションは次のとおりです。

  • フォームフィールド内の次のデータを検索する

    • メッセージタイプ - メッセージタイプを識別

    • コンテキスト ID - コンテキスト ID を識別

  • 応答 MIME タイプを text/html に設定することで、返信が標準的な HTML ページであることをブラウザに伝える


Identrus プロトコルハンドラ

プロトコルハンドラは、TC に配信されるメッセージのうち、「application/identrus-」文字列で始まる MIME タイプを持つものすべての初期処理を行います。

プロトコルハンドラが順次実行するアクションは次のとおりです。

  • クライアントから原初 XML ストリームを読み取る

  • 原初 XML を内部 iPlanet オブジェクト構造 (メッセージツリー) に解釈する

  • XML メッセージ内の DOCTYPE によって指定されている DTD に照らし合わせて、メッセージツリーを確認する

  • メッセージツリーをトラバースし、ID 属性がある場合は重複するものがないかどうかを確認する (XML 処理に必須のステップ。XML 構造がデジタル署名される場合は特に重要)

  • IdentrusConstants.SYSTEM_ID_ATTR が特定する iPlanet Trustbase Transaction Manager メッセージ属性に DOCTYPE タグのシステム識別子を入れる

  • NIB から原初メッセージログ処理可能な要素を抽出する

  • メッセージから証明書バンドルを抽出し、証明書ログにすべての証明書を記録する

  • メッセージの証明書バンドル以外の部分を原初メッセージログに送信する

  • ログから返された原初ログ ID を、IdentrusConstants.RAW_RECORD_MARKER が特定する iPlanet Trustbase Transaction Manager メッセージ属性に入れる

  • iPlanet Trustbase Transaction Manager メッセージのタイプを
    IdentrusConstants.IDENTRUS_MESSAGE に設定する

  • メッセージツリーをシリアル化された内容として iPlanet Trustbase Transaction Manager メッセージに付加することで、メッセージを適切なメッセージリーダに送信可能な状態にする


    注

    変数 DOCTYPE は、XML の概念です。http://www.w3.org/TR/REC-xml などを参照してください。
    定数 SYSTEM_ID_ATTR、RAW_RECORD_MARKER および IDENTRUS_MESSAGE は、Identrus 定数です。Identrus 定数については、com.iplanet.trustbase.identrus.IdentrusConstants を参照してください。




メッセージリーダ

適切なメッセージリーダの選択は、プロトコルハンドラが収集した情報に基づいて行われます。各メッセージリーダは、それぞれどのメッセージのクラスを内部 iPlanet Trustbase Transaction Manager メッセージに変換できるかを暗黙のうちに理解しています。


デフォルトメッセージリーダ、HTTP リーダ

iPlanet Trustbase Transaction Manager には、MIME タイプ
application/x-www-form-url-encoded を処理する HTTP/POST メッセージリーダが組み込まれています。HTTP/POST メッセージリーダはすでにデフォルトのメッセージリーダとして登録されているため、ホスト環境アダプタによって検知されたメッセージタイプに一致するものがメッセージリーダレジストリ内にない場合は、このリーダが返されます。MIME タイプが application/x-www-form-url-encoded でない場合は、エラーが返されます。

適切なメッセージリーダが見つかると、iPlanet Trustbase Transaction Manager メッセージオブジェクトおよび未処理のメッセージ内容を含む入力ストリームがそのメッセージリーダに渡されます。メッセージリーダは入力ストリームからメッセージ内容を読み取って解釈し、メッセージ内容の内部表現を含むデータブロックを作成します。このデータブロックは、適切なサービスが使用できるように、iPlanet Trustbase Transaction Manager メッセージオブジェクト内に格納されます。

メッセージリーダが入力ストリームの解釈およびiPlanet Trustbase Transaction Manager メッセージの構築を完了すると、メッセージアナライザがその iPlanet Trustbase Transaction Manager メッセージをルータに送り、その後の iPlanet Trustbase Transaction Manager メッセージ処理で発生したエラーや例外に対処します。


デフォルト HTTP リーダの使用

HTTP リーダは、HTTP Post または Get 文字列から各入力フィールドを抽出して DOM 構造に入れるという、比較的単純な方法で入力ストリームから情報を抽出します。すべてのフィールドが抽出されると、この DOM オブジェクトは iPlanet Trustbase Transaction Manager メッセージ内に格納されます。DOM オブジェクトの構造がユーザによって指定されていない場合、各フィールドはノード HTTP_VALUES の属性として格納されます。
HTTP
HTTP_VALUES Attributes [<フィールド名> = <値>]*

ただし、特定のエスケープシーケンスを使用することで、フィールドをより複雑な構造に格納するよう強制できます。

HTTPReader クラスは入力フィールド名 <input name="$|xml:<ノード1>...<ノードn>|$"> に含まれるエスケープシーケンスを認識するため、開発者は独自の DOM 構造を作成できます。次に例を示します。
<input name="$|xml:message.user.name|$">
<input name="$|xml:message.user.address|$">
<input name="$|xml:message.user?jobtitle|$">

これによって、ルート HTTP ノードの下に、次のデータを含む一連のノードが作成されます。
HTTP
HTTP_VALUES Attributes [<フィールド名> = <値>]*
message
user Attribute jobtitle=<値>
name = <値>
address = <値>


デフォルトメッセージリーダ、Identrus リーダ

このメッセージリーダは、「application/identrus-」で始まる MIME タイプおよびメッセージタイプ IdentrusConstants.IDENTRUS_MESSAGE を持つメッセージを処理します。

メッセージリーダのアクションは次のとおりです。

  • 必須の DSIG 署名をチェックする

  • メッセージ内の証明書チェーンをチェックし、チェーンのルート証明書がデータベース内に存在することを確認する。チェーンのルートが証明書ストア属性 IdentrusConstants.IR_CA を持っていることを確認する

  • ルータでの認可段階に対する準備が整っている iPlanet Trustbase Transaction Manager メッセージのセキュリティコンテキストを設定する

  • メッセージの請求ログエントリを記録する

その後、メッセージはルータに送信されます。


デフォルトメッセージリーダ、Identrus エラーリーダ

このメッセージリーダは、MIME タイプ application/identrus-identrustransporterror およびメッセージタイプ IdentrusConstants.IDENTRUS_TRANSPORT_ERROR を持つメッセージを処理します。

メッセージリーダのアクションは次のとおりです。

  • 受信する「Identrus トランスポートエラー」にはチェックすべき署名がないため、
    iPlanet Trustbase Transaction Manager メッセージのセキュリティコンテキストを設定しない。このリーダに送られるメッセージはコネクタだけを経由しているため、ルータにこれらのメッセージを送らない



メッセージライタ

メッセージが 1 つ以上のサービスに配信され、その後ルータに返されると、そのメッセージはメッセージアナライザに返されます (例外またはエラーが発生しなかった場合)。この時点で、メッセージアナライザは、返された iPlanet Trustbase Transaction Manager メッセージをユーザへの送信に適切な形にするにはどのメッセージライタを使用すべきかを判別しなくてはなりません。メッセージアナライザは、メッセージリーダを選択する場合と同様、メッセージの返されたタイプおよび応答 MIME タイプの値に基づいて、適切なメッセージライタを選択します。

メッセージライタは iPlanet Trustbase Transaction Manager メッセージに含まれる情報を抽出し、メッセージをクライアントに送信可能な形式に処理します。

iPlanet Trustbase Transaction Manager には、メッセージライタをレジストリに登録するための HTML 管理インターフェイスがあります。したがって、iPlanet Trustbase Transaction Manager に関連付けられている内部構成ストアに新しいメッセージライタのサブクラスを登録できます。または、tbase.properties ファイルに適切なエントリを追加することでも登録できます。その場合は、たとえば次のように新しいメッセージライタを [MessageWriter] セクションに追加します。
message.writer=<名前>:<クラスパス>
message.writer= Script:uk.co.jcp.tbaseimpl.parse.message.http.ScriptWriter

<名前> は新しい MessageWriter インスタンスのユーザ定義名を示し、<クラスパス> は完全指定のクラスパスを示します。管理インターフェイスを通じて新しいメッセージライタを追加し、その後 properties ファイルを使用して iPlanet Trustbase Transaction Manager を再起動すると、変更がすべて失われるので注意してください。このような事態を避けるため、管理インターフェイスを使用する場合でも、properties ファイルにエントリを追加することをお勧めします。


デフォルト HTML メッセージライタ

iPlanet Trustbase Transaction Manager には、MIME タイプ text/html を処理する HTML メッセージライタが組み込まれています。この HTML メッセージライタはすでにデフォルトのメッセージライタとして登録されているため、ホスト環境アダプタによって検知されたメッセージタイプおよび MIME タイプに一致するものがメッセージライタレジストリ内にない場合は、このライタが返されます。MIME タイプが text/HTML でない場合は、エラーが返されます。

このメッセージライタは、他の Dynamic HTML ライタに類似のパターンマッチングおよびテンプレートを使用して、メッセージに含まれる XML フィールドを HTML 形式に変換する能力を備えています。

デフォルトの HTML メッセージライタである ScriptWriter は、完全な XSL に頼らず単純な情報を迅速および能率的に表示するためのスクリプト言語を使用します。

ScriptWriter は、応答にテキスト (通常は HTML) が含まれると想定され、かつルータから返された情報が XML からテンプレートへそのまま値を代入できるような単純なものである場合に使用されるべきライタです。

ScriptWriter クラスは、返されたメッセージに含まれる DOM オブジェクトを取り、その中のフィールドをすべて抽出することで機能します。これらのフィールドは、返されたメッセージのタイプおよび形式に基づいて適切なテンプレートに代入されます。この代入は、一連のスクリプトタグによって行われます。開発者は、これらのスクリプトタグを使用して、メッセージの各部分をそれぞれテンプレートのどの場所に入れるかを指定できます。ScriptWriter が使用するテンプレートを構成するには、iPlanet Trustbase Transaction Manager HTML 管理インターフェイスを使用するか、または次のように tbase.properties ファイルの [ScriptWriter] セクションに適切なエントリを追加します。
writer.typeandformat=<形式>:<タイプ>:<テンプレート>
writer.typeandformat=text/html:TimeServiceTimeResponse:Config¥Templates¥Time Service¥TimeServiceTimeResponse.html

<形式> は text/html です。<タイプ> は、ライタに返される前に最後にそのメッセージを処理したサービスが設定するメッセージタイプを示します。<テンプレート> は、テンプレートファイル名を示します。このファイル名には絶対パスまたは相対パスを使用できますが、相対パスの場合は 'root':template.directory=.¥ (最後の「¥」は必須) の場所を指定するためのエントリが必要です。


スクリプトタグ

スクリプトテンプレートでは、主に次の 4 種類のタグが使用されます。

  • $$xml:<XML 変数名>$$

これは、1 つの変数が XML 文書からテンプレートに 1 度代入されることを表すタグです。<XML 変数名> は、ルータから返された XML 文書に含まれるノードの完全指定の「場所」であり、テンプレートに代入可能な文字列値が含まれていることが想定されています。たとえば、XML 文書から 名前 (name) を取得するタグは、次のようになります。
$$xml:message.content.user.name$$

また、このタグでは、エスケープシーケンス「?」を使用して XML ノードの属性を指定することも可能です。たとえば、名前 (name) の属性として格納されているミドルイニシャル (middle_initials) を取得するタグは、次のようになります。
$$xml:message.content.user.name?middle_initials$$

  • $$repeat:<XML 配列名>[<ユーザ定義のタグ名>:<反復子>]$$...$$/repeat$$

これは、XML 文書に含まれる、値の繰り返し配列の始点を表すタグです。

<XML 配列名> は、XML 文書内の配列の完全指定の「場所」です。

<ユーザ定義のタグ名> によって、この配列の場所に省略名を付けられます。たとえば、配列がユーザ (user) の住所 Response.Content.User.Address を表す場合、繰り返しのブロック内で簡単に使用できるように、これを住所 (address) としてタグできます。

<反復子> によって、配列のどの「部分」を表示するかを指定できます。

表 2-1    XML Repeat 反復子



反復子

説明

例

*  

指定の配列内に含まれるすべてのアイテムを反復  

*  

<n>  

配列内の n 番目の要素を選択。配列内に含まれる要素が n 個未満の場合は、何も表示しない  

2  

<m>-<n>  

m 番目から n 番目までの要素 (m および n を含む) を選択。配列に含まれる要素が n 個未満の場合は、m から最後までを選択。要素が m 個未満の場合は何も表示しない  

3-5  

<m>-*  

配列の m 番目から最後の要素までをすべて選択  

2-*  

<属性>=<値>  

指定の属性が指定の値に等しい配列内の要素を「すべて」選択  

location=

London  

,  

複数の反復子を同時に指定することを許可  

0,3-5,9,postcode=EC1  

繰り返しの各ブロックは $$/repeat$$ 文によって中断されます。

  • $$xif:<XML 変数名>[="<値>"]$$ ... $$/xif$$

これは、条件を表すタグです。最も単純な形で記述された場合、このタグは、XML 内にノード (または同じ「?」エスケープシーケンス使用の属性) が存在するときに条件文に含まれるすべてを反復するように指示します。

ただし、「=」が使用されている場合は、ノードまたは属性が存在するだけではなく、その値が指定されている値と正確に一致している必要があります (大文字と小文字の区別を含む)。たとえば、職名 (jobtitle) が「SysAdmin」に一致する場合だけユーザ詳細情報を表示するよう指示する条件ブロックは、次のようになります。
$$xif:message.content.user?jobtitle="SysAdmin"$$

$$xif:_$$ タグに関連するタグとして、任意の条件分岐を行うための $$xelse:_$$ があります。このタグは、2 とおりの方法で使用できます。
$$xelse$$

最も単純な使用法です。これは、$$xif:_$$ 条件が満たされていない場合に、代わりに適用する条件を表すタグです。XML ノードの内容によって、2 種類の表示形式を使用する必要がある場合などに使用します。
$$xelse:<XML 変数名>[="<値>"]$$

このタグの記述の仕方は xif 文と同じです。これは、このブランチを実行する条件を表すタグです。テンプレートのどのセクションを使用するかをより詳細に指定するために、追加の条件分岐を行う場合に使用します。

  • $$xprop:[<セクション>]<プロパティ>[=<デフォルト値>]$$

これは、プロパティの値を tbase.properties ファイルからテンプレートに取り入れるための特殊なタグです。このタグによって、同じテンプレートが異なるアプリケーションサーバ環境をサポートできるようになります。プロパティ値は各サーバのタイプによって変化します。また、$$xprop:...$$ タグは、他のタグに先立って前処理されるため、プロパティに他のタグの情報 ($$xprop:...$$ そのものを除く) を含むことができるという特徴を持っています。

  • <セクション> は、プロパティを含むセクションの名前です。指定されていない場合は、ScriptWriter セクションが使用されます。

  • <プロパティ> は、使用されるプロパティの名前です。

  • <デフォルト値> は、プロパティが見つからない場合に使用されるデフォルト値です。プロパティが見つからず、かつデフォルト値が指定されていない場合は、空白文字列が返されます。


ScriptWriter タグの使用

  • $$xml:...$$ substitution

前述のとおり、このタグは返された XML 文書に含まれる 1 つの値がそのまま HTML テンプレートに代入されることを表します。ルータから返される XML 文書にサポートデスクのメールアドレス (supportaddress) を示すデータが含まれるという前提のもとに記述されたテンプレートの一部を次に示します。
<P>
<FONT SIZE=-2>
お問い合わせは、
<A HREF="mailto:$$xml:response.content.supportaddress$$">サポートデスク </A>
までお送りください。
</FONT>
</P>

  • $$xml:...$$ filtering

次のように、絶対パスに属性フィルタを挿入することも可能です。
<P>
ログインの詳細については、
<A HREF="mailto:$$xml:response.content.user?title="SysAdmin".email$$"> システム管理者</A>
まで電子メールでお問い合わせください。
</P>

この例では、XML 文書に 1 人以上のユーザ (user) の詳細情報の配列が含まれ、各ユーザにそれぞれの電子メールアドレス (email) を含むノードが含まれています。ユーザの title 属性を使用して職名 (title) が「SysAdmin」であるユーザを判別し、その結果から電子メールアドレス (email) を抽出します。

  • $$repeat:...$$ loop

$$/repeat$$ を含む繰り返しのブロックを実際にどのように使用できるかを、次に示します。この例では、XML 文書がノード http_response.content.transaction の下にトランザクション (transaction) の配列を含んでいると想定されています。さらに、XML 文書ツリーのこのセクションは、txn としてタグ付けされています。

繰り返しのブロック内では、通常の $$xml:...$$ 表記によって、返された配列内の各要素に含まれるデータが選択されています。

各トランザクションは、日付 (date)、説明 (description)、および金額 (amount) の 3 つのノードを含みます。これらのノードは 1 つのテーブル行に挿入され、テーブルには返されたトランザクションと同じ数の行が含まれます。
<table BORDER="1" BGCOLOR="#fff0a0">
     <th COLSPAN="3" BGCOLOR="ffd080"><b><i><font SIZE="+1" COLOR="#00a000">明細</font></i></b></th>
     <tr>
          <td WIDTH="50" ALIGN="center"><B>日付</B></td>
          <td WIDTH="400" ><B>説明</B></td>
          <td WIDTH="200" ALIGN="center"><B>金額</B></td>
     </tr>
     $$repeat:message.content.transaction[txn:*]$$
          <tr>
          <td>$$xml:[txn].date$$</td>
          <td>$$xml:[txn].description$$</td>
          <td ALIGN="right">$$xml:[txn].amount$$</td>
          </tr>
     $$/repeat$$
</table>

  • $$repeat: ...$$ ブロックの入れ子

繰り返しのブロックは、入れ子にすることも可能です。前述のユーザの例に当てはめてみましょう。各ユーザ (user) のノードが住所 (address) のノード (住所 1 行 あたり 1 つずつ) の配列を含んでいるため、各ユーザに対してすべての住所行を反復したいと仮定します。この場合、テンプレートの記述はたとえば次のようになります。
<table BORDER="1" BGCOLOR="#fff0a0">
     <th COLSPAN="3" BGCOLOR="ffd080"><b><i><font SIZE="+1" COLOR="#00a000">システムユーザ</font></i></b></th>
     <tr>
          <td WIDTH="100" ALIGN="center"><B>名前</B></td>
          <td WIDTH="400" ALIGN="center"><B>住所</B></td>
          <td WIDTH="100" ALIGN="center"><B>電話番号</B></td>
     </tr>
     $$repeat:message.content.user[user:*]$$
          <tr>
          <td>$$xml:[user].name$$</td>
          <td>
          $$repeat:[user].address[addr:*]$$
               $$xml:[addr]$$<br>
          $$/repeat$$
          </td>
          <td>$$xml:[user].telno$$</td>
          </tr>
     $$/repeat$$
</table>

  • $$xif:...$$

ここでは、繰り返しのブロックの例をさらに発展させて、条件付き表示を実行する方法を示します。この場合、電話番号の列には、在宅勤務の従業員の自宅番号 (homePhone) またはオフィス勤務の従業員の内線番号 (workExtn) が表示されます。
<table BORDER="1" BGCOLOR="#fff0a0">
     <th COLSPAN="3" BGCOLOR="ffd080"><b><i><font SIZE="+1" COLOR="#00a000">システムユーザ</font></i></b></th>
     <tr>
          <td WIDTH="100" ALIGN="center"><B>名前</B></td>
          <td WIDTH="400" ALIGN="center"><B>住所</B></td>
          <td WIDTH="100" ALIGN="center"><B>電話番号</B></td>
     </tr>
     $$repeat:http_response.content.user[user:*]$$
          <tr>
          <td>$$xml:[user].name$$</td>
          <td>
          $$repeat:[user].address[addr:*]$$
               $$xml:[addr]$$<br>
          $$/repeat$$
          </td>
          <td>
               $$xif:[user].workType="在宅勤務"$$
                    $$xml:[user].homePhone$$
               $$xelse$$
                    $$xml:[user].workExtn$$
               $$/xif$$
          </td>
          </tr>
     $$/repeat$$
</table>

  • $$else:...$$

さらに、xelse 構造を使用して複数の条件文を実行することも可能です。前述の例に当てはめてみると、条件分岐を拡張して、営業担当の従業員を含むことができます。
<td>
     $$xif:[user].workType="在宅勤務"$$
                    $$xml:[user].homePhone$$
     $$xelse:[user].workType="営業"$$
                    $$xml:[user].mobile$$
     $$xelse$$
                    $$xml:[user].workExtn$$
     $$/xif$$
</td>

  • $$xprop:...$$ プロパティ代入

tbase.properties ファイルからテンプレートにプロパティを取り込むためのコードの例を次に示します。
<hr>
<form METHOD=post ACTION="$$xprop:[ApplicationServcer]form.string$$/appservlet">
     <h3>
ID 確認のため、ご使用のカードに関する情報を入力してください。
</h3>


デフォルト Identrus メッセージライタ

このメッセージライタは、「application/identrus-」で始まる MIME タイプおよびメッセージタイプ IdentrusConstants.IDENTRUS_MESSAGE を持つメッセージを処理します。

メッセージライタのアクションは次のとおりです。

  • IdentrusConstants.SIGNING_CERT_ATTR が特定する iPlanet Trustbase Transaction Manager メッセージ属性が存在しない場合は、IdentrusConstants.L1_IP_SC 証明書を使用してメッセージに署名する。属性が存在する場合は、その値を送信メッセージの署名に使用される証明書または鍵の目的 ID として取る

  • DOCTYPE に基づいて送信メッセージの DTD を確認し、不正なメッセージが TC の外部に出されないようにする

  • DOCTYPE タグを設定し、DOCTYPE からメッセージの MIME タイプを判別する

  • メッセージから証明書バンドルを抽出し、証明書ログに記録する

  • 証明書バンドルを除く送信メッセージの XML をメッセージログに記録する

  • メッセージをクライアントに送信可能な形式にする


デフォルト Identrus エラーライタ

このメッセージライタは、MIME タイプ application/identrus-identrustransporterror およびメッセージタイプ IdentrusConstants.IDENTRUS_TRANSPORT_ERROR を持つメッセージを処理します。

メッセージライタのアクションは次のとおりです。

  • DOCTYPE に基づいて送信メッセージの DTD を確認し、不正なメッセージが TC の外部に出されないようにする

  • DOCTYPE タグを設定し、DOCTYPE からメッセージの MIME タイプを判別する

  • 送信メッセージの XML を原初ログに記録する

  • メッセージをクライアントに送信可能な形式にする



接続マネージャ

iPlanet Trustbase Transaction Manager は、メッセージを受信すると、それを適切に処理できるサービスに配信し、必要に応じて応答メッセージを送ります。しかし、iPlanet Trustbase Transaction Manager システムが受信したメッセージを適切なサービスに配信しても、そのサービスが 他のソースから追加情報を取得しないとメッセージの処理を完了できない場合もあります。したがって、iPlanet Trustbase Transaction Manager は、特定のメッセージトランスポートプロトコルを使用して新しいメッセージを生成し、そのメッセージを特定の外部目的地に送るための機能を備えている必要があります。この機能を提供するのが「接続マネージャ」であり、サービスは接続マネージャを呼び出すことでメッセージを処理できるようになります。

図 2-2    接続マネージャのアーキテクチャ

  


注

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

  • uk.co.jcp.tbase.connector

  • uk.co.jcp.tbase.xurl

  • uk.co.jcp.tbaseimpl.connector


接続マネージャは、基本的に、外部エンティティとのメッセージの送受信に使用可能なサービスです。接続マネージャは、iPlanet Trustbase Transaction Manager メッセージおよび Destination オブジェクトを受け取り、これらの情報に基づいて、関連するメッセージの送受信を行います。接続マネージャのメッセージ処理の流れは次のとおりです。

  • サービスが Connector を呼び出し、外部リソースへのリクエストを含む iPlanet Trustbase Transaction Manager メッセージおよび外部リソースの説明である Destination オブジェクトを渡します。Destination オブジェクトはアプリケーション定義の実装であり、Connector のアプリケーション定義のプラグインである ProtocolMap オブジェクトによって認識されます。無効なメッセージパラメータが渡された場合は、接続が確立されても URLConnection オブジェクトへのデータの書き込みは行われません。

  • Connector は、受け取った Destination オブジェクトを ProtocolDescriptor オブジェクトに変換するため、ProtocolMapManager を呼び出します。(ProtocolDescriptor オブジェクトは、接続のための URL およびリクエスト内容のための MIME タイプを指定します。) ProtocolMapManager は、(管理者によって) 登録されている ProtocolMap の中から、受け取った Destination 実装の処理を担当しているものを選び出し、その ProtocolMap に Destination オブジェクトを渡します。

  • ProtocolMap が Destination オブジェクトを ProtocolDescriptor に変換します。このアクションは、単純でローカル処理が可能な場合もあり、複雑でさらに外部へのリクエストが必要な場合もあります。

  • Connector が ProtocolDescriptor 内の URL を使用して外部リソースに接続し、URLConnection を形成します。

  • Connector にメッセージが送られた場合、Connector は URLConnection の doOutput 変数を true に設定することで、接続にデータを書き込むことを明示します。Connector は次に、記述されるべきメッセージのタイプ (メッセージ の Type 属性が指定) および 形式 (ProtocolDescriptor が指定) に従って、MessageWriter のレジストリから MessageWriter を選択します。その MessageWriter が呼び出され、メッセージを適切な形式に変換して URLConnection の OutputStream に書き込みます。Connector にメッセージが送られていない場合は、URLConnection の doOutputfield が false に設定されるので、URLConnection には何も書き込まれません。

  • Connector が URLConnection の InputStream および応答の MIME タイプ (URLConnection に基づいて判別) を ConnectionProtocolAnalyser に渡します。ConnectionProtocolAnalyser は、応答の MIME タイプに基づいて、どの
    ProtocolHandler を呼び出すかを判別します。

  • ConnectionProtocolAnalyser が、選択した ProtocolHandler に InputStream および新しい iPlanet Trustbase Transaction Manager メッセージを与えます。ProtocolHandler は、InputStream から応答のメッセージタイプを判別し、新しいメッセージのタイプをそれと同じものに設定します (同時にコンテキスト識別子も設定することがあるが、ここでは無視される)。

  • Connector が 応答メッセージタイプおよび応答 InputStream MIME タイプに基づいて MessageReader を選択します。MessageReader が呼び出され、応答の解釈を完了します。MessageReader の作業が完了すると、Connector が外部との接続確立に使用されたリソースをすべて開放し、解釈済みのメッセージをリクエスト元であるサービスに返します。


    注

    iPlanet Trustbase Transaction Manager は、
    uk.co.jcp.tbaseimpl.connector.DefaultConnector で定義されているコネクタインターフェイスを実装するデフォルトコネクタを提供しています。これらのクラスの大部分は、iPlanet Trustbase Transaction Manager の一部として提供されていますが、そうでないものもあります。たとえば、java.net.URLConnection はコア Java API の一部です。



プロトコルマップマネージャ

接続マネージャは、iPlanet Trustbase Transaction Manager フレームワーク内のサービスが他の外部エンティティと通信することを可能にします。通信の際、Service は Connector (接続マネージャ) に メッセージおよび Destination を渡します。Connector は指定の外部エントリにメッセージを配信し、通信先のアドレスを見つけるために ProtocolMapManager に Destination を渡します。ProtocolMapManager は登録されている ProtocolMap の中からその Destination に関連付けられているものを選択し、その ProtocolMap に Destination を渡します。ProtocolMap は Destination に関連付けられている ProtocolDescriptor オブジェクトを返します。受け取った Destination に対してどの ProtocolDescriptor を返すかは、各 ProtocolMap が判別します。

新しいアプリケーション固有プロトコルマッピングシステムを作成するには、次のステップを実行する必要があります。

  • 特定の ProtocolMap の作成

  • 特定の Destination の作成

  • 新しい ProtocolMap の ProtocolMapManager への登録

  • ProtocolMap へのデータ提供


    注

    フレームワーク uk.co.jcp.tbase.connector を参照してください。また、デフォルトの接続マネージャクラス実装については、uk.co.jcp.tbaseimpl.connector を参照してください。


各ステップの詳細は次のとおりです。

  • 特定の ProtocolMap の作成

ProtocolMap オブジェクトはすべて ProtocolMap インターフェイスを実装する必要があります。また、空白またはデフォルトのコンストラクタを提供する必要もあります。これは、ProtocolMapManager がクラス登録のために ProtocolMap オブジェクトを動的にインスタンス化するからです。

ProtocolMap は次のメソッドを呼び出します。
public Enumeration getDestinationTypes()

これは、ProtocolMap が認識できる Destination 実装のパッケージ指定クラス名のリストを返すメソッドです。
public ProtocolDescriptor getProtocolDescriptor(Destination destination)
     throws InvalidDestinationException

これは、アプリケーションの指定された Destination オブジェクトを ProtocolDescriptor に変換し、接続に必要な URL および MIME タイプを指定するメソッドです。


注

アプリケーション固有の ProtocolMap は、シリアル化できないオブジェクトを含むことはできません。これは、ProtocolMapManager に永続性があるためです。詳細は、API uk.co.jcp.tbase.connector.ProtocolMap を参照してください。


  • 特定の Destination の作成

Destination はすべて Destination インターフェイスを実装する必要があります。このインターフェイスはメソッドを呼び出しません。すべてのメソッドおよびデータはアプリケーション固有であり、関連付けられている ProtocolMap が前もってインターフェイスの形式を認識している必要があります。


注

アプリケーション固有の Destination がシリアル化できないオブジェクトを含むことはできません。これは、ProtocolMapManager に永続性があるためです。詳細は、API uk.co.jcp.tbase.connector.Destination を参照してください。


  • 新しい ProtocolMap の ProtocolMapManager への登録

アプリケーション固有の ProtocolMap および Destination を構築したら、iPlanet Trustbase Transaction Manager 内のサービスが ProtocolMap の機能を活用できるように、ProtocolMap を ProtocolMapManager に登録する必要があります。


注

ProtocolMapManager に登録されている既存 ProtocolMap が使用する特定の Destination への参照がアプリケーション固有の新しい ProtocolMap に含まれている場合、新しい ProtocolMap は ProtocolMapManager に登録されません。


プロトコルマップは、「ProtocolMapManager」というプロパティセクションを含む tbase.properties ファイル内で登録できます。このセクションにアプリケーション固有の ProtocolMap オブジェクトのエントリを記述します。次に例を示します。
[ProtocolMapManager]
protocol.map=uk.co.jcp.tbase.connector.SimpleProtocolMap


注

iPlanet Trustbase Transaction Manager のインスタンスに関連付けられている構成オブジェクトを削除しない限り、この tbase.properties ファイルが読み込まれるのは 1 度だけです。また、完全なパッケージ名を指定する必要があります。



URL 接続の実装

接続マネージャ内部では、ProtocolMapManager が受け取った Destination に基づいて ProtocolDescriptor を返すと、ProtocolDescriptor から URL の文字列表現が取得されます。この URL の文字列表現からは URLConnection オブジェクトが取得されます。接続マネージャ (Connector) は、URLConnection からの出力ストリームおよび入力ストリームを通じてメッセージを送受信します。URL の文字列表現から URLConnection オブジェクトへの変換は、「XURLxxxxx」の形式を持つクラスによって行われます。使用されるクラスは次のとおりです。

  • XURL

  • XURLStreamHandler

  • XURLStreamHandlerFactory

これらのクラスが必要なのは、javasoft によって提供されている既存の URL クラス階層は EJB 形式では拡張できないからです。既存のフレームワークでは、URL クラスは、URL 形式を認識できないと XURLStreamHandlerFactory が読み込まれているかどうかを確認しますが、この際に XURLStreamHandlerFactory が不明な URL 形式を提供することがあります。このファクトリを設定できるのは 1 度だけなので、EJB 環境では URLStreamHandlerFactory がインスタンス化されているかどうかを確認できず、その結果フレームワークを使用できないということになります。この問題を解決するため、どの環境でも動作可能な拡張フレームワークが作られました。これらのオブジェクトは、XURL、XURLStreamHandler、および XURLStreamHandlerFactory と呼ばれます。

プロセスの流れは次のとおりです。

  • ProtocolDescriptor が提供する URL の文字列表現に基づいて、XURL オブジェクトが構築されます。

  • URLConnection オブジェクト取得のため、XURL のメソッド openConnection() が呼び出されます。

  • このメソッド内で XURLStreamHandlerFactory が呼び出されます。

  • 初めて呼び出された場合、XURLStreamHandlerFactory は tbase.properties ファイルの「XURLStreamHandlerFactory」セクションに各 XURLStreamHandler クラスを登録し、それぞれを値「url.stream.protocol」に対応づけて、自己初期化を行います。

  • 指定された URL への接続に使用されるプロトコルをキーとして、
    XURLStreamHandlerFactory 内の検索が行われます。

  • このプロトコルが XURLStreamHandlerFactory に登録されている
    XURLStreamHandler に対応づけられている場合は、XURLStreamHandler オブジェクトが呼び出され、必要な URLConnection オブジェクトを提供します。

  • プロトコルが XURLStreamHandlerFactory 内のどの XURLStreamHandlers とも一致しない場合は、XURL の文字列表現から URL オブジェクトが作成され、そこから直接 URLConnection オブジェクトが取得されます。

この拡張フレームワークによって、JCP は既存のプロトコル形式を無効にし、特定の拡張機能 (例 : HTTPS。SSL が証明書ストアインターフェイスに直接結び付けられている) を組み込むことを可能にしています。


注

詳細は、API uk.co.jcp.tbase.xurl を参照してください。



前へ     目次     索引     DocHome     次へ     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

最終更新日 2001 年 3 月 14 日