データ中心ルールファイルのデフォルトのパスおよび名前は、domain-dir /cluster/config/ data-centric-rules.xmlです。データ中心ルールファイルを指定する融合ロードバランサ設定がクラスタまたはスタンドアロンサーバーインスタンスをまったく参照しない場合、デフォルトのパスおよび名前は domain-dir/config/ data-centric-rules.xmlです。ファイル形式を検証する DTD ファイルは、as-install/lib/dtds/ sun-data-centric-rule_1_0.dtd です。
データ中心ルールファイルが指定されている場合、コンシステントハッシュアルゴリズムにより、要求の転送先のサーバーインスタンスが特定されます。サーバーインスタンスの選択は、ハッシュキーに基づいて行われます。キーは、データ中心ルールに従って、受信される SIP および HTTP 要求から抽出されます。これらのルールは、LB ターゲットに配備されたすべてのアプリケーションに適用され、操作中に変更できます。そのような変更は、新規の初期要求のみに影響を及ぼします。
データ中心ルール言語は、要求をサーブレットにマッピングするためのトリガー言語に似ています。ルール言語は、SIP および HTTP キー抽出をサポートする変数および条件から構成されます。サーブレットマッピング言語と対照的に、データ中心ルールファイルは、non-null (true) または null (false) のいずれかの値を返す必要があります。
個々の受信される SIP および HTTP 要求は、現在のルールセットと合わされます。一致する最初のルールがキー抽出に使用されます。条件が non-null 値を返すまで、ルールは順次評価されます。OR 式の場合、最初の non-null sub-result が返されます。AND 式の場合、最後の sub-result が返されます。一致するルールがない場合、キーは null に設定されます。
HTTP 要求が DCR ファイルルールにまったく一致しない場合、ハッシュキーはリモートホストおよびポートを使用して生成されます。SIP 要求が DCR ファイルルールにまったく一致しない場合、ハッシュキーは from-tag,call-id を使用して生成されます。
次はデータ中心ルールファイルの例です。
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE user-centric-rules PUBLIC "-//Sun Microsystems Inc.//DTD Sailfin 1.0//EN" "http://www.sun.com/software/appserver/dtds/sun-data-centric-rule_1_0.dtd"> <user-centric-rules> <sip-rules> <if> <session-case> <equal>ORIGINATING</equal> <if> <header name="P-Asserted-Identity" return="request.P-Asserted-Identity.uri.resolve.user"> <exist/> </header> <if> <header name="P-Asserted-Identity" return="request.from.uri.resolve.user"> <notexist/> </header> <if> <header name="P-Asserted-Identity" return="request.to.uri.resolve.user"> <notexist/> </header> </if> </if> </if> </session-case> <else return="request.uri.resolve.user" /> </if> </sip-rules> <http-rules> <or> <request-uri return="match.resolve.user"> <match>/users/([^/]+)</match> </request-uri> <and> <request-uri> <match>^/css/</match> </request-uri> <or> <request-uri parameter="referredBy" return="parameter.requestUri.uri.resolve.user"> <exist/> </request-uri> <request-uri parameter="referredBy" return="parameter.from.uri.resolve.user"> <notexist/> </request-uri> </or> </and> </or> </http-rules> </data-centric-rules>
次の節では、data-centric-rules.xml ファイルの要素について説明します。
トップレベル要素は SIP/SIPS および HTTP/HTTPS 要求のルールを決定します。
これは data-centric-rules.xml ファイルのトップレベルまたはルート要素です。
次のサブ要素のいずれかまたは両方を指定できます: 「sip-rules」、「http-rules」
SIP および SIPS 要求のデータ中心ルールを決定します。
次のサブ要素はすべてオプションです。使用できる数および順序に制限はありません。
「or」、「and」、「if」、「header」、「request-uri」、「session-case」、「cookie」
HTTP および HTTPS 要求のデータ中心ルールを決定します。
次のサブ要素はすべてオプションです。使用できる数および順序に制限はありません。
「or」、「and」、「if」、「header」、「request-uri」、「session-case」、「cookie」
演算子要素は、複数のルール間での決定を指定します。 or、and、および if 要素は再帰的です。これらの要素の分岐およびレベルは、各分岐の最も低いレベルに「条件要素」の 1 つが含まれている限り、何個でも指定できます。
含まれている条件の少なくとも 1 つが non-null 値と評価されるときに限り、true と評価されます。
「sip-rules」、「http-rules」、「or」、「and」、「if」
次のサブ要素はすべてオプションです。使用できる数および順序に制限はありません。
「or」、「and」、「if」、「header」、「request-uri」、「session-case」、「cookie」
含まれている条件のすべてが non-null 値と評価されるときに限り、true と評価されます。
「sip-rules」、「http-rules」、「or」、「and」、「if」
次のサブ要素はすべてオプションです。使用できる数および順序に制限はありません。
「or」、「and」、「if」、「header」、「request-uri」、「session-case」、「cookie」
1 つの条件を含みます。条件が non-null 値と評価された場合、評価は if 分岐で続行されます。条件が null と評価された場合、評価はオプションの else 分岐で続行されます。
「sip-rules」、「http-rules」、「or」、「and」、「if」
次のサブ要素はすべてオプションです。使用できる数および順序に制限はありません。
「or」、「and」、「if」、「header」、「request-uri」、「session-case」、「cookie」
「else」 サブ要素はオプションです。指定する場合には、最後に置く必要があります。
親の if 要素の条件が null と評価された場合に、代替文を指定します。
次の属性が必須です。大文字と小文字は区別されます。
戻り値として評価される変数を指定します。「変数」を参照してください。
条件要素は、ルール決定の基になるデータの種類を指定します。すべての属性値は大文字と小文字が区別されます。
要求ヘッダーに基づいてルールを指定します。
「sip-rules」、「http-rules」、「or」、「and」、「if」
次のサブ要素が厳密に 1 つ必要です。
次の属性が必要です。
要求ヘッダーの名前を指定します。
戻り値として評価される変数を指定します。「変数」を参照してください。
要求 URI とそのパラメータに基づいてルールを指定します。
「sip-rules」、「http-rules」、「or」、「and」、「if」
次のサブ要素が厳密に 1 つ必要です。
次の属性は、サブ要素が exist または notexist である場合は必須で、サブ要素が match である場合はオプションです。
要求 URI パラメータを指定します。
戻り値として評価される変数を指定します。「変数」を参照してください。
SIP セッションの call パラメータに基づいてルールを指定します。IMS/3GPP (Internet Protocol Multimedia Subsystem Third Generation Partnership Project: インターネットプロトコルマルチメディアサブシステム / 第 3 世代移動体通信システムの標準化プロジェクト) 環境でのみ関連性があります。詳細は、「equal」 サブ要素の説明を参照してください。
「sip-rules」、「http-rules」、「or」、「and」、「if」
「equal」 サブ要素は必須で、先頭に置く必要があります。
次のサブ要素はすべてオプションです。使用できる数および順序に制限はありません。
「or」、「and」、「if」、「header」、「request-uri」、「session-case」、「cookie」
HTTP クッキーに基づいてルールを指定します。
「sip-rules」、「http-rules」、「or」、「and」、「if」
次のサブ要素が厳密に 1 つ必要です。
次の属性が必要です。
クッキーの名前を指定します。
戻り値として評価される変数を指定します。「変数」を参照してください。
条件型要素は要求データをルールによって予測されているデータと比較します。すべての比較で、大文字と小文字は区別されます。
要求に存在する header、 request-uri、または cookie として変数が評価されるように指定します。「変数」を参照してください。
「header」、「request-uri」、「cookie」
要求に存在しない header、 request-uri、または cookie として変数が評価されるように指定します。「変数」を参照してください。
「header」、「request-uri」、「cookie」
呼び出しのどの部分 (呼び出しの発信側または終端側) が処理されるかを指定します。 IMS/3GPP 環境でのみ関連性があります。指定できる値は次のとおりです。
EXTERNAL — SIP 要求にルートヘッダーがない、またはルートヘッダーに call パラメータがないことを指定します。
ORIGINATING — ルートヘッダーに call=orig が含まれることを指定します。
TERMINATING — ルートヘッダーに call=term_registered が含まれることを指定します。
TERMINATING_UNREGISTERED — ルートヘッダーに call=term_unregistered が含まれることを指定します。
request-uri が一致する必要のある正規表現を指定します。戻り値は、正規表現の前方参照を行うグループの一致です。正規表現の詳細については、http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/Pattern.html を参照してください。
match 要素では、オプションの接頭辞を戻り値に付加できます。
データ中心ファイルの name、parameter、および return 属性と 「exist」 および 「notexist」 要素では、変数が使用されます。 文字列 resolve を含む変数には、TEL URI の ENUM 検索を実行することで取得された値が含まれます。一部の変数には、置換可能なテキストが含まれます。たとえば、request. header 変数では、header は SIP または HTTP ヘッダーの名前に置き換えられます。SIP および HTTP 要求を一致させるための構文は多少異なります。
次の SIP 変数がサポートされます。
request.uri request.uri.scheme request.uri.user request.uri.host request.uri.port request.method request.uri.resolve request.uri.resolve.user request.uri.resolve.host request.header request.header.uri request.header.uri.scheme request.header.uri.user request.header.uri.host request.header.uri.port request.header.uri.display-name request.header.uri.resolve request.header.uri.resolve.user request.header.uri.resolve.host request.header.match request.header.match.resolve.user match match.resolve.user
次の HTTP 変数がサポートされます。
request.header request.header.uri request.header.uri.user request.header.uri.host request.header.uri.resolve request.header.uri.resolve.user request.header.uri.resolve.host parameter.parameter parameter.parameter.uri parameter.parameter.uri.user parameter.parameter.uri.host parameter.parameter.uri.resolve parameter.parameter.uri.resolve.user parameter.parameter.uri.resolve.host match match.resolve.user cookie.cookie-name
HTTP 変数 parameter. parameter.uri.resolve.user の解決は複雑です。この変数は HTTP 要求のパラメータ値と一致します。この値は 1 つの name-addr か、またはそのシーケンス (コンマ区切り) です。name-addr 要素は、使用可能なユーザー中心ハッシュキーが見つかるまで解決されます。分解の順序は次のとおりです。
name-addr に user=phone パラメータが含まれている場合、TEL URL として解決されます。それ以外の場合、URI のユーザー部が抽出されます。したがって、ENUM で解決できない電話番号エンティティーを指定している場合、または SIP URI にユーザー部がない場合、SIP URI の分解は失敗することがあります。
すべての SIP URI が考察された後、2 回目の試行が行われ、TEL URL は左から右に読み取られます。使用可能なユーザー中心キーが見つかった時点で、評価はただちに停止します。
分解がすべての試行で失敗した場合、ユーザー中心キーは見つかりません。HTTP 要求が DCR ファイルルールにまったく一致しない場合、ハッシュキーはリモートホストおよびポートを使用して生成されます。SIP 要求が DCR ファイルルールにまったく一致しない場合、ハッシュキーは from-tag,call-id を使用して生成されます。
たとえば、変数が parameter.from.uri.resolve.user で HTTP 要求が GET ...?...&from=...&...HTTP/1.1である場合、結果は次の表の値に基づきます。実際には、例示されている文字の一部は、URL エンコード処理の必要がある場合があります (例: < が %3C のように表示されることがある)。
表 2–3 from パラメータ値の例
from パラメータの値 |
ユーザー中心キー |
---|---|
<sip:server.xx.yy> |
なし |
<sip:alice@server.xx.yy> |
alice |
<tel:+1-333-555>,<sip:+1-22-22@server.xx.yy;user=phone> |
ENUM から |