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



第 3 章   ルーティング


ルータコンポーネントには、2 つの特定の機能があります。

  • 特定のサービスへのリクエストを認可する手段を提供する

  • トランザクションの流れを制御する手段を提供する

ルータのアーキテクチャは規則ベースになっています。通常の場合、トランザクションの動きを変更するために開発者が Java コードを記述する必要はありません。これは、システム内でのメッセージ処理の流れを判別する XML 規則を作成し、これらの規則と iPlanet Trustbase Transaction Manager メッセージ内の値を比較するメカニズムが存在するためです。

この章では、ルータのアーキテクチャの基盤となっている概念、ルータの機能、および Identrus メッセージ処理のデフォルト実装について説明します。



メッセージ


iPlanet Trustbase Transaction Manager メッセージは、iPlanet Trustbase Transaction Manager のある部分から別の部分へと移動するエンティティであり、iPlanet Trustbase Transaction Manager が受信したメッセージおよびそのメッセージに関する内部データをカプセル化したものです。iPlanet Trustbase Transaction Manager メッセージを構成する基本要素は次のとおりです。

  • メッセージタイプ

  • 属性

  • データの内容


    注

    iPlanet Trustbase Transaction Manager メッセージの要素に関する詳細は、uk.co.jcp.tbase.environment.Message の API ドキュメントを参照してください。


フレームワークそのものが iPlanet Trustbase Transaction Manager メッセージをどう処理するかは、メッセージのタイプおよび属性によって決定されます。iPlanet Trustbase Transaction Manager フレームワークでは、データの内容は不透明なものとして扱われます。つまり、データの内容が変更されても、iPlanet Trustbase Transaction Manager フレームワークはその変更を認識しません。

メッセージの状態を判別するのはルータの役目です。ルータは、属性値に基づく一連の前提条件を使用してメッセージの状態を判別し、その状態に従ってどのアクションを適用すべきかを判別します。これらの前提条件およびアクションは、ルータ規則として格納されています (詳細は後述)。


メッセージの属性

メッセージの属性は、Java プロパティと同様、名前と値が対になったものです。属性の名前と値は、必ず文字列によって表されます。

メッセージ属性の読み取りおよび書き込みは、プロトコルハンドラ、メッセージリーダ、メッセージライタ、ルータ、またはサービスによって行われます。したがって、メッセージ処理パイプラインの各段階で、その時点でのメッセージの状態に関する情報が追加されます。

属性は任意のユーザアプリケーションコードによって定義できますが、iPlanet Trustbase Transaction Manager フレームワークでは、次のような 標準的な属性が使用されています。

  • messageType
    Message API クラスが処理する属性。メッセージの MIME タイプとともに、メッセージ処理に使用するメッセージリーダ、メッセージライタ、およびプロトコルハンドラの判別に使用される。MIME タイプがこの属性を適切に設定するように管理するのは、プロトコルハンドラの役目。また、messageType 属性は、メッセージ処理中に変化することがある

  • security.role
    メッセージが帰するセキュリティ役割を含む属性。認証サービス (Authenticator) によって、認証に成功した場合は役割名に、役割を割り当てられない場合はデフォルト値に設定される

  • security.cert
    認証の証拠として使用される証明書のエンコード。通常は SSL クライアント証明書だが、Identrus メッセージの場合は、必須であるレベル 1 署名の確認に使用される証明書

  • security.cert_encoding
    必ず BASE64 で表される

  • security.cert_present
    認証に使用できる有効な証明書が存在しているかどうか

  • security.username
    認証に使用されるユーザ名

  • security.password
    認証に使用されるパスワード

  • security.user_pass_present
    有効なユーザ名/パスワードの証拠がメッセージに存在しているかどうか

  • security.auth_failed
    executeServiceDirective が呼び出された際に、認可に失敗したことを示す。iPlanet Trustbase Transaction Manager 内に役割/サービス名の対応づけ (マッピング) が存在しない、つまりメッセージをリクエスト先のサービスに送信する認可が与えられていないことを意味する


    注

    セキュリティに固有の属性名は、
    uk.co.jcp.tbaseimpl.authenticator.SecurityContext 内で定数として宣言されます。また、uk.co.jcp.tbase.environment.attribute も参照してください。



Identrus メッセージの属性

Identrus メッセージ処理の場合は、さらに次のメッセージ属性が使用されます。

  • DocType
    メッセージのタイプを特定する XML メッセージの DOCTYPE (CSCRequest や PingRequest など)

  • SigningCertPurposeId
    デフォルト Identrus メッセージライタだけが使用する省略可能な属性。指定されている場合、この属性は署名証明書および秘密鍵の抽出に使用する証明書ストア属性を指定する。この属性が指定されていない場合は、メッセージライタは Level 1
    Inter-participant Signing Certificate を使用する

  • XMLSystemId
    受信 XML メッセージの「システム識別子」属性を含む属性。対応する応答メッセージに XML システム識別子を埋め込むために Identrus メッセージライタが使用する


    注

    Identrus に固有の属性名は、
    com.iplanet.trustbase.identrus.IdentrusConstants 内で定数として宣言されます。




ルータのアーキテクチャ

ルータは、iPlanet Trustbase Transaction Manager の柔軟性の中核であるコア規則ベースのメッセージルーティングを行いますが、認証情報および認可設定に基づいてサービスへのアクセスを制御するゲートとしての役割も担っています。図 3-1 に、iPlanet Trustbase Transaction Manager 内でメッセージを移動し、適切なサービスに転送するための基幹要素を示します。

図 3-1    ルータのアーキテクチャ

  

  • iPlanet Trustbase Transaction Manager に着信したメッセージは、プレゼンテーション層 (プロトコルハンドラおよびメッセージリーダ) を通過します。この間に、messageType の識別と設定、およびその他の標準的な属性の設定が行われます。これらの属性は、メッセージの認証証拠の基盤となります。

  • その後、メッセージはルータに送られます。ルータは受け取ったすべてのメッセージをまず認証サービス (Authenticator) に送ります。iPlanet Trustbase Transaction Manager にはデフォルトの認証サービスが実装されていますが、必要に応じて変更することも可能です。

  • デフォルト認証サービスは、メッセージの属性を確認することで、そのメッセージの認証レベルを判別します。認証サービスの機能に関する詳細は、下記の説明を参照してください。

  • セキュリティコンテキスト属性 (security.role) を設定されたメッセージが、ルータに送り返されます。このコンテキスト属性によって、メッセージがどの役割に対して認証されたかが判別されます。

  • ルータは、ルーティング規則に従ってメッセージを処理することでターゲットサービスを検出し、そのサービスにメッセージを送ります。ルーティング規則の詳細は、この章後述の説明を参照してください。

  • メッセージは、サービスに到達する前に認可ゲートを通過する必要があります。この認可ゲートでは、メッセージに割り当てられた役割属性とターゲットサービスが対応づけられているか (マッピングが存在するかどうか) が確認されます。マッピングが存在する場合、メッセージはサービスに送られ、存在しない場合は認可エラーサービスに送られます。

iPlanet Trustbase Transaction Manager メッセージはすべて上記の各段階を通過します。また、Identrus XML メッセージ処理のためのパイプラインは、開発者の観点から合理化されています。詳細は、この章の「デフォルトルーティング」を参照してください。



認証と認可


iPlanet Trustbase Transaction Manager の認証メカニズムは独立したコンポーネントではありません。認証データはデフォルト iPlanet Trustbase Transaction Manager フレームワークによって収集されます。また、ドメイン固有のサービスによってさらにデータが追加されることもあります。これらのサービスが識別情報を特定の属性セットに対応づけ、iPlanet Trustbase Transaction Manager はこれらの属性を使用して他のサービスへのアクセスを制御します。


認証

可能な限りさまざまな組織に対応できる認証および認可メカニズムを維持するため、iPlanet Trustbase Transaction Manager フレームワークそのものは認証作業を行いません。識別情報の確認および特定の役割への対応付けは、サービスによって行われます。システムにはデジタル署名データアイテムおよびそれに付随する X509 デジタル証明書があり、サービスはこのデータを役割に対応づける機能を備えています。基本的な認証情報は、次の 2 種類の方法で提示されます。

  • 暗黙的 - トランスポートプロトコル内 (SSL など) で提示

  • 明示的 - メッセージ内容の中 (Identrus XML メッセージの署名済みメッセージブロックなど) で提示

ルータコンポーネントのアーキテクチャは、SSL ハンドシェイク内で使用されている証明書を削除し、認証サービスに送られるメッセージにこの証明書を付加することで、認証情報を明示化するように設計されています。このため、トランスポートレベルの認証に対して暗黙の「ブラックボックス」アプローチが取られる場合とは異なり、ターゲットシステムがさまざまなレベルの認証を実行できます。

また、デフォルトサービスは、ルータがリクエスト認可時に使用できるように、ユーザ名およびパスワードを役割に対応づける手段も提供しています。このメカニズムは、HTML テンプレートメカニズムを使用して構成情報および管理情報を提示する場合に一般的に使用されるものです。大規模な HTML ベースアプリケーションに対してプラットフォームを使用する場合は、排他的コミュニティメカニズムの代わりに、企業レベルのユーザ名およびパスワードメカニズムを使用することをお勧めします。


認可

デジタル証明書またはその他の方法でメッセージの送信元を判別したら、次の各操作を実行するためのメカニズムが必要となります。

  • ユーザに対して適切な認可レベルを特定する

  • 認可に基づいて各サービスにアクセスする

適切な認可レベル (または役割) を特定するのは、iPlanet Trustbase Transaction Manager の認証サービス (Authenticator) の役目です。デフォルトとして実装されているこのサービスは、認可データベース内のユーザ名/パスワードテーブルおよび証明書テーブルを使用して、メッセージとセキュリティ属性の対応づけ (マッピング) を判別します。マッピングの詳細は、『iPlanet Trustbase Transaction Manager 構成およびインストールガイド』を参照してください。各サービスへのアクセスは、ルータによって自動的に行われます。一致するルーティング規則が存在し、かつ本文に「executeServiceDirective」が含まれている場合、ルータはこのディレクティブを実行する前に、メッセージに割り当てられた役割とターゲットサービスの間にマッピングが存在するかどうかを確認します。これらのマッピングは認可テーブル内に維持されます。テーブルがどのように使用されるかについては、『iPlanet Trustbase Transaction Manager 構成およびインストールガイド』を参照してください。マッピングが存在する場合、メッセージはサービスに送られます。存在しない場合は、メッセージに新しい属性「security.auth_failed」が追加され、ルータに送り返されます。ルーティング規則は、認可失敗を必ず検知し、クライアントに「認可失敗」の応答を送るためのサービスを実行します。「unauthorisedExecuteServiceDirective」が含まれる場合は、認可チェックは行われず、無条件にサービスが実行されます。



デフォルトルーティング


Identrus メッセージサービスの開発を簡易化するため、iPlanet Trustbase Transaction Manager は Identrus メッセージ用のデフォルトルーティングメカニズムを提供しています。このデフォルトルーティングは、開発および配置されるすべての Identrus サービスに適用されます。詳細は、第 8 章「Identrus ソリューションの構築」を参照してください。

デフォルトルーティングは大部分の Identrus サービスに対応できるように設計されていますが、このルーティングでは不十分な場合は、開発者が新しいルーティング規則を記述する必要があります。


ルータ規則

iPlanet Trustbase Transaction Manager バージョン 2.2 のルータはより高度な機能を搭載しているため、基本的な規則処理が非常に簡易化されています。以前のバージョンでは、各サービスがサービス間でのメッセージ移送を明示的に対応づける規則セットを定義している必要がありました。しかし、新バージョンではシステムが動的に規則を定義できるため、この基本的な動作は自動的に定義されます。下記の 2 つの項で、このメカニズムについて説明します。


サービスへのルーティング

サービスの名前は、サービス JAR ファイルに含まれる配置記述子によって特定されます。システム起動時に、規則ハンドラがどのサービスを読み込むかを判別し、該当する各サービスに対して、指定の doctype とともにメッセージを転送するためのルーティング規則を動的に設定します。サービスがユーザ定義の規則セットを持つ場合は、動的に作成された規則によって、サービスではなくこの規則セットにメッセージが送られます。ユーザ定義の規則セットはサービスの JAR ファイル内に含まれます。単純なメッセージ処理の場合はこの規則セットは不要です。


返送パス

ルーティングをできるだけ単純にするため、「ReturnToUser」属性が設定されているメッセージはユーザに送り返されます。この属性は、処理が完了した時点でサービスによって設定されます。サービスレベルで作成されるエラーメッセージの場合も同様です。

図 3-2    デフォルトルーティング規則

  



高度なルーティング


この節では、ルーティング規則について詳しく説明します。単純な Identrus サービスの場合、メッセージをサービスに送るために開発者がルーティング規則を記述する必要はありませんが、デフォルトルーティングが不適切な場合、または Identrus 以外のメッセージを処理する場合は、新しく規則を記述する必要があります。


ルーティング規則セット

ルーティングテーブルには、プライベートおよびパブリックの 2 つの論理領域があります。パブリック規則セットは管理インターフェイスを通じて追加または構成できます。プライベート規則セットは基本的なサービスを提供するために iPlanet Trustbase Transaction Manager が使用するものであり、開発者またはシステム管理者が構成することはできません。この構造の最上部には、プライベート規則がどのように実行されるかを管理するルート規則セットがあります。パラメータに一致するプライベート規則が存在しない場合は、パブリックルート規則セットが実行されます。システム開発者は、このパブリックルート規則セットから独自のタスク規則セットをリンクできます (規則セットの定義については、次項を参照)。

図 3-3    規則セット

  

各領域には複数の規則セットが含まれています。各パブリック規則セットには名前があり、通常の場合はその名前が規則セットが行うビジネスタスクを示しています。パブリック規則セットはプラットフォームが起動するたびにディスクから読み込まれます。ルート規則セット内の規則が実行された結果として、名前そのものが明示的に読み込まれることもあります。

メッセージは、ルータに送られた時点ですでにコンテキストに関連付けられています。各コンテキストは、それぞれ規則セットに関連付けられています。これは、次のことを意味しています。

  • メッセージはルートコンテキストで動作し、ルート規則セットが関連付けられている

  • メッセージはサブコンテキストで動作し、パブリック規則領域の規則セットが関連付けられている

  • ただし、iPlanet Trustbase Transaction Manager メッセージが処理されている場合は例外であり、その場合はプライベート規則セットが関連付けられる

規則セットは順次処理され、現在の条件に当てはまる最初の規則が使用されます。ルータは規則セット内の各規則を最初から順に取り、メッセージタイプが規則前提条件に一致するかどうかを確認します。一致するものが見つかると、アクションが実行されます。一致するものがない場合は、エラー条件が返されます。規則は順次処理されるため、より明示的な規則を規則セットの始めの部分に、一般的な規則を後の部分に設定することが重要です。そうしないと、明示的な規則が一般的な規則によって実行対象外として排除されてしまう可能性があります。

ルート規則セットはできるだけ小さくしておくのが理想的です。そのためには、ルート規則セット内の規則がビジネスタスク内の最初のメッセージ (非請求メッセージ) だけに一致するようにしておく必要があります。アクションは、必ず新しいコンテキストを開始するためのものである必要があります。また、メッセージに適用する規則セットの名前 (および場合によっては開始位置となる規則の名前) を示していなくてはなりません。その後、メッセージが同様の方法で処理されます。

規則セットは、次の項で説明する DTD に準拠する、1 つの完全な XML 文書です。ルータは、起動時にまず iPlanet Trustbase Transaction Manager 初期化ファイル内の Router セクションを参照し、開発者によって記述された規則を格納しているディレクトリを探します。次に .xml ファイルを探し、これらのファイルをパブリック規則セット領域にコンパイルします。次の DTD の例に示されるように、各規則セットは、規則を含まない場合や、1 つあるいは複数の規則を含む場合があります。
<!ELEMENT ruleSet (rule*)>
<!ATTLIST ruleSet name CDATA #REQUIRED>

規則セット内の規則の構造については、次の項で説明します。


ルータ規則の構文

この項では、各要素の目的を定義しながら規則セットの DTD について説明します。各規則には、次の 3 つの要素があります。

  • 規則名を示す属性。省略可能。特定の規則を使用するかどうかを判別する必要がある場合は、新しいコンテキスト開始時にその名前を指定できる

  • 一連の前提条件。本文のディレクティブが実行されるためには、これらの条件がすべて満たされている必要がある

  • 規則の本文。前提条件がすべて満たされている場合に実行されるアクションのリスト

典型的な規則名は次のようになります。
<!ELEMENT rule ( preconditions, body )>
<!ATTLIST rule name CDATA #IMPLIED>
<!ELEMENT preconditions (attributeCondition*)>

前提条件は、属性条件 (attributeCondition) を含まない場合や、1 つあるいは複数の attributeCondition を含む場合があります。すべての attributeCondition が満たされていない場合、本文は実行されません。
<!ELEMENT attributeCondition EMPTY>
<!ATTLIST attributeCondition name CDATA #REQUIRED>
<!ATTLIST attributeCondition operator ( greaterThan | greaterThanEqualTo | lessThan | lessThanEqualTo | notEqual | startsWith | contains | endsWith | equals ) "equals">
<!ATTLIST attributeCondition valueType ( any | null | string ) "string">
<!ATTLIST attributeCondition value CDATA #IMPLIED>

iPlanet Trustbase Transaction Manager は、各 attributeCondtion を次のように解釈して処理します。
IF ( name operator value ) then pre-condition met

通常の場合、valueType は「string」に設定されます。value フィールドを持つ規則の場合は、valueType は不要です。属性の存在を確認するよう指定されている場合、または null に対してテストするよう指定されている場合は、valueType フィールドが使用されます。このような場合、value フィールドは不要であり、指定されていても無視されます。
<!ELEMENT body ((setAttribute | executeServiceDirective | unauthorisedExecuteServiceDirective )*, (startContextDirective | endContextDirective | returnToUserDirective )?)>

前提条件が満たされると、規則の本文が実行されます。規則の本文には、複数のアクションが含まれていることがあり、これらのアクションは記述順に実行されます。アクションの中には「中断」アクションとして認識されるものが 3 種類あり、これらのアクションは最終アクションとして規則の末尾部分に 1 度だけ記述されます。表 3-1 に、使用可能な本文ディレクティブを示します。

表 3-1    DTD の規則本文



ディレクティブ

説明

SetAttribute  

メッセージに iPlanet Trustbase Transaction Manager 属性を設定する  

executeServiceDirective  

必須の認可チェックを実行してルータから指定のサービスに制御を移す  

unauthorisedExecuteServiceDirective  

必須の認可チェックを実行せずにルータから指定のサービスに制御を移す  

StartContextDirective  

ある規則セットから別の規則セットにルータ制御を移す  

EndContextDirective  

現在のコンテキストを終了し、規則の検索を再開する  

ReturnToUserDirective  

ルータからシステムユーザに制御を返す  

<!ELEMENT setAttribute EMPTY>
<!ATTLIST setAttribute name CDATA #REQUIRED>
<!ATTLIST setAttribute value CDATA #REQUIRED>
<!ATTLIST setAttribute location (MESSAGE | CONTEXT) "CONTEXT">
<!ATTLIST setAttribute type (ASCEND_TRANSITIVE | NONE | INHERIT_TRANSITIVE | INHERIT) "ASCEND_TRANSITIVE">

setAttribute アクションによって、ルータがメッセージまたはコンテキストに属性を追加することが可能になります。name、value、location、および type フィールドは、API を通じて属性を作成する場合の設定と同じです。


注

詳細は、uk.co.jcp.tbase.environment.attribute.Attribute の API ドキュメントを参照してください。


<!ELEMENT executeServiceDirective EMPTY>
<!ATTLIST executeServiceDirective name CDATA #REQUIRED>

executeServiceDirective には、起動するサービス名を指定する必要があります。この方法でサービスを実行すると、メッセージがリクエスト先のサービスに送られる前に、まず認可チェックが実行されます。

このサービス名は、tbase.properties ファイルの ServiceRegistry セクションでサービス名として指定されているものに関連しています。tbase.properties ファイル内の新しい service.description エントリは、そのサービスの名前およびクラスパスによって構成されます。
<!ELEMENT unauthorisedExecuteServiceDirective EMPTY>
<!ATTLIST unauthorisedExecuteServiceDirective name CDATA #REQUIRED>

unauthorisedExecuteServiceDirective には、起動するサービス名を指定する必要があります。この方法でサービスを実行すると、認可チェックは実行されずにメッセージがリクエスト先のサービスに送られます。

このサービス名は、tbase.properties ファイルの ServiceRegistry セクションでサービス名として指定されているものと関連しています。tbase.properties ファイル内の新しい service.description エントリは、そのサービスの名前およびクラスパスによって構成されます。
<!ELEMENT startContextDirective EMPTY>
<!ATTLIST startContextDirective ruleset CDATA #REQUIRED>
<!ATTLIST startContextDirective rule CDATA #IMPLIED>

ルータは、startContextDirective を実行する際に、検索していた現在の規則セットを破棄し、ディレクティブ内で指定されている新しい規則セットを読み込みます。ディレクティブ内で個々の規則が指定されている場合は、新しい規則セット内にその規則が存在するかどうかを確認し、それ以外の場合は、規則セットの最初からチェックを開始して前提条件が満たされている最初の規則を見つけようとします。

startContextDirective には、使用する規則セットの名前が含まれている必要があります。また、指定の規則セット内で実行される規則名が含まれることもあります。
<!ELEMENT endContextDirective EMPTY>

endContextDirective には、属性または子はありません。
<!ELEMENT returnToUserDirective EMPTY>
<!ATTLIST returnToUserDirective endContext ( true | false ) #REQUIRED>

ルータは、returnToUserDirective によって、現在のコンテキストを終了するかどうかを判断します。

ユーザのためにいったんサービスが起動された後は、コンテキストは存在意義を失うため、破棄できることもあります。ただし、ユーザがサービスを実行するために認証を受ける必要があり、インタラクション間で「認可済み」コンテキストを維持したい場合など、ユーザが毎回認可プロセスを通さずにサービスを繰り返し使用できるような設定が必要な場合もあります。


注

これらのデータ構造に準拠するコア Trustbase サービス用の規則および規則セットの例は、<インストールディレクトリ>/Trustbase/TTM/current/Config/Rules/Public にあります。



ルータ規則の完全な DTD

iPlanet Trustbase Transaction Manager 内で使用可能なすべてのルーティング規則を指定する完全な DTD を次に示します。
<!-- A rule set is zero or more rules -->
<!ELEMENT ruleSet (rule*)>
<!ATTLIST ruleSet name CDATA #REQUIRED>
<!-- A rule optionally has a name attribute, preconditions & body elements -->
<!ELEMENT rule ( preconditions, body )>
<!ATTLIST rule name CDATA #IMPLIED>
<!-- preconditions element is a set of zero or more attribute condition elements -->
<!ELEMENT preconditions (attributeCondition*)>
<!-- An attribute condition is an empty tag with name, valueType & value attributes -->
<!-- the name is mandatory. valueType may be any, null or string. if string is -->
<!-- selected then value must be present. If any is selected then the value -->
<!-- matches any value and if null is selected then the value is disregarded -->
<!-- and assumed to be null -->
<!ELEMENT attributeCondition EMPTY>
<!ATTLIST attributeCondition name CDATA #REQUIRED>
<!ATTLIST attributeCondition operator ( greaterThan | greaterThanEqualTo | lessThan | lessThanEqualTo | notEqual | startsWith | contains | endsWith | equals ) "equals">
<!ATTLIST attributeCondition valueType ( any | null | string ) "string">
<!ATTLIST attributeCondition value CDATA #IMPLIED>
<!-- The body contains one of four directives -->
<!ELEMENT body ((setAttribute | executeServiceDirective | unauthorisedExecuteServiceDirective )*, (startContextDirective | endContextDirective | returnToUserDirective )?)>
<!-- A setAttribute directive -->
<!ELEMENT setAttribute EMPTY>
<!ATTLIST setAttribute name CDATA #REQUIRED>
<!ATTLIST setAttribute value CDATA #REQUIRED>
<!ATTLIST setAttribute location (MESSAGE | CONTEXT) "CONTEXT">
<!ATTLIST setAttribute type (ASCEND_TRANSITIVE | NONE | INHERIT_TRANSITIVE | INHERIT) "ASCEND_TRANSITIVE">
<!-- A start context directive must contain a name for the rule set to be used. -->
<!-- optionally contains a rule name to be executed in the specified rule set -->
<!ELEMENT startContextDirective EMPTY>
<!ATTLIST startContextDirective ruleset CDATA #REQUIRED>
<!ATTLIST startContextDirective rule CDATA #IMPLIED>
<!-- An end context directive has no attributes or children -->
<!ELEMENT endContextDirective EMPTY>
<!-- execute directive must specify a name for the service to be executed -->
<!ELEMENT executeServiceDirective EMPTY>
<!ATTLIST executeServiceDirective name CDATA #REQUIRED>
<!-- unauthorisedExecute directive must specify service name to be executed -->
<!ELEMENT unauthorisedExecuteServiceDirective EMPTY>
<!ATTLIST unauthorisedExecuteServiceDirective name CDATA #REQUIRED>
<!-- A return to user directive is empty and has no attributes -->
<!ELEMENT returnToUserDirective EMPTY>
<!ATTLIST returnToUserDirective endContext ( true | false ) #REQUIRED>


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

最終更新日 2001 年 3 月 14 日