| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、エンドツーエンド統合フローの設計と作成に関するベスト・プラクティスについて説明します。
注意:
コンポジット・ビジネス・プロセス(CBP)は、次のリリースから非推奨となります。人間/システム相互作用のモデル化には、BPMの使用をお薦めします。
この章の内容は次のとおりです。
この項には次のトピックが含まれます:
XMLインスタンス・ドキュメントに空の要素タグが必要なのは、コンシューマが要素の値を無効にすることを送信者が意図している場合のみです。それ以外の場合、これらのタグは指定できません。このような重要でないタグの設定は、メモリーの消費量に影響を与え、アプリケーションのスケーラビリティに重大な影響を与えます。
エンタープライズ・ビジネス・メッセージ(EBM)には重大な要素のみを指定することをお薦めします。
他のアプリケーションと異なり、一部のアプリケーションでは、コンテンツを検査して重大なタグのみが指定されたXMLドキュメントを生成できます。ABCSにはアプリケーションとの密接な関係があるため、アプリケーションの動作に基づいて適切なスタイルを選択できます。変更の有無に関係なくすべての要素が含まれたアプリケーション・ビジネス・メッセージ(ABM)がアプリケーションで生成される状況でのリクエスタ・コネクタ・サービスでは、ABM内の空の要素は重要ではないと想定し、EBMの生成時には無視する必要があります。例20-1の最初のコード例に、この実行方法を示します。値の変更があった要素のみがABMに含まれている状況でのコネクタ・サービスでは、その要素の値をコンシューマが無効にすることが送信者の意図であるとして、空の要素の存在を処理する必要があります。例20-2に、このユースケースを示します。前述の方法でEBMを生成するサービス・リクエスタの場合、コンシューマのジョブは簡単になります。すべての要素が重要であると想定できるため、EBMを使用するABCSでは空の要素をスキップしません。例20-3に、重要な要素を含むメッセージの処理方法を示します。
例20-1の構造を使用するのは、ソース・アプリケーションのABMに、値の変更の有無に関係なくそのスキーマに定義されているすべての要素が含まれている場合です。この状況ではメモリー節約のために、AIAでは、空の要素は重要ではない要素と想定して無視します。
例20-2の構造を使用するのは、値の変更があった要素のみがソース・アプリケーションのABMに含まれている場合です。この状況での空の要素の存在は、重要である可能性があるため、AIAは無視しません。
前述のルールに従った場合、EBM内の空の要素はすべて重要であると想定できるため、EBMからABMへの変換時に無視されることはありません。従って、例20-3の構造を使用します。
例20-1 ABMからEBMへの変換
~--> <xsl:if test="ABMSourceElement/text()"> <EBMTargetElement> <xsl:value-of select="ABMSourceElement"/> </EBMTargetElement> </xsl:if>
例20-2 ABMからEBMへの変換
~--> <xsl:if test="ABMSourceElement/text()"> <EBMTargetElement> <xsl:value-of select="ABMSourceElement"/> </EBMTargetElement> </xsl:if>
例20-3 EBMからABMへの変換
~--> <xsl:if test="EBMSourceElement"> <ABMTargetElement> <xsl:value-of select="EBMSourceElement"/> </ABMTargetElement> </xsl:if>
完了したコンポジット・インスタンスを指定期間後にアーカイブしてクリーン・アップするプロセスの指定をお薦めします。
同期リクエスト/レスポンスに基づいて完了したコンポジット・インスタンスは、1か月後にSOAデハイドレーション・データ・ストアからパージしてください。
データの同期に関連したコンポジット・インスタンスは、完了後3か月から4か月の間にパージしてください。
コンポジット・ビジネス・プロセスは、完了後1年から2年の間にパージしてください。
この期間は会社のポリシーに基づいて変更されますが、なるべく早い時期にパージしてください。パージは、インスタンス・データのアーカイブより先に実行する必要があります。
詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のデータベースのサイズの増大の管理に関する項を参照してください。
Webサービス・エンドポイントでは、ドキュメント・スタイルに従って検証パーサーの機能を使用し、構文の検証をビジネス文書で実行するためのランタイムをそれぞれのスキーマ定義に対して使用できます。
スキーマによって、Webサービス操作に送信可能なペイロードのデータ形状が指定されます。Webサービス・ハンドラがSOAPメッセージを受信すると、コールされている操作に関連するスキーマが、そのSOAPメッセージのコンテンツの検証に使用されます。
この検証にはパフォーマンスの影響があるため、本番環境では慎重に使用してください。範囲外のリクエスタからのサービス受信メッセージに対してはスキーマ検証のみの有効化をお薦めします。リクエスタが内部アプリケーションの場合でも、外部ソースからのメッセージに構文の検証が適用されるのは通常、実行時のみです。AIAレイヤー内の仲介サービスに対するスキーマ検証はオフにすることをお薦めします。
開発環境では、特定のテスト・フェーズ中はすべてのサービスに対するスキーマ検証をオンにし、サービスによって生成されたメッセージが構文的に有効であることの確認をお薦めします。
スキーマ検証を有効化する方法の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください。
多くの場合、クロス機能ビジネス・プロセスの実装には、可用性などの異なる非機能的な特性および同時処理機能を備えたエンドポイント・システムの統合が必要です。計画または未計画の停止が原因でエンドポイントが使用できず、多くのシステムで大量のコンカレント・メッセージを処理できなくなる場合があります。大量のリクエストによるこれらのシステムへの負担は、結果としてターゲット・エンドポイントの失敗となり、統合全体にカスケード的な影響を与える場合があります。ほとんどの場合、リクエスタまたはプロバイダ・アプリケーションと相互作用する際は、キューを使用してストア・アンド・フォワード機能を実装することをお薦めします。これによって、顧客は、メッセージ・リクエストを特定のエンドポイントに渡す比率への制限設定に役立つスロットルを実装できます。
詳細は、「AIAメッセージ処理パターン」を参照してください。
エンタープライズ・ビジネス・オブジェクト、エンタープライズ・ビジネス・サービスWSDL、アプリケーション・ビジネス・メッセージ・スキーマ、ABCS WSDL、ドメイン値マップ、相互参照メタ・データなどの共有アーティファクトの管理を容易にするために、これらのアーティファクトはそれを使用するサービス機能とは関係なしに設計して実装することをお薦めします。これらのアーティファクトの管理と保持を個々のサービスの一部としないことをお薦めします。AIAのプログラミング・モデルでは、これらのアーティファクトの保持にMDSを使用することをお薦めします。
MDSを使用してアセットを集中管理する方法の詳細は、「AIAでのMDSの使用」を参照してください。
関心の分離はSOAのコアとなる原則です。これは、疎結合を、それが必要な統合フローに導入する際に役立ちます。ただし、アーキテクチャ・レベルのみでなく、実装レベルにも適用する必要があります。
開発時と実行時におけるサービス間の依存性の管理は、開発者がリクエスタとプロバイダABCサービスを実装している場合、困難なタスクです。1つの方法は分離です。この方法を使用すると、サービスの各関心を処理するコード内の相互依存性を最小化できます。
無効なSOAコンポジットを示すエラー・メッセージがサーバーの再起動後に表示される場合があります。これは、抽象WSDLを使用する必要がある場所で具象WSDLを参照していることが原因です。
新しいコンポジットXの最初のデプロイメント時にコンポジットYの具象WSDLを参照した場合は問題がありません。なぜでしょうか。コンポジットYは、コンポジットXのデプロイメント時には起動して稼働しています。問題はサーバーを再起動した際に発生しますが、これは、依存性を解決する正しい順序でコンポジットがアクティブ化される保証がないためです。コンポジットYの前にサービスXがアクティブ化された場合は、Yが停止しているため参照を解決できず、このため、Xのステータスは無効のままとなります。
実装からインタフェースを分離することから開始できます。
消費アーティファクトでは具象WSDLを直接使用しないでください。サービス・プロバイダ(ProviderABCS内のサービス・プロバイダ以外)の変更がある場合は、コンシューマの再デプロイが必要です。
サービス・プロバイダのデプロイ済の具象WSDLを参照しないでください。プロバイダが使用できない場合は、コンシューマをコンパイルしたりデプロイすることはできません。
たとえば、アダプタ・サービスを使用するプロバイダABCSを作成する場合は、そのアダプタ・サービスの具象WSDLを直接参照し、消費プロバイダABCSを開発します。アダプタ・サービスが使用できない場合やデプロイされていない場合、プロバイダABCSをコンパイルまたはデプロイしている場合は、ここで障害となります。
サービスの抽象WSDLの共通ディレクトリを導入し、集中的にアクセス可能なエンドポイントにそれらの抽象WSDLを格納します。
SOAでは、設計時にサービスを完全に分離する方法が用意されています。コンポジットが他のコンポジットを参照する際は、常に抽象WSDLを使用することをお薦めします。設計時にはすべて必要となるサービスのインタフェースが抽象WSDLで完全に記述されていることを確認してください。具象WSDLが後で必要となるのは、バインディング詳細(デプロイしたコンポジットを呼び出す方法に関する情報)を指定する実行時のみです。
図20-1に、抽象WSDL (設計時)と具象WSDL (実行時)の2つの部分で実際に構成された複数のSOAコンポジット間での参照を示します。
図20-1 SOAコンポジット間の参照
AIAでは、各サービスの抽象WSDLの格納にメタデータ・サービス(MDS)を使用します。このため、MDSがすべてのサービス・インタフェースに関する真のソースとなるため、コンポジットに冗長なコピーはありません。
SOA Suite 11gでは、中央リポジトリのメタデータ・サービス(MDS)が導入され、設計時および実行時にアプリケーション(およびコンポジット)をバックアップします。MDSは、共有している共通のアーティファクトを設計時および実行時に格納して使用できるバージョン管理システムに類似しています。
AIAでは、MDSリポジトリを利用して、すべての開発者が共有する共通の設計時アーティファクトを格納します。AIAでは、集中的にアクセス可能なエンドポイントである抽象WSDLの共通ディレクトリがMDSに導入されました。
MDSに格納されるアーティファクトには、次の内容が含まれます。
スキーマ - EBOスキーマおよびABMスキーマ
WSDL - EBS、ABCS、アダプタ・サービス、CBPおよびEBFの抽象WSDL
DVMおよびXREF
AIAコンポーネントは、様々なスキーマおよび様々なサービスが参照するWSDLを提示します。表20-1に構造を示します。
表20-1 AIAコンポーネントの構造
| 場所 | アーティファクト |
|---|---|
ApplicationConnectorServiceLibrary |
様々なアプリケーション・ビジネス・コネクタ・サービス(ABCS)の抽象WSDL |
ApplicationObjectLibrary |
複数のアプリケーションおよびアプリケーション・ビジネス・オブジェクトのスキーマによって公開されたサービスのWSDL |
B2BObjectLibrary |
企業間(B2B)スキーマ |
B2BServiceLibrary |
様々なB2Bコネクタ・サービス(B2BCS)およびB2Bインフラストラクチャ・サービスの抽象WSDL |
BusinessProcessServiceLibrary |
コンポジット・ビジネス・プロセス(CBP)およびエンタープライズ・ビジネス・フロー(EBF)の抽象WSDL |
EnterpriseBusinessServiceLibrary |
エンタープライズ・ビジネス・サービス(EBS)の抽象WSDL |
EnterpriseObjectLibrary |
Oracle AIA標準モデルのスキーマ |
InfrastructureServiceLibrary |
インフラストラクチャ・サービスの抽象WSDL |
Transformations |
様々なサービス間で共有されるXSL |
UtilityArtifacts |
ユーティリティ・スキーマおよびWSDL |
config |
AIAConfigurationProperties.xmlおよびAIAEHNotification.xml |
dvm |
ドメイン値マップ |
faultPolicies |
すべてのサービスに適用可能なデフォルトのポリシー |
xref |
相互参照用のメタデータ |
これらのアーティファクトのMDSへのアップロード方法およびMDS内での更新方法の詳細は、「AIAでのMDSの使用」を参照してください。
すべてのAIAサービスの抽象WSDLは、MDSに格納されています。コンシューマAIAサービス・コンポジット・アプリケーションは、参照サービスの抽象WSDLを使用して作成します。
MDSはどこにあり、アプリケーションではどのようにして参照しますか。
開発環境を構成してMDSをポイントします。構成ファイルは$application_home/.adf/META-INF/adf-config.xmlにあり、デフォルトでローカル(JDeveloperファイル・システム・ベースのMDS)をポイントしています。これを構成して、管理対象SOAサーバー上のMDSをポイントする必要があります。
詳細は、「AIA開発でのQuick Startの入手」を参照してください。
コンポジット内で、参照サービスはそのサービスの抽象WSDLによって定義されます。
例として、この項では前述のシナリオを使用します。
アダプタ・サービスの抽象WSDLを参照して、そのアダプタ・サービスを使用するプロバイダABCSを作成します。
表への影響
最初に、コンポジットのデプロイメント中に参照先サービスへの依存関係はありません。したがって、コンポジットに対するデプロイメント順序への依存関係はありません。参照先サービスは、他のサービスが参照できるように、最初にデプロイする必要はありません。これによって、サービス間で循環参照がある場合も解決されます。
コンポジットを設計した後は、タスクをいくつか実行する必要があります。外部サービスの参照に抽象WSDLを使用したため、コンポジットにはランタイム・バインディングが生成されていません。参照先サービスの場合は、コンポジットをソース・モードで開き、このバインディング情報(要素binding.wsの値)を指定する必要があります。
コンポジットのbinding.ws.port要素およびbinding.ws.location要素の入力方法の詳細は、「composite.xmlへのbinding.ws要素の挿入」を参照してください。
既存アプリケーションの移行で最も一般的な推奨方法は、1対1の移行です。これによって、古いアプリケーションのすべてのコンポーネントがSCAコンポジットになります。次のステップではSCAの利点を使用して、複数のSCAコンポジットを1つのコンポジットに結合します。複数コンポジットの結合は常に有利でしょうか。
アーキテクチャ上の判断は、SCAの作成方法によって異なります。SOA/SCAでは、すべてが再利用性に関係します。SCAをビジネス・フローに基づいて設計しているのか、技術的な視点から設計しているのかについて考えてみます。答えは、両者の間の適切なバランスの中にあります。
一度設計したサービスは、何回も再利用できる必要があります。この視点からは、小型のSCAを作成することになります。しかし、外部に公開する複数サービスを備えた大型のSCAを選択することもできます。この場合、SCAは比較的大型であるため、保守性が向上します。
必要なことは、サービスの定義と設計およびこれらのサービスを参照するコンポジットの作成です。結果として、一度設計されたサービスが何回も再利用されます。
ベスト・プラクティスとして、アダプタはABCSコンポジット内か、または個別のコンポジットとして開発するかという質問に戻った場合、図20-2に示すように、異なるコンポジット内のABCSとインタフェースしているアダプタを配置することをお薦めします。これは、同じトランスポート・アダプタ・サービスが複数のABCSで使用できる場合の推奨方法でもあります。
図20-2 異なるコンポジット内のABCSとインタフェースするアダプタの例
ただし、そのような再利用性が予測されない場合は、図20-3に示すように、ABCSおよびトランスポート・アダプタ・サービスが同じコンポジットにある代替の設計を使用しても構いません。
図20-3 同じコンポジット内にあるABCSおよびトランスポート・アダプタ・サービスの例
開発して作成し、デプロイした後のAIAアーティファクトは、管理の対象となります。
EBO、EBS WSDL、ABMスキーマ、ABCS WSDL、DVM、XREFなどの共有アーティファクトの管理を可能にするために、これらのアーティファクトはそれを使用するサービスの機能とは関係なしに設計して実装することをお薦めします。これらは、サービス・アーティファクトとして処理せず、中央の場所で管理して保持する必要があります。
いくつかの項で前に説明したように、AIAでは、MDSを使用してアーティファクトを保持します。
注釈は、WSDLファイルの注釈とは別に、開発フェーズ時にコンポジットXMLファイルに挿入されます。コンポジット・ファイル内の注釈には、次の内容に関する詳細な情報が記述されています。
AIAアーティアクトおよび他のAIAアーティアクトとの関係。
デプロイメント時と実行時にコンポーネントを構成するために使用する、コンポジットレベルのディスクリプタ・プロパティ。
この項では、BPELベースのプロセスを可能なかぎり最小に保持する方法に関する推奨事項を示します。
この項の内容は、次のとおりです。
BPELは編成言語であるため、主に、アプリケーション・システムによって公開される一連のサービスを編成するためのグルーとして使用する必要があります。BPELでは多様なプログラミング構成をサポートしていますが、これらの構成は、BPELプロセス内での複雑なプログラミング・ロジックの作成が目的ではありません。
割当のかわりにXSLを使用
XMLメッセージに様々な要素を挿入するために複数のassignアクティビティを使用することは避けてください。変換の実行にはXSLの使用を考慮してください。XSLスクリプトの呼出しはコストを伴うため、8個から10個の割当を実行する必要がある場合のみ、メッセージの入力にXSLを使用することを考慮してください。
データ・セットの制約にXPath式を使用
指定のデータ配列(A)をループし、(条件Cを使用して)その配列の特定サブセットで操作する必要があるプログラミング・シナリオがあります。これを実行する簡単な方法は、Aにwhileループを設定し、次にそのwhileループ内に切替え条件Cを設定します。この方法では、常にすべての行をループすることになり、非効率となります。この状況に対するより効率的な方法は、多重インデックスの使用です。これによって、AをA[i]としてアクセスしてから条件を確認するかわりに、AをA[C][i]としてアクセスできるため、(iを使用して)条件Cを満たすAのすべての要素をループします。この方法で、BPELアクティビティの数を減らします。
通常、whileループは次の内容を処理するために使用されます。
XMLメッセージ内にある複数の反復する子インスタンス
XMLメッセージ内にある大量の独立したオブジェクト・インスタンス
XMLメッセージ内にある反復する子インスタンス(maxOccurencesの制限なし)の処理にwhileループが使用されている状況では、そのwhileループ内のBPELアクティビティは、大量の反復数の可能性に注意しながら設計する必要があります。たとえば、100個の反復インスタンスがあるインスタンス・ドキュメントを処理する場合、whileループ内で単一のインスタンスを処理するアクティビティが50個あるとすると、実行時には急に5000個のアクティビティが作成される結果となります。
BPELのassignアクティビティ内では、可能なかぎりプロセス変数のかわりにローカル変数を使用してください。ローカル変数は、BPELプロセスのスコープ内に制限されます。これらの変数は、スコープを閉じた後はメモリーおよびデータベースから削除されます。一方、グローバル変数またはプロセス変数のライフ・サイクルは、インスタンスのライフ・サイクルと結び付けられています。これらの変数は、インスタンスが完了するまで、メモリー内またはディスク内にとどまります。したがって、プロセス変数またはグローバル変数より、ローカル変数をお薦めします。ただし、同じ変数がwhileループ内またはプロセス全体のすべての反復で使用されている場合は、1つのグローバル変数を作成してすべての反復でアクセスするほうが効率的です。
例20-4のBPELフラグメントは、ローカル変数の使用を示しています。
例20-4 ローカル変数の使用
<scope name="Scope_1">
<variables> <variable name="Invoke_CallprocessBillingMove_InputVariable"
messageType=
"sordmovsubabcs:ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcessRequest
Message"/>
<variable name="Invoke_CallprocessBillingMove_OutputVariable"
messageType=
"sordmovsubabcs:ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcessResponse
Message"/>
</variables>
<sequence name="Sequence_MoveAdd_SubProcess">
<assign name="Assign_Variable_Invoke_CallMoveAdd">
<copy>
<from variable="inputSubProcess"
query="/sordsubebo:ProcessFulfillmentOrderBillingBRMCommsSubprocessMessage"/>
<to variable="Invoke_CallprocessBillingMove_InputVariable"
part="payload"
query="/sordsubebo:ProcessFulfillmentOrderBillingBRMCommsSubprocessMessage"/>
</copy>
</assign>
<invoke name="Invoke_CallMove-Add_Subprocess"
partnerLink="ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess"
portType="sordmovsubabcs:ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess"
operation="processBillingMove"
inputVariable="Invoke_CallprocessBillingMove_
InputVariable"
outputVariable="Invoke_CallprocessBillingMove_
OutputVariable"/>
</sequence>
</scope>
FlowNアクティビティがあるBPELプロセスの設計には慎重な考慮が必要です。Nの上限について十分な理解が必要です。フローで実行するアクティビティのタイプによっては、composite.xmlのnonBlockingInvokeプロパティをtrueに設定して、フローを非同期モードで実行するオプションを慎重に考慮する必要があります。
auditLevelプロパティには、監査証跡のロギング・レベルを設定します。この構成プロパティは、永続プロセスと一時プロセスの両方に適用されます。このプロパティが制御するのは、プロセスによってログに記録される監査イベントの数です。監査イベントを記録すると、audit_level表およびaudit_details表へのデータベース挿入が増えるため、パフォーマンスに影響が出ることがあります。監査情報は、Oracle Enterprise Managerコンソールからプロセスの状態を確認する目的でのみ使用されます。
監査情報を保存しない場合は、Off値を使用します。監査レベルは、常にビジネス要件およびユースケースに従って選択してください。
同期BPELプロセスの場合は、インスタンス詳細は保持しないことをお薦めします。このためには、auditLevelプロパティをサービス・コンポーネント・レベルでOffに設定します。この一般的なガイドラインは、ユースケースに基づいて個々のサービス用にオーバーライドできます。
多重呼出し不変サービスは再試行できます。サービスを呼び出す回数に関係なく、同じ結果が再生成されます。悪影響はありません。
多重呼出し不変プロパティに対するデフォルト値は、trueです。多重呼出し不変プロパティをfalseに設定すると、プロセスはパートナ・リンクの実行後にデハイドレーションとなります。多重呼出し不変プロパティの構成に関する判断は、設計時と開発時に開発者が行う必要があります。
idempotentプロパティの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください
各反復ノードを処理する一連のアクティビティがXMLメッセージ内にある場合や反復ノードの数がきわめて多数の場合、トランザクションは、大きくなる傾向があります。
dspMaxThreadDepthプロパティに対するデフォルト値は、600に設定されています。トランザクションで実行するBPELアクティビティがこの数を超えた場合、BPELエンジンは暗黙的なコミットを自動発行してそのトランザクションを終了します。これは、アプリケーション・トランザクション・セマンティクスと一致しない場合があります。この問題は、このプロパティを任意の高い値に設定することで排除できる場合があります。この方法では、BPELが新しいしきい値に到達するずっと前に、統合開発者が定義したグローバル・トランザクションが終了することを想定しています。ほとんどの状況で、高い値へのプロパティの設定はトランザクションの完了に役立っています。ただし、アプリケーションの全体的なスケーラビリティに影響を与える可能性があります。このため、トランザクションのスコープは極力小さくするようにしてください。
中間プロセス・ブレークポイント・アクティビティがない同期BPELベースのサービスに対する監査は完全にオフにすることをお薦めします。
auditLevel
このプロパティは、監査証跡のロギング・レベルを設定し、プロセスによってログに記録される監査イベントの数を制御します。SOAインフラストラクチャ、BPELプロセス・サービス・エンジンおよびコンポジット・アプリケーションの各レベルで指定した値は、BPELプロセス・サービス・コンポーネント・レベルで設定した値によってオーバーライドされます。値をオーバーライドする対象は、中間プロセス・ブレークポイント・アクティビティがない同期BPELプロセスのみです。
このプロパティに次の値を設定することをお薦めします。
Off: BPELサービス・エンジンはペイロードを取得しません。フローの監査証跡でペイロード詳細は使用できません。他のBPELアクティビティのペイロード詳細は、assignアクティビティを除いて収集されます。多くの場合、通常の操作およびテストにはこのレベルが最適です。
例20-5に、SOAプロジェクトのcomposite.xmlファイルのbpel.config.auditLevelプロパティを適切な値に設定する方法を示します。
例20-5 composite.xmlのbpel.config.auditLevelプロパティの設定
<component name="BPELProcess"> <implementation.bpel src="graphics/BPELProcess.bpel" /> <property name="bpel.config.auditLevel">Off</property> </component>
同期リクエスト/レスポンス・メッセージ交換パターンを実装しているBPELサービスには、midprocess receive、wait、onMessage、onAlarmなどのブレークポイント・アクティビティを指定しないことをお薦めします。
同様に、同期リクエスト/レスポンス・メッセージ交換パターンを実装しているメディエータ・サービスには、パラレル・ルーティング・ルールを指定しないでください。リクエスト/レスポンス・メッセージ交換パターンを実装しているESBルーティング・サービスには、非同期モードで呼び出したターゲット・サービスを指定しないでください。
