高度なカスタマイズ > サービスおよびインフラストラクチャのカスタマイズ > サーバーロジックの開発 > サービス管理
  
サービス管理
標準の再使用可能な Windchill サービスの開発により、これらのサービスの動作とサービス間の相互作用を管理する一般的なメカニズムが必要になります。このサービス管理メカニズムは、起動、シャットダウン、および複数の Windchill サービス間の通信のためのプロトコルを指定します。
サービスの自動起動
wt.properties コンフィギュレーションファイルには、Windchill サーバーの起動時に自動的に開始するサービスを指定するエントリが含まれています。また、各エントリは、サービスインタフェースと構築されるサービスの実装の組み合わせも指定します。つまり、サービスの標準の実装以外に別の実装が提供された場合、これらのエントリでほかの実装の 1 つの実行を宣言できます。また、一方では、複数のサービスインタフェースを単一クラスで実装することもできます。たとえば、PersistenceManager と PersistenceManagerSvr は、どちらも StandardPersistenceManager で実装されます。以下は、標準の Windchill サービスのエントリの例です。
サービスエントリの番号付け
サービス番号は、サービスの起動順序を示しています。サービスは、番号の小さいものから順に起動されます。サービスがほかのサービスに依存している場合、これらのサービスが先に起動する必要があります。
Windchill サービスまたはカスタマイズされたサービスに予約されている範囲や値はありません。それぞれ新規のリリースで、デフォルトの Windchill サービスに番号が再指定され、新しい番号が割り当てられている場合があります。サービス番号の最大値は 231-1 (=2147483647) です。
カスタマイズしたサービスを定義する場合は、Windchill サービスに使用されている最大の番号よりも明らかに大きい番号のうち、最小のサービス番号を選択する必要があります。Windchill サービスの番号は、インストール場所の <Windchill>/codebase/wt.properties の wt.services.service.#### エントリを調べることで確認できます。Windchill の新規リリースをインストールするたびに、wt.properties でエントリを確認し、カスタマイズしたすべてのサービスの番号が、Windchill サービスの最大の番号より大きいことを確認する必要があります。
カスタマイズしたサービスごとに、サービス番号が既存の Windchill サービスまたはカスタマイズしたサービスの番号と重複していないことを確認する必要があります。
サービスとマネージャ
サービスまたはマネージャと呼ばれるエントリもあります。Windchill 開発の初期の段階で、マネージャという用語とサービスという用語の使用方法は曖昧でした。サービスはより一般的な概念を表し、マネージャはオブジェクトの管理グループのようにより専門的なこれらのサービスを表すとされていました。現在では、マネージャとサービスという用語は同じ意味です。
サービスの起動とシャットダウン
サービスの管理のためには、wt.services.Manager インタフェースを実装する必要があります。このインタフェースは、サービスの開始と終了のメソッドを指定します。
wt.services.StandardManager という名前の wt.services.Manager の参照実装は、サービス管理に必要な基本的な機能のほとんどを提供します。新しいタイプのサービスが特別な起動またはシャットダウン処理を必要としない場合、メソッドをオーバーライドせずに、wt.services.StandardManager 基本クラスを拡張することができます。
通常は、wt.services.StandardManager クラスの 2 つのメソッドは、起動とシャットダウンの処理を専門化するためにオーバーライドされます。これらのメソッドは、performStartupProcess と performShutdownProcess です。起動処理の例には、サービスイベントの購読とバックグラウンド処理で使用するキューの確立が含まれます。
サービス管理
ManagerService は、サービスの起動と定義済みマネージャリストへのアクセスに使用するマネージャです。このリストには、さまざまなサービスのマネージャが含まれています。マネージャの管理のほかに、ManagerService は同期イベント発行サービスを提供します。このサービスでは、イベントキーのすべてのリスナーに、拒否可能イベントまたは拒否不可能イベントを発行できます。各リスナーは、イベントを拒否することも受け入れることもできます。同期イベント発行サービスでは、イベントキーによって識別されるイベントブランチの各イベントリスナー用の "スレッド内またはトランザクション内" の同期通知を実行します。各購読ユーザーに対する notifyEvent 操作を呼び出します。