サービス部品を呼び出すためには，基本的にサービスリクエスタ，受付，HCSCメッセージ配送制御，サービスアダプタ，およびサービス部品が必要です。受付は，サービス部品を呼び出すための要求を受け付けるところで，標準受付とユーザ定義受付があります。

標準受付とは，HCSCサーバが標準提供している，サービスリクエスタからの要求電文を受け付けるための機能（インターフェース）です。ユーザ定義受付とは，開発環境でユーザが定義したものをHCSCサーバに配備してから，サービスリクエスタからの実行要求を受け付けるための機能（インターフェース）で，ユーザが定義した任意のインターフェースで受け付けることができます。

(a)　標準受付の場合

標準受付を使用する場合の構造と開発の流れとの関係を次の図に示します。

図5-3　標準受付を使用する場合の構造と開発の流れとの関係

サービス部品を呼び出すサービスリクエスタとHCSCサーバ，およびサービス部品の関係は，次のようになっています。開発の流れに沿って，それぞれの関係を説明します。

• サービス部品側の開発の流れ
  最初に呼び出すサービス部品を作成します。次に，呼び出すサービス部品に合わせた形式の電文フォーマットやビジネスプロセス定義（BPEL）を作成し，開発環境で電文フォーマットからサービスアダプタを定義したり，ビジネスプロセスを定義したりします（ビジネスプロセスにも電文フォーマットを定義します）。呼び出すサービス部品に合わせた形式の電文フォーマットを作成する方法は，使用するプロトコル（SOAP，RMI-IIOP，WS-R，およびJMS）によって異なります。定義したサービスアダプタやビジネスプロセスは実行環境（HCSCサーバ）へ配備します。
  
• サービスリクエスタ側の開発の流れ
  サービス部品の作成後，定義したサービスアダプタやビジネスプロセスを呼び出すサービスリクエスタを作成します。サービスリクエスタを作成する方法については，使用する標準受付のプロトコルによって異なります。
  

電文フォーマット，ビジネスプロセス定義（BPEL），およびサービスリクエスタの作成については，マニュアル「Cosminexus サービスプラットフォーム　開発ガイド」を参照してください。

(b)　ユーザ定義受付の場合

ユーザ定義受付を使用する場合の構造と開発の流れとの関係を次の図に示します。

図5-4　ユーザ定義受付を使用する場合の構造と開発の流れとの関係

SOAP通信を使用する場合は，ユーザ定義受付を使用できます。サービス部品を呼び出すサービスリクエスタとHCSCサーバ，およびサービス部品の関係は，次のようになっています。開発の流れに沿って，それぞれの関係を説明します。

• サービス部品側の開発の流れ
  最初に呼び出すサービス部品を作成します。次に，呼び出すサービス部品に合わせた形式の電文フォーマットやビジネスプロセス定義（BPEL）を作成し，開発環境で電文フォーマットからサービスアダプタを定義したり，ビジネスプロセスを定義したりします（ビジネスプロセスにも電文フォーマットを定義します）。定義したサービスアダプタ，ビジネスプロセス，およびユーザ定義受付は実行環境（HCSCサーバ）へ配備します。
  
• 受付側の開発の流れ
  サービス部品の作成後，呼び出すビジネスプロセスの電文フォーマットに合わせたWSDLを作成し，開発環境でユーザ定義受付を定義します。
  
• サービスリクエスタ側の開発の流れ
  ユーザ定義受付の作成後，定義したユーザ定義受付を呼び出すサービスリクエスタを作成します。ユーザ定義受付を定義するときに使用したWSDLからスタブを生成し，スタブを呼び出すサービスリクエスタを作成します。
  

電文フォーマット，ビジネスプロセス定義（BPEL），ユーザ定義受付，およびサービスリクエスタの作成については，マニュアル「Cosminexus サービスプラットフォーム　開発ガイド」を参照してください。

サービスリクエスタからサービス部品を呼び出す流れは，受付の種類と呼び出すHCSCコンポーネントの組み合わせによって動作が異なります。受付の種類と呼び出すHCSCコンポーネントの組み合わせを次に示します。

(a) 標準受付からサービスアダプタを直接呼び出す場合

(b) 標準受付からビジネスプロセスを呼び出す場合

(c) ユーザ定義受付からビジネスプロセスを呼び出す場合

これらの場合について，次に説明します。エラー時の処理の流れについては「7.　障害対策」を参照してください。

(a)　標準受付からサービスアダプタを直接呼び出してサービス部品を実行する場合

標準受付からサービスアダプタを直接呼び出してサービス部品を実行する場合，サービスアダプタで定義したサービス名をサービスリクエスタで指定して実行します。実行すると，サービスアダプタで定義したサービス部品を呼び出します。

サービスアダプタを直接呼び出す場合の電文の流れを次の図に示します。

図5-5　サービスアダプタを直接呼び出す場合の電文の流れ

1. サービスリクエスタから標準受付に送信する要求電文は，開発環境でサービスアダプタを定義したときに設定した（サービス部品の形式に合わせた）電文フォーマットを使用します。そのため，サービスリクエスタ内で，サービスアダプタで定義した電文フォーマットに合わせた要求電文を作成し，作成した電文を標準受付のパラメタ（ユーザ電文のパラメタ）に設定して実行します。
2. サービスアダプタからサービス部品を呼び出します。呼び出すときは，サービスアダプタで定義した要求電文を使用します。このように，サービスリクエスタから送信する要求電文とサービス部品が受け取る要求電文は同一になります。なお，サービス部品の電文フォーマット以外の電文フォーマットでも，サービスアダプタでデータ変換定義をすれば，サービスリクエスタから要求できます。
3. サービス部品からサービスアダプタに応答電文を送信します。応答電文は，サービスアダプタで定義した応答電文と同じ電文フォーマットを使用します。
4. サービスリクエスタへ応答します。応答には，サービスアダプタで定義した応答電文の電文フォーマットを使用します。このように，サービス部品から返す応答電文とサービスリクエスタで受け取る応答電文は同一になります。

データ変換定義については，マニュアル「Cosminexus サービスプラットフォーム　開発ガイド」を参照してください。

(b)　標準受付からビジネスプロセスを呼び出してサービス部品を実行する場合

標準受付からビジネスプロセスを呼び出してサービス部品を実行する場合，ビジネスプロセスで定義したサービス名（ビジネスプロセス名）をサービスリクエスタで指定して実行します。そして，ビジネスプロセスに定義したプロセスに従って，処理を実行します。プロセスはアクティビティから構成されています。その中の，サービス部品呼出アクティビティでは，定義されたサービスアダプタを呼び出して，サービスアダプタに定義されたサービス部品を実行します。ビジネスプロセスを呼び出す場合の電文の流れを次の図に示します。

図5-6　ビジネスプロセスを呼び出す場合の電文の流れ

1. サービスリクエスタ内で，ビジネスプロセスの受付アクティビティで定義した要求電文の電文フォーマットに合わせた要求電文を作成し，作成した電文を標準受付のパラメタ（ユーザ電文のパラメタ）に設定して実行します。サービスリクエスタで指定する要求電文は，ビジネスプロセスの受付アクティビティに定義した電文フォーマットを使用します。
2. ビジネスプロセスからサービス部品を呼び出します。呼び出すときは，サービス呼出アクティビティで定義した要求電文を使用します。この要求電文の電文フォーマットは，呼び出すサービス部品のサービスアダプタで定義した要求電文の形式と同じである必要があります。なお，サービス部品の電文フォーマット以外の電文フォーマットでも，サービスアダプタでデータ変換定義をすれば，サービス呼出アクティビティから要求できます。
3. サービス部品からサービスアダプタに応答電文を送信します。応答電文は，ビジネスプロセスのサービス呼出アクティビティの応答電文と同じ電文フォーマットを定義します。
4. サービスリクエスタへ応答します。応答には，ビジネスプロセスの応答アクティビティで定義した応答電文の電文フォーマットを使用します。

データ変換定義については，マニュアル「Cosminexus サービスプラットフォーム　開発ガイド」を参照してください。

(c)　ユーザ定義受付からビジネスプロセスを呼び出してサービス部品を実行する場合

ユーザ定義受付は，ビジネスプロセスの呼び出しをする場合にだけ使用できます。サービスリクエスタからは，HCSCサーバで定義したサービス名（ビジネスプロセス名）などは指定しないで，ユーザ定義受付に定義したWSDLを使用して要求します。ユーザ定義受付に定義したWSDLは，ビジネスプロセスの受付アクティビティに定義した電文フォーマットに形式を合わせます。

開発環境での定義に従ってユーザ定義受付からビジネスプロセスを呼び出し，ビジネスプロセスに定義したプロセスに従って，処理を実行します。サービス呼出アクティビティでは，定義されたサービスアダプタを呼び出し，サービスアダプタに定義されたサービス部品を実行します。ユーザ定義受付を使う場合の電文の流れを次の図に示します。

図5-7　ユーザ定義受付を使う場合の電文の流れ

1. サービスリクエスタからの要求電文は，ビジネスプロセスの受付アクティビティに定義した電文フォーマットと同一のものになります。そのため，ビジネスプロセスの受付アクティビティに定義した電文フォーマットに合わせた形式のWSDLを開発環境のユーザ定義受付定義で設定する必要があります。サービスリクエスタからユーザ定義受付を呼び出すときは，開発環境でユーザ定義受付に定義したWSDLを使用します。WSDLからWSDL2Javaコマンドを使用してスタブを生成し，スタブを呼び出すようにサービスリクエスタを実装します。
2. ビジネスプロセスからサービス部品を呼び出すときは，サービス呼出アクティビティで定義した要求電文を使用します。この要求電文の電文フォーマットは，呼び出すサービス部品のサービスアダプタで定義した要求電文の形式と同じである必要があります。
3. サービス部品からの応答電文もビジネスプロセスのサービス呼出アクティビティの応答電文で同じ電文フォーマットを定義します。なお，サービス部品の電文フォーマット以外の電文フォーマットでも，サービスアダプタでデータ変換定義をすれば，サービス呼出アクティビティから要求できます。
4. サービスリクエスタへの応答は，ビジネスプロセスの応答アクティビティで定義した応答電文の電文フォーマットを使用します。この電文フォーマットは開発環境のユーザ定義受付定義で設定するWSDLの応答電文と同じ形式である必要があります。

データ変換定義については，マニュアル「Cosminexus サービスプラットフォーム　開発ガイド」を参照してください。

サービス部品側の電文フォーマットと異なる電文でサービス部品を呼び出す場合，またはサービス部品側の電文フォーマットと異なる電文を応答として受信する場合は，開発環境で標準電文フォーマットを定義します。また，標準電文フォーマットとサービス部品電文フォーマットの変換ルールを定義したデータ変換定義は，開発環境で定義します。標準電文フォーマットの電文をサービス部品電文フォーマットの電文に変換することでサービス部品を呼び出せます。標準電文フォーマットとデータ変換定義の関係を次の図に示します。

図5-8　標準電文フォーマットとデータ変換定義の関係

1. サービスリクエスタからは，標準電文フォーマットの形式に合わせた電文フォーマットを要求電文に指定して，サービス部品の呼び出しを要求します。
2. サービスアダプタでは標準電文フォーマットからサービス部品電文フォーマットにデータを変換し，変換後の電文フォーマットでサービス部品を呼び出します。
3. サービス部品からの応答についても，サービスアダプタで，サービス部品電文フォーマットから標準電文フォーマットにデータを変換します。
4. サービスリクエスタに標準電文フォーマットを応答します。

複数のサービスアダプタがある場合も，図5-9に示すようにService1用のサービスアダプタ，Service2用のサービスアダプタ，Service3用のサービスアダプタで，それぞれに同一の標準電文フォーマットAと，それぞれのデータ変換定義を定義すると，サービスリクエスタ側から要求するときに，要求時のサービス名（Service1など）を変更すれば，同じ要求電文で要求できます。

図5-9　複数のサービスアダプタで同一の標準電文フォーマットを定義した場合の流れ

標準電文フォーマット，サービス部品電文フォーマット，およびデータ変換定義については，マニュアル「Cosminexus サービスプラットフォーム　開発ガイド」を参照してください。

HCSCサーバ内のサービス部品呼び出し要求とその流れを区別するために，各要求電文にメッセージ共通IDとサービスリクエストIDが割り当てられます。これらのIDは電文の実行履歴，メッセージログ，リクエストトレース，および性能解析トレースで出力されます。

メッセージ共通IDとサービスリクエストIDをたどることで，サービス部品呼び出しの処理の流れを追跡できます。電文の追跡については「7.7　サービス部品呼び出し要求時の障害対策」を参照してください。

なお，HCSCサーバに割り当てられる識別情報のほかに，ユーザが任意の値を設定できるクライアント相関IDがあります。

(a)　識別情報の種類

• メッセージ共通ID
  サービスリクエスタからサービス部品呼び出し要求を受け取ったタイミングで自動的に割り当てられます。応答まで同じメッセージ共通IDを使用します。
  サービスリクエスタからビジネスプロセスを呼び出す場合でも，ビジネスプロセス内の個々のサービス部品呼び出し処理を同一の処理として識別できます。メッセージ共通IDの形式を次に示します。
  

  CSC_[サーバ名]_[受付時刻(ミリ秒)]_[通番]

  　注　末尾に与えられる通番は，「1」から順番に割り当てられる番号です。

  （例）CSC_CSCServerName_2008-04-20_11:32:18.360_1
  　

• サービスリクエストID
  HCSCサーバ内の個別のサービス部品呼び出し処理ごとに割り当てられる識別情報です。
  サービスリクエスタからのサービス部品呼び出し要求を受け取ったタイミングだけでなく，ビジネスプロセスからのサービス部品呼び出し処理を実施するタイミングでも割り当てられます。サービスリクエストIDの形式を次に示します。
  

  MSG_[サーバ名]_[受付種別]_[受付時刻(ミリ秒)]_[通番]

  　注　末尾に与えられる通番は，「1」から順番に割り当てられる番号です。

  （例）MSG_CSCServerName_MDBWSR_2008-04-20_11:32:18.360_1
  　

• ビジネスプロセスインスタンスID
  ビジネスプロセスの個々のプロセスインスタンスを特定するための識別情報（プロセスインスタンスの識別子）です。サービスリクエスタからビジネスプロセスの再実行を要求する場合や，プロセスインスタンスの実行履歴を削除するときに使用します。
  

(b)　識別情報が割り当てられるタイミング

標準受付から直接サービスアダプタを呼び出す場合は，メッセージ共通IDおよびサービスリクエストIDは，HCSCサーバ内で識別情報として引き継がれます。標準受付やユーザ定義受付からビジネスプロセスを経由してサービスアダプタを呼び出す場合は，メッセージ共通IDは，HCSCサーバ内で識別情報として引き継がれます。しかし，サービスリクエストIDは，サービス部品呼び出し処理ごとの識別情報として引き継がれます。また，ビジネスプロセスインスタンスIDは，ビジネスプロセスが最初に要求を受け付けるときに割り当てます。

メッセージ共通IDとサービスリクエストIDが割り当てられるタイミングを次の図に示します。

図5-10　識別情報割り当てのタイミング

(a)　HCSCサーバ内の多重度

サービスリクエスタからのサービス部品の呼び出し要求が同時に実行される場合があるため，これを考慮して，サービス部品呼び出し処理の多重度（同時に実行できる数）を設定する必要があります。多重度の設定が良くない場合，性能上のボトルネックになるおそれがあります。多重度の設定によってボトルネックになる例を次の図に示します。

図5-11　多重度の設定によってボトルネックになる例

図5-11に示すように，リクエスト受付（標準受付またはユーザ定義受付）の多重度が小さいと，一度にたくさん要求が来ても同時に処理ができないため，一度に実行できる処理が少なくなります。また，リクエスト受付の多重度を大きくしても，サービスアダプタで定義している多重度が小さいと，サービスアダプタで一度に実行できる処理が少ないため，サービスアダプタがボトルネックになり，意図した性能を得られなくなります。

多重度は，標準の同期受付（Webサービス）の場合は，スレッド数および最大同時実行数で設定します。標準の同期受付（SessionBean）の場合は，インスタンス数で設定します。HCSCサーバ内の多重度の設定について，表5-6，表5-7，および表5-8に示します。

表5-6　標準受付の多重度を設定するプロパティ

定義ファイル	プロパティ	内容
HCSCサーバランタイム定義ファイル	request-ejb.instance.minimum	標準の同期受付（SessionBean）のインスタンス最小数
	request-ejb.instance.maximum	標準の同期受付（SessionBean）のインスタンス最大数
	request-ejb.parallel.count	CTMがアプリケーションを呼び出すために用意するスレッド数
	request-soap.instance.minimum	標準の同期受付（Webサービス）の最小同時実行数
	request-soap.instance.maximum	標準の同期受付（Webサービス）の最大同時実行数
	request-jms.instance.maximum	標準の非同期受付（MDB（WS-R））のインスタンス最大数

表5-7　ユーザ定義受付の多重度を設定するプロパティ

定義ファイル	プロパティ	内容
ユーザ定義受付ランタイム定義ファイル	user-defined-reception-soap.threads.maximum	最大同時実行数

表5-8　サービスアダプタの多重度を設定する項目

画面	内容
開発環境でのサービスアダプタ定義画面	最大インスタンス数

注　最大インスタンス数に0を指定した場合は，上限が設定されないで無制限になります。

Webサービス（SOAP通信）の場合，同時実行数のほかにWebコンテナレベルでの最大キュー滞留数を設定できます。最大同時実行数と最大キュー滞留数を設定しておくと，サービスリクエスタからの要求を受けたときに，実際の処理をしないで処理を待たせておけるため，流量制御ができます。サービスリクエスタからの要求と最大キュー滞留数の関係を次の図に示します。

図5-12　サービスリクエスタからの要求と最大キュー滞留数の関係

例えば，図5-12に示すように，最大同時実行数を3とした場合，最大キュー滞留数を10にしておくと，同時にきたサービス部品呼び出し要求のうち，3件までは同時に処理されます。同時実行数より多くのサービス部品呼び出し要求（4件以上）がきた場合は，最大キュー滞留数（10件）までは，処理待ちの状態となり，先に実行されている処理が終わり次第，順次処理が実行されます。

最大キュー滞留数の数が上限（10件）まで達している場合に，さらにサービスリクエスタからサービス部品呼び出し要求がきた場合は，要求は受け付けられないため，エラーとしてサービスリクエスタに応答されます。

HCSCサーバ内の最大キュー滞留数は，表5-9および表5-10に示す定義ファイルのプロパティで設定します。

表5-9　標準受付の最大キュー滞留数を設定するプロパティ

定義ファイル	プロパティ	内容
HCSCサーバランタイム定義ファイル	request-soap.queue-size	標準の同期受付（Webサービス）の実行待ちキューのサイズ

表5-10　ユーザ定義受付の最大キュー滞留数を設定するプロパティ

定義ファイル	プロパティ	内容
ユーザ定義受付ランタイム定義ファイル	user-defined-reception-soap.queue-size	実行待ちキューサイズ

(b)　データベースへのアクセスに関する多重度

永続化するビジネスプロセスを使用する（プロセスインスタンスの実行履歴を採取する）場合，非同期プロトコルを使用する場合，および電文の実行履歴を採取する場合は，HCSCサーバに設定するDB Connectorの定義で，コネクションプール数を設定します。

• 永続化するビジネスプロセスを使用する場合
  HCSCサーバに設定した二つのDB Connectorのうち，HCSCサーバセットアップ定義ファイルのdbcon-xadisplaynameプロパティに指定したDB Connectorを使用します。リクエスト受付からビジネスプロセスを経由して，一度に多くの要求が来ても，DB Connectorの部分でデータベースへの出力が一度にできなくなります。すると，性能上のボトルネックが発生して，その結果，ビジネスプロセスの同時実行処理性能が遅くなります。そのため，プロセスインスタンスの実行履歴を採取するときの多重度を設定する必要があります。永続化するビジネスプロセスを使用する場合のボトルネックを次の図に示します。
  

  図5-13　永続化するビジネスプロセスを使用する場合のボトルネック

  

• 非同期プロトコルを使用する場合
  HCSCサーバに設定した二つのDB Connectorのうち，HCSCサーバセットアップ定義ファイルのdbcon-xadisplaynameプロパティに指定したDB Connectorは，非同期（MDB（WS-R）またはMDB（DBキュー））の標準受付でキューからメッセージを取り出したり，非同期（MDB（WS-R）またはMDB（DBキュー））のサービスアダプタでメッセージを送信したりするときにも使用します。そのため，プロセスインスタンスの実行履歴を採取するときの多重度に加えて，HCSCサーバがリクエスト受付のキューからメッセージを取り出すときや，サービスアダプタが転送キューにメッセージを送信するときの多重度も含めて，コネクションプール数を検討する必要があります。
  キューに対して一度に多くの要求が来ても，Cosminexus RMのリソースアダプタが同時にメッセージの取り出し処理ができないで，性能上のボトルネックが発生します。また，サービスアダプタの多重度を大きくしていても，サービスアダプタがキューにメッセージを送信するときの同時実行数が少ないと，やはり性能上のボトルネックが発生します。非同期プロトコルを使用する場合のボトルネックを次の図に示します。
  

  図5-14　非同期プロトコルを使用する場合のボトルネック

  

• 電文の実行履歴を採取する場合
  HCSCサーバに設定した二つのDB Connectorのうち，HCSCサーバセットアップ定義ファイルのdbcon-nodisplaynameプロパティに指定したDB Connectorを使用します。リクエスト受付に一度に多くの要求が来ても，DB Connectorの部分でデータベースへの出力が一度にできなくなるため，性能上のボトルネックが発生して，その結果，サービス部品呼び出しの同時実行処理性能が遅くなります。そのため，電文の実行履歴を採取するときの多重度を設定する必要があります。電文の実行履歴を採取する場合のボトルネックを次の図に示します。
  

  図5-15　電文の実行履歴を採取する場合のボトルネック

  

データベースへのアクセスに関する多重度は，次の表に示すように設定します。

表5-11　DB Connectorの多重度を設定するプロパティ

定義ファイル	プロパティ	内容
DB Connector（LocalTransactionまたはXATransaction）のセットアップ時に設定する属性ファイル	MinPoolSize	プールの最小値
	MaxPoolSize	プールの最大値
DB Connector（NoTransaction）のセットアップ時に設定する属性ファイル	MinPoolSize	プールの最小値
	MaxPoolSize	プールの最大値

注1　プールの最大値を増やした場合，データベース側の同時接続数も変更する必要があるため，注意が必要です（HiRDBの場合，pd_max_users（HiRDBの最大接続数）となります）。

注2　実行環境が使用するDBコネクション数の最大値については，「表3-1　実行環境が使用するDBコネクションの数」を参照してください。

表5-12　Cosminexus RMの多重度を設定するプロパティ

定義ファイル	プロパティ	内容
Cosminexus RMのセットアップ時に設定する属性ファイル	MinPoolSize	プールの最小値
	MaxPoolSize	プールの最大値

(c)　Webサービス（SOAP通信）に関する多重度

Webサービス（SOAP通信）を使用する場合は，実行環境で設定しているWebサーバ（HTTPサーバ）の同時実行スレッド数も関係します。

Webサービス（SOAP通信）の標準受付やユーザ定義受付が複数ある場合，

各受付に設定した同時実行スレッド数の合計より，Webサーバに設定した全体の同時実行スレッド数が優先されます。そのため，Webサーバに設定した全体の同時実行スレッド数が，各受付に設定した同時実行スレッド数の合計より小さいと，一度に多くの要求が来ても同時に処理ができないため，性能上のボトルネックになることがあります。Webサービス（SOAP通信）を使用する場合のボトルネックを次の図に示します。

図5-16　Webサービス（SOAP通信）を使用する場合のボトルネック

Webサービス（SOAP通信）に関する多重度は，次のように設定します。

• Hitachi Web Serverの場合
  コンフィグファイルに指定できるディレクティブでのサーバの性能についての定義をします。
  詳細については，マニュアル「Hitachi Web Server」を参照してください。
  
• インプロセスHTTPサーバ機能の場合
  運用管理ポータルの[論理サーバの環境設定]−[J2EEサーバ]−[J2EEサーバの論理サーバ名]−[HTTPサーバ]で次の内容を設定します。
  
  • 同時実行スレッド数
  • 初期スレッド数
  詳細については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。
  

なお，Webサーバ（HTTPサーバ）の同時実行スレッド数が十分な数を確保できない状況であっても，個々のリクエスト受付で必ず最低限の実行をする場合は，占有スレッド数を定義します。

占有スレッド数を定義した場合は，Webサーバ（HTTPサーバ）の同時実行スレッド数以上の要求が個別のリクエスト受付に来た場合でも，必ず指定した数だけは同時に実行されます。

ほかのリクエスト受付に要求が来ていない場合は，最大同時実行数まで同時に実行できます。

HCSCサーバ内の占有スレッド数は，表5-13および表5-14に示すように設定します。

表5-13　標準受付の占有スレッド数を設定するプロパティ

定義ファイル	プロパティ	内容
HCSCサーバランタイム定義ファイル	request-soap.exclusive.threads	標準の同期受付（Webサービス）の占有スレッド数

表5-14　ユーザ定義受付の占有スレッド数を設定するプロパティ

定義ファイル	プロパティ	内容
ユーザ定義受付ランタイム定義ファイル	user-defined-reception-soap.exclusive.threads	占有スレッド数

最大同時実行数と占有スレッド数の関係を次の図に示します。

図5-17　最大同時実行数と占有スレッド数の関係

図5-17に示すように，標準受付，二つのユーザ定義受付，およびWebサーバ（HTTPサーバ）を次のように設定した場合，標準受付は必ず二つのスレッドを占有します。

• 標準受付：最大キュー滞留数10，同時実行数3，占有スレッド数2
• ユーザ定義受付：同時実行数2
• Webサーバ（HTTPサーバ）：同時実行数5

そのため，Webサーバ（HTTPサーバ）の同時実行数に指定した5件以上の要求が来ると，二つのスレッドは標準受付の実行のために使用され，残りの三つのスレッドを使ってユーザ定義受付が動作します。

ただし，最大キュー滞留数，標準受付の同時実行数，占有スレッド数，およびWebサーバ（HTTPサーバ）の同時実行数が図5-17と同じ場合で，図5-18に示すように，占有スレッド数を指定した標準受付に要求が来ていないときでも，必ず二つはスレッドを占有して実行する状態になります。また，ほかのユーザ定義受付では，それぞれ同時実行数が2件で合計の同時実行数は4件になるはずですが，Webサーバ（HTTPサーバ）の同時実行数5件であるため，残り三つしか処理できなくなります。ほかのリクエスト受付の同時実行数が増えることはありません。

図5-18　占有スレッド数を指定した受付に要求が来ない場合

同期のサービス部品呼び出しの場合，応答が返って来ない場合のタイムアウト値を設定することで，無応答でハングアップすることを回避できます。

また，サービス部品での実際の処理に掛かる最大時間を考慮して，タイマを設定する必要があります。設定できるタイマについて次の図に示します。

図5-19　設定できるタイマ

図5-19の各項番は次のタイマを示しています。

1. サービス部品に接続するときのタイマ（Webサービス）
2. サービス部品に接続するときのタイマ（SessionBean）
3. HCSCサーバに接続するときのタイマ（Webサービス）
4. HCSCサーバに接続するときのタイマ（SessionBean）
5. HCSCサーバ内のトランザクションのタイマ

タイマは接続先やプロトコルによって設定方法が異なります。

(a)　サービス部品に接続するときのタイマ（Webサービス）

サービス部品（Webサービス）に接続する場合，書き込み，読み込み，および接続時のタイマを設定できます。

• 書き込み時のタイマ
  HTTPおよびHTTPS（TCP/IP通信）で使用するソケットに対するwrite（データ送信）処理でのタイムアウト値を設定します。接続確立後のデータ送信が完了しない場合などで有効となります。
  
• 読み込み時のタイマ
  HTTPおよびHTTPS（TCP/IP通信）で使用するソケットに対するread（データ受信）処理でのタイムアウト値を設定します。接続確立後のデータ受信が完了しない場合などで有効となります。
  
• 接続時のタイマ
  HTTPおよびHTTPS（TCP/IP通信）で使用するソケットに対するconnect（ソケット接続）処理でのタイムアウト値を設定します。接続確立時の要求に対する応答がない場合などで有効となります。
  

(i)タイムアウト値の設定

サービス部品に接続するときのタイマ（Webサービス）は，HCSCサーバ全体に設定したり，サービスアダプタ個別に設定したりできます。設定方法を次に示します。

• HCSCサーバ全体の設定
  HCSCサーバ稼働マシンでのSOAP通信基盤（Cosminexus Web Services）のサーバ定義ファイルで定義します。サーバ定義ファイルの設定の詳細については，マニュアル「Cosminexus　SOAPアプリケーション開発ガイド」を参照してください。
  

  表5-15　HCSCサーバ全体のタイマ（Webサービス）の設定

  値	キー名称	デフォルト値（秒）
  サーバ兼クライアントのソケットの書き込みタイムアウト値	c4web.application.<識別子>.socket_write_timeout	60
  サーバ兼クライアントのソケットの読み込みタイムアウト値	c4web.application.<識別子>.socket_read_timeout	300
  サーバ兼クライアントのソケットの接続タイムアウト値	c4web.application.<識別子>.socket_connect_timeout	60

• サービスアダプタ個別の設定
  開発環境で定義する場合，サービスアダプタ定義画面のクライアント定義ファイルに指定するファイルで設定します。クライアント定義ファイルの設定の詳細については，マニュアル「Cosminexus　SOAPアプリケーション開発ガイド」を参照してください。
  

  表5-16　サービスアダプタ個別のタイマ（Webサービス）の設定

  値	キー名称	デフォルト値（秒）
  クライアントのソケットの書き込みタイムアウト値	c4web.application.socket_write_timeout	60
  クライアントのソケットの読み込みタイムアウト値	c4web.application.socket_read_timeout	300
  クライアントのソケットの接続タイムアウト値	c4web.application.socket_connect_timeout	60

(ii)タイムアウト値の変更

すでにHCSCサーバに配備しているサービスアダプタに対して運用環境で定義する場合は，cscsvcctlコマンドを使用して，サービス部品呼び出しの通信タイムアウト値を変更します。変更方法の詳細については，「5.2.28　サービス部品呼び出しの通信タイムアウト値を変更する」を参照してください。コマンドの使い方については，「10.　コマンド」の「cscsvcctl（サービス情報の管理）」を参照してください。

表5-17　タイマ（Webサービス）の設定値の変更

値	キー名称
書き込みタイムアウト値	<クラスタ名>.<サービスID>.WebService.c4web.application.socket_write_timeout
読み込みタイムアウト値	<クラスタ名>.<サービスID>.WebService.c4web.application.socket_read_timeout
接続タイムアウト値	<クラスタ名>.<サービスID>.WebService.c4web.application.socket_connect_timeout

(b)　サービス部品に接続するときのタイマ（SessionBean）

(i)タイムアウト値の設定

サービス部品に接続するときのタイマ（SessionBean）は，HCSCサーバ全体に設定したり，サービスアダプタ個別に設定したりできます。設定方法を次に示します。

• HCSCサーバ全体の設定
  HCSCサーバ稼働マシンのCosminexusで，EJBコンテナでタイムアウトを設定します。RMI-IIOP通信のタイムアウトの詳細については，マニュアル「Cosminexus　機能解説」を参照してください。また，定義の詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。
  

  表5-18　HCSCサーバ全体のタイマ（SessionBean）の設定

  値	設定するファイル	キー名称	デフォルト値（秒）
  RMI-IIOP通信すべてに有効となるタイムアウト値	EJBクライアントアプリケーション用ユーザプロパティファイル（usrconf.properties）	ejbserver.rmi.request.timeout	0 （タイムアウトしません）
  CORBAネーミングサービス部品との通信でのタイムアウト値		ejbserver.jndi.request.timeout	0 （タイムアウトしません）

• サービスアダプタ個別の設定
  開発環境で定義する場合，サービスアダプタ定義画面のクライアント定義ファイルに指定するファイルで設定します。クライアント定義ファイルの設定の詳細については，マニュアル「Cosminexus　SOAPアプリケーション開発ガイド」を参照してください。
  

  表5-19　サービスアダプタ個別のタイマ（SessionBean）の設定

  値	キー名称	デフォルト値（秒）
  呼び出しタイムアウト値	c4web.application.ejb_j2ee_timeout	0 （タイムアウトしません）

(ii)タイムアウト値の変更

すでにHCSCサーバに配備しているサービスアダプタに対して運用環境で定義する場合は，cscsvcctlコマンドを使用して，サービス部品呼び出しの通信タイムアウト値を変更します。変更方法の詳細については，「5.2.28　サービス部品呼び出しの通信タイムアウト値を変更する」を参照してください。コマンドの使い方については，「10.　コマンド」の「cscsvcctl（サービス情報の管理）」を参照してください。

表5-20　タイマ（SessionBean）の設定値の変更

値	キー名称
呼び出しタイムアウト値	<クラスタ名>.<サービスID>.SessionBean.c4web.application.ejb_j2ee_timeout

(c)　HCSCサーバに接続するときのタイマ（Webサービス）

HCSCサーバに接続するときのタイマ（Webサービス）は，サービスリクエスタ稼働マシン側で設定します。サービスリクエスタの稼働しているマシン全体に設定したり，サービスリクエスタ個別に設定したりできます。サービスリクエスタ稼働マシンでSOAP通信基盤（Cosminexus Web Services）を使用している場合の設定方法を次に示します。

• サービスリクエスタ稼働マシン全体の設定
  サービスリクエスタ稼働マシンでのSOAP通信基盤（Cosminexus Web Services）のサーバ定義ファイルで定義します。設定内容は「(a) サービス部品に接続するときのタイマ（Webサービス）」の場合と同様です。サーバ定義ファイルの設定の詳細については，マニュアル「Cosminexus　SOAPアプリケーション開発ガイド」を参照してください。
  
• サービスリクエスタ個別の設定
  作成するサービスリクエスタごとに個別に設定する場合，サービスリクエスタを実行するときに指定するクライアント定義ファイルで設定します。設定内容は「(a) サービス部品に接続するときのタイマ（Webサービス）」の場合と同様です。クライアント定義ファイルの設定の詳細については，マニュアル「Cosminexus　SOAPアプリケーション開発ガイド」を参照してください。
  

(d)　HCSCサーバに接続するときのタイマ（SessionBean）

HCSCサーバに接続するときのタイマ（SessionBean）は，サービスリクエスタの稼働しているマシン全体に設定したり，サービスリクエスタ個別に設定したりできます。設定方法を次に示します。

HCSCサーバに接続するときのタイマ（SessionBean）は，サービスリクエスタ稼働マシン側で設定します。サービスリクエスタの稼働しているマシン全体に設定したり，サービスリクエスタ個別に設定したりできます。サービスリクエスタ稼働マシンでCosminexusを使用している場合の設定方法を次に示します。

• サービスリクエスタ稼働マシン全体の設定
  サービスリクエスタ稼働マシンのCosminexusで，EJBコンテナでタイムアウトを設定します。設定内容は「(b) サービス部品に接続するときのタイマ（SessionBean）」の場合と同様です。RMI-IIOP通信のタイムアウトの詳細については，マニュアル「Cosminexus　機能解説」を参照してください。定義の詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。
  
• サービスリクエスタ個別の設定
  作成するサービスリクエスタごとに個別に，createからremoveまでのAPI通信のタイムアウト値を設定する場合，サービスリクエスタのアプリケーション開発時にAPI（RequestTimeoutConfigFactoryクラスおよびRequestTimeoutConfigクラスのメソッド）で設定します。
  

(e)　HCSCサーバ内のトランザクションのタイマ

HCSCサーバ内のトランザクションのタイマは，HCSCサーバ全体で設定します。HCSCサーバ稼働マシンのCosminexusで，EJBコンテナでタイムアウトを設定します。定義の詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

表5-21　HCSCサーバ内のトランザクションのタイマの設定

値	設定するファイル	キー名称	デフォルト値（秒）
EJBクライアントで開始されるトランザクションのトランザクションタイムアウト値	EJBクライアントアプリケーション用ユーザプロパティファイル（usrconf.properties）	ejbserver.jta.TransactionManager.defaultTimeOut	180

(f)　タイマ設定時の注意事項

• サービス部品に接続するときのタイマとHCSCサーバに接続するときのタイマの関係
  HCSCサーバに接続するときのタイマは，サービス部品に接続するときのタイマよりも大きい値を指定してください。
  サービス部品呼び出しで時間が掛かり正常応答した場合でも，HCSCサーバに接続するときのタイマが先にタイムアウトし，処理が正常に完了しません。
  なお，ビジネスプロセスを呼び出して，サービス部品を呼び出す場合は，複数のサービス部品を呼び出すことを考慮して，HCSCサーバに接続するときのタイマを設定する必要があります。
  
• サービス部品に接続するときのタイマとトランザクションのタイマの関係
  トランザクションのタイマは，サービス部品に接続するときのタイマよりも大きい値を指定してください。
  サービス部品呼び出しで時間が掛かり正常応答した場合でも，トランザクションがタイムアウトすると，トランザクションがロールバックします。