[
"<p>batch サブシステムは、バッチアプリケーションを実行する環境を設定するために使用されます。</p>\n<p>${build.fullName} は\nバッチの実装に <a href=\"https://github.com/jberet/jsr352\" rel=\"nofollow\" target=\"_blank\">JBeret</a> を使用します。JBeret に関する情報は \n<a href=\"http://jberet.gitbooks.io/jberet-user-guide/content/\" rel=\"nofollow\" target=\"_blank\">ユーザーガイド</a> を参照してください。</p>\n",
"<p>Bean バリデーションは以下のような Java 仕様です: </p>\n<ul>\n    <li>アノテーションを用いてオブジェクトモデルで制約を表すことができます。</li>\n    <li>拡張可能な状態でカスタム制約を作成できます。</li>\n    <li>オブジェクトとオブジェクトグラフの検証に API を提供します。</li>\n    <li>メソッドおよびコンストラクターのパラメーターおよび戻り値の検証に API を提供します。</li>\n    <li>違反を報告します (ローカライズされます)。</li>\n    <li>Java SE を実行しますが、Java EE に統合されます (バージョン 6 および 7。Bean バリデーション 2.0 は Java EE 8 の一部となる予定です)。</li>\n</ul>\n<p>${build.fullName} はバッチの実装に <a href=\"http://hibernate.org/validator/\" rel=\"nofollow\" target=\"_blank\">Hibernate Validator</a> を使用します。</p>\n",
"<p>通常の 2 つのリソースタイプは、データソースおよび XA データソースと呼ばれます。</p>\n<ul>\n    <li><strong>非 XA データソース</strong> は、トランザクションを使用しないアプリケーションや、単一のデータベースでトランザクションを使用するアプリケーションに使用されます。</li>\n    <li><strong>XA データソース</strong> は、複数のデータベースにまたがってトランザクションが分散されるアプリケーションによって使用されます。XA データソースを使用すると追加のオーバーヘッドが発生します。</li>\n</ul>\n",
"<p>datasource サブシステムでは、データソースの作成および設定が可能で、JDBC データベースドライバーを管理できます。</p>\n<h2>データソース</h2>\n<p>通常の 2 つのリソースタイプは、データソースおよび XA データソースと呼ばれます。</p>\n<ul>\n    <li><strong>非 XA データソース</strong> は、トランザクションを使用しないアプリケーションや、単一のデータベースでトランザクションを使用するアプリケーションに使用されます。</li>\n    <li><strong>XA データソース</strong> は、複数のデータベースにまたがってトランザクションが分散されるアプリケーションによって使用されます。XA データソースを使用すると追加のオーバーヘッドが発生します。</li>\n</ul>\n<h2>JDBC ドライバー</h2>\n<p>アプリケーションがデータソースに接続できるようにするには、データソースベンダーの JDBC ドライバをインストールする必要があります。JDBC ドライバーのインストールする方法は 2 つあり、どちらかを選択できます。</p>\n<dl>\n    <dt>モジュール</dt>\n    <dd><p>JDBC ドライバーをモジュールとしてインストールするには、\n<code>${build.installDir}/modules</code> の下に ファイルパス構造を作成し、JDBC ドライバー JAR を \n<code>main/</code> サブディレクトリーに コピーして <code>module.xml</code> ファイルを作成する必要があります。</p>\n        <p>JDBC ドライバーをモジュールとして使用できるようになったら、このセクションを使用してドライバー設定を追加および削除できます。</p>\n    </dd>\n\n    <dt>デプロイメント</dt>\n    <dd>\n        <p>JDBC ドライバーは他のデプロイメント同様にデプロイできます。そのため、管理対象ドメインを使用する場合は、サーバーグループの複数のサーバーにまたがってデプロイすることができます。JDBC 4 対応のドライバーは自動的に認識され、名前とバージョンでシステムにインストールされます。</p>\n        <p>ドメインモードでは、選択したプロファイルと一致する稼働中のサーバーがある場合に、アプリケーションとしてデプロイされたドライバーのみがこのセクションに表示されます。</p>\n    </dd>\n</dl>\n",
"<p>デプロイメントスキャナーはスタンドアロンモードでのみ使用されます。デプロイメントスキャナーの役割は、新しいファイルのディレクトリーを監視し、これらのファイルをデプロイすることです。</p>\n<p>deployment-scanner エントリーを追加で定義すると、より多くの場所からデプロイメントをスキャンできます。</p>\n",
"<p>distributable-web サブシステムは、分散可能セッションマネージャーの設定をカプセル化するセッション管理プロファイルのセットを管理します。これらのプロファイルの 1 つはデフォルトのプロファイルとして指定される (\"default-session-management\" 属性より) ため、分散可能 Web アプリケーションのデフォルト動作を定義します。</p>\n<p>デフォルトのセッション管理は Web セッションデータを Infinispan キャッシュ内に格納します。</p>\n",
"<p>全体のシステム設定。サーバーグループへ適用できるメイン設定プロファイルへのアクセスを提供します。</p>\n\n<p>利用可能な各 <strong>サブシステム</strong> の設定を表示および編集します。たとえば、データソースの追加、メッセージングプロバイダーの設定、またはアプリケーションセキュリティーの設定を行います。</p>\n\n<p>関連リンク</p>\n<ul>\n    <li><a href=\"#runtime\">ドメインランタイム</a></li>\n</ul>",
"<p>EE サブシステムは、EE Concurrency Utilities (JSR 236) や <code>@Resource</code> のインジェクションなど、Java EE プラットフォームで共通する機能を提供します。このサブシステムは、Java EE アプリケーションのデプロイメントのライフサイクルも管理します (.ear ファイル)。</p>\n<p>EE サブシステムは以下に使用できます:</p>\n<ul>\n    <li>Java EE アプリケーションのデプロイメントの動作をカスタマイズできるようにします。</li>\n    <li>グローバルモジュールの管理: 各 Java EE デプロイメントの JBoss Module に依存関係として追加される JBoss モジュールのセット。このような依存関係により、Java EE デプロイメントはグローバルモジュールによってエクスポートされたクラスを認識できます。</li>\n    <li>EE Concurrency Utilities (JSR 236) の管理: マルチスレッドの Java EE アプリケーションの書き込みを容易にするため、Java EE 7 で導入されました。これらのユーティリティーのインスタンスは ${build.fullName} と、EE サブシステムによって提供される関連設定によって管理されます。</li>\n</ul>",
"<p>エンタープライズ Bean は、Enterprise JavaBeans (EJB) 3.1 仕様の JSR-318 に定義されているサーバー側のアプリケーションコンポーネントです。エンタープライズ Bean は、再使用を推奨するために、分離されたアプリケーションビジネスロジックの実装向けに設計されています。\n    エンタープライズ Bean は Java クラスとして記述され、適切な EJB アノテーションが追加されます。エンタープライズ Bean は独自のアーカイブ (JAR ファイル) でアプリケーションサーバーにデプロイするか、Java EE アプリケーションの一部としてデプロイすることが可能です。アプリケーションサーバーは各エンタープライズ Bean のライフサイクルを管理し、セキュリティー、トランザクション、および同時実行管理などのサービスを提供します。\n    エンタープライズ Bean はビジネスインターフェースをいくつでも定義することも可能です。ビジネスインターフェースを使用すると、クライアントが利用できる Bean のメソッドをより確実に制御でき、リモート JVM で稼働しているクライアントへのアクセスも許可できます。\n    エンタープライズ Bean には、セッション Bean、メッセージ駆動型 Bean、およびエンティティー Bean の 3 種類があります。</p>\n\n<h2>セッション Bean</h2>\n<p>セッション Bean は、関連するビジネスプロセスやタスクのセットをカプセル化し、それらをリクエストしたクラスにインジェクトするエンタープライズ Bean です。セッション Bean には、ステートレス、ステートフル、およびシングルトンの 3 種類があります。</p>\n\n<h2>メッセージ駆動型 Bean</h2>\n<p>メッセージ駆動型 Bean (MDB) は、アプリケーションの開発にイベント駆動型モデルを提供します。JDB のメソッドは、クライアントコードへはインジェクトされず、クライアントコードから呼び出しされませんが、Java Messaging Service (JMS) サーバーなどのメッセージングサービスからメッセージが受信されるとトリガーされます。Java EE 6 仕様は、JMS のサポートを必要としますが、他のメッセージングシステムをサポートすることもできます。</p>\n\n<h2>エンティティ Bean</h2>\n<p>エンティティー Bean は EJB 3.1 で非推奨となり、JPA エンティティーの使用が推奨されるようになりました。エンティティー Bean は、レガシーシステムとの後方互換性を維持する場合のみ使用してください。</p>",
"<h2>ファクトリー</h2>\n<p>認証ファクトリーは、特定の認証メカニズムに使用される認証ポリシーです。認証ファクトリーは、http-authentication-factory、sasl-authentication-factory、kerberos-security-factory など、認証メカニズムを基にしています。</p>\n<h2>プリンシパルトランスフォーマー</h2>\n<p>プリンシパルトランスフォーマーは、elytron サブシステム内の複数の場所で使用できます。プリンシパルトランスフォーマーは名前を別の名前に変換またはマップできます。</p>\n",
"<h2>ロールマッパー</h2>\n<p>ロールマッパーはロールの変更をアイデンティティーに適用します。これは、ロールの形式の正規化から特定ロールの追加や削除までさまざまです。ロールマッパーはセキュリティーレルムとセキュリティードメインの両方に関連付けることができます。</p>\n<h2>パーミッションマッパー</h2>\n<p>パーミッションマッパーはセキュリティードメインと関連付けられ、パーミッションを SecurityIdentity に割り当てます。</p>\n<h2>プリンシパルデコーダー</h2>\n<p>プリンシパルデコーダーは、 elytron サブシステム内の複数の場所で使用できます。プリンシパルデコーダーはアイデンティティーを Principal から名前の文字列表現に変換します。たとえば、X500PrincipalDecoder を使用すると X500Principal を証明書の識別名から文字列表現に変換できます。</p>\n<h2>ロールデコーダー</h2>\n<p>ロールデコーダーはセキュリティードメインに関連付けられ、現ユーザーのロールをデコードするために使用されます。ロールデコーダーは、セキュリティーレルムから返される未処理の AuthorizationIdentity を取り、その属性をロールに変換します。</p>\n\n",
"<p>このセクションは以下の説明どおりに複数のリソースから構成されます。</p>\n<h2>認証の設定</h2>\n<p>リモート接続の確立時、認証用に ${build.fullName} およびその他のリソースにデプロイされたクライアントによって使用される個別の認証設定定義。</p>\n<h2>認証コンテキスト</h2>\n<p>${build.shortName} およびその他のリソースにデプロイされたクライアントがリモート接続を確立するときに ssl-context および authentication-configuration を提供するために使用される個別の認証コンテキスト定義。</p>\n<h2>ストア</h2>\n<p>キーストアはキーストアの種類、その場所、およびアクセスするためのクレデンシャルが含まれるキーストアまたはトラストストアの定義です。クレデンシャルストアは、外部サービスのパスワードなどの機密性の高い情報のエイリアスを保持します。</p>\n<h2>SSL</h2>\n<p>SSL 接続のクライアントおよびサーバー側を設定します。SSL コンテキストの作成に使用されるキーマネージャーリストを作成するためのキーマネージャー定義。利用可能なその他のリソース: Security プロパティー、Provider ローダー、Aggregate プロバイダー。</p>\n<h2>セキュリティードメイン</h2>\n<p>セキュリティードメインは、1 つ以上のセキュリティーレルムや変換を実行するリソースのセットが関係するセキュリティーポリシーを表します。</p>\n<h2>ログ</h2>\n<p>ファイルまたは syslog で永続する監査ロガー。</p>\n",
"<h2>セキュリティーレルム</h2>\n<p>セキュリティーレルムはアイデンティティーストアへのアクセスを提供し、クレデンシャルの取得に使用されます。これらのクレデンシャルにより、認証メカニズムは認証を実行するために未処理の AuthorizationIdentity を取得できます。</p>\n<h2>レルムマッパー</h2>\n<p>レルムマッパーはセキュリティードメインと関連付けられ、セキュリティードメインに複数のセキュリティーレルムが設定されている場合に使用されます。レルムマッパーは、認証中に提供された名前を使用して認証のセキュリティーレルムを選択します。</p>\n",
"<p>Common Object Request Broker Architecture (CORBA) は、アプリケーションとサービスが複数の互換性がない言語で記述され、異なるプラットフォームでホストされる場合でも、アプリケーションとサービスが連携することを可能にする標準です。CORBA のリクエストは Object Request Broker (ORB) というサーバーサイドコンポーネントが仲介します。${build.shortName} は、Open JDK ORB コンポーネントを用いて ORB インスタンスを提供します。</p>\n",
"<p>Infinispan は Java データグリッドプラットフォームです。キャッシュされた データの管理に <a href=\"http://www.jcp.org/en/jsr/detail?id=107\">JSR-107</a> 準拠のキャッシュインターフェースを提供します\n</p>\n<p>以下の Infinispan キャッシュコンテナーが ${build.fullName} で使用されます:</p>\n<ul>\n    <li>Web セッションクラスタリング用の <code>web</code></li>\n    <li>ステートフルセッション Bean クラスタリング用の <code>ejb</code></li>\n    <li>エンティティーキャッシング用の <code>hibernate</code></li>\n    <li>シングルトンキャッシング用の <code>singleton</code></li>\n</ul>\n<p>各キャッシュコンテナーは「repl」および「dist」キャッシュを定義します。これらのキャッシュは、ユーザーアプリケーションによって直接使用されてはなりません。</p>\n\n<p>Infinispan の機能と設定オプションに関する詳細は、\n<a href=\"http://infinispan.org/docs/5.3.x/index.html\">Infinispan ドキュメント</a> を参照してください。</p>\n\n<h2>クラスタリングモード</h2>\n<p>${build.shortName} で Infinispan を使用すると、2 つの方法でクラスタリングを設定できます。ご使用のアプリケーションに適した方法は要件によって異なります。各モードでは可用性、一貫性、信頼性、およびスケーラビリティーのトレードオフが発生します。クラスタリングモードを選択する前に、ネットワークで最も重要な点を特定し、これらの要件のバランスを取ることが必要となります。</p>\n\n<h3>レプリケーションモード</h3>\n<p>Replicated モードはモードはクラスターの新しいインスタンスを自動的に検出し、追加します。これらのインスタンスに加えられた変更は、クラスター上のすべてのノードにレプリケートされます。ネットワークでレプリケートされる情報量が多いため、通常レプリケートモードは小型のクラスターでの使用に最も適しています。UDP マルチキャストを使用するよう Infinispan を設定すると、ネットワークトラフィックの輻輳をある程度軽減できます。</p>\n\n<h3>分散モード</h3>\n<p>Distribution モードでは、Infinispan はクラスターを線形にスケールできます。Distribution モードは一貫性のあるハッシュアルゴリズムを使用して、クラスター内で新しいノードを配置する場所を決定します。保持する情報のコピー数 (または所有者数) は設定可能です。保持するコピー数、データの永続性、およびパフォーマンスにはトレードオフが生じます。保持するコピー数が多いほどパフォーマンスへの影響が大きくなりますが、サーバーの障害時にデータを損失する可能性は低くなります。ハッシュアルゴリズムは、メタデータのマルチキャストや保存を行わずにエントリーを配置し、ネットワークトラフィックを軽減します。\n</p>\n<p>クラスターサイズが 6-8 ノードを超える場合は Distribution (dist) モードをキャッシュストラテジーとして使用するよう考慮してください。デフォルトの Replicated モードではデータはクラスター内のすべてのノードで分散されますが、Distribution モードではノードのサブセットのみに分散されます。\n</p>\n\n<h3>同期および非同期のレプリケーション</h3>\n<p>レプリケーションは同期または非同期モードのいずれかで実行でき、要件とアプリケーションの応じてモードが選択されます。同期レプリケーションでは、ユーザーのリクエストを処理するスレッドはレプリケーションが正常に終了するまでブロックされます。レプリケーションに成功した場合のみ応答がクライアントに返信され、スレッドが開放されます。同期レプリケーションはクラスターの各ノードからの応答を必要とするため、ネットワークトラフィックに影響を与えます。ただし、クラスターのすべてのノードへ確実に変更が加えられる利点があります。</p>\n<p>非同期レプリケーションはバックグラウンドで実行されます。Infinispan は、バックグラウンドスレッドがレプリケーションの実行に使用するレプリケーションキューを実装します。レプリケーションは、時間ベースまたはキューのサイズのいずれかによってトリガーされます。アプリケーションキューを使用すると、クラスターノード間で対話が行われないため、パフォーマンスを向上することができます。非同期レプリケーションの難点は、精度が低いことです。実行に失敗したレプリケーションはログに書き込まれ、リアルタイムでは通知されません。</p>\n\n<h2>キャッシュコンテナー</h2>\n<p>キャッシュコンテナーはサブシステムによって使用されるキャッシュのリポジトリーです。Infinispan では、デフォルトキャッシュコンテナーは設定 xml ファイルで定義されます。1 つのキャッシュがデフォルトキャッシュとして定義され、そのキャッシュがクラスタリングに使用されます。</p>\n",
"<p>ソケットのバインド先となるネットワークインターフェース / IP アドレス / ホスト名の論理名。 <code>domain.xml</code>、<code>host.xml</code>、および <code>standalone.xml</code> の設定にはすべてインターフェースを宣言できるセクションが含まれます。設定のその他のセクションは、マシンによって異なる可能性があるインターフェースの完全な詳細を含める代わりに、論理名を使用してこれらのインターフェースを参照できます。</p>\n\n<p>インターフェースの設定には、インターフェースの論理名と、使用する実際の物理アドレスを解決するために使用する基準を指定する情報が含まれます。</p>",
"<p>IO サブシステムは、Undertow や Remoting などの他のサブシステムによって使用される XNIO ワーカーおよびバッファープールを定義します。</p>\n<h2>ワーカー</h2>\n<p>ワーカーは XNIO ワーカーインスタンスです。XNIO ワーカーインスタンスは、IO およびワーカースレッドの管理や SSL サポートなどの機能を提供する Java NIO API の抽象化レイヤーです。デフォルトでは、${build.shortName} は <code>default</code> という単一のワーカーを提供しますが、複数のワーカーを定義できます。</p>\n<h2>バッファープール</h2>\n<p>バッファープールはプールされた NIO バッファーインスタンスです。</p>\n<p><strong>重要:</strong><br/> \nバッファーサイズの変更はアプリケーションのパフォーマンスに大きく影響します。通常、ほとんどのサーバーでは 16k が理想のサイズになります。\n</p>",
"<p>JAX-RS サブシステムは、JAX-RS アプリケーションのデプロイメントおよび機能を有効にするために使用されます。</p>\n<p>${build.fullName} は \nJAX-RS 実装に <a href=\"http://resteasy.jboss.org/\" rel=\"nofollow\" target=\"_blank\">RESTEasy</a> を使用します。</p>",
"<p>Java EE Connector Architecture (JCA) は外部にある異種のエンタープライズ情報システム (EIS) に対して Java EE システムの標準アーキテクチャーを定義します。EIS の例として、 エンタープライズリソースプランニング (ERP) システム、メインフレームトランザクション処理 (TP)、データベース、メッセージングシステムなどが挙げられます。リソースアダプターは Java EE Connector API アーキテクチャーを実装するコンポーネントです。</p>\n<p>データソースオブジェクトと似ていますが、JCA 1.7 は以下を管理する機能を提供します。</p>\n<ul>\n    <li>connections</li>\n    <li>transactions</li>\n    <li>セキュリティー</li>\n    <li>life-cycle</li>\n    <li>work instances</li>\n    <li>transaction inflow</li>\n    <li>message inflow</li>\n</ul>\n<p>JCA 1.7 は Java Community Process で \n<a href=\"https://www.jcp.org/en/jsr/detail?id=322\" rel=\"nofollow\" target=\"_blank\">JSR-322</a> として開発されました。</p>\n\n<h2>リソースアダプター</h2>\n<p>リソースアダプターは、 Java Connector Architecture (JCA) 仕様を使用して Java EE アプリケーションとエンタープライズ情報システム (EIS) との間の通信を提供するデプロイ可能な Java EE コンポーネントです。EIS ベンダーの製品と Java EE アプリケーションの統合を容易にするため、リソースアダプターは通常 EIS ベンダーによって提供されます。</p>\n<p>エンタープライズ情報システムは、組織内における他のあらゆるソフトウェアシステムのことです。例としては、エンタープライズリソースプランニング (ERP) システム、データベースシステム、電子メールサーバー、商用メッセージングシステムなどが挙げられます。</p>\n<p>リソースアダプターは、${build.shortName} にデプロイできる Resource Adapter Archive (RAR) ファイルでパッケージ化されます。また、RAR ファイルは、Enterprise Archive (EAR) デプロイメントにも含めることができます。</p>\n",
"<p>アプリケーションがデータソースに接続できるようにするには、データソースベンダーの JDBC ドライバをインストールする必要があります。JDBC ドライバーのインストールする方法は 2 つあり、どちらかを選択できます。</p>\n<dl>\n    <dt>モジュール</dt>\n    <dd><p>JDBC ドライバーをモジュールとしてインストールするには、\n<code>${build.installDir}/modules</code> の下に ファイルパス構造を作成し、JDBC ドライバー JAR を \n<code>main/</code> サブディレクトリーに コピーして <code>module.xml</code> ファイルを作成する必要があります。</p>\n        <p>JDBC ドライバーをモジュールとして使用できるようになったら、このセクションを使用してドライバー設定を追加、編集、および削除できます。</p>\n    </dd>\n\n    <dt>デプロイメント</dt>\n    <dd>\n        <p>JDBC ドライバーは他のデプロイメント同様にデプロイできます。そのため、管理対象ドメインを使用する場合は、サーバーグループの複数のサーバーにまたがってデプロイすることができます。JDBC 4 対応のドライバーは自動的に認識され、名前とバージョンでシステムにインストールされます。</p>\n        <p>ドメインモードでは、選択したプロファイルと一致する稼働中のサーバーがある場合に、アプリケーションとしてデプロイされたドライバーのみがこのセクションに表示されます。</p>\n    </dd>\n</dl>\n",
"<p>トラブルシューティングに役立つ診断データの収集を有効にします。${build.shortName} のサブスクライバーはサポートをリクエストするときにこの情報を Red Hat に提供できます。</p>",
"<p>JGroups は信頼できるメッセージングのためのツールキットで、お互いにメッセージを送信するノードを持つクラスターを作成するために使用できます。</p>\n<p>    <code>jgroups</code> サブシステムは ${build.shortName} で高可用性サービスのグループ通信サポートを提供します。これにより、名前付きのチャネルおよびプロトコルスタックを設定でき、チャネルのランタイム統計を表示することもできます。\n<code>jgroups</code> サブシステムは高可用性の機能を提供する設定を使用する場合に使用できます \n(管理対象ドメインでは <i>ha</i> または <i>full-ha</i> プロファイル、スタンドアロンサーバーは <code>standalone-ha.xml</code> または <code>standalone-full-ha.xml</code> 設定ファイルなど)。</p>\n<p>${build.shortName} には 2 つの JGroups スタックが事前に設定されています。</p>\n<dl>\n    <dt>udp</dt>\n    <dd>クラスターのノードは UDP (User Datagram Protocol) マルチキャストを使用してお互いに通信します。これはデフォルトのスタックです。</dd>\n    <dt>tcp</dt>\n    <dd>クラスターのノードは TCP (Transmission Control Protocol) を使用してお互いに通信します。</dd>\n</dl>\n<p>事前設定されたスタックを使用できますが、システムの要件に合うよう独自に定義することもできます。</p>\n<p><strong>注記:</strong><br/> \nTCP はエラーのチェック、パケットの順番、および輻輳制御を処理するため、TCP のオーバーヘッドは UDP よりも大きく、速度も遅くなると考えられます。JGroups は UDP のこれらの機能を処理しますが、TCP はこれらの機能を独自で処理します。信頼できないネットワークや輻輳度の高いネットワークで JGroups を使用する場合やマルチキャストが使用できない場合は、TCP を選択するとよいでしょう。\n</p>\n",
"<p>リモート JMX (Java Management Extensions) のアクセスを設定します。</p>\n<p>JMX サブシステムは Remoting エンドポイントでサービスを登録するため、JMX へのリモートアクセスは公開された Remoting コネクター上で取得できます。</p>\n<p>これは、スタンドアロンモードではデフォルトで有効になっており、9990 番ポート上でアクセス可能ですが、ドメインモードでは無効になっているため、有効にする必要があります。ドメインモードでのポートは、${build.fullName} インスタンスが監視される Remoting コネクターのポートになります。</p>\n",
"<p>JPA (Java Persistence API) 2.1 のコンテナ管理の要件を管理し、永続ユニットの定義、アノテーション、および記述子のデプロイを可能にします。</p>\n<p>Java Persistence API (JPA) は、Java オブジェクトまたはクラスとリレーショナルデータベースとの間でデータをアクセス、永続化、および管理する Java 仕様です。JPA 仕様は透過的なオブジェクトまたはリレーショナルマッピングパラダイムの興味と成功を認識します。これは、オブジェクトまたはリレーショナル永続メカニズムに必要な基本的な API およびメタデータを標準化します。</p>",
"<p>JSF (JavaServer Faces) 実装を管理します。</p>",
"<p>    <a href=\"https://jcp.org/en/jsr/detail?id=77\" rel=\"nofollow\" target=\"_blank\">JSR-77</a> 仕様によって定義される Java EE 管理機能を提供します。</p>",
"<p>logging サブシステムは、内部使用とデプロイされたアプリケーションによる使用の両方で容易に設定できるロギング機能を提供します。JBoss LogManager を基盤とし、JBoss Logging だけでなくサードパーティーアプリケーションのロギングフレームワークを複数サポートします。</p>\n\n<p>logging サブシステムは、ログカテゴリーおよびログハンドラーのシステムを使用して設定されます。ログカテゴリーはキャプチャーするメッセージを定義し、ログハンドラーはこれらのメッセージの処理方法 (ディスクへの書き込み、コンソールへの送信など) を定義します。</p>\n\n<p>ロギングプロファイルは、一意な名前が付けられたロギング設定の作成や、他のロギング設定に関係しないアプリケーションへの割り当てを可能にします。ロギングプロファイルの設定は、メインの logging サブシステムとほぼ同じです。</p>",
"<p>logging サブシステムは、ログカテゴリーおよびログハンドラーのシステムを使用して設定されます。ログカテゴリーはキャプチャーするメッセージを定義し、ログハンドラーはこれらのメッセージの処理方法 (ディスクへの書き込み、コンソールへの送信など) を定義します。</p>\n",
"<p>ロギングプロファイルは、一意な名前が付けられたロギング設定の作成や、他のロギング設定に関係しないアプリケーションへの割り当てを可能にします。ロギングプロファイルの設定は、メインの logging サブシステムとほぼ同じです。</p>",
"<p>Mail サブシステムでは、mail-session と呼ばれる個別のメール設定を指定できます。メールセッションでは、IMAP、POP、および SMTP の 3 種類のサーバーのみを使用できます。</p>\n<p>各サービスは既存のアウトバウンドソケットバインディング <code>outbound-socket-binding</code> を参照します (<a href=\"#configuration;path=configuration%255C2socket-bindings\">ソケットバインディンググループ</a> を確認してください)。</p>\n",
"<h2>Apache ActiveMQ Artemis</h2>\n<p>Apache ActiveMQ Artemis は非同期メッセージングシステムのオープンソースプロジェクトです。Apache ActiveMQ Artemis はパフォーマンスに優れ、埋め込み可能でクラスター化され、複数のプロトコルをサポートします。${build.shortName} は Apache ActiveMQ Artemis をJMS ブローカーとして使用し、messaging-activemq サブシステムを使用して設定されます。これによって HornetQ ブローカーは完全に置き換えられますが、以前のバージョンとのプロトコルの互換性を維持します。</p>\n\nコア ActiveMQ Artemis は JMS にとらわれず、コア API と呼ばれる非 JMS API を提供します。ActiveMQ Artemis は、ファサード層を使用して JMS セマンティックをコア API の上部に実装する JMS クライアント API も提供します。基本的に、JMS の対話は JMS クライアント API を使用してクライアント側でコア API 操作に変換されます。すべての操作は、コアクライアント API および Apache ActiveMQ Artemis ワイヤ形式を使用して、そこから送信されます。サーバー自体はコア API のみを使用します。コア API とその概念に関する詳細は、 <a target=\"_blank\" href=http://activemq.apache.org/artemis/docs/1.1.0/using-core.html\">ActiveMQ Artemis のドキュメント</a> を参照してください。\n",
"<p>${build.shortName} メッセージングクラスターは、メッセージ処理の負荷を共有するために ${build.shortName} メッセージングサーバーのグループ化を可能にします。クラスターのアクティブな各ノードは、アクティブな ${build.shortName} メッセージングサーバーで、独自のメッセージを管理し、独自の接続を処理します。</p>\n\n<p>クラスターは、${build.shortName} 設定ファイルで他のノードへのクラスター接続を宣言する各ノードによって形成されます。ノードが別のノードへのクラスター接続を形成すると、それらのノード間のコア api 接続を内部的に作成します。これは背後で透過的に行われ、各ノードに対して api を明示的に宣言する必要はありません。これらのクラスター接続は、クラスターのノード間でメッセージを移動し、負荷を分散できるようにします。</p>\n\n<p>クラスターに関する詳細情報は、 \n<a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-28-clusters-overview\">Clusters Overview</a> を参照してください。\n</p>\n\n<p>本セクションには以下のトピックの設定が含まれます。</p>\n<ul>\n    <li>ブロードキャストグループ</li>\n    <li>ディスカバリーグループ</li>\n    <li>クラスター接続</li>\n    <li>グルーピングハンドラー</li>\n    <li>コアブリッジ</li>\n</ul>\n\n<h2>ブロードキャストグループ</h2>\n<p>ブロードキャストグループとは、サーバーがネットワーク上でコネクターをブロードキャストする手段です。コネクターは、クライアントまたはその他のサーバーがサーバーへの接続を確立する方法を定義します。</p>\n\n<p>ブロードキャストグループは、コネクターのセットをネットワーク上でブロードキャストします。クラスターに設定したブロードキャストの技術に応じて、UDP または JGroups を使用してコネクターペアの情報をブロードキャストします。</p>\n\n<p>ブロードキャストグループは、サーバー設定の messaging-activemq サブシステムで定義されます。${build.shortName} メッセージングサーバーごとに多くのブロードキャストグループが存在することもあります。</p>\n\n<h2>ディスカバリーグループ</h2>\n<p>ブロードキャストグループはサーバーからコネクター情報をブロードキャストする方法を定義しますが、ディスカバリーグループは UDP マルチキャストアドレスや JGroups チャネルなどのブロードキャストエンドポイントからコネクター情報を受信する方法を定義します。</p>\n\n<p>ディスカバリーグループは、各サーバーの各ブロードキャストごとに 1 つのコネクターリストを保持します。特定のサーバーからブロードキャストエンドポイントでブロードキャストを受信すると、そのサーバーのリストのエントリーを更新します。特定のサーバーからブロードキャストを長時間受信しないと、そのリストからサーバーのエントリーを削除します。</p>\n\n<h2>クラスター接続</h2>\n<p>クラスター接続は、サーバーとクラスターにグループ化し、クラスターのノード間でメッセージの負荷を分散できるようにします。クラスター接続は、${build.shortName}cluster-connection${build.shortName} 要素を使用して <code> サーバー設定で定義されます。${build.shortName} メッセージングサーバーごとに 0 以上のクラスター接続を定義できます。\n</p>\n\n<h2>グルーピングハンドラー</h2>\n<p>クラスターでは、特定のグループ id を持つメッセージグループはどのノードにも到達できます。どのグループ id がどのノードでどのコンシューマーにバインドされるかをノードが判断することが重要になります。デフォルトでメッセージグループが到達する場所に関係なく、各ノードはメッセージグループをグループ id を処理するコンシューマーを持つノードへ適切にルーティングします。あるグループ id を持つメッセージがあるノードに接続する特定のコンシューマーに送信されると、コンシューマーの接続が切断されてもこれらのメッセージは他のノードには送信されません。</p>\n\n<p>この状態は、グルーピングハンドラーによって対処されます。各ノードはグルーピングハンドラーを持ち、このグルーピングハンドラー (およびその他のハンドラー) はメッセージンググループを適切なノードにルーティングします。</p>\n\n<h2>コアブリッジ</h2>\n<p>api には、1 つの宛先からメッセージを消費し、それらのメッセージを別の宛先 (一般的に異なる ${build.shortName} メッセージングサーバーにある) に転送する機能があります。</p>\n\n<p>ソースおよびターゲットアーバーは同じクラスターに存在する必要はないため、WAN や接続の信頼性を欠くインターネット上などで 1 つのクラスターから別のクラスターへ確実にメッセージを送信するには、ブリッジングの使用が適しています。</p>\n\n<p>api は障害に対する復元性を備えているため、ネットワーク障害などの理由でターゲットサーバーの接続が失われると、api はターゲットサーバーがオンライン状態に戻るまで接続を試みます。オンラインになったら、操作を通常どおり再開します。</p>\n\n<p>ブリッジは、2 つの ${build.shortName} メッセージングサーバーを確実に接続する方法です。コア api ではソースおよびターゲットサーバーの両方が ${build.shortName} メッセージングサーバーである必要があります。</p>\n",
"<p>以下のトピックの設定が含まれます。</p>\n<ul>\n    <li>アクセプターおよびコネクター</li>\n    <li>コネクターサービス</li>\n    <li>(プールされた) 接続ファクトリー</li>\n</ul>\n\n<h2>アクセプターおよびコネクター</h2>\n<p>アクセプターは、${build.shortName} 埋め込みのメッセージングサーバーによって許可される接続の種類を定義します。サーバーごとに任意の数のアクセプターを定義できます。</p>\n\n<p>コネクターは、${build.shortName} 埋め込みメッセージングサーバーへ接続する方法を定義し、接続を確立するためにクライアントによって使用されます。</p>\n\n<p>アクセプターおよびコネクターの詳細は \n<a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-8-configuring-the-messaging-transports\">アクセプターおよびコネクターの項</a> を参照してください。\n</p>\n\n<h2>コネクターサービス</h2>\n<p>コネクターサービスを使用して外部コンポーネントと Apache ActiveMQ Artemis を統合し、メッセージの送受信ができるようになります。</p>\n\n<h2>接続ファクトリー</h2>\n<p>デフォルトでは、${build.shortName} messaging サブシステムは <code>InVmConnectionFactory</code> および \n<code>RemoteConnectionFactory</code> 接続ファクトリーを提供し、さらに プールされた \n<code>activemq-ra</code> 接続ファクトリーも提供します。</p>\n\n<p><code>InVmConnectionFactory</code> は <code>in-vm-connector</code> を参照し、クライアントとサーバーの両方が同じ JVM で実行されている場合にメッセージの送受信に使用できます。 <code>RemoteConnectionFactory</code> は <code>http-connector</code> を参照し、クライアントとサーバーが異なる JVM で実行されている場合に HTTP 上でのメッセージの送受信に使用できます。\n</p>\n\n<p>プールされた接続ファクトリーでは、統合された ActiveMQ Artemis リソースアダプターのインバウンドおよびアウトバウンド接続を設定できます。pooled-connection-factory を設定してリモート ActiveMQ Artemis サーバーに接続する方法は \n<a target=\"_blank\" href=\"https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html/configuring_messaging/resource_adapters#use_provided_amq_adapter\">Using the Integrated Resource Adapter for Remote Connections</a> を参照してください。\n</p>\n",
"<p>以下のトピックの設定が含まれます。</p>\n<ul>\n    <li>コアキュー</li>\n    <li>JMS 宛先</li>\n    <li>セキュリティー設定</li>\n    <li>アドレス設定</li>\n    <li>迂回 (Divert)</li>\n</ul>\n\n<h2>コアキュー</h2>\n<p>Apache ActiveMQ Artemis コアは JMS に依存せず、JMS トピックの概念はありません。JMS トピックはアドレス (トピック名) としてコアに実装され、0 以上のキューがバインドされます。そのアドレスにバインドされた各キューは、トピックサブスクリプションを表します。同様に、JMS キューはアドレス (JMS キュー名) として実装され、JMS キューを表す 1 つのキューにバインドされます。 </p>\n\n<p>慣例では、すべての JMS キューはコアキューにマップされ、コアキュー名の最初に文字列「 jms.queue.」が追加されます。たとえば、「orders.europe」という名前の JMS キューは「jms.queue.orders.europe」という名前のコアキューにマップされます。コアキューがバインドされるアドレスもコアキュー名によって付与されます。</p>\n\n<p>JMS トピックでは、サブスクリプションを表すキューがバインドされるアドレスは、文字列「jms.topic.」を JMS トピック名の最初に追加して付与されます。たとえば、「news.europe」という名前の JMS トピックは、コアアドレス 「jms.topic.news.europe 」にマップします。</p>\n\n<h2>JMS 宛先</h2>\n<p>JMS 宛先や JMS 接続ファクトリーは JMS 管理オブジェクトです。宛先は、メッセージを生成および消費するために JMS クライアントによって使用されます。宛先は、JMS クライアントがメッセージの生成時にターゲットを指定できるようにし、メッセージの消費時にメッセージのソースを生成できるようにします。パブリッシュ-サブスクライブパターンを使用する場合、宛先はトピックとして見なされます。ポイントツーポイントパターンを使用する場合、宛先はキューとして見なされます。</p>\n\n<p>アプリケーションは、サーバー側に設定され、通常は JNDI 経由でアクセスされる、多くの異なる JMS 宛先を使用することがあります。</p>\n\n<h2>セキュリティー設定</h2>\n<p>セキュリティー設定は、特定の宛先周囲のセキュリティーを設定するために使用されます。これは、security-setting 設定要素を使用して、セキュリティー制約を追加して行われます。${build.shortName} メッセージングにはデフォルトで設定された <code>security-setting</code> が含まれます。</p>\n\n<p>security-setting オプションは、ワイルドカードを利用して、どの宛先にセキュリティー制約を適用するかを処理します。単一の <code>#</code> パターンはすべてのアドレスと一致します。セキュリティー制約でワイルドカードを使用する詳細は、 <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-7-configuring-security#role_based_security_for_address\">Role Based Security for Addresses</a> を参照してください。\n</p>\n\n<h2>アドレス設定</h2>\n<p>messaging-activemq サブシステムには、メッセージの配信時および配信方法、試行回数、およびメッセージの失効時を制御する複数の設定可能なオプションがあります。これらの設定オプションは、すべて <code>&lt;address-setting></code> 設定要素内に存在します。 ワイルドカード構文を使用すると、${build.shortName} は 1 つの <code>&lt;address-setting></code> を複数の宛先に適用できます。</p>\n\n<p>アドレス設定におけるワイルドカードの使用に関する詳細は「<a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-6-address-settings\">Wildcard Syntax</a>」を参照してください。\n</p>\n\n<h2>迂回 (Divert)</h2>\n<p>迂回 (Divert) は、メッセージがあるアドレスから別のアドレスに迂回できるようにする、${build.shortName} メッセージングに設定されたオブジェクトです。迂回は以下の種類に分類されます。\n\n<dl>\n    <dt>排他的</dt>\n    <dd>メッセージは新しいアドレスにのみ迂回され、古いアドレスには送信されません。</dd>\n    <dt>非排他的</dt>\n    <dd>メッセージは古いアドレスに送信され、そのコピーは新しいアドレスに送信されます。非排他的な迂回は、メッセージの流れの分割に使用できます。</dd>\n</dl>\n\n<p>メッセージは同じサーバー上のアドレスへのみ迂回されます。異なるサーバーのアドレスへ迂回したい場合は、ローカルの store-and-forward キューに迂回し、そのキューから消費し、異なるサーバーのアドレスに転送する api を設定します。</p>",
"<p>高可用性とは、1 つ以上のサーバーに障害が発生した後もシステムが機能し続けることです。</p>\n\n<p>フェイルオーバーは高可用性の機能の 1 つで、サーバーの障害発生時にクライアント接続を別のサーバーに移行して、クライアントアプリケーションの操作が続行されるようにします。</p>\n\n<p><strong>注記</strong><br/> 永続メッセージデータのみがフェイルオーバー後も維持されます。非永続メッセージデータはフェイルオーバー後に利用できません。</p>\n\n<h2>ライブ / バックアップのペア</h2>\n<p>${build.shortName} メッセージングは、サーバー同士がライブとバックアップのペアとしてリンクし、各サーバーがバックアップを持つようにします。ライブサーバーはクライアントからメッセージを受信し、バックアップサーバーはフェイルオーバーが発生するまで操作しません。1 つのバックアップサーバーは 1 つのライブサーバーのみが所有でき、ライブサーバーの作業を引き継ぐためにパッシブモードで待機します。</p>\n\n<p>ライブサーバーがクラッシュしたり、適切なモードで停止された場合、パッシブモードの状態のバックアップサーバーは新しいライブサーバーとなります。新しいライブサーバーが自動フェイルバックを許可するよう設定されている場合、停止した以前のライブサーバーの回復を検出して自動的に停止するため、以前のライブサーバーはメッセージの受信を再開することができます。</p>\n\n<p><strong>注記</strong><br/> ライブ / バックアップサーバーのペアを 1 つのみデプロイする場合、バックアップインスタンスはアクティブにメッセージを処理しないため、ペアの前でロードバランサーを効果的に使用できません。さらに、JNDI や Undertow web サーバーなどのサービスもバックアップサーバーではアクティブになりません。そのため、バックアップメッセージングサーバーとして使用される ${build.shortName} のインスタンスへ JEE アプリケーションをデプロイすることはサポートされません。</p>\n\n<h2>HA ポリシー</h2>\n<p>${build.shortName} メッセージングはサーバーのバックアップで <em>レプリケーション</em> と <em>共有ストア</em> の 2 つのストラテジーをサポートします。 各ストラテジーはマスターまたはスレーブになります。メッセージングサーバーごとに 1 つの HA ポリシーオプションのみを設定できることに注意してください。</p>\n\n<p>高可用性や、ストラテジーおよびポリシーの種類に関する詳細は、「<a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-29-high-availability\">High Availability</a>」を参照してください。</p>\n",
"<p>${build.shortName} メッセージには完全機能する JMS メッセージ api が含まれています。ソースキューまたはトピックからメッセージを消費し、通常は異なるサーバーにあるターゲットキューまたはトピックにメッセージを送信するのが JMS api の役目です。</p>\n\n<p>ソースおよびターゲットアーバーは同じクラスターに存在する必要はないため、WAN 全体や接続の信頼性を欠く状況で 1 つのクラスターから別のクラスターへ確実にメッセージを送信するには、ブリッジングの使用が適しています。</p>\n\n<p>\n    <strong>注記</strong><br/> JMS ブリッジとコアブリッジを混同しないでください。JMS ブリッジは JMS 1.1 準拠の JMS プロバイダーを 2 つブリッジするために使用でき、JMS API を使用します。コアブリッジは 2 つの ${build.shortName} メッセージングインスタンスをブリッジするために使用され、コア API を使用します。可能な限り JMS ブリッジの代わりにコアブリッジを使用することが推奨されます。\n</p>",
"<p>リモート ActiveMQ Artemis サーバーへのディスカバリーグループ、コネクター、コネクションファクトリー、キュー、およびトピックの設定が含まれます。</p>\n\n<h2>コネクター</h2>\n<p>コネクターは、リモート ActiveMQ Artemis サーバーへの接続方法を定義します。</p>\n\n<p>コネクターに関する詳細は、<a target=\"_blank\" href=\"https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1/html/configuring_messaging/acceptors_and_connectors\">コネクターに関するドキュメント</a>を参照してください。\n</p>\n\n<h2>ディスカバリーグループ</h2>\n<p>ディスカバリーグループは、UDP マルチキャストアドレスや JGroups チャネルなどのブロードキャストエンドポイントからコネクター情報を受け取る方法を定義します。</p>\n<p>ディスカバリーグループは、各サーバーの各ブロードキャストごとに 1 つのコネクターリストを保持します。特定のサーバーからブロードキャストエンドポイントでブロードキャストを受信すると、そのサーバーのリストのエントリーを更新します。特定のサーバーからブロードキャストを長時間受信しないと、そのリストからサーバーのエントリーを削除します。</p>\n\n\n<h2>接続ファクトリー</h2>\n<p>デフォルトでは、${build.shortName} messaging サブシステムは <code>InVmConnectionFactory</code> および \n<code>RemoteConnectionFactory</code> 接続ファクトリーを提供し、さらに プールされた \n<code>activemq-ra</code> 接続ファクトリーも提供します。\n</p>\n\n<p>プールされた接続ファクトリーでは、リモートの ActiveMQ Artemis リソースアダプターのインバウンドおよびアウトバウンド接続を設定できます。pooled-connection-factory を設定してリモート ActiveMQ Artemis サーバーに接続する方法は「<a target=\"_blank\" href=\"https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1/html/configuring_messaging/resource_adapters#use_provided_amq_adapter\">Using the Integrated Resource Adapter for Remote Connections</a>」を参照してください。\n</p>\n\n<h2>外部キュー / トピック</h2>\n<p>リモート ActiveMQ Artemis サーバーに存在するキューおよびトピック。</p>\n",
"<p>Apache ActiveMQ Artemis サーバー。各 Apache ActiveMQ Artemis は、メッセージやその他の永続性に使用する、パフォーマンスに大変優れた独自の永続ジャーナルを持ちます。</p>\n\n<p>高パフォーマンスなジャーナルを使用すると、永続性にリレーショナルデータベースを使用する場合では達成不可能な卓越したパフォーマンスを永続メッセージで実現できます。</p>\n\n<p>異なる物理マシン上に存在する可能性のある Apache ActiveMQ Artemis クライアントは Apache ActiveMQ Artemis サーバーと対話します。現在、Apache ActiveMQ Artemis はクライアント側でメッセージの API を 2 つ提供します。</p>\n\n<ol>\n    <li>コアクライアント API。これは、簡単で直感的な Java API で、JMS の複雑性を一部緩和してメッセージング機能をすべて利用できます。</li>\n    <li>JMS クライアント API。標準の JMS API はクライアント側で利用できます。</li>\n</ol>\n\n<p>Apache ActiveMQ Artemis は、サーバーで異なるプロトコル実装も提供するため、これらのプロトコルに対応するクライアントを使用できます。</p>\n\n<ol>\n    <li>Stomp</li>\n    <li>OpenWire</li>\n    <li>AMQP</li>\n</ol>\n\n<p>JMS セマンティックは、クライアント側の JMS ファサード層によって実装されます。</p>\n\n<p>Apache ActiveMQ Artemis サーバーは JMS で対話せず、JMS に関することは何も理解しません。複数の異なるプロトコルと使用するために設計されたプロトコルにとらわれないメッセージングサーバーです。</p>\n\n<p>ユーザーがクライアント側で JMS API を使用する場合、JMS の対話すべてが Apache ActiveMQ Artemis コアクライアント API で操作に変換された後、Apache ActiveMQ Artemis ワイヤ形式を使用して転送されます。</p>\n\n<p>サーバーは常にコア API の対話のみに対応します。</p>",
"<p>WildFly にデプロイされたアプリケーションの Eclipse MicroProfile Config をサポートします。統合は \n<a href=\"https://github.com/smallrye/smallrye-config/\">SmallRye</a> コンポーネントを使用して MicroProfile Config 実装を提供します。\n</p>\n",
"<!--\n  ~ Copyright 2015-2016 Red Hat, Inc, and individual contributors.\n  ~\n  ~ Licensed under the Apache License, Version 2.0 (the \"License\");\n  ~ you may not use this file except in compliance with the License.\n  ~ You may obtain a copy of the License at\n  ~\n  ~ https://www.apache.org/licenses/LICENSE-2.0\n  ~\n  ~ Unless required by applicable law or agreed to in writing, software\n  ~ distributed under the License is distributed on an \"AS IS\" BASIS,\n  ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\n  ~ See the License for the specific language governing permissions and\n  ~ limitations under the License.\n  -->\n<p>WildFly の Eclipse MicroProfile Metrics をサポートします。統合は <a href=\"https://github.com/smallrye/smallrye-metrics/\">SmallRye</a> コンポーネントを使用して MicroProfile Metrics 実装を提供します。\n</p>\n",
"<p>mod_cluster は httpd ベースのロードバランサーです。mod_cluster は mod_jk や mod_proxy と同様に、通信チャネルを使用してリクエストを httpd からアプリケーションサーバーノードの 1 つに転送します。mod_jk や mod_proxy と異なることは、mod_cluster はアプリケーションサーバーノードと httpd 間の追加の接続を利用することです。</p>\n\n<p>アプリケーションサーバーノードは、この接続を使用してサーバー側の負荷分散係数を送信し、ライフサイクルイベントを httpd に返信します。これは、Mod-Cluster Management Protocol (MCMP) と呼ばれる HTTP メソッドのカスタムセットを介して行われます。mod_cluster は、この追加のフィードバックチャネルで、他の負荷分散ソリューションでは提供できないインテリジェンスや粒度のレベルを提供します。</p>",
"<p>エントリーをグローバル JNDI 名前空間にバインドし、リモート JNDI インターフェースを設定します。</p>",
"<p>ファイルシステムパスの論理名。 <code>domain.xml</code>、<code>host.xml</code>、および <code>standalone.xml</code> の設定にはすべてパスを宣言できるセクションが含まれます。設定のその他のセクションは、マシンによって異なる可能性があるパスの完全な詳細を含める代わりに、論理名を使用してこれらのパスを参照できます。</p>\n\n<p>たとえば、logging サブシステム設定には、サーバーの <code>log</code> ディレクトリーを示す <code>jboss.server.log.dir</code> パスへの参照が含まれます。</p>",
"<p>過去のバージョンの ${build.shortName} でサポートされたように、JBoss Microcontainer サービスが含まれるアプリケーションのデプロイメントを有効にします。</p>",
"<p>プロファイルは、サブシステムと各サブシステムの設定の名前付きセットです。サブシステムは、拡張機能によってコアサーバーに追加される機能のセットです。サブシステムは、サーブレット処理機能、EJB コンテナー、JTA などの機能を提供します。</p>\n\n<p>異なるサーバーグループの特定のニーズに対応するよう、プロファイルは個別に定義できます。</p>\n\n<img class=\"preview\" src=\"previews/profiles.png\"/>",
"<p>JBoss Remoting にはワーカースレッドプール、1 つ以上のコネクター、複数のローカルおよびリモート接続 URI の 3 つのトップレベル設定可能要素があります。</p>\n<p>独自のアプリケーションにカスタムコネクターを使用する場合を除き、Remoting サブシステムの設定は必要でないことがほとんどです。EJB などの、Remoting クライアントとして動作するアプリケーションには特定のコネクターに接続するための別の設定が必要になります。</p>",
"<p>${build.shortName} は正常に一時停止およびシャットダウンできます。これにより、新しいリクエストを許可せずにアクティブなリクエストを正常に完了できます。タイムアウト値は、一時停止またはシャットダウン操作がアクティブなリクエストの完了まで待つ期間を指定します。サーバーが一時停止しても管理リクエストは処理されます。</p>\n<p>正常なシャットダウンは、リクエストがサーバーに入るエントリーポイントを中心にサーバー全体のレベルで調整されます。以下のサブシステムが正常なシャットダウンをサポートします。</p>\n<dl>\n    <dt>Undertow</dt>\n    <dd><code>undertow</code> サブシステムはすべてのリクエストが終了するまで待機します。</dd>\n    <dt>Modcluster</dt>\n    <dd><code>modcluster</code> サブシステムは <code>PRE_SUSPEND</code> フェーズでサーバーが一時停止することをロードバランサーに通知します。\n    </dd>\n    <dt>EJB</dt>\n    <dd>        <code>ejb3</code> サブシステムはすべてのリモート EJB リクエストおよび MDB メッセージ配信が終了するまで待機します。MDB への配信は <code>PRE_SUSPEND</code> フェーズで停止します。EJB タイマーは中断され、サーバーが再開したときにタイマーがアクティベートされます。\n    </dd>\n    <dt>EE Concurrency</dt>\n    <dd>サーバーはすべてのアクティブなジョブが終了するまで待機します。キューに置かれたジョブはすべてスキップされます。現在、EE Concurrency には永続性がないため、キューに置かれスキップされたジョブは失われます。<br/>サーバーが一時停止状態である間、スケジュールされたタスクはスケジュールどおりの時間に実行されますが、 <code>java.lang.IllegalStateException</code> が発生します。サーバーが再開されると、スケジュールされたタスクは通常どおり実行され、ほとんどの場合でタスクのスケジュールを変更する必要はありません。\n    </dd>\n    <dt>Batch</dt>\n    <dd>サーバーはタイムアウト期間内の実行中のジョブをすべて停止し、スケジュール済みのジョブをすべて延期します。<br/>現在、正常なシャットダウンはインバウンドのリモート分散トランザクションや新しいインバウンド JMS メッセージを拒否しません。インフライトアクティビティーによってスケジュールされた EE バッチジョブおよび EE 同時実行タスクは、現在実行の継続が許可されます。しかし、タイムアウトウィンドウを渡す EE 同時実行タスクが提出されると、実行時にエラーが発生します。\n    </dd>\n</dl>\n<p>リクエストは request-controller サブシステムによって追跡されます。このサブシステムがないと、中断および再開機能が制限され、リクエストの完了を待たずにサーバーが中断またはシャットダウンします。しかし、この機能が必要ない場合は、request-controller サブシステムを削除してパフォーマンスを若干向上することができます。</p>",
"<p>リソースアダプターは、 Java Connector Architecture (JCA) 仕様を使用して Java EE アプリケーションとエンタープライズ情報システム (EIS) との間の通信を提供するデプロイ可能な Java EE コンポーネントです。EIS ベンダーの製品と Java EE アプリケーションの統合を容易にするため、リソースアダプターは通常 EIS ベンダーによって提供されます。</p>\n<p>エンタープライズ情報システムは、組織内における他のあらゆるソフトウェアシステムのことです。例としては、エンタープライズリソースプランニング (ERP) システム、データベースシステム、電子メールサーバー、商用メッセージングシステムなどが挙げられます。</p>\n<p>リソースアダプターは、サーバーにデプロイできる Resource Adapter Archive (RAR) ファイルでパッケージ化されます。また、RAR ファイルは、Enterprise Archive (EAR) デプロイメントにも含めることができます。</p>",
"<p>過去のバージョンの ${build.shortName} でサポートされたように、MBean サービスが含まれる SAR アーカイブのデプロイメントを有効にします。</p>",
"<p>セキュリティードメインは認証、承認、セキュリティーマッピング、監査の設定によって構成されます。セキュリティードメインは Java Authentication and Authorization Service (JAAS) の宣言的セキュリティーを実装します。</p>\n<p>認証とはユーザーアイデンティティーを検証することを言います。セキュリティー用語では、このユーザーをプリンシパルと呼びます。認証と承認は異なりますが、含まれている認証モジュールの多くは承認の処理も行います。\n</p>\n<p>承認は、認証されたユーザーが、システムまたは操作の特定のリソースへアクセスできるパーミッションまたは特権を持っているかどうかをサーバーが判断するプロセスです。</p>\n<p>セキュリティーマッピングとは、情報をアプリケーションに渡す前にプリンシパル、ロール、または属性から情報を追加、編集、削除する機能のことです。</p>\n<p>監査マネージャーは、プロバイダーモジュールを設定して、セキュリティーイベントの報告方法を制御できるようにします。\nセキュリティードメインを使用する場合、アプリケーション自体から特定のセキュリティー設定をすべて削除することが可能です。これにより、一元的にセキュリティーパラメーターを変更できるようにします。このような設定構造が有効な一般的な例には、アプリケーションをテスト環境と実稼動環境間で移動するプロセスがあります。&lt;remark>Bugzilla のバグの内容を反映済み&lt;/remark></p>",
"<p>elytron サブシステムは ${build.fullName} で新規導入されました。これは、アプリケーションサーバー全体でのセキュリティーの統一に使用されるセキュリティーフレームワークである WildFly Elytron プロジェクトをベースにしています。elytron サブシステムにより、単一の設定場所でアプリケーションと管理インタフェースの両方をセキュアにできます。WildFly Elytron は、機能のカスタム実装を提供し、elytron サブシステムと統合するために複数の API と SPI も提供します。</p>\n<p>他にも、Elytron には複数の重要な機能があります。</p>\n<ul>\n    <li>強化された HTTP および SASL 認証の認証メカニズム。</li>\n    <li>セキュリティードメイン全体で SecurityIdentities が伝搬されるようにする改良されたアーキテクチャー。これにより、透過的な変換を承認に使用できる状態にします。変換は、設定可能なロールデコーダー、ロールマッパー、およびパーミッションマッパーを使用して実行されます。</li>\n    <li>暗号化スイートおよびプロトコルを含む SSL/TTS 設定の一元化。</li>\n    <li>一括 SecureIdentity 構築などの SSL/TLS の最適化と、確立中の SSL/TLS 接続への承認の密な結び付け。一括 SecureIdentity 構築によって、リクエストごとに SecureIdentity を構築する必要がなくなります。確立中の SSL/TLS 接続に認証を密に結び付けると、最初のリクエストを受け取る前にパーミッションチェックが行われるようになります。</li>\n    <li>以前の vault 実装に取って代わるセキュアなクレデンシャルストア。新しいセキュアなクレデンシャルストアは、暗号化された文字列の他に、暗号化された他のクレデンシャルタイプも複数格納できます。</li>\n</ul>\n<p>新しい elytron サブシステムは、レガシーの security サブシステムとレガシーのコア管理認証と並行して存在します。レガシーと Elytron の両方は、管理インターフェースのセキュア化や、アプリケーションのセキュリティーを提供するために使用されます。</p>",
"<p>Java Security Manager によって使用される Java セキュリティーポリシーを設定します。</p>\n<p>Java Security Manager は、Java 仮想マシン (JVM) サンドボックスの外部境界を管理するクラスで、JVM 内で実行するコードが JVM 外のリソースと対話する方法を制御します。Java Security Manager が有効な場合、Java API は安全ではない可能性のある操作を行う前に Java Security Manager が承認するか確認します。Java Security Manager は、セキュリティーポリシーを使用して該当するアクションを許可または拒否するかどうかを決定します。</p>",
"<p>シングルトンポリシーを定義して、シングルトンデプロイメントの動作を設定したり、シングルトン MSC サービスを作成したりします。</p>\n<p>高可用性 (HA) シングルトンとも呼ばれるクラスター化されたシングルトンサービスは、クラスターの複数のノードにデプロイされるサービスです。このサービスはノードの 1 つにのみ提供されます。通常、シングルトンサービスで稼働しているノードはマスターノードと呼ばれます。</p>\n<p>マスターノードに障害が発生したり、マスターノードがシャットダウンした場合、残りのノードから別のマスターが選択され、サービスは新しいマスター上で再起動されます。マスターが停止してから別のノードが引き継ぎするまでの短い間以外は、サービスは 1 つのノードによって提供されます。</p>",
"<p>ソケットバインディングは名前が付けられたソケット設定のことです。<code>domain.xml</code> および <code>standalone.xml</code> の設定には、名前付きのソケット設定を宣言できるセクションが含まれています。設定のその他のセクションは、マシンによって異なる可能性があるソケット設定の完全な詳細を含める代わりに、論理名を使用してこれらのソケットを参照できます。</p>",
"<p>インターフェース、ソケットバインディング、パス、およびシステムプロパティーなど、サブシステムやグローバルリソースを設定します。</p>\n\n<p>利用可能な各 <strong>サブシステム</strong> の設定を表示および編集します。たとえば、データソースの追加、メッセージングプロバイダーの設定、またはアプリケーションセキュリティーの設定を行います。</p>\n\n<p>関連リンク</p>\n<ul>\n    <li><a href=\"#runtime\">サーバーランタイム</a></li>\n</ul>",
"<p>サブシステム設定のセット。サブシステムは、拡張機能によってコアサーバーに追加される機能のセットです。サブシステムは、サーブレット処理機能、EJB コンテナー、JTA サポートなどを提供します。</p>",
"<p>システムプロパティの値は <code>domain.xml</code>、<code>host.xml</code>、および <code>standalone.xml</code> 内の複数の箇所で設定することができます。<code>standalone.xml</code> 内の値はサーバー起動プロセスの一部として設定されます。<code>domain.xml</code> および <code>host.xml</code> 内の値はサーバーが起動した際にそのサーバーに適用されます。</p>",
"<p>タイムアウト値やトランザクションロギングなどのトランザクションマネージャーのオプションを設定し、JTS (Java Transaction Service) を使用するかどうかを設定します。</p>",
"<p>Undertow サブシステムは、Web サーバーおよびサーブレットコンテナーの設定を可能にします。 \n<a href=\"https://jcp.org/en/jsr/detail?id=340\" target=\"_blank\">Java Servlet 3.1 仕様</a>や WebSocket を実装し、HTTP Upgrade をサポートします。また、サーブレットデプロイメントでパフォーマンスの高い非ブロッキングハンドラーの使用をサポートします。Undertow サブシステムは、mod_cluster をサポートするパフォーマンスの優れたリバースプロキシとして動作することも可能です。\n</p>\n\n<p>Undertow サブシステム内で設定する主なコンポーネントは 6 つあります。</p>\n<ol>\n    <li>グローバル設定</li>\n    <li>バッファーキャッシュ</li>\n    <li>サーバー</li>\n    <li>サーブレットコンテナー</li>\n    <li>フィルター</li>\n    <li>ハンドラー</li>\n</ol>\n\n<p><strong>重要</strong><br/> Undertow サブシステムは IO サブシステムに依存して XNIO ワーカーやバッファープールを提供します。IO サブシステムは個別に設定され、ほとんどの場合で最適なパフォーマンスを実現できるデフォルト設定を提供します。\n</p>\n",
"<p>デプロイされたアプリケーションで参照されるセキュリティードメインからのマッピングと、シングルサインオン設定。</p>\n",
"<p>バッファーキャッシュは静的リソースをキャッシュするために使用されます。${build.shortName} では複数のキャッシュを設定でき、デプロイメントによる参照が可能であるため、デプロイメントごとに異なるキャッシュサイズを使用することができます。バッファーは固定サイズで、リージョンで割り当てられます。使用領域の合計は、バッファーサイズ、リージョンごとのバッファー数、およびリージョンの最大数を掛けて算出できます。バッファーキャッシュのデフォルトサイズは 10MB です。</p>",
"<p>IO 操作に使用されるバイトバッファープール。これは、IO サブシステムからのバッファープールと同じ機能を提供するため、相互に交換でき、一意な名前を付ける必要があります。このバッファープールを使用すると、保持されたメモリーの合計容量を IO サブシステムよりも正確に設定できます。</p>",
"<p>フィルターはリクエストの一部の変更を可能にし、述語を使用してフィルターの実行時を制御できます。フィルターの一般的なユースケースには、ヘッダーの設定や GZIP 圧縮などがあります。</p>\n\n<p>以下のタイプのフィルターを定義できます。</p>\n<ol>\n    <li>カスタムフィルター (Custom Filter)</li>\n    <li>エラーページ (Error Page)</li>\n    <li>式フィルター (Expression Filter) </li>\n    <li>GZip</li>\n    <li>Mod Cluster</li>\n    <li>リクエストの制限 (Request Limit)</li>\n    <li>応答ヘッダー (Response Header)</li>\n    <li>再書き込み (Rewrite)</li>\n</ol>\n\n<p><strong>注記</strong><br/> フィルターの機能は、過去のバージョンの ${build.shortName} で使用されたグローバルバルブと同等です。</p>\n",
"<p>Undertow では、2 つのタイプのハンドラーを設定できます。</p>\n<ol>\n    <li>ファイルハンドラー</li>\n    <li>リバースプロキシハンドラー</li>\n</ol>\n<p>ファイルハンドラーは静的ファイルに対応します。各ファイルハンドラーは仮想ホストにある場所にアタッチされている必要があります。リバースプロキシーハンドラーによって、${build.shortName} は高パフォーマンスなリバースプロキシーとして機能することができます。AJP、HTTP、および HTTP.2 バックエンドを処理でき、mod_cluster をサポートします。</p>\n\n",
"<p>サーバーは Undertow のインスタンスを表し、複数の要素で構成されます。</p>\n<ol>\n    <li>ホスト</li>\n    <li>HTTP リスナー</li>\n    <li>HTTPS リスナー</li>\n    <li>AJP リスナー</li>\n</ol>\n\n<p>ホスト要素は仮想ホスト設定を提供し、3 つのリスナーはそのタイプの接続を Undertow インスタンスに提供します。</p>\n\n<p><strong>注記</strong><br/> \n複数のサーバーを設定でき、デプロイメントやサーバーを完全に分離できます。これは、マルチテナント環境などで便利です。\n</p>",
"<p>サーブレットコンテナーは、すべてのサーブレット、 JSP、およびソケット関連の設定 (セッションに関連する設定を含む) を提供します。ほとんどのサーバーにはサーブレットコンテナーが 1 つだけ必要ですが、servlet-container 要素を追加すると複数のサーブレットコンテナーを設定することができます。サーブレットコンテナーが複数設定されていると、複数のデプロイメントを異なる仮想ホストの同じコンテキストパスにデプロイできるなど、一部の動作を有効にすることができます。</p>\n\n<p><strong>注記</strong><br/> <code>web.xml</code>ファイルを使用すると、サーブレットコンテナーによって提供される設定の多くをデプロイされたアプリケーションで個別にオーバーライドできます。</p>",
"<p>JBossWS コンポーネントは、webservices サブシステムを介してアプリケーションサーバーに提供されます。JBossWS コンポーネントは WS エンドポイントの処理に対応します。このサブシステムは、公開されたエンドポイントアドレスとエンドポイントハンドラーチェーンの設定をサポートします。デフォルトの webservices サブシステムは、サーバーのドメインおよびスタンドアロン設定ファイルに提供されます。</p>\n\n<h2>その他のリソース</h2>\n<p>webservices サブシステムは JBossWS プロジェクトによって提供されます。利用可能な設定プロパティーの詳細は、プロジェクトのドキュメントを参照してください。</p>\n<ul>\n    <li>JBossWS ホームページ: <a href=\"https://www.jboss.org/jbossws\" target=\"_blank\">http://www.jboss.org/jbossws</a></li>\n    <li>プロジェクトのドキュメント: \n<a href=\"https://docs.jboss.org/author/display/JBWS\" target=\"_blank\">https://docs.jboss.org/author/display/JBWS</a>\n    </li>\n</ul>",
"<p>${build.shortName} の CDI (Contexts and Dependency Injection) を設定します。</p>",
"<p>コア管理は以下の機能を設定します。</p>\n<ul>\n    <li>設定の変更: このプロファイルに対する設定変更のインメモリーへの記録を有効または無効にします。プロファイルセクションの設定変更は、このプロファイルに関連するサーバーのランタイムセクションで確認できます。</li>\n    <li>プロセス状態リスナー: サーバーのプロセス状態の変更に対してカスタムクラスリスナーを追加します。</li>\n</ul>\n",
"<p>コンテンツリポジトリーは、ドメインコントローラーにアップロードされたすべてのコンテンツを保持します。コンテンツをアップロードした後、サーバーグループに割り当てることができます。</p>\n\n<p id=\"drag-and-drop-deployment\"> <strong>ドラッグアンドドロップ</strong> を使用すると新しいコンテンツを追加したり既存コンテンツを削除することができます。1 つまたは複数のファイルをコンテンツ列にドラッグします。同じ名前のコンテンツがすでに存在する場合は、コンテンツが置き換えられ、存在しない場合はコンテンツが追加されます。</p>\n\n<p>未管理のデプロイメントを追加することもできます。未管理のデプロイメントはサーバーのローカルファイルシステム上のフォルダーを示します。未管理のデプロイメントは、デプロイされる前にサーバーのデプロイメントリポジトリーにコピー (アップロード) されないことが管理されたデプロイメントとは異なります。デプロイメントコンテンツは元の場所に保持され、元の場所から直接デプロイされます。</p>\n\n<p>コンテンツがサーバーグループに割り当てられなくなったら、コンテンツを再度削除できます。</p>",
"<p><strong>デプロイメント</strong> は、WAR や EAR アプリケーションなどの、サーバーにデプロイ可能なリソースです。</p>\n\n<p>管理対象ドメイン内で、デプロイはサーバーグループに割り当てられます。サーバーグループ内のすべてのサーバーインスタンスは、同じデプロイメントコンテンツを持つことになります。</p>\n\n<img class=\"preview\" src=\"previews/deployments.png\"/>",
"<p>サーバーグループのデプロイメントの管理</p>\n<p id=\"drag-and-drop-deployment\">    <strong>ドラッグアンドドロップ</strong> を使用して新しいデプロイメントを選択したサーバーグループに追加できます。1 つまたは複数のファイルをデプロイメント列にドラッグします。ドラッグアンドドロップで追加されたデプロイメントはデフォルトで無効になっています。\n</p>\n<p>コンテントリポジトリーから 1 つ以上の項目を選択し、選択したサーバーグループにデプロイします。</p>\n<p>未管理のデプロイメントを追加します。未管理のデプロイメントはサーバーのローカルファイルシステム上のフォルダーを示します。未管理のデプロイメントは、デプロイされる前にサーバーのデプロイメントリポジトリーにコピー (アップロード) されないことが管理されたデプロイメントとは異なります。デプロイメントコンテンツは元の場所に保持され、元の場所から直接デプロイされます。</p>\n",
"<p>サーバーグループとは、1 つのグループとして管理および設定される複数のサーバーインスタンスのことです。管理対象ドメインでは、各アプリケーションサーバーインスタンスは唯一のメンバーである場合でも 1 つのサーバーグループに属します。グループのサーバーインスタンスは同じプロファイル設定とデプロイされたコンテンツを共有します。</p>\n\n<p>この列を使用して、1 つ以上のサーバーグループに割り当てられたデプロイメントを管理します。新しいデプロイメントをアップロードし、コンテンツリポジトリーからコンテンツをデプロイするか、未管理のデプロイメントを作成します。</p>\n",
"<p>デプロイメントは、サーバーにデプロイ可能なもの (例：EJB-JAR、WAR、EAR に加え、RAR あるいは JBoss 固有のデプロイメントなどその他の標準アーカイブといったアプリケーション) を表します。</p>\n<p id=\"drag-and-drop-deployment\">    <strong>drag and drop</strong> を使用すると新しいデプロイメントを追加したり既存デプロイメントを削除することができます。1 つまたは複数のファイルをデプロイメント列にドラッグします。同じ名前のデプロイメントがすでに存在する場合は、デプロイメントが置き換えられ、存在しない場合はデプロイメントが追加されます。ドラッグアンドドロップで追加されたデプロイメントは、デフォルトで有効になっています。\n</p>",
"<p>拡張は、新しい機能を管理コンソールに追加する方法です。拡張は JavaScript で書かれ、 <a href=\"https://github.com/hal/hal.next/wiki/JavaScript-API\">JavaScript API</a> を使用してコンソールおよび管理インターフェースと対話する必要があります。拡張を開発する場合は、 <a href=\"https://github.com/hal/hal.next/wiki/Extensions\">https://github.com/hal/hal.next/wiki/Extensions</a> を参照してください。\n</p>\n\n<div class=\"alert alert-warning\">\n    <span class=\"pficon pficon-warning-triangle-o\"></span>拡張は <strong>JavaScript</strong> で書かれ、ブラウザーに<strong>インジェクト</strong>されます。信頼できる拡張のみをインストールするようにしてください。\n</div>\n\n<h2>拡張ポイント</h2>\n<p>コンソールは拡張で使用できる 4 つの拡張ポイントを提供します。</p>\n<ol>\n    <li>ヘッダー: メニューアイテムをヘッダーの「Extensions」ドロップダウンに追加します。</li>\n    <li>ファインダーアイテム: 新規アイテムを特定のファインダー列に追加します。</li>\n    <li>フッター: メニューアイテムをフッターの「Extensions」ドロップダウンに追加します。</li>\n    <li>カスタム: 拡張をコンソールに追加する方法は拡張自体によります。</li>\n</ol>\n\n<h2>インストール</h2>\n<p>拡張は 2 つの方法でコンソールに追加できます。</p>\n\n<dl>\n    <dt>バンドルされた拡張</dt>\n    <dd>\n        <p>バンドルされた拡張は ${build.fullName} インストールの一部で、モジュールとしてインストールされます。バンドルされた拡張はコンソールの外部にインストールする必要があります。WildFly とコンソールは、バンドルされた拡張が追加または削除された後に再起動 / リロードする必要があります。</p>\n    </dd>\n\n    <dt>スタンドアロン拡張</dt>\n    <dd>\n        <p>スタンドアロン拡張は、パブリックで利用可能なエンドポイントによってホストされます。このエンドポイントは、拡張のメタデータが含まれる JSON ファイルに対応する必要があります。管理コンソールを使用するとスタンドアロン拡張を追加および削除できます。スタンドアロン拡張はブラウザーのローカルストレージに格納されるため、管理コンソールを実行するブラウザーおよび URL にスコープが指定されます。</p>\n    </dd>\n</dl>\n",
"<p>管理インターフェースに関連する設定を行い、最新の設定変更を確認し、管理コンソールへの拡張を管理します。</p>\n\n<h2>管理インターフェース</h2>\n<p>許可されるオリジン、セキュリティーレルム、SSL コンテキストのリストなど、http およびネイティブ管理インターフェースの設定を確認および編集します。</p>\n\n<h2>拡張</h2>\n<p>管理コンソールへの拡張を確認および管理します。拡張は、新機能を管理コンソールに追加する方法です。拡張は JavaScript で書かれ、2 つのカテゴリーに分類されます。</p>\n<ul>\n    <li>バンドルされた拡張: モジュールによって提供される ${build.fullName} インストールの一部。</li>\n    <li>スタンドアロン拡張: パブリックサーバーによってホストされるサードパーティーの拡張。</li>\n</ul>\n",
"<p>${build.shortName} にパッチを適用する方法は、インストールの方法によって異なります。ZIP またはインストーラーで ${build.shortName} をインストールした場合は、ZIP ベースのパッチ管理システムを使用する必要があります。RPM を使用して Red Hat Enterprise Linux 上に ${build.shortName} をインストールした場合は、RPM パッチを使用する必要があります。\n重要。</p>\n\n<p>パッチを適用またはロールバックする前に、すべてのデプロイメントと設定ファイルを含む ${build.shortName} サーバーをバックアップしてください。</p>\n\n<p>${build.shortName} の ZIP またはインストーラーインストールの累計パッチは、Red Hat カスタマーポータルからダウンロードできます。</p>\n\n<p>管理対象ドメイン環境の複数の ${build.shortName} ホストの場合、各ホストは ${build.shortName} ドメインコントローラーからパッチできます。</p>\n\n<p>パッチ適用の他に、パッチの適用をロールバックすることもできます。</p>\n\n<h3>ZIP/インストーラーインストールのパッチに関する重要事項</h3>\n\n<ul>\n    <li>モジュールを更新するパッチを適用する場合、起動時に使用される新たにパッチが適用された JAR は <code>${build.installDir}/modules/system/layers/base/.overlays/PATCH_ID/MODULE</code> に格納されます。パッチが適用されていない元のファイルは <code>${build.installDir}/modules/system/layers/base/MODULE</code> に残されますが、これらの JAR はランタイムに使用されません。</li>\n    <li>${build.shortName} の累計パッチリリースのサイズを大幅に小さくするため、累計パッチを部分的にロールバックすることはできません。適用済みのパッチはパッチ全体のみをロールバックできます。</li>\n    <li>たとえば、CP03 を ${build.shortName} に適用する場合、CP01 や CP02 にロールバックできません。各累計パッチリリースにロールバックできるようにするには、各累計パッチをリリース順に個別に適用する必要があります。</li>\n</ul>",
"<p><code>mgmt-users.properties</code> ファイルまたは LDAP サーバーを使用して認証されるユーザーはユーザーグループのメンバーになれます。ユーザーグループは、1 名以上のユーザーに割り当てできる任意のラベルです。</p>\n<p>RBAC システムは、ユーザーがメンバーであるユーザーグループに応じて自動的にロールをユーザーに割り当てるよう設定できます。また、グループメンバーシップを基にユーザーをロールから exclude (除外) することも可能です。</p>\n<p><code>mgmt-users.properties</code>ファイルを使用する場合、グループ情報は <code>mgmt-groups.properties</code> ファイルに保存されます。LDAP を使用する場合、グループ情報は LDAP サーバーに保存され、LDAP サーバーの管理者によって維持されます。</p>",
"<p>ロールベースアクセスコントロール (RBAC) は、管理ユーザーのパーミッションセットを指定するメカニズムです。これにより、各ユーザーが無制限のアクセスを必要とせずに複数のユーザーがサーバーの管理業務を共有できます。管理ユーザーの「職務の分離」を実現することで、不必要な特権を与えずに組織における個人またはグループの業務分散を容易にします。これにより、設定、デプロイメント、および管理の柔軟性を維持しながらサーバーやデータのセキュリティーを可能な限り強化できます。</p>\n<p>ロールベースアクセス制御は、ロールパーミッションと制約の組み合わせに対処します。異なる固定パーミッションを持つ 7 つのロールが事前定義されています。事前定義されたロールは Monitor、Operator、Maintainer、Deployer、Auditor、Administrator、および SuperUser です (ロールを選択してそのパーミッションの詳細を確認してください)。各管理ユーザーには 1 つ以上のロールが割り当てられます。各ロールは、サーバーを管理するときにユーザーが実行できる操作を指定します。</p>\n<p><strong>重要:</strong> プロバイダーを <code>rbac</code> に変更する前に、RBAC ロールの 1 つにマップされるユーザー (最低でも Administrator または SuperUser ロールを持つユーザー 1 名) が設定されていることを確認してください。そうでないと、インストールがシャットダウンし、XML 設定が編集されないと、インストールを管理することができなくなります。</p>",
"<h2>標準のロール</h2>\n<p>事前定義されたユーザーロールは 7 つあります。</p>\n<ul>\n    <li>Monitor</li>\n    <li>Operator</li>\n    <li>Maintainer</li>\n    <li>Deployer</li>\n    <li>Auditor</li>\n    <li>Administrator</li>\n    <li>SuperUser</li>\n</ul>\n<p>これらの各ロールは異なるパーミッションのセットを持ち、特定のユースケース向けに設定されています。Monitor、Operator、Maintainer、Administrator、および SuperUser ロールは、それぞれ前のレベルのロールから継承したパーミッションと追加のパーミッションを持ちます。Auditor および Deployer ロールはそれぞれ Monitor および Maintainer ロールに似ていますが、特別なパーミッションおよび制限が追加されています。</p>\n\n<h2>スコープ指定ロール</h2>\n<p>スコープ指定ロールは、指定された 1 つ以上のサーバーグループまたはホストに対してのみ、1 つの標準ロールのパーミッションを付与するユーザー定義のロールです。スコープ指定ロールにより、必要なサーバーグループやホストのみに限定されるパーミッションを管理ユーザーに付与できます。</p>\n<p>スコープ指定ロールは 5 つの特性によって定義されます。</p>\n<ol>\n    <li>一意名。</li>\n    <li>ベースになる標準ロール。</li>\n    <li>サーバーグループまたはホストへ適用されるかどうか。</li>\n    <li>スコープ指定ロールが制限されるサーバーグループまたはホストのリスト。</li>\n    <li>すべてのユーザーが自動的に含まれるかどうか。デフォルトは false です。</li>\n</ol>\n<p>スコープ指定ロールの作成後、標準ロールと同様にユーザーやグループへ割り当てできます。</p>\n<p>スコープ指定ロールを作成しても、新しいパーミッションは定義できません。スコープ指定ロールは、既存ロールのパーミッションを制限されたスコープで適用するために使用されます。たとえば、単一のサーバーグループに制限される Deployer ロールを基にスコープ指定ロールを作成できます。</p>\n<p>ロールは、ホストとサーバーグループの 2 つのスコープのみに限定されます。</p>\n<dl>\n    <dt>ホストスコープ指定ロール</dt>\n    <dd>ホストスコープ指定されたロールは、そのロールのパーミッションを 1 つ以上のホストに制限します。これにより、関連する /host=*/ リソースツリーにアクセスできますが、他のホスト固有のリソースは表示されません。</dd>\n    <dt>サーバーグループスコープ指定ロール</dt>\n    <dd>サーバーグループスコープ指定のロールは、そのロールのパーミッションを 1 つ以上のサーバーグループに制限します。さらに、ロールパーミッションは、指定されたサーバーグループに関連するプロファイル、ソケットバインディンググループ、サーバー設定、およびサーバーリソースにも適用されます。サーバーグループに論理的に関連しないリソース内のサブリソースは、ユーザーに対して表示されません。</dd>\n</dl>",
"<p>事前定義されたユーザーロールは 7 つあります。</p>\n<ul>\n    <li>Monitor</li>\n    <li>Operator</li>\n    <li>Maintainer</li>\n    <li>Deployer</li>\n    <li>Auditor</li>\n    <li>Administrator</li>\n    <li>SuperUser</li>\n</ul>\n<p>これらの各ロールは異なるパーミッションのセットを持ち、特定のユースケース向けに設定されています。Monitor、Operator、Maintainer、Administrator、および SuperUser ロールは、それぞれ前のレベルのロールから継承したパーミッションと追加のパーミッションを持ちます。Auditor および Deployer ロールはそれぞれ Monitor および Maintainer ロールに似ていますが、特別なパーミッションおよび制限が追加されています。</p>",
"<p>管理ユーザーの許可されるアクションは、そのユーザーに割り当てられたロールによって決定されます。ユーザーメンバーシップを基にした include (含まれる) および exclude (除外される) のシステムによって、ユーザーが属するロールが決定されます。</p>\n<p>以下の場合に、ロールがユーザーに割り当てられたとみなされます。</p>\n<ol>\n    <li>ユーザーが以下のいずれかである場合。</li>\n    <ul>\n        <li>ロールに含まれるユーザーとしてリストに記載されている。</li>\n        <li>ロールに含まれるとリストに記載されたグループのメンバーである。</li>\n    </ul>\n    <li>ユーザーが以下のいずれかに該当しない場合。</li>\n    <ul>\n        <li>ロールから除外されるユーザーとしてリストに記載されている。</li>\n        <li>ロールから除外されるとリストに記載されたグループのメンバーである。</li>\n    </ul>\n</ol>\n<p>exclude は include よりも優先度が高くなります。</p>",
"<p>アプリケーションセキュリティードメイン設定と、それに関連するデプロイメントを表示します。</p>\n",
"<p>「Test Connection」やフラッシュ操作などのランタイム操作へのアクセスを提供します。</p>\n<p>データソースおよび JDBC 統計を表示するため、必ず設定セクションでそれらを有効にしてください。</p>",
"<p>デプロイメントに含まれたとおりサーブレットおよび websocket のランタイムメトリックスを表示します。</p>\n",
"<p>各ドメインは 1 つのドメインコントローラー、1 つ以上のホストコントローラー、およびホスト毎に 0 個以上のサーバーグループによって構成されます。</p>\n<img class=\"preview\" src=\"previews/domain.png\"/>\n<p>ドメインコントローラーは、ドメインが制御される中心点です。各サーバーがドメインの管理ポリシーに従って設定されるようにします。ドメインコントローラーはホストコントローラーでもあります。</p>\n<p>ホストコントローラーは、domain.sh または domain.bat スクリプトが実行される物理または仮想ホストです。ホストコントローラーは、ドメイン管理タスクをドメインコントローラーに委譲するよう設定されます。各ホストのホストコントローラーはドメインコントローラーと対話し、そのホスト上で実行しているアプリケーションサーバーインスタンスのライフサイクルを制御し、ドメインコントローラーと協力してそれらのインスタンスを管理します。各ホストには複数のサーバーグループを含めることができます。</p>\n<p>サーバーグループは、${build.shortName} がインストールされているサーバーインスタンスの集まりで、これらのサーバーインスタンスは 1 つとして管理および設定されます。ドメインコントローラーはサーバーグループにデプロイされたアプリケーションとその設定を管理します。そのため、サーバーグループの各サーバーは同じ設定とデプロイメントを共有します。</p>\n",
"<p>elytron サブシステムの以下のリソースにランタイム操作のセットを提供します。</p>\n<ul>\n    <li><strong>証明機関アカウント</strong>: アカウントの作成、無効化、および更新を行い、アカウントキーを変更します。</li>\n    <li><strong>キーマネージャー (Key Manager)</strong>: キーマネージャーを再度初期化します。</li>\n    <li><strong>セキュリティードメイン (Security Domain)</strong>: アイデンティティーを読み取ります。</li>\n    <li><strong>トラストマネージャー (Trust Manager)</strong>: 証明書失効リストをリロードします。</li>\n</ul>",
"<p>elytron サブシステムの以下のリソースにランタイム操作のセットを提供します。</p>\n<ul>\n    <li><strong>キャッシングレルム (Cashing Realm)</strong>: キャッシュからすべてのエントリーを削除します。</li>\n    <li><strong>カスタム編集可能レルム (Custom Modifiable Realm)</strong>: アイデンティティーを追加、読み取り、および削除します。アイデンティティーのパスワードも設定します。</li>\n    <li><strong>ファイルシステムレルム (Filesystem Realm) </strong>: アイデンティティーを追加、読み取り、および削除します。アイデンティティーのパスワードも設定します。</li>\n    <li><strong>LDAP レルム (LDAP Realm)</strong>: アイデンティティーを追加、読み取り、および削除します。アイデンティティーのパスワードも設定します。</li>\n    <li><strong>プロパティーレルム (Properties Realm)</strong>: ファイルシステムからプロパティーファイルをリロードします。</li>\n</ul>",
"<p>elytron サブシステムの以下のリソースにランタイム操作のセットを提供します。</p>\n<ul>\n    <li><strong>クレデンシャルストア (Credential Store)</strong>: エイリアスを追加、読み取り、および削除し、エイリアスのパスワードを設定します。また、クレデンシャルストアをリロードします。</li>\n    <li><strong>フィルタリングキーストア (Filtering Key Store)</strong>: エイリアスを読み取りおよび削除します。</li>\n    <li><strong>キーストア (Key Store)</strong>: エイリアスを読み取り、変更、および削除します。証明書をインポートおよびエクスポートします。キーペアを生成します。証明書署名リクエストを生成します。キーストアをロードおよび保存します。</li>\n    <li><strong>LDA_ キーストア (LDAP Key Store)</strong>: エイリアスを読み取りおよび削除します。</li>\n</ul>",
"<p>ホストコントローラーは <code>domain.sh</code> または <code>domain.bat</code> スクリプトがホストで実行されると起動します。</p>\n\n<p>ホストコントローラーの主な役割はサーバーを管理することです。ドメイン管理タスクを委譲し、ホスト上で実行される個別のアプリケーションサーバープロセスを開始および停止します。</p>\n\n<p>ホストコントローラーはドメインコントローラーと対話し、サーバーとドメインコントローラー間の通信を管理できるようにします。ドメインの複数のホストコントローラーは 1 つのドメインコントローラーのみと対話できます。そのため、単一のドメインモード上で実行されるホストコントローラーおよびサーバーインスタンスはすべて単一のドメインコントローラーを持ち、同じドメインに属する必要があります。</p>\n\n<p>デフォルトでは、各ホストコントローラーはホストファイルシステムの未展開の <code> インストールファイルにある ${build.shortName}domain/configuration/host.xml${build.shortName} ファイルから設定を読み取ります。 <code>host.xml</code> ファイルには、特定のホストに固有する以下の設定情報が含まれています。\n</p>\n\n<ul>\n    <li>このインストールから実行されるはずの ${build.shortName} インスタンスの名前。</li>\n    <li>次の設定のいずれか。</li>\n    <ul>\n        <li>ホストコントローラーがドメインコントローラーへ通知して、ホストコントローラー自体を登録し、ドメイン設定へアクセスする方法。</li>\n        <li>リモートドメインコントローラーの検索および通知方法。</li>\n        <li> ホストコントローラーがドメインコントローラーとして動作するか。</li>\n    </ul>\n    <li>ローカルの物理インストールに固有する設定。たとえば、 <code>domain.xml</code> に宣言された名前付きのインターフェース定義は、 <code>host.xml</code> にある実際のマシン固有の IP アドレスにマップできます。また、domain.xml の抽象パス名を <code>host.xml</code> の実際のファイルパスにマップできます。\n    </li>\n</ul>",
"<p>デプロイされた REST リソースをリストします。</p>",
"<p>ローカル JNDI ネームスペースの概要を提供します。Java EE プラットフォーム仕様は以下の JNDI コンテキストを定義します。</p>\n<ul>\n    <li><code>java:comp</code> - ネームスペースは現在のコンポーネントにスコープ指定されます (例: EJB)。</li>\n    <li><code>java:module</code> - 現在のモジュールにスコープ指定されます。</li>\n    <li><code>java:app</code> - 現在のアプリケーションにスコープ指定されます。</li>\n    <li><code>java:global</code> - アプリケーションサーバーにスクープ指定されます。</li>\n</ul>\n<p>${build.shortName} は、標準のネームスペースの他に、以下の 2 つのグローバルネームスペースも提供します。</p>\n<ul>\n    <li><code>java:jboss</code></li>\n    <li><code>java:/</code></li>\n</ul>\n<p>リモート JNDI 上では java:jboss/exported コンテキスト内のエントリーのみにアクセスできることに注意してください。web デプロイメントでは <code>java:comp</code> のエイリアスは <code>java:module</code> になるため、war にデプロイされた EJB は独自の comp ネームスペースを持ちません。</p>",
"<p>選択されたサーバーのアクティブなデプロイメントの一部である永続ユニットの統計を表示します。</p>\n<p>統計を表示するには、    <code>&lt;property name=\"hibernate.generate_statistics\" value=\"true\"/></code> を persistence.xml に追加して有効にしてください。\n</p>",
"<p>エラー、パフォーマンスの問題、およびその他の問題を診断するには、サーバーおよびアプリケーションのログを確認します。ログを表示できるようにするには、ログがサーバーの <code>jboss.server.log.dir</code> ディレクトリーに存在する必要があります。コンソールはユーザーに割り当てられた RBAC ロールにも従うため、ユーザーはアクセス権限のあるログのみを確認できます。\n</p>\n\n<p>デフォルトでは、コンソールはログファイルの最後の 2000 行を表示します。ログファイル全体を確認する場合は「Download (ダウンロード）」を選択してください。ログファイルを別のブラウザーウインドウに表示する場合は「Open in external window (別のウインドウで開く)」を選択してください。</p>",
"<p>管理操作は ${build.shortName} で実行される操作で、管理スコープに関連しています。アプリケーションの使用に関連する HTTP 処理 (ejb、rest、jms など) は管理操作として登録されません。</p>\n<p>デプロイメントの追加、データソースのパスワードの変更、スレッドプールの増加などが管理操作の例になります。</p>\n<p>リソースの書き込みに排他的ロックが必要な管理操作があります。この排他的ロックが 15 秒を超えて保持されると、進行していない操作と見なされ、このビューに報告されます。</p>\n<p>管理操作ビューで、管理者はスタンドアロンサーバーや、ドメインのホストおよびサーバーすべての稼働中の管理操作を表示することができます。また、アクティブな管理操作をキャンセルしたり、進行していない操作をすべてキャンセルすることができます。</p>\n\n",
"<p>バランサー、ノード、およびコンテキストのランタイムメトリックスを表示します。</p>\n",
"<p>elytron サブシステムは ${build.fullName} で新規導入されました。これは、アプリケーションサーバー全体でのセキュリティーの統一に使用されるセキュリティーフレームワークである WildFly Elytron プロジェクトをベースにしています。elytron サブシステムにより、単一の設定場所でアプリケーションと管理インタフェースの両方をセキュアにできます。WildFly Elytron は、機能のカスタム実装を提供し、elytron サブシステムと統合するために複数の API と SPI も提供します。</p>\n<p>このランタイムビューは、このサーバーに対して設定されたさまざまなストア、セキュリティーレルム、および ssl リソースに関する情報を動的に提供します。</p>",
"<p>サーバーグループとは、1 つのグループとして管理および設定される複数のサーバーインスタンスのことです。管理対象ドメインでは、各アプリケーションサーバーインスタンスは唯一のメンバーである場合でも 1 つのサーバーグループに属します。グループのサーバーインスタンスは同じプロファイル設定とデプロイされたコンテンツを共有します。</p>\n\n<p>ドメインコントローラーとホストコントローラーは、ドメインにある各サーバーグループのすべてのインスタンスに標準設定を強制します。</p>\n\n<p>ドメインは複数のサーバーグループで構成されます。異なるサーバーグループを異なるプロファイルやデプロイメントで設定できます。たとえば、ドメインは異なるサービスを提供する異なるサーバー層で設定できます。</p>\n\n<p>異なるサーバーグループが同じプロファイルやデプロイメントを持つこともできます。これにより、最初のサーバーグループでアプリケーションがアップグレードされた後に 2 つ目のサーバーグループでアプリケーションがアップデートされるアプリケーションのローリングアップグレードが可能になり、サービスの完全停止を防ぎます。</p>\n",
"<p>ログファイルなどのランタイムサービス、JVM メトリックス、およびサブシステム固有のランタイムデータを表示および監視します。</p>",
"<p class=\"topology\">サーバーグループを列、ホストを行としてドメインで定義されたホスト、サーバーグループ、およびサーバーの概要。サーバーはその状態に応じて表示されます。 <span class=\"status error\">エラー</span>、\n <span class=\"status warning\">リロード / 再起動が必要</span>、 \n<span class=\"status suspended\">一時停止</span>、 \n<span class=\"status ok\">稼働中</span>、および \n<span class=\"status inactive\">停止または無効</span></p>\n<p>ホスト、サーバーグループ、またはサーバーを選択して、追加の情報を表示するか操作を実行します。</p>",
"<p>特定サーバーの ajp-listener、http-listener、https-connectors として登録されたコネクターのランタイムメトリックスを表示します。</p>",
"<p>web サーバー (Undertow) には、多くのランタイムメトリックスが含まれ、以下のセクションに分割されます。</p>\n<ul>\n    <li><strong>アプリケーションセキュリティードメイン</strong>: アプリケーションセキュリティードメイン設定とそれに関連するデプロイメントを表示します。</li>\n    <li><strong>サーバー</strong>: 特定サーバーの ajp-listener、http-listener、https-connectors として登録されたコネクターのランタイムメトリックスを表示します。</li>\n    <li><strong>Modcluster</strong>: バランサー、ノード、およびコンテキストのランタイムメトリックスを表示します。</li>\n    <li><strong>Deployment</strong>: デプロイメントに含まれたとおりサーブレットおよび websocket のランタイムメトリックスを表示します。</li>\n</ul>",
"<p>ワーカーは XNIO ワーカーインスタンスです。XNIO ワーカーインスタンスは、IO およびワーカースレッドの管理や SSL サポートなどの機能を提供する Java NIO API の抽象化レイヤーです。デフォルトでは、${build.shortName} は <code>default</code> という単一のワーカーを提供しますが、複数のワーカーを定義できます。</p>"]