この章の内容は次のとおりです。
非同期メッセージ形式は、サービス(融資処理など)でクライアント・リクエストの処理に時間がかかる環境で役に立ちます。また、非同期サービスは、同期サービスよりも優れた耐障害性を持ち、かつスケーラブルなアーキテクチャも提供します。
この項では、United Loanという企業での非同期Webサービスの起動について説明します。United Loanは、クライアントの融資申請リクエストを処理して融資提案を返す非同期Webサービスを公開します。このユースケースでは、BPELプロセス・サービス・コンポーネントとこの非同期融資申請承認Webサービスを統合する方法について説明します。
このユースケースでは、非同期サービスからの情報をリクエストし、レスポンスを受け取るための基本的な設計概念について説明します。この例のUnited Loanの非同期サービスは、別のBPELプロセス・サービス・コンポーネントです。しかし、適切に設計されたWebサービスであれば、同じBPELコールで対話できます。ターゲットのWebサービスのWSDLファイルには、必要な情報のリクエストと受信に必要な情報が含まれています。
非同期Webサービスでは、次のアクションが(優先度に従って)実行されます。
assignアクティビティにより融資申請が準備されます。
invokeアクティビティにより融資申請が開始されます。申請の内容は、リクエスト変数に入力されます。このリクエスト変数が非同期融資処理Webサービスに送信されます。
融資申請の開始時、申請を開始したクライアントとパートナ・リンクに固有の相関IDも、融資処理Webサービスに送信されます。相関IDにより、適切な融資提案レスポンスが、対応する融資申請のリクエスト元に確実に返されます。
その後、融資処理Webサービスにより、適切なレスポンスがreceiveアクティビティ(相関IDを使用して追跡)に送信されます。
assignアクティビティにより融資申請提案が読み取られます。
この章の後続の各項では、非同期機能の詳細を説明します。
この項では、非同期機能をBPELプロセス・サービス・コンポーネントに追加するためのタスクの概要を説明します。
次の手順を実行し、Webサービスを非同期で起動します。
パートナ・リンクの追加
invokeアクティビティの追加
receiveアクティビティの追加
assignアクティビティの作成
ここでは、融資申請承認Webサービスに対するパートナ・リンク(この例ではLoanServiceという名前)をBPELプロセスに作成する方法について説明します。
非同期サービスに対してパートナ・リンクを追加する手順は、次のとおりです。
次の手順に従って、invokeアクティビティとrequest
という名前のグローバル入力変数を作成します。このアクティビティは、融資申請承認Webサービス(United Loan)を使用して、非同期BPELプロセス・サービス・コンポーネント・アクティビティを開始します。融資申請承認Webサービスは、request
入力変数を使用してクライアントからの融資申請を受け取ります。
invokeアクティビティを追加する手順は、次のとおりです。
次の手順に従って、receiveアクティビティとresponse
という名前のグローバル出力変数を作成します。このアクティビティは、融資申請承認Webサービスのコールバック処理を待機します。融資申請承認Webサービスは、この出力変数を使用して、融資提案結果をクライアントに送信します。
receiveアクティビティを追加する手順は、次のとおりです。
この項では、非同期Webサービス起動時の処理内容について説明します。
WSDLファイル(この例ではLoanService
)のportType
セクションは、非同期サービスに使用するポートを定義します。
非同期サービスにはポート・タイプが2つ定義されます。各ポート・タイプは一方向操作を実行します。この例では、次のようになります。
一方のポート・タイプが非同期プロセスに応答します。
他方のものが、非同期レスポンスでクライアントにコールバックします。
次の例では、portType
LoanServiceCallback
がクライアントの融資申請リクエストを受け取り、portType
LoanService
が融資提案レスポンスを使用してクライアントを非同期でコールバックします。
<!-- portType implemented by the LoanService BPEL process --> <portType name="LoanService"> <operation name="initiate"> <input message="tns:LoanServiceRequestMessage"/> </operation> </portType> <!-- portType implemented by the requester of LoanService BPEL process for asynchronous callback purposes --> <portType name="LoanServiceCallback"> <operation name="onResult"> <input message="tns:LoanServiceResultMessage"/> </operation> </portType>
WSDLファイル(この例ではLoanService
)のpartnerLinkType
セクションは、BPELプロセス・サービス・コンポーネントの次の特性を定義します。
果たすロール(操作)
対話でメッセージを受信するために提供するportType
非同期サービスのパートナ・リンク・タイプには、Webサービス・プロバイダに対するロールとクライアント・リクエスタに対するロールの2つのロールがあります。
次の例では、LoanServiceProvider
ロールおよびLoanService
portType
は、クライアント・リクエスト・メッセージに使用され、LoanServiceRequester
ロールおよびLoanServiceCallback
portType
は、レスポンス・メッセージをクライアントに非同期で返す(コールバックする)ために使用されます。
<plnk:partnerLinkType name="LoanService"> <plnk:role name="LoanServiceProvider"> <plnk:portType name="client:LoanService"/> </plnk:role> <plnk:role name="LoanServiceRequester"> <plnk:portType name="client:LoanServiceCallback"/> </plnk:role> </plnk:partnerLinkType>
2つのポート・タイプ(invoke
アクティビティのportType="services:LoanService"
とreceive
アクティビティのportType="services:LoanServiceCallback"
)は、この1つの非同期BPELプロセス・サービス・コンポーネントに結合されます。基本的に、ポート・タイプは実行される一連の操作です。このBPELプロセス・サービス・コンポーネントの場合、実行する操作は2つ(invoke
アクティビティのinitiate
とreceive
アクティビティのonResult
)あります。
サービスをBPELからコールするには、プロセスとWebサービスの連携方法をBPELファイルで定義する必要があります。partnerLinks
セクションを表示します。プロセスが相互作用するサービスはパートナ・リンクとして設計されます。各パートナ・リンクは、partnerLinkType
によって定義されます。
各パートナ・リンクには名前が付けられています。この名前は、そのパートナ・リンクによるすべてのサービス相互作用に使用されます。これは、レスポンスを、同じタイプの同時リクエストに対する異なるパートナ・リンクに相関する場合に重要です。
非同期プロセスは、クライアントへのコールバックに2番目のパートナ・リンクを使用します。この例では、2番目のパートナ・リンクLoanService
が融資申請承認Webサービスによって使用されます。次に例を示します。
<!-- This process invokes the asynchronous LoanService. --> <partnerLink name="LoanService" partnerLinkType="services:LoanService" myRole="LoanServiceRequester" partnerRole="LoanServiceProvider"/> </partnerLinks>
属性myRole
は、クライアントのロールを示します。属性partnerRole
は、この対話におけるパートナのロールを示します。非同期プロセスでは、各partnerLinkType
にmyRole
属性とpartnerRole
属性があります。
composite.xml
ファイルには、次に示すように、融資申請承認Webサービスが表示されます。
<component name="LoanBroker"> <implementation.bpel process="LoanBroker.bpel"/> </component>
パートナ・リンクの作成手順の詳細は、「非同期サービスに対するパートナ・リンクの追加」を参照してください。
variables
およびsequence
セクションを表示します。ここでは特に、invoke
アクティビティとreceive
アクティビティの2つの領域に注目します。
invokeアクティビティは、同期Webサービスを起動(「BPELプロセスからの同期Webサービスの起動」を参照)するか、または非同期サービスを開始します。
invokeアクティビティにはvariable
セクションで定義されたrequest
グローバル入力変数が含まれます。request
グローバル入力変数は融資申請承認Webサービスで使用されます。この変数には、最初の融資申込書の内容が格納されます。
融資申請承認Webサービスからの非同期コールバックを待機するreceiveアクティビティ。receiveアクティビティにはvariables
セクションで定義されたresponse
グローバル出力変数が含まれます。この変数には、融資提案レスポンスが格納されます。receiveアクティビティは、サービスからのコールバック・メッセージを非同期に待機します。BPELプロセス・サービス・コンポーネントは、コールバック・メッセージの到着を待機中、デハイドレーション(圧縮して格納)されます。
次に例を示します。
<variables> <variable name="request" messageType="services:LoanServiceRequestMessage"/> <variable name="response" messageType="services:LoanServiceResultMessage"/> </variables> <sequence> <!-- initialize the input of LoanService --> <assign> . . . . . . </assign> <!-- initiate the remote process --> <invoke name="invoke" partnerLink="LoanService" portType="services:LoanService" operation="initiate" inputVariable="request"/> <!-- receive the result of the remote process --> <receive name="receive_invoke" partnerLink="LoanService" portType="services:LoanServiceCallback" operation="onResult" variable="response"/>
invokeアクティビティによって非同期サービスが開始されると、Web Services Addressing (WS-Addressing)(「非同期サービスでのWS-Addressingの使用」で説明)を使用して、クライアント・リクエストに固有の相関IDが送信されます。複数のプロセスがサービス・コールバックを待機している可能性があるため、サーバーでは、どのBPELプロセス・サービス・コンポーネント・インスタンスが融資申請承認Webサービスからのコールバック・メッセージを待機しているかを把握する必要があります。相関IDによって、サーバーは、レスポンスを適切なリクエスト・インスタンスと関係付けることができます。
最初のreceive
アクティビティには、createInstance
属性があります。この最初のreceive
アクティビティでは、createInstance
要素はyes
に設定されています。これにより、新しいBPELプロセス・サービス・コンポーネント・インスタンスが起動されます。対話のためには、少なくとも1つのインスタンスが起動している必要があります。このため、2番目のreceive
アクティビティではcreateInstance
変数をno
に設定します。
次の例に、createInstance
属性のソース・コードを示します。
<!-- receive input from requester -->
<receive name="receiveInput" partnerLink="client"
portType="tns:LoanBroker"
operation="initiate" variable="input"
createInstance="yes"/>
非同期コールバックの待機中、長期間にわたる非同期プロセスとその現在の状態の情報をデータベース内に自動的に保存するには、データベースをデハイドレーション・ストアとして使用します。データベースにプロセスを格納することにより、プロセスを維持し、システムの停止やネットワークの問題が発生した場合の状態や信頼性の低下を防ぎます。この機能により、BPELプロセス・サービス・コンポーネントの信頼性とスケーラビリティの両方が向上します。また、クラスタリングおよびフェイルオーバーのサポートにもこの機能を使用できます。
invokeアクティビティとreceiveアクティビティの間にこのポイントを挿入します。dehydrateアクティビティを使用してデハイドレーション・ポイントを明示的に指定することもできます。詳細は、「dehydrateアクティビティ」を参照してください。
Oracle SOA Suiteでは、パートナ・リンクの複数のエンドポイント・ロケーションの指定がサポートされています。この機能は、最初のエンドポイントが停止した場合に、フェイルオーバーするのに便利です。パートナ・リンクの代替エンドポイント・ロケーションを提供するには、composite.xml
ファイルにlocation
属性を追加します。次に例を示します。
<reference name="HeaderService ...> <binding.ws port="http://services.otn.com/HelloWorldApp#wsdl.endpoint(client/ HelloWorldService_pt)" location="http://server:port/soa-infra/services/default/ HelloWorldService!1.0/client?WSDL"> <property name="endpointURI">http://jsmith.us.example.com:80/a.jsp @http://myhost.us.example.com:8888/soa-infra/services/HelloWorldApp/HelloWorld! 1.0*2007-10-22_14-33-04_195/client </property> </binding.ws> </reference>
タイムアウトによって発生した例外が処理されない場合は、receiveアクティビティで構成されたタイムアウトが期限切れになった後も、BPELプロセスによって中間プロセスのreceiveアクティビティのメッセージがコンシュームされます。このようなシナリオでは、コールバック・メッセージは配信時にコンシュームされます。これは予想された動作です。
たとえば、次のタスクを実行するとします。
クライアントBPELプロセスおよびサービスBPELプロセスでSOAコンポジット・アプリケーションを作成し、非同期のinvokeアクティビティおよびreceiveアクティビティを使用してメッセージを交換する。
クライアントBPELプロセスのreceiveアクティビティの「タイムアウト」タブで、30秒のタイムアウトを構成する。
サービスBPELプロセスに5分間待機するwaitアクティビティを構成する。
タイムアウトが発生した後は、クライアントBPELプロセスが引き続き実行中の状態ではなく、フォルト状態で完了済としてマークされ、サービスBPELプロセスからのコールバック・メッセージが無視されることが予想されます。ただし、クライアントBPELプロセスでタイムアウト・フォルトがスローされた場合、そのプロセスは実行中の状態のままになります。サービスBPELプロセスがwaitアクティビティの完了から5分後に応答すると、レスポンスがクライアントBPELプロセスに返信されてコンシュームされ、実行中のプロセス・インスタンスに対して調整されます。
複数のクライアント・コンポーネントがそのリモートのWSDLファイルを使用して1つのSOAコンポジット・アプリケーションを起動した場合は、リモート・コンポジットをコールしている元のクライアントにreceiveアクティビティが存在する場合にのみ、コールバック・レスポンスをこのクライアントで取得できます。元のクライアントにreceiveアクティビティが存在せず、コンポジットをコールする後続のクライアントのいずれにもreceiveアクティビティが存在しない場合、レスポンス・メッセージは失われます。これにより、元のクライアント・プロセスのリカバリ状態となります。
これは予想された動作です。これは、起動されているコンポジットでは、receiveアクティビティがどのクライアントに存在するか、またはクライアントが実際にBPELプロセス・サービス・コンポーネントであるかどうかを認識できないためです。
receiveアクティビティは一種のインバウンド・メッセージ・アクティビティ(IMA)です。IMAのその他の例は次のとおりです。
scopeアクティビティ(BPEL 1.1)またはpickアクティビティのonMessageブランチ
BPEL 2.0のscopeアクティビティのonEventブランチ
BPEL 2.0仕様では、複数のIMAを相互に使用する、または拡張アクティビティから導出した他のIMAとともに使用することができます。実行時の動作を一定に保つために、BPEL 2.0仕様ではinitiate
属性をjoin
に設定した相関セットを使用できます。ただし、Oracle BPEL Process ManagerにおけるBPEL 2.0仕様では、この動作がサポートされていません。複数のIMAをサポートする唯一の方法は、それらをpickアクティビティのonMessageブランチとしてコーディングする(つまり、createInstance
をyes
に設定する)ことです。また、Oracle BPEL Process Managerでは、複数IMAのその他の形、たとえば2つのブランチを持つflowアクティビティで、それぞれがreceiveアクティビティを持ち、createInstance
の設定がyes
で、相関セットのinitiate
の設定がjoin
であるなどの形もサポートされていません。
解決方法として、次のように、交互に2つのreceiveアクティビティがある2つのBPELプロセスを設計する必要があります。
Process1: receive1の後にreceive2が続き、receive1でのみ、createInstance
がyes
に設定されています。
Process2: receive2の後にreceive1が続きます。receive2でのみ、createInstance
がyes
に設定されています。
同じことが、receiveアクティビティとpickアクティビティ、または2つのpickアクティビティなど、IMAの他の組合せにも適用されます。
invokeアクティビティ(およびreceiveアクティビティなどの他のアクティビティ、pickまたはscopeアクティビティのonMessageブランチ)の「対話ID」フィールドにオプションの対話ID値を入力することもできます。
対話IDは、非同期対話中にプロセス・インスタンスを識別します。デフォルトでは、BPELプロセス・サービス・エンジンにより、WSAアドレッシングで指定されているように、対話(複数のinvokeアクティビティおよびreceiveアクティビティにまたがる可能性があります)ごとに一意のIDが生成されます。必要に応じて、使用するサービス・エンジンに独自の値を指定できます。対話IDはbpelx:conversationId
拡張要素で実装されます。
次に、BPELバージョン1.1をサポートするBPELプロジェクト内のbpelx:conversationId
拡張要素の例を示します。bpelx:conversationId
拡張要素はXPath式をとります。
<invoke ... bpelx:conversationId="$convId2"> </invoke> <receive ... bpelx:conversationId="$convId2"> </receive> <onMessage... bpelx:conversationId="$convId2"> </onMessage>
次に、BPELバージョン2.0をサポートするBPELプロジェクト内のbpelx:conversationId
拡張要素の例を示します。bpelx:conversationId
拡張要素はBPEL 2.0 XPath式をとります。
<invoke ...> <bpelx:conversationId>$convId1</bpelx:conversationId> </invoke> <receive ...> <bpelx:conversationId>$convId1</bpelx:conversationId> </receive> <onMessage ...> <bpelx:conversationId>$convId2</bpelx:conversationId> </onMessage>
複数のreceiveアクティビティまたはpickアクティビティが同じパートナ・リンクに関連付けられている場合に、適切なエンドポイント・アドレスへのコールバック・メッセージのルーティングを解決するには、replyToAddress
正規化されたメッセージのプロパティが必要です。
これは、BPELプロセス・サービス・エンジンでは、replyToAddress
プロパティが格納されるのは、起動元のreceiveまたはpickアクティビティでパートナ・リンクからのリクエストを受信するときの1回のみであるためです。replyToAddress
は、コールバック・メッセージをルーティングし、中間プロセスのreceiveまたはpickアクティビティが使用されている場合にリセットされません。replyToAddress
プロパティは、bpelx:inputProperty
拡張要素を使用します。
中間プロセスのreceiveアクティビティの後に続くinvokeアクティビティ(コールバック用)に対して、このプロパティをクライアントのreplyToAddress
に設定してください。つまり、クライアントが、中間プロセスのreceiveアクティビティに対してWS-Addressing replyTo
情報を送信する場合でも、assignアクティビティを使用してそれを動的に設定しないかぎり、それがパートナ・リンクに設定されることはありません。
たとえば、BPELプロセスが次に示すとおりであるとします。
Caller Callee ----------------------------------------------------------- <receive> <receive> Initiate CS1 <invoke>initiate CS1 --------> <receive> Use CS1 <wait> <receive>use CS1 <-------- <invoke> <invoke>
複数のreceiveおよびpickアクティビティで同じパートナ・リンクが使用されている場合において適切なエンドポイントにコールバック・メッセージをルーティングする手順は、次のとおりです。
idempotentアクティビティは、問題なく再試行できるアクティビティです。idempotentアクティビティは、永続プロセスと一時プロセスの両方に適用されます。冪等性は、パートナ・リンクの操作レベルで管理できます。たとえば、いくつかのパートナ・リンクでは複数の操作を公開できます(たとえば、getEmployee
、depositPayCheck
など)。いくつかの操作を冪等として定義できます(たとえば、getEmployee
)。これによって、これらの操作を複数回コールできるようになります。他の操作は、冪等にする必要がない場合があり(たとえば、depositPayCheck
)、この設定は不要です。デハイドレーションは、非冪等操作の後に発生します。
デフォルトでは、すべてのパートナ・リンク操作は冪等です。必要な場合は、操作を非冪等に設定できます。この設定は、idempotent
デプロイメント・ディスクリプタのプロパティと同じ機能を、より詳細な操作レベルで提供します。
idempotent
デプロイメント・ディスクリプタのプロパティの詳細は、「idempotentプロパティとフォルト処理に関する必知事項」および「デプロイメント・ディスクリプタのプロパティの概要」を参照してください。
SOAコンポジット・アプリケーションを設計する場合、次の課題に直面することがあります。
サービス・エンドポイント(アドレス)が設計時にわからない場合があります。
アプリケーションの実行中に、エンドポイント参照の変更が必要な場合があります。
動的パートナ・リンク機能を使用すると、BPELバージョン1.1および2.0の実行時に使用するために、エンドポイント参照をパートナ・リンクに動的に割り当てることができます。動的パートナ・リンクでは、switchアクティビティに類似した条件が提供され、この条件は実行時に評価されます。
動的パートナ・リンクを使用すると複数のWebサービスと対話できます。この対話には、メッセージを暗号化するために様々なセキュリティ証明書を必要とするメッセージ保護ポリシーの使用が含まれる場合があります。これらの証明書は、Webサービスごとに異なる場合があります。キーストア受信者別名値を指定して、WebサービスのWSDLファイル内のセキュリティ証明書をオーバーライドできます。
パートナ・リンクを起動する際にセキュリティ証明書をオーバーライドする手順は、次のとおりです。
正規化されたメッセージのプロパティの詳細は、「メッセージ・ヘッダーを介した正規化メッセージ・プロパティの伝播」を参照してください。
場合によっては、次のような理由によって、動的パートナ・リンクによって使用されるデフォルトWSDLファイルをオーバーライドする必要があります。
メッセージ保護セキュリティ・ポリシーを使用するサービスと統合する必要がある。
WSDLに、メッセージ暗号化に使用される証明書など重要な情報が含まれている可能性がある。
正規化されたメッセージのプロパティendpointWSDLによって、動的パートナ・リンクのWSDLファイルを指定できます。エンドポイントのみでなく、WSDL全体を動的に指定する必要があります。これにより、WSDLファイルをOracle Web Services Manager (OWSM)に渡すことができ、その後、OWSMは指定されたWSDLから適切なサービス証明書を取得できます。
WSDLファイル内の証明書は、次の場合には無視されます。
「動的パートナ・リンクを起動する際のセキュリティ証明書のオーバーライド」に記載されているrecipient.key.aliasプロパティ名が存在している。
endpointWSDLプロパティが存在していない。
それ以外の場合、証明書はWSDLファイルから取得されます。
動的パートナ・リンクのWSDLファイルをオーバーライドする手順は、次のとおりです。
正規化されたメッセージのプロパティの詳細は、「メッセージ・ヘッダーを介した正規化メッセージ・プロパティの伝播」を参照してください。
ある時点でアクティブなインスタンスは多数存在する可能性があるため、サーバーはWebサービス・レスポンスに、対応する適切なBPELプロセス・サービス・コンポーネント・インスタンスを指示する必要があります。WS-Addressingを使用すると、非同期メッセージを識別して、非同期コールバックが確実に適切なクライアントを特定できるようにすることができます。
図8-9 に、WS-Addressingの概要を示します。WS-Addressingは、非同期メッセージの相関にSimple Object Access Protocol (SOAP)ヘッダーを使用します。メッセージは、使用されるトランスポートまたはアプリケーションに依存しません。
図8-9 は、レスポンスが正しい宛先に送信されるように、メッセージがWSヘッダーとともに渡される様子を示しています。
この章の例では、相関にWS-Addressingを使用しています。メッセージの表示には、TCPトンネリングを使用できます。これについては、「プログラム間で交換されるメッセージを表示するためのTCPトンネリングの使用方法」で説明します。
WS-Addressingは、通常は通信プロトコルおよびメッセージ・システムで提供される次の情報を定義します。この情報は、トランスポートまたはアプリケーションに依存せずに処理されます。
エンドポイント・ロケーション(返信先アドレス)
返信先アドレスは、BPELクライアントがコールバック・メッセージをリスニングする場所を指定します。
対話ID
TCPトンネリングを使用して、BPELプロセス・サービス・コンポーネント・フローとWebサービスの間で交換されたSOAPメッセージ(相関IDを含むメッセージなど)を表示します。BPELプロセス・サービス・コンポーネント・フローの通信先のサービスに対して送受信される正確なSOAPメッセージを確認できます。
BPELプロセス・サービス・コンポーネント・フローとWebサービスの間にソフトウェア・リスナーを挿入します。BPELプロセス・サービス・コンポーネント・フローはリスナー(TCPトンネル)と通信します。リスナーはメッセージをWebサービスに転送し、表示します。Webサービスからのレスポンスはトンネルに返され、トンネルはレスポンスを表示して、BPELプロセス・サービス・コンポーネントに返します。
WS-Addressingは公開されている仕様であり、でサポートされるデフォルトの相関方法です。WS-Addressingを使用するために、.bpel
ファイルおよび.wsdl
ファイルを編集する必要はありません。
プログラムとサービスの間で交換されるメッセージは、TCPトンネリングにより表示できます。これは、BPELプロセス・サービス・コンポーネント・フローとWebサービスの間で交換される正確なSOAPメッセージを表示する場合に、特に役立ちます。
SOAPメッセージを監視するには、フローとサービスの間にソフトウェア・リスナーを挿入します。フローはリスナー(TCPトンネル)と通信し、リスナーはサービスにメッセージを転送し、メッセージを表示します。同様に、サービスからのレスポンスはトンネルに返され、トンネルはレスポンスを表示してフローに返します。
サーバーとWebサービスの間で交換されたすべてのメッセージを表示する場合、該当するすべてのメッセージがサービスとの間で1回のリクエスト/リプライのやり取りで交換されるため、同期サービスに対して必要なTCPトンネルは1つのみです。非同期サービスの場合、2つのトンネル(サービスの起動用に1つ、フローのコールバック・ポート用に1つ)を設定する必要があります。
非同期サービスからのコールバックのSOAPメッセージを表示するTCPリスナーを設定する手順は、次のとおりです。
ポートでのリスニングとOracle BPEL Process Managerポートの送信を実行するTCPリスナーを起動します。
「Oracle Enterprise Manager Fusion Middleware Control」を開きます。
「SOAインフラストラクチャ」メニューから、「SOA管理」→「共通プロパティ」の順に選択します。
「コールバック・サーバーURL」に値を指定します。このURLは、サーバーによって非同期コールバック・アドレスの一部としてインボーカに送信されます。
「SOAインフラストラクチャ」メニューから、「管理」→「システムMBeanブラウザ」の順に選択します。
「アプリケーション定義のMBean」→「oracle.soa.config」→「サーバー: soa_server」→「SCAComposite」の順に展開します。
soa_serverは、特定のサーバー・インスタンス名です(例: AdminServer)。
サーバーにデプロイされているすべてのSOAコンポジット・アプリケーションが表示されます。
次の手順に従って、このプロパティをコンポジット・アプリケーションに設定します。このアクションにより、コンポジット・アプリケーションのすべてのバインディングにプロパティ設定が適用されます。
コンポジットをクリックします。
「属性」タブが選択されていることを確認します。
「名前」列で、「プロパティ」をクリックします。
「追加」アイコンをクリックします。
新しく追加した「Element_number」(リストの最後に表示されます)を開きます。
numberは、最後のプロパティの番号の次の番号です。たとえば、プロパティ・リストに12個の要素があるときに新しいプロパティを追加すると、Element_13が表示されます。
「名前」フィールドに、oracle.webservices.local.optimization
と入力します。
「値」フィールドに、false
と入力します。
「複数」フィールドに、false
と入力します。
「適用」をクリックし、次に「戻る」をクリックします。
「操作」タブの「名前」列で、「保存」をクリックします。
「起動」をクリックして操作を実行します。
「戻る」をクリックするか、「システムMBeanブラウザ」ペインでノードをクリックします。
注意:
プロパティを追加、削除または更新した後は、「システムMBeanブラウザ」ページの右上隅にある「キャッシュされたツリー・データのリフレッシュ」アイコンをクリックすると、新しいデータを参照できます。
次の手順に従って、このプロパティを特定のバインディングに設定します。
非同期Webサービスを起動するフローを開始します。これを同期TCPトンネリング構成と組み合せると、サービス開始リクエストを最初のTCPトンネル経由で送信できます。
非同期サービスからのコールバックは、TCPリスナーに表示されます。
Oracle JDeveloperユーザーは、組込みパケット・モニターを使用して、同期サービスと非同期サービスの両方についてSOAPメッセージを表示することもできます。
メッセージの相関での相関セットの使用方法の詳細は、「相関セットおよびメッセージ集約の使用」を参照してください。