サーバーソフトウェアのコンポーネント

HTTP サーバーは、PTC HTTP Server (powered by Apache) または IIS などの商用 HTTP サーバーです。PTC HTTP Server は Windchill にバンドルされています。その他の HTTP サーバーは、必要に応じて別途購入できます。すべての Windchill サーバーホストに、それぞれ HTTP サーバーが配置されている必要があります。Web サーバーは HTML ページと Java クラスを提供します。さらに、プロセス内 Java サーブレットとして Windchill HTTP ゲートウェイへのアクセスも提供します (この後の説明を参照)。

Web ブラウザおよび Web サーバーに内蔵され、改善中の認証標準を利用するため、Windchill では Web サーバーのユーザー認証機能が使用されます。これらには、HTTP 1.0 基本認証、HTTP 1.1 メッセージダイジェスト認証、デジタル証明書、Windows/NT チャレンジレスポンス認証などが含まれます。Windchill は Web セントリックであるため、顧客の環境に統合されていない古い認証スキームを使用してセキュリティに盲点を作るより、サーバーのユーザー認証を強化することが重要です。たとえば、サイトで LDAP ベースの集中型ユーザーおよびアクセス管理をサポートする Web サーバーを使用している場合、ユーザープリファレンスの補助セットを管理するのではなく、ユーザー認証のために Windchill と自動的に統合されます。

Windchill HTTP ゲートウェイの保護されたインスタンスを設定することによって、統合が行われます。Java アプレットからは、URL にセッションのログインリクエストが送られます。Web サーバーは、ユーザーがそのサーバーのユーザー認証条件を満たすまでアクセスを許可しません。通常、このことは、認証スキームが必要であることを識別するクライアントブラウザに認証されていないレスポンスを返すサーバーに関係します。ブラウザでは、パスワードの入力プロンプトをユーザーに表示することがあり、その後で適切な認証ヘッダーとともにリクエストを再送信して対処します。

本質的には、Web ブラウザと Web サーバーでユーザーのアイデンティティが確立されるまで Windchill は関与しません。確立した時点で、セッションのログオンリクエストと認証されたユーザーのアイデンティティを受け取ります。

認証および認証メソッドのカスタマイズ方法の詳細については、Windchill Help Centerの「基本的なカスタマイズ」および「高度なカスタマイズ」領域にあるカスタマイズ情報を参照してください。

HTTP ゲートウェイは、サーブレットとして実行される Java アプリケーションです。これは、クライアントブラウザと Windchill サービス間の接続の開始点として機能します。HTTP ゲートウェイは (メソッドサーバーに組み込まれている) Embedded Servlet Engine 内に配置され、HTTP サーバー (Web サーバー) と Windchill メソッドサーバー間でリクエストおよびレスポンスをやり取りするためのパイプとして機能します。

HTTP ゲートウェイは特殊なメソッドを呼び出して、HTTP リクエストを処理します。Web サーバーで設定されたリクエストヘッダー (または CGI プロパティ) は、サブミットされたデータとともに Windchill メソッドサーバーに渡されます。起動されたメソッドは、サブミットされたデータを基にリクエストの内容を判断します。HTTP レスポンスを生成するために、該当するサブメソッドが指定されます。HTTP レスポンスは通常、適切なアプレットが埋め込まれた HTML ページの形式で生成されます。

HTTP ゲートウェイへのほとんどのリクエストは、すでに表示されている静的な HTML ページに埋め込まれたリンクの結果として HTML ブラウザウィンドウで発生するか、HTML ブラウザウィンドウにページをブートストラップする AppletContext.showDocument メソッドを使用している Java アプレットで行われます。

これは、2 つのシステムの Java クラスは直接通信できないので、連結したシステムをリンクするための基本的なメカニズムになります。標準 Web ブラウザ HTML ウィンドウで複数の Windchill システムのページを表示すると、クライアントブラウザがスター型ネットワークの中心になり、信頼できないアプレットに課せられた厳しいセキュリティの制約に違反していないシステムにリンクできます。HTTP ゲートウェイに対する適切な GET リクエストをエンコーディングし、Web ブラウザ HTML ウィンドウ内のフレームにこれらのリクエストの送信を任せることによって、リクエストはシステム間に転送されます。

HTTP ゲートウェイは、HTTP GET または POST リクエストによりアクセスされます。通常、Windchill の URL は以下の形式をとります。

メソッドサーバーは <クラス名> と <メソッド名> を使用して、リクエストを特定のメソッドへ渡して処理します。<引数> は URL でエンコードされたクエリー文字列です。クエリ文字列は、呼び出されるメソッドに関連する追加データ (オブジェクト ID など) を提供します。POST リクエストを使用する場合、POST リクエストの本文内にもデータが追加されます。

このデータには、URL がコード化された単純な HTML 形式のデータから、1 つまたは複数のファイルの全コンテンツを含むマルチパート MIME メッセージまで可能です。いずれの場合も、URL はターゲットクラスで形成されるので、ターゲットメソッドで予測できます。

多くのターゲットメソッドは、GET リクエストと POST リクエストの両方を受諾し、GET リクエストの照会文字列または POST リクエストのボディにコード化された URL 形式のデータが含まれていると見込みます。これは、Web サーバーへ単純な HTML を送信した結果として行われる標準のエンコーディングです。それにより、リクエストは、HTML フォームではなく Windchill Java アプレットで生成される場合でも、HTML フォームをこれらのメソッドのテストドライバとして使用できます。

基本的に、URL をエンコード化したフォームデータでは、疑問符 (?) で区切られた名前と値の等しい任意の対が送信されます。すべてのスペースはプラス記号 (+) に置き換えられ、特殊文字はすべて %dd フォーマットの 16 進表現になります。ここで dd は、元の文字を表す 16 進法の ASCII 値です。

HTTP ゲートウェイは、認証されたユーザー認証を確立する際に使用されます。そのためには、まったく同じ 2 つの HTTP ゲートウェイを設定して、そのうち 1 つを公開し、もう 1 つを Web サーバーのユーザーアクセス制御で保護します。Java クライアントは、Windchill メソッドサーバーに対して安全な RMI 呼び出しを実行する目的で有効な認証を確立する必要がある場合、保護された HTTP ゲートウェイを経由してログインリクエストを送信します。Web サーバーは認証されたユーザー名と認証タイプを HTTP ゲートウェイに渡し、その情報が Windchill メソッドサーバーに渡されます。

HTTP ゲートウェイは、リクエストを Windchill メソッドサーバーに配信し、HTTP サーバーによるレスポンスを返すための導管としての役割を果たします。レスポンス内容は、Windchill メソッドサーバーで実行されたメソッドによって制御されます。これらのメソッドは、レスポンスの際に高度な手法で JavaScript または JScript を使用して、HTML ブラウザウィンドウやスタンドアロンの Java ウィンドウを 1 つまたは複数の Windchill システムから管理します。それによって、シームレスな統合環境の体裁を実現します。

ファイルは、チャンクされた RMI アップロードを使用してクライアントからサーバーに転送されます。ファイルは管理可能な 2 つの部分に分割されてからサーバーに送られ、サーバーで再構築されて永続ストレージに挿入されます。この機能にはアプレットクライアントのみがアクセスでき、Windchill コア内では標準ビーンとして利用できます。このビーンには、クライアントのファイルシステムへの直接アクセスがあります。ビーンでは、RMI 転送でファイルをアップロードしたり、Windchill システムからファイルを除去および置換したりできます。

このアップロードアーキテクチャには、一部のブラウザの Java HTTP クラスで制限があることに注意してください。HTTP アップロード手順は使用できますが、アプレットからのコンテンツのアップロードには使用しないでください。HTTP による Windchill サーバーからのダウンロードにはアップロードにあるような制限はないので、ダウンロードでは次に説明する HTTP アーキテクチャを使用できます。

種類の異なるコンテンツタイプで Web ブラウザの表示、保存、および操作機能を活用するには、ファイルの内容を HTTP ゲートウェイを通じて Windchill システムからブラウザにストリームできる必要があります。以下の図に示すように、ファイル転送のリクエストはサーバーの HTTP ゲートウェイに対する適切な HTTP リクエストにコード化されます。次に、Web ブラウザの HTML ウィンドウ内のフレームに、これらのリクエストの送信とレスポンスの受信が任されます。

Windchill メソッドサーバーでは、HTTP のレスポンスはストリーミングインタフェースを使用して生成されるので、レスポンスを任意の大きさにすることができます。下の図に示すように、RMI 結果マーシャルストリームに直接書き込みできるようにするために、RMI 応答マーシャルからレスポンスを生成するメソッドが起動されます。これにより、ファイルをディスクまたはメモリに保存しなくても、ファイル全体をデータベースから直接ストリームできます。

以下の図に示すように、アップロードストリームも HTTP POST リクエストを使用して同様の方法で行われます。この場合、POST リクエストを読み取るメソッドは RMI 引数マーシャルから起動されるので、RMI 引数マーシャルストリームから直接読み取ることができます。

クライアントのファイルシステムに直接アクセスするカスタマイズされた信頼できるアプレットが開発できます。その際、Windchill サーバーとのストリームデータのやり取りの場合と同様の手法を使用できます。ただし、クライアント側の管理の必要上、Windchill アーキテクチャはコードの署名のようなテクニックへの依存度を最小限にするよう試みています。したがって、このタイプのファイル転送を行うクライアントアプレットは、コード署名をサポートできるクライアント基礎構造がサイトに存在する場合にカスタマイズとして構築するのが一般的です。

サーバーマネージャとは、各サーバーホストで稼働する Java アプリケーションを指します。サーバーマネージャのプライマリ役割は一連のメソッドサーバーを管理することですが、ユーザーセッション認証の保守、およびバックグラウンド処理やほかのシステム管理機能も管理します。

各 Windchill サーバーホストには、サーバーマネージャのインスタンスが 1 つあります。これは、独自の Java 仮想マシン (VM) で実行され、Windchill システムで使用できると考えられる場合に稼働している必要があります。インスタンスは常に稼働している必要があるので、このプロセスを Windchill デーモンとして表示できます。

複数のサーバー VM を実行することは、Java アーキテクチャの要件ではありません。信頼性とスケーラビリティを高めるため、Windchill にはこのアーキテクチャが実装されています。複数のメソッドサーバーが稼働できると、1 つの VM 内での共有リソースの競合が制限要因となった場合、高パフォーマンスのマルチプロセッサハードウェアが 1 つの VM で完全に使用不可能になる危険性を抑えることができます。複数のプロセスを使用すると、各 VM の容量以上にシステムそのものを拡張できるので処理するトランザクション率が高くなります。

たとえば、指定のタイプ II (ネイティブメソッド) JDBC ドライバ実装が複数の同時 DB トランザクションスレッドで同期障害を示し始めた場合、第 2 のメソッドサーバーが同時トランザクションに対してシステムの能力を 2 倍にできます。

メソッドサーバーはサーバーマネージャと異なり Windchill 以外のプログラマが開発しカスタマイズされた Java コードが実行されるので、このアーキテクチャでは信頼性も配慮されます。Java VM は信頼性が非常に高いスレッドセーフ環境で、間違ったコードによるほかのスレッドへの影響が抑えられていますが、メモリ消費またはリソースのデッドロックの形で不安定になることもあります。メソッドサーバーでは、データベースのインタフェースまたはほかのアプリケーションに固有のインタフェースにネイティブ (非 Java) のライブラリを使用することもあります。ネイティブライブラリには、VM 全体を不安定にしてしまうようなバグが含まれていることもあります。Windchill システムのデーモン (サーバーマネージャ) とメソッドサーバーのインスタンスを別々の VM に分けておくと、Windchill システムが使用できなくなったりユーザーの検証情報を失ったりすることなく、個々のメソッドサーバーを強制終了できます。

パフォーマンスに関する問題は、メソッドサーバーとサーバーマネージャ間、あるいはクライアントとサーバーマネージャ間で必要なプロセス間の通信を最小限に抑えることによって対処できます。クライアントはサーバーマネージャを使用してメソッドサーバーを 1 度バインドした後、メソッドサーバーを直接呼び出します。メソッドサーバーが後で利用 (強制終了) できなくなると、自動例外処理によってクライアントが新規のものに再びバインドされます。

Windchill Java クライアントは Java RMI を使用して、Windchill サーバーと通信します。RMI を使用するには、メソッドを起動できるリモートオブジェクトへの参照をクライアントでまず取得する必要があります。Java RMI のランタイムでは、ブートストラップレジストリオブジェクトの概念を使用してこの操作が開始されます。クライアントには、ブートストラップレジストリオブジェクトの構築機能が内蔵されています。これによって、クライアントは、レジストリの照合操作を起動して、ほかのリモートオブジェクトへの参照を取得できます。

クライアントとサーバー間のネットワーク接続数だけでなくシステムの複雑さを軽減するために、Windchill ではコンフィギュレーション可能なポート番号を使用して、サーバーマネージャ内の独自のレジストリオブジェクトが実行されます。このレジストリに登録される唯一のオブジェクトは、ローカルサーバーマネージャの実装です。ほかの Java RMI アプリケーションではこのレジストリを共有せず、Windchill はほかの Java RMI アプリケーションで使用するレジストリには依存していません。

デフォルトの RMI レジストリの実装とは異なり、サーバーマネージャで内部的に使用されるレジストリを使用すると、クライアント接続をタイムアウトできるので、多くのユーザーが存在する環境でシステムの拡張性を高めることができます。Windchill システムの内部部分としてブートストラップレジストリを制御する理由の 1 つには、この柔軟性があります。

Windchill サーバーマネージャの主な目的は、必要に応じてクライアントにメソッドサーバーを提供することです。Windchill アーキテクチャでは、信頼性および拡張性の理由により、サーバーマネージャの VM とメソッドサーバーの VM が隔離されています。クライアントは、サーバーマネージャを呼び出してメソッドサーバーへの参照を取得してから、そのサーバーとできるだけ長く直接通信します。複数のメソッドサーバーを利用できる場合は、それらのサーバー間で負荷を分散できるようにするためにサーバーマネージャから参照が返されます。

クライアントでメソッドサーバーの参照を取得するために使用されるプロトコルは、リモートメソッドを起動するクラスに存在します。このプロトコルには、ネットワーク障害やサーバーマネージャを再起動するための障害許容値も含まれ、Windchill カスタマイザからは直接アクセスしないのが一般的です。

サーバーマネージャは、メソッドサーバーを保守する役割を果たします。

サーバーマネージャは、必要に応じてメソッドサーバーを子プロセスとして実行します。管理しきい値の範囲内で、負荷や使用状況に応じて利用できるサーバー数が左右されます。

一般に、Windchill メソッドサーバーはすべて同じように作成されます。すべてが同じ実装のインスタンスで、クライアントからのリクエストを実行するために Java クラスを必要に応じて動的にロードします。ただし、アプリケーション固有のネイティブライブラリの制限などの特異な管理要件を持つ特殊なサーバーを作成できるようにすると、管理しきい値やメソッドサーバーの起動引数を制御する特殊なサーバー名をサーバー管理プロトコルで割り当てることができます。

生成されたほとんどのインタフェースではデフォルトのメソッドサービスが起動されますが、特定のサービス名をリクエストするカスタムインタフェースも構築できます。

エンドユーザーに直接接続しないで操作を実行する必要がある場合があります。これには、定期的 (タイムベース) なアクティビティやユーザー操作によって起動される操作がありますが、ユーザーはそのような処理を待つことはありません。たとえば、オブジェクトを新しいライフサイクル状態にプロモートする操作が実行されたとします。ライフサイクル状態の変更により、ユーザー操作には直接関係しない別の処理が起動されることがあります。これらのアクティビティは、バックグラウンドで実行する必要があります。

Windchill サーバーマネージャでは、バックグラウンド処理が確実に実行されます。キュー処理およびメカニズムの起動を行う実装は、実際には Windchill メソッドサーバーに常駐します。サーバーマネージャでは、バックグラウンド処理を実行できるようにメソッドサーバーのインスタンスで実行状態に維持するだけです。

高度な実装で説明したように、複数のメソッドサーバーを配置し、そのうち 1 つでバックグラウンド処理キューを実行するように環境を設定できます。

キューの設定とメンテナンスの詳細については、バックグラウンドキューについてを参照してください。

Windchill では、HTTP サーバーのユーザー認証機能が使用されます。HTTP ではなく RMI を使用するクライアントリクエストの場合、HTTP で認証されたユーザー名をキャッシュしておく場所が必要になります。これによって、それ以降の RMI 呼び出しにクライアントリクエストを安全に関連付けることができます。サーバーマネージャは各メソッドサーバーのプロセスより長期間存在するデーモンプロセスに相当するので、キャッシュ場所はサーバーマネージャの VM 内になります。

前述のように、クライアントが有効な認証を必要とする場合、HTTP サーバーが保護された Windchill HTTP ゲートウェイへのアクセスを許可するまで Windchill は呼び出されません。認証された HTTP リクエストは、ゲートウェイからメソッドサーバーに渡されて処理されます。メソッドサーバーでは、認証されたユーザー名および関連するセッションプロパティ (リクエスト時に渡される) をサーバーマネージャの VM で稼働するセッションマネージャとともに保存することによって、認証のリクエストが処理されます。

サーバーマネージャでは、セッションデータベースの保守には活動中の接続は使用されません。リソースの消費を抑えるために、クライアントがサーバーマネージャから切断されている場合でも、認証をメソッドサーバーが確認します。活動中の接続の代わりに、限られたサイズの最近使用したキャッシングアルゴリズムが使用されます。セッション認証が無効になった後でもクライアントがまだ活動しているイベントでは、自動例外処理によって認証が再び確立されます。

拡張性という点では、重要なサーバーリソースを各クライアントで無制限に消費しないことが要求されます。使用頻度の低い多くのユーザーにとっては、システムがスーパーサーバーのハードウェアでホストされる必要はありません。サーバーホストのサイズは、ユーザー数ではなくトランザクションのスループットに基づいて決定するようにします。

Java の入出力モデル、特に Java の RMI 実装では、最低 1 つのスレッドが各ネットワーク接続に当てられています。これを多くのユーザーに拡張できるようにするために、Windchill では 2 つのメカニズムを使用してネットワーク接続とスレッドを解放しています。1 つは指定期間アイドル状態にするために、接続をタイムアウトすることです。もう 1 つは RMI ランタイムで消費できるクライアントソケットの合計数を制限することです。この制限は、使用した時期の最も古い接続を閉じることによって実行されます。したがって、新規のクライアント接続は拒否されず、クライアントの負荷が大きいときに比べて接続タイムアウトが速くなります。クライアントは、切断状態から自動的に回復されます。

サーバーマネージャは、Windchill アーキテクチャのデーモン処理であり、メソッドサーバーの起動、終了など Windchill システム管理機能を実行する主要プロセスになります。

JMX MBean を使用してシステム管理機能を実行できますが、一部の操作 (サーバーのシャットダウンなど) は認証ユーザーだけに制限されます。

JMX の詳細については、Java Management Extensions (JMX) の使用を参照してください。

このコンポーネントは、ビジネスオブジェクトトランザクションを表すすべてのメソッドを実行する Java アプリケーションです。アーキテクチャの観点からは、サービスクライアントのリクエストの必要性に応じて、特定の Java クラスを単に動的にロードするスケルトンプロセスとして開始します。以下の図に、メソッドサーバーの構造を示します。

メソッドサーバーのプロセスを開始すると、メソッドサーバーオブジェクトのインスタンスが作成され、リモートオブジェクトとしてサーバーマネージャにエクスポートされます。クライアントはこのオブジェクトの参照をサーバーマネージャから読み込んでメソッドサーバーにバインドし、メソッドサーバーと直接やり取りします。

バインドおよびメソッド起動の方法は、ユーティリティクラスおよび生成されたヘルパークラスによって、アプリケーションの開発者が意識しなくても済むようになっています。そのアーキテクチャに関して重要なのは、Windchill のランタイム動作の方法を説明するのに役立つ点です。

Java RMI を使用してサーバーメソッドを起動する重要な利点は、複雑な任意のオブジェクトグラフをクライアントとサーバー間で転送する内蔵サポートにあります。これによって、トランザクションでは、クライアントサーバーインタフェースの複雑なプログラミングを使用せずに高度な引数と結果を使用できます。

各ビジネスクラスに対応するヘルパークラスを使用すると、サーバー側のメソッドへのアクセスがクライアントに公開されます。ヘルパークラスでは、本来のメソッドが起動されたときにメソッドサーバーに呼び出しを転送する、外部的に利用可能なビジネスクラスのサーバー側のメソッドが確保されます。

インタフェースのモデル化とヘルパークラスの生成の詳細については、Windchill Help Centerの「基本的なカスタマイズ」および「高度なカスタマイズ」領域にあるカスタマイズ情報を参照してください。

メソッドサーバーは、データベースと直接通信する唯一の Windchill プロセスです。この意味では、Windchill ランタイムは典型的な 3 階層のアーキテクチャになっています。共有のデータベースログインを使用すると、ワーカースレッドに割り当てられた複数のデータベース接続がメソッドサーバーで必要に応じて保守され、各トランザクションが実行されます。

データベースへのインタフェースは、ビジネスロジックから実際のデータベースインタフェースを抽出するサーバーの永続オブジェクトマネージャ (POM) レイヤーで実装されます。

永続の詳細については、Windchill Help Centerの「基本的なカスタマイズ」および「高度なカスタマイズ」領域にあるカスタマイズ情報を参照してください。

サーバーマネージャの場合と同様に、拡張性という点では、重要なメソッドサーバーのリソースを各クライアントで無制限に消費しないことが要求されます。したがって、Windchill メソッドサーバーでは、サーバーマネージャと同じメカニズムを使用して、アイドル状態の接続をタイムアウトしたり、RMI ランタイムで消費できるクライアントソケット数を制限したりしています。

Java RMI などの、現在の分散オブジェクトテクノロジーの中にはサーバーからクライアントオブジェクトにコールバックしてフィードバックを提供できるものもありますが、クライアントのフィードバック方法には明らかに問題があります。

まず、このアプローチでは、クライアントがフィードバック呼び出しを受け取るオブジェクトを作成する必要があるので、操作からフィードバックを論理的に分離する処理を強制的に行います。これらのオブジェクトでは、操作に関する状態を維持したり、後でフィードバックを操作に再び関連付けるためにコールに関する十分な情報を渡したりする必要があります。いずれの場合も、サーバーでフィードバックが生成されないと、この余分な負荷が無駄になります。同様に、例外が生じる操作から例外が切り離されていると、困難な例外処理が生じる場合もあります。操作のフィードバックと例外処理での論理的な類似性については、議論の余地があります。

次に、リモートオブジェクトの参照を渡すとオーバーヘッドが生じ、サーバーがコールバックを実行しない場合は無駄になります。あらかじめ参照をキャッシュする (つまり、いったん送信して後で再使用する) ことによってこの無駄をなくそうとすると、元のオブジェクトをエクスポートした通信トランスポートは、そのオブジェクトが使用される時間まで切断されるので、信頼性が損なわれます。Java アプレットでは着信接続を承諾できないので、無効になったクライアント参照は再接続できません。タイムアウトした接続でコールバックしようとすると、サーバーで単に例外が生じることになります。

最後に、アプレットは着信接続を受け入れられないので、HTTP プロキシを通してトンネル化された Java RMI はサーバーにコールバックを許可しません。呼び出し (HTTP) に使用される通信転送が反対方向の呼び出しを十分に処理できないからです。

Windchill アーキテクチャでは、リモートメソッドを起動するプロトコルにライトウェイトのフィードバックメカニズムを導入してこの問題に対処しています。つまり、サーバーからクライアントに RMI 応答マーシャルストリームの一部としてフィードバックオブジェクトを送信できます。これらのオブジェクトは、コールを実行するスレッド内で受信および処理され、コールと同じ通信接続が共有されるので、コールそのものと論理的に結合されたままの状態になります。

クライアントからメソッドを起動する際、RMI 応答マーシャルコードでサーバー側のメソッドが起動され、サーバー側のメソッドでフィードバックオブジェクトを応答ストリームに随意にフラッシュできます。クライアントの応答マーシャルコードでは、これらのオブジェクトがフィードバックとして認識されてクライアントの init メソッドが呼び出され、実際の応答が待ち続けられます。長時間にわたる操作を開始する場合、サーバーメソッドは、進捗状況バーやキャンセルボタンなどの GUI コンポーネントを送信できます。サーバーでは、このコンポーネントを更新するほかのフィードバックオブジェクトを定期的にフラッシュできます。キャンセルボタンは、メソッドサーバーの最初のスレッドを中断するため、2 番目のスレッドの操作キャンセルメソッドを呼び出します。

特定のオブジェクトまたは操作へのアクセスを認証するには、操作を実行するユーザーをメソッドサーバーで確実に識別できる必要があります。ユーザーの認証 (セッションの認証の確実な確立) のさまざまな面については、すでに説明しました。これらをメソッドサーバーに取り入れて、現在の実行スレッドに関連するユーザーについてメソッドで問い合わせできます。この機能によって、アプリケーションはアクセス制御ポリシーを実装できます。アクセス制御ポリシーの詳細については、Windchill ヘルプセンターのポリシー管理セクションを参照してください。

Java RMI には、呼び出しを行うユーザーを確実に識別する固有の手段はありません。ただし、Windchill ランタイムのアーキテクチャは、メソッドサーバーのリモートメソッドを起動するインタフェースでこの要件を満たします。クライアントの認証は RMI メソッドの引数に連動的に含まれ、認証されたユーザー名への RMI スレッドの関連付けにデジタル署名が使用されます。この関連付けはターゲットメソッドが呼び出される前に行われるので、メソッド署名に余分の内容またはユーザー引数を含める必要はありません。情報は、必要に応じて読み込まれます。

操作の実行時に、関連付けを動的に修正することもできます。たとえば、トランザクションを開始するユーザー以外にも、参加者としてそのトランザクションの特定のステップを実行する必要がある場合もあります。調停型の認証委任スキームを実装するために、メソッドで現在実行スレッドに関連付けられている参加者を制御できます。

Windchill には、データベースに保存されているバックグラウンドメソッドキューを使用したバックグラウンド処理があります。キューとは、バックグラウンド処理マネージャで実行されるメソッド起動仕様のテーブルを指します。本来、仕様は、信頼性の理由によりデータベースに保存されているメソッド名とシリアル化された引数 (BLOB として保存) を指します。

バックグラウンド処理を起動するトランザクションには、総合的なトランザクションの一部としてのバックグラウンドメソッドキューの更新があります。この処理をコミットすると、バックグラウンドマネージャに通知され、メソッドが非同期に実行されます。キューからのエントリの除去はメソッドを実行するトランザクション内で行われるので、エントリの処理は 1 回だけしか完了せず、システム障害後の未完了のトランザクションが確実に再開始されます。システム障害が発生すると、エントリは管理者が介入する必要があるとしてマークされ、無視されます。

バックグラウンド処理メカニズムの例として、ライフサイクル処理、ワークフローの自動化、および FTR (全文抽出) インデックスの保守があります。

キューの設定とメンテナンスの詳細については、バックグラウンドキューについてを参照してください。

ログファイルを使用して、例外およびエラーのトレースバックを取り込み、トレーシングメッセージをデバッグします。前者の場合では、例外イベントとしてマークされるログエントリは頻繁に発生しないのが一般的です。ただし、トラブルシューティング用に詳細なログレベルを有効にできます(特定の JIT コンパイラ実装を実行している場合、全トレースバックは使用できません)。

Apache log4j は、Windchill 9.0 以降、ログメッセージの管理および発行のための主なメカニズムとして使用されています。従来のログ機能の中には log4j を利用するように修正されたものもありますが、既存の多くの Windchill ログ機能は以前のリリースのままであり、Windchill プロパティファイルの設定によって管理されています。10.0 リリースでは、従来の一部の Windchill ログ機能が log4j へ移行されました。

ログはパフォーマンスに影響を及ぼすので、デバッグ時以外は詳細モードをオフにしてください。

サーバーアプリケーションごとに (サーバーマネージャとメソッドサーバー)、それぞれログが生成されます。サーブレットおよび JSP のログはメソッドサーバーのログファイルに取り込まれます。