ヘッダーをスキップ
Oracle SOA Suite開発者ガイド
10g(10.1.3.1.0)
B31839-01
  目次へ
目次
索引へ
索引

前へ
前へ
 
次へ
次へ
 

2.5 SOA Order Bookingアプリケーションの詳細説明

SOA Order Bookingアプリケーションは、SOADEMO-CLIENTアプリケーションを実行することによって実行します。 このアプリケーションでは、ビュー・テクノロジとしてJavaServer Faces(JSF)が使用され、他のアプリケーション用のWebサービスを起動するためにバッキングBeanが使用されます。

クライアントを起動するには、ブラウザを開いて次のURLを入力します。

http://<host_hame>:<port_number>/soademo

例:

http://localhost:8888/soademo

ログイン・ページが起動すると、有効な電子メール/パスワードの組合せを使用してWebサイトにアクセスできます。または、新規顧客として登録することもできます。 SOA Order Bookingアプリケーションには、事前定義の顧客データが含まれています。 これらの顧客の電子メールおよびパスワードの1つを使用してログインするか、または新規顧客として登録できます。 表2-2に、事前登録済の顧客を示します。

表2-2 SOA Order Bookingアプリケーションの事前登録済の顧客

電子メール パスワード 顧客ステータス 説明

sking@soademo.org

welcome1

Gold

$1,000以上の注文の場合は手動による承認が必要

jchen@soademo.org

welcome1

Platinum

クレジット・カード番号が無効

ghimuro@soademo.org

welcome1

Silver

すべての注文について手動による承認が必要


注文を作成するとESBが起動され、このESBによって、注文を処理するBPELプロセス・フローが起動されます。 注文が処理中になると、ESB Consoleを使用してESBのステータスを表示でき、BPEL Consoleを使用してプロセス・フローのステータスを表示できます。 また、Oracle Enterprise Managerを使用すると、システム全体のステータスを表示できます。

SOA Order Bookingアプリケーションには、サービスに対してデフォルトではセキュリティ制約が設定されていませんが、Oracle Web Services Manager(Oracle WSM)を使用してサービスを保護できます。 このアプリケーションには、サービスに対してセキュリティを定義するためのツール、およびサービスを監視できるコンソールが含まれています。 Oracle WSMの使用方法の詳細は、第10章「システムの保護」を参照してください。

2.5.1 登録プロセス

ユーザーが顧客として登録すると、Webクライアントによって必要な情報が収集され、Customer Webサービスが起動されて、その情報がCustomer Serviceアプリケーションに送信されます。 図2-19にRegistrationページを示します。

図2-19 Registrationページ

ユーザーは、Registrationページで登録情報を入力できます。

ユーザーが「Register」ボタンをクリックすると、Register.javaバッキングBeanのメソッドによってデータが収集され、CustomerService Webサービスが起動されます。 次に、CRMアプリケーションによって、データがCustomer表に格納されます。

実装詳細の参照先

登録プロセスで使用されるコンポーネントの開発方法は、このマニュアルの次の各項を参照してください。

  • Webページでの情報の収集: 登録ページでは、JSF入力コンポーネントをバッキングBeanのプロパティにバインドすることによって情報が収集されます。 このページは、CustomerService Webサービスで示されている必要な情報を収集するように設計されています。 Webサービスに必要な情報を収集するWebページの作成方法は、第9.6項「Webサービスで使用するデータの収集」を参照してください。

  • WebページからのWebサービスの起動: register.java JSFバッキングBeanには、Webサービスを起動し、Webサービスに登録データを移入するメソッドが含まれています。 詳細は、第9.6.3項「バッキングBeanを使用したサービスの起動方法」を参照してください。

2.5.2 ログイン・プロセス

登録済ユーザーがWebクライアントにログインすると、ユーザー名とパスワードが、顧客サービス・データベースに格納されている資格証明情報と比較されます。 図2-20に、Webクライアント用のApplication Loginページを示します。

図2-20 Application Loginページ

ユーザーはApplication Loginページでログインします。

ユーザーが「Login」ボタンをクリックすると、関連するLogin.javaバッキングBeanによって、その情報が収集され、CustomerService Webサービスが起動されます。このWebサービスによって、データベース内のユーザー情報が検証されます。

2.5.3 注文プロセス

注文プロセスは、ユーザーが製品を参照して注文できるWebクライアント・アプリケーションから開始されます。 このWebアプリケーションによって、ESBフローが開始され、BPELフローが起動されます。 BPELフローによって、実際の注文プロセスが処理されます。

2.5.3.1 Webクライアント

登録済ユーザーは、図2-21に示されているWelcomeページの「Browse products」リンクをクリックすると、製品を参照できます。Welcomeページはログイン直後に表示されます。

図2-21 Application Welcomeページ

Application Welcomeページ

このリンクからBrowse Itemsページが表示され、図2-22に示すように、販売可能なすべての製品がリストされます。 製品情報は、クライアント・アプリケーションのデータベース内のPRODUCT表に格納されています。 該当するデータは、ADFデータ・バインディングを使用する表に表示されます。

図2-22 BookingのBrowse Itemsページ

ユーザーは、BrowseItemsページで製品を選択できます。

ユーザーが製品を選択し、「View Details」ボタンをクリックすると、図2-23に示すように、Item Detailsページに製品の詳細が表示されます。 このページには、製品に関する詳細情報が表示されます。ユーザーは、数量を選択し、その製品をカートに追加できます。

図2-23 Item Detailsページ

ユーザーは、ItemDetailsで詳細を表示し、品目をカートに追加できます。

ユーザーが「Go to Shopping Cart」リンクをクリックすると、図2-24に示すように、追加した品目がCartページに表示されます。

図2-24 SOA Order BookingのCartページ

ユーザーは、Cartページから注文を発行できます。

ユーザーが「Place Order」ボタンをクリックすると、発注が作成され、OrderBookingESBフローに送信されます。

実装詳細の参照先

注文プロセスで使用されるWebクライアント・コンポーネントの開発方法は、このマニュアルの次の各項を参照してください。

2.5.3.2 OrderBookingESBフロー

ユーザーが「Place Order」ボタンをクリックすると、OrderBookingESBフローが起動されます。 このフローによって、SOAOrderBooking BPELフローが起動されます。 図2-25に、ESBフローをOracle JDeveloperで表示されるとおりに示します。

図2-25 OrderBookingESBフロー

OrderBookingESBフロー

実装詳細の参照先

OrderBookingESBフローによって、BPELフロー用のWebサービスが起動されます。 詳細は、第6.7項「Oracle Enterprise Service BusへのSOAPサービスの追加」を参照してください。

2.5.3.3 SOAOrderBooking BPELフロー

SOAOrderBooking BPELフローによって、図2-26に示すように、注文プロセスが処理されます。

図2-26 SOAOrderBooking BPELフロー

SOAOrderBooking BPELフロー

各スコープ・アクティビティ・アイコン(フロー付きのグレーのボックス)は、フローの詳細部分の上位レベルのビューを表しています。 後続の各項では、各スコープ・アクティビティ内の詳細など、フローの各ステップについて説明します。 最初のアクティビティ(receiveInput)は、フローの起点として機能するのみであるため、説明はありません。

2.5.3.3.1 InsertOrderIntoDBスコープ

InsertOrderIntoDBスコープには、次のアクティビティが含まれています。

  • GetOrderId: データベース・アダプタを使用して注文IDを取得して、Order順序にアクセスします。

  • AssignOrderStatus: 注文IDおよびステータス(pending)をコピーして、これらの値を変数に割り当てます。

  • TransformOrder: 注文データをorderRequest変数に変換します。

  • InsertOrder: データベース・アダプタを使用して注文をORDER表に挿入します。

図2-27に、InsertOrderIntoDBスコープを詳細に示します。

図2-27 InsertOrderIntoDBスコープ

JDeveloperでのBPEL内のInsertOrderIntoDBScope

実装詳細の参照先

InsertOrderIntoDBスコープで使用される各種コンポーネントの開発方法は、このマニュアルの次の各項を参照してください。

  • 変数への値の割当て: AssignOrderStatusアクティビティでは、注文ID番号とステータスが、スコープ内で使用される変数に割り当てられます。 変数の使用方法と割当方法の詳細は、第7.4項「assignアクティビティの使用」を参照してください。

  • データの変換: 注文データは、ESBフローから受信されたときのメッセージ・コンテンツから、データベース・アダプタで受け入れられるデータに変換されます。 データの変換方法の詳細は、第7.5項「トランスフォーメーションの作成」を参照してください。

  • サービスの起動: Orderデータベース・サービスが起動され、注文データをデータベースに格納できます。 データベース・アダプタの使用方法の詳細は、第7.6項「データベースとの通信」を参照してください。

2.5.3.3.2 CustomerServiceスコープ

CustomerServiceスコープには、次のアクティビティが含まれています。

  • AssignRequest: 顧客のIDをコピーし、その値を変数に割り当てます。

  • GetCustInfo: Customerサービスを同期で起動し、顧客IDを使用して顧客情報を取得します。

  • AssignInitialCustomerResponse: ESBフローからBPELフロー内の変数に発注をコピーします。

  • AssignCustomerResponse: 顧客の姓名をコピーし、その値を変数に割り当てます。

図2-28に、CustomerServiceスコープを詳細に示します。

図2-28 CustomerServiceスコープ

JDeveloperでのCustomerService BPELスコープ

実装詳細の参照先

CustomerServiceスコープで使用される各種コンポーネントの開発方法は、このマニュアルの次の各項を参照してください。

  • サービスの同期起動: GetCustInfoアクティビティでは、CustomerService Webサービスへの同期コールを使用し、顧客IDに従って顧客の姓名が取得されます。サービスの同期コールの作成方法の詳細は、第7.3項「Webサービスの起動」を参照してください。

  • サービスへのパートナ・リンクの作成: CustomerServiceパートナ・リンクは、顧客情報を取得するためにCustomerService Webサービスにアクセスします。 パートナ・リンクの作成方法の詳細は、第7.3.1.1項「パートナ・リンクの作成」を参照してください。

2.5.3.3.3 CreditServiceスコープ

CreditServiceスコープには、次のアクティビティが含まれています。

  • InitializeRequest: 顧客データからクレジット・カードの種類と番号をコピーし、その値を変数に割り当てます。

  • InvokeCreditService: クレジット・カードの種類と番号を含む同期コールを使用して、CreditValidatingService Webサービスを起動します。 このサービスは、有効または無効のレスポンスでリプライします。

  • 汎用switchアクティビティ: switchタスクの式では、サービスからカードが無効であることを示すレスポンスが戻された場合は、エラーをスローする必要があることが示されます。 このswitchアクティビティには、次の2つのアクティビティが含まれています。

図2-29に、CreditServiceスコープを詳細に示します。

図2-29 CreditServiceスコープ

JDeveloperでのCredit Service BPELスコープ

実装詳細の参照先

CreditServiceスコープで使用される各種コンポーネントの開発方法は、このマニュアルの次の各項を参照してください。

  • switchアクティビティを使用した条件付きブランチの作成: switchアクティビティを使用すると、条件付きのケースを作成できます。 このフローは、trueに評価されるパスに従います。 条件付きブランチの作成方法の詳細は、第7.7項「switchアクティビティを使用した条件付きブランチの作成」を参照してください。

  • フォルトの処理: クレジット・サービスからカードが無効であることを示すメッセージが戻された場合、フローは続行できないため、フォルトとして処理する必要があります。 フォルトの処理方法の詳細は、第7.10項「フォルト処理」を参照してください。

2.5.3.3.4 RequiresManualApprovalスコープ

RequiresManualApprovalスコープには、次のアクティビティが含まれています。

  • BPEL_Header: BPELフローに関する情報を取得し、その情報を変数に割り当てます。

  • BPEL_Var_To_Rule_Facts: 発注価格および顧客ステータスの変数値をファクトに割り当てます。このファクトは、注文に対して手動による承認が必要かどうかを判断するルールによって使用されます。

  • Facts_To_Rule_Service: ファクトを変数に割り当てます。

  • Invoke: デシジョン・サービスを起動します。このデシジョン・サービスによって、注文に対して手動による承認が必要かどうかを判断するルールが起動されます。

  • Rule_Service_To_Facts: レスポンス(注文に対して手動による承認が必要かどうか)を受け取り、値をルール・ファクトに設定します。

  • Facts_To_BPEL­_Var: ルール・ファクトの値を変数に割り当てます。

図2-30に、RequiresManualApprovalスコープを詳細に示します。

図2-30 RequiresManualApprovalスコープ

JDeveloperでのRequiresManualApproval BPELスコープ

実装詳細の参照先

RequiresManualApprovalスコープで使用される各種コンポーネントの開発方法は、このマニュアルの次の各項を参照してください。

  • ビジネス・ルールの作成: フローでは、注文に対して手動による承認が必要かどうかを判断するビジネス・ルールが使用されます。 顧客のステータスが「platinum」の場合、承認は必要ありません。 顧客のステータスが「gold」で、かつ注文が$1,000以上の場合は、注文に対して手動による承認が必要です。 顧客のステータスが「silver」の場合は、注文に対して手動による承認が必要です。 ルールの作成方法の詳細は、第8章「デシジョン・サービスに関するルールの作成と使用」を参照してください。

  • デシジョン・サービスを使用したビジネス・ルールの起動: 起動可能なルールはアプリケーションを介して作成できますが、SOA Order Bookingアプリケーション内のルールは、デシジョン・サービスを使用してBPELフローから起動されます。 デシジョン・サービスの使用方法の詳細は、第7.8項「ビジネス・ルールおよびdecideアクティビティの使用」を参照してください。

2.5.3.3.5 RequiresApprovalスイッチ

RequiresApprovalスイッチは、デシジョン・サービスによって、注文に対して手動による承認が必要と判断された場合にのみ実行されます。 次のアクティビティが含まれています。

  • ApproveOrder_AssignTaskAttributes: 注文の承認に必要な注文属性値を受け取り、その値を変数に割り当てます。

  • ApproveOrder_AssignSystemTaskAttributes: 承認に必要なプロセス・フロー属性値を受け取り、その値を変数に割り当てます。

  • InitiateTask_ApproveOrder: ヒューマン・ワークフローを、TaskService Webサービスの非同期コールで起動します。

  • ReceiveCompletedTask_ApproveOrder: ヒューマン・ワークフローからのレスポンスを受信します。

  • switchタスク: 注文が承認されたかどうかに基づいてフローを決定します。

    • 結果がReject: 注文が却下された場合は、フローによってOrder Bookingフォルトがスローされます。

    • 結果がApprove: 注文が承認された場合、フローはそのまま続行されます。

    • その他の場合: タスクの結果が「期限切れ」、「失効」、「取消し済」または「却下」の場合に使用されます。

図2-31に、RequiresApprovalスイッチを詳細に示します。

図2-31 RequiresApprovalスイッチ

JDeveloperでのRequiresApproval BPELスイッチ

実装詳細の参照先

注文に対して手動による承認が必要な場合は、BPELフローによって、TaskService Webサービスが起動され、注文を承認するためのヒューマン・ワークフローが開始されます。 このサービスは非同期で起動され、情報はワークフローに送信されます。 このワークフローでは、ユーザーが割当タスクを完了できるWebベースのインタフェースが提供されます。 図2-32に、マネージャが注文を承認できるWebページを示します。 注文が承認されると、情報は、再度非同期コールを使用してBPELフローに戻されます。 タスク・サービスの使用方法の詳細は、第7.12項「ヒューマン・ワークフロー・タスクの作成」を参照してください。

図2-32 Workflow Webページ

BPELのWorkflowページからヒューマン・ワークフローにアクセスできます。

2.5.3.3.6 SelectSupplierスコープ

SelectSupplierスコープには、2つの異なるサプライヤに情報を送信するパラレル・フローが含まれています。 サプライヤはそれぞれ注文に対する価格を戻します。 次に、switchアクティビティによって、注文を履行するために使用されるサプライヤが評価条件に基づいて決定されます。 SelectSupplierスコープには、次のアクティビティが含まれています。

  • GetSelectMfrQuote: 注文情報をSelect Manufacturerに非同期コールで送信するフロー。 このフローには、次のアクティビティが含まれています。

    • TransformSelectRequest: 注文情報を受け取り、その情報を、Select Manufacturerが見積りを完了するために必要なパラメータに変換します。

    • InvokeSelectManufacturer: SelectService Webサービスを起動し、前述のアクティビティで変換された情報を送信します。

    • ReceiveSelectManufacturer: Select Manufacturerから非同期のレスポンスを受信し、それを変数として格納します。

  • CallRapidManufacturer: 注文情報をRapid Manufacturerに同期コールで送信するフロー。 このフローには、次のアクティビティが含まれています。

    • TransformRapidRequest: 注文情報を受け取り、その情報を、Rapid Manufacturerが見積りを完了するために必要なパラメータに変換します。

    • InvokeRapidManufacturer: RapidService Webサービスを起動して、Rapid Manufacturerからの見積りを取得します。

  • SelectByPriceスイッチ: 式によって、注文が割り当てられる製造業者が決定されます。 Select Manufacturerの価格がRapid Manufacturerの価格より低い金額の場合、注文はSelect Manufacturerに割り当てられます。 それ以外の場合、注文はRapid Manufacturerに割り当てられます。 結果によって、次のいずれかのアクティビティが起動されます。

    • AssignSelectManufacturer: 価格およびSelect Manufacturerを変数に割り当てます。

    • AssignRapidManufacturer: 価格およびSelect Manufacturerを変数に割り当てます。

図2-33に、SelectSupplierスコープを詳細に示します。

図2-33 SelectSupplierスコープ

JDeveloperでのSelectSupplier BPELスコープ

実装詳細の参照先

SelectSupplierスコープで使用される各種コンポーネントの開発方法は、このマニュアルの次の各項を参照してください。

  • パラレル・フローの作成: サプライヤをコールする2つのフローが同時に実行されます。 パラレル・フローの作成方法の詳細は、第7.9項「パラレル・フローの作成」を参照してください。

  • サービスの非同期起動: フローでは、非同期コールを使用してSelectService Webサービスが起動されます。 このサービスによって、個別のリプライがフローに戻されます。

2.5.3.3.7 PostFulfillmentReqスコープ

PostFulfillmentReqスコープでは、出荷ベンダーを決定するために使用されるESBフローが起動されます。 次のアクティビティが含まれています。

  • InitializeRequest: 発注を表す変数の値を、ESBフローで使用される変数に割り当てます。

  • PostFulfillmentReq: OrderFulfillment ESBフローを起動し、変数値を渡します。 このESBフローの詳細は、第2.5.3.4項「OrderFulfillmentESBフロー」を参照してください。

図2-34に、PostFulfillmentReqスコープを詳細に示します。

図2-34 PostFulfillmentReqスコープ

JDeveloperでのPostFulfillmentReq BPELスコープ

実装詳細の参照先

PostFulfillmentReqアクティビティによってESBフローが起動されます。 ESBフローの起動方法の詳細は、第7.3項「Webサービスの起動」を参照してください。

2.5.3.3.8 SetFinalOrderStatusスコープ

SetFinalOrderStatusスコープでは、データベース・アダプタを使用して、ORDERS表内の注文のステータスが更新されます。 SetFinalOrderStatusスコープには、次のアクティビティが含まれています。

  • AssignOrderStatus: 注文IDおよびステータス(completed)をコピーして、これらの値を変数に割り当てます。

  • UpdateOrderStatus: データベース・アダプタを起動し、変数を使用して注文のステータスを更新します。

図2-35に、SetFinalOrderStatusを詳細に示します。

図2-35 SetFinalOrderStatusフロー

JDeveloperでのSetFinalStatus BPELスコープ

実装詳細の参照先

Orderデータベース・サービスが起動され、注文データがデータベースに格納されます。 データベース・アダプタの詳細は、第7.6項「データベースとの通信」を参照してください。

2.5.3.3.9 NotifyCustomerスコープ

NotifyCustomerスコープでは、通知サービスが起動され、注文が履行されていることが顧客に通知されます。 NotifyCustomerスコープには、次のアクティビティが含まれています。

  • Assign: 注文と顧客の変数値を、電子メールを作成するNotificationサービスで使用される変数に割り当てます。

  • NotifyCustomer: 通知サービスを起動して電子メールを送信します。

図2-36に、NotifyCustomerスコープを詳細に示します。

図2-36 NotifyCustomerスコープ

JDeveloperでのNotifyCustomer BPELスコープ

実装詳細の参照先

NotifyCustomerアクティビティによって通知サービスが起動され、電子メール通知の作成に使用される変数が渡されます。 この通知サービスによって、電子メールが送信されます。 通知サービスの詳細は、第7.13項「電子メール通知の作成」を参照してください。

2.5.3.3.10 CallbackClientアクティビティ

CallbackClientアクティビティでは、図2-37に示すように、Webクライアントが起動されます。 このアクティビティによって、注文のステータスとともに、レスポンス・メッセージがクライアントに戻されます。

図2-37 CallBackClientスコープ

JDeveloperでのCallBackClient BPELアクティビティ

2.5.3.3.11 OrderBookingFaultスコープ

OrderBookingFaultスコープは、フロー内でフォルトが発生したときに起動される汎用フォルトです。 OrderBookingFaultスコープには、次のアクティビティが含まれています。

  • AssignOrderStatus: 注文およびステータスに対する変数値を割り当てます。

  • SetFaultedOrderStatus: データベース・アダプタを使用して、注文のステータスをCancelledに設定します。

図2-38に、OrderBookingFaultスコープを詳細に示します。

図2-38 OrderBookingFault

JDeveloperでのOrderBookingFault

実装詳細の参照先

OrderBookingFaultスコープは、プロセス・フロー内でスローされたすべての例外およびエラーを処理するために使用されます。 フローに対するフォルトの作成方法の詳細は、第7.10項「フォルト処理」を参照してください。

2.5.3.4 OrderFulfillmentESBフロー

OrderFulfillmentESBフローでは、注文を出荷するベンダー(USPSまたはFederal Express)が決定されます。 決定は、ルーティング・ルールに基づいて行われます。 このフローには、次のサービスが含まれています。

  • OrderFulfillmentルーティング・サービス: 注文情報をShipmentルーティング・サービスにルーティングします。 また、メッセージをFulfillmentBatch JMSアダプタにルーティングします。

  • Shipmentルーティング・サービス: 注文合計が$500以上の場合は注文情報をFedExにルーティングし、$500未満の場合はUSPSにルーティングします。その後、FedExまたはUSPSによって理解されるメッセージに情報を適切に変換します。

  • FedexShipmentデータベース・アダプタ: 注文情報をFedExに送信し、その情報をFEDEXSHIPMENTデータベース表に挿入します。

  • USPSShipmentデータベース・アダプタ: 注文情報をUSPSに送信します。

  • FulfillmentBatch JMSアダプタ: JMSアダプタを使用して、完了メッセージをBPELフローに戻します。

図2-39に、OrderFulfillmentESBフローを詳細に示します。

図2-39 OrderFulfillmentESBフロー

JDeveloperでのOrderFulfillment ESBフロー

実装詳細の参照先

OrderFulfillmentESBスコープで使用されるコンポーネントの開発方法は、このマニュアルの次の各項を参照してください。

2.5.4 システムへのセキュリティの追加

SOA Order Bookingアプリケーションにセキュリティは組み込まれていませんが、Oracle WSMを使用すると、サービス指向環境のWebサービスおよびプロセス・フローを、クライアント・アプリケーションまたはWebサービスを変更せずに保護できます。

Oracle WSMでは、次の主要コンポーネントでサービス環境が保護されます。

  • Oracle WSM Policy Manager: 操作のベスト・プラクティスおよび要件を反映したポリシーを定義できます。 このコンポーネントには、ビルトインまたはカスタムのポリシー・ステップを使用して、Webサービスおよびビジネス・プロセスに対するセキュリティ・ポリシーと管理ポリシーを作成および保守するためのブラウザ・ベースのツールが含まれています。

  • Oracle WSM Gateway: このコンポーネントによって、他に影響を与えずにポリシーを実行するためのメカニズムが提供されます。

  • Oracle WSM Agent: ポリシー実行点としても機能するこのコンポーネントは、Webサービスと同じコンテナ(アプリケーション・サーバー環境)で実行される軽量コンポーネントです。 Oracle Web Services Managerには、クライアント・エージェントとサーバー・エージェントの2種類のエージェントが用意されています。

  • Oracle WSM Monitor: このコンポーネントでは、Webサービスのトラフィック・データの収集および集計が管理され、アラートおよび通知が提供されます。 このモニターの概要は、第2.5.5.4項「Oracle Web Services Manager Monitor」を参照してください。

Oracle WSMの使用方法の詳細は、第10章「システムの保護」を参照してください。

2.5.5 システムの監視

注文が処理中になると、Oracle Enterprise Service Bus ControlおよびOracle BPEL Controlを使用して、ESBおよびBPELプロセス・フロー全体のプロセスを監視できます。 また、Oracle Enterprise Managerを使用して、システム全体のステータスを表示できます。 SOAシステム内のサービスにセキュリティを適用する場合は、Oracle Web Services Manager Control Consoleを使用してそのセキュリティを監視できます。

2.5.5.1 Oracle ESB Control

Oracle ESB Controlは、ブラウザ・ベースのツールで、ESBフロー全体のメッセージ・インスタンス処理を、ESBフローを表す図式ダイアグラムで監視できます。 このダイアグラムを使用して、次の操作を実行できます。

  • ESBへの全接続の表示

  • ESB外部のアプリケーションからESBサービスをコールするために必要なURLなど、ESBの詳細の表示

  • 宛先に着信しなかったメッセージも含めた、図式内でのエラー状態の表示

  • 失敗したメッセージの再送信も含めた、エラー状態の修正

図2-40に、成功したメッセージ処理の表示に使用されているESB Controlを示します。

図2-40 ESB Console - 「インスタンス」ビュー

ESB Controlにメッセージ・フローが表示されています。
「図2-40 ESB Console - 「インスタンス」ビュー」の説明

Oracle ESB Controlの使用方法の詳細は、第12章「Oracle Enterprise Service Busの監視」を参照してください。

2.5.5.2 Oracle BPEL Control

Oracle BPEL Controlは、BPELプロセスのライフサイクルを管理するためのブラウザ・ベースのツールです。 Oracle BPEL Controlを使用して、次の操作を実行できます。

  • デプロイ済、実行中および完了プロセスの表示

  • インスタンス内の失敗したメッセージのリカバリなど、プロセスのライフサイクルの管理、およびプロセスの開始

  • テスト・データの入力およびプロセスの直接開始(SOAシステムへのデプロイ前にプロセスのテストが可能)

  • プロセス・インスタンスの表示

  • プロセス・アクティビティの表示

図2-41に、手動による承認を待機中のSOAOrderBookingプロセス・インスタンスが表示されたBPEL Controlを示します。

図2-41 Oracle BPEL ControlでのSOA Order Bookingインスタンス

Oracle BPEL Controlにフロー・ステータスが表示されています。

Oracle BPEL Controlの使用方法の詳細は、第13章「Oracle BPEL Process Managerの監視」を参照してください。

2.5.5.3 Oracle Enterprise Manager Control Console

Oracle Enterprise Manager 10g Application Server Control Consoleは、Webベースのユーザー・インタフェースで、OC4J内のアプリケーションを監視できます。 Enterprise Managerを使用して、次の項目を監視できます。

  • OC4Jインスタンス

  • クラスタ・トポロジ

  • デプロイ済アプリケーション

  • WebモジュールおよびEJBモジュールのパフォーマンス

  • JVMメトリック

図2-42に、J2EEコンテナのパフォーマンスの監視に使用されているEnterprise Managerを示します。

図2-42 コンテナのパフォーマンス

EMでは、システム・パフォーマンス・メトリックを表示できます。

Enterprise Managerを使用してシステムを監視する方法の詳細は、第15章「Enterprise Managerを使用したSOAアプリケーションの監視」を参照してください。

2.5.5.4 Oracle Web Services Manager Monitor

Oracle Web Services Manager Monitorは、ブラウザ・ベースのツールで、SOAシステム内で使用される管理サービスのステータスおよびパフォーマンスを監視できます。Webサービスを保護するために設定したコンポーネント(ゲートウェイおよびエージェント)の動作状態を監視できる拡張機能などがあります。

Web Services Manager Monitorを使用して、次の操作を実行できます。

  • 実行メトリックの表示

  • セキュリティ統計の表示

  • サービス統計の表示

  • アラームの表示

  • セキュリティ・ロールの管理

図2-43に、セキュリティ統計の監視に使用されているWeb Services Manager Monitorを示します。

図2-43 セキュリティの監視

OWSM Monitorに、Webサービスのセキュリティの状態が表示されています。