ヘッダーをスキップ
Oracle SOA Suiteクイック・スタート・ガイド
10g(10.1.3.1.0)
B31832-01
  目次へ
目次
索引へ
索引

前へ
前へ
 
次へ
次へ
 

1 Oracle SOA Suiteの概要

この章では、SOAアプリケーションを設計、開発、デプロイおよび監視するOracle SOA Suiteの概要を示します。

項目は次のとおりです。

1.1 サービス指向アーキテクチャに移行する理由

多くの企業は、サービス指向アーキテクチャ(SOA)を使用して、アプリケーションおよびIT環境の複雑さに対処しています。 SOAでは、複合型エンタープライズ・アプリケーションの構築をサポートするエンタープライズ・アーキテクチャが提供されます。 SOAによって、エンタープライズ・アプリケーションを、簡単に統合および再利用できるモジュール化ビジネスWebサービスとして開発することが容易になり、高い柔軟性と適応性を備えたITインフラストラクチャを作成できます。

Webサービスでは、所有権のあるソフトウェアの相互運用性が提供されます。 Web Services Description Language(WSDL)、Extensible Markup Language(XML)、Simple Object Access Protocol(SOAP)などのWebサービス標準が、サービスを公開するための効率的で相互運用性の高いプラットフォームとして出現しています。 さらに、高パフォーマンスのバインディング・フレームワークによって、SOAPインタフェースにラップすることなくレガシー・システムやネイティブのJavaコードにアクセスできます。

Webサービスを機能させるには、次の2段階の処理が必要です。

  1. サービスの公開

    サービスの公開とは、既存のアプリケーションまたはシステム内の機能を取得し、その機能を標準的な方法で使用可能にすることです。

  2. ビジネス・フローへのサービスの構成(オーケストレーション)

    オーケストレーションとは、複数のサービスからエンドツーエンドのビジネス・プロセスを構成することです。 このオーケストレーションは、Business Process Execution Language(BPEL)言語でサポートされます。

1.2 Oracle SOA Suiteの機能

Oracle SOA Suiteは、サービスの作成、デプロイおよび管理に対応するサービス・インフラストラクチャ・コンポーネントの完全なセットです。 Oracle SOA Suiteを使用すると、サービスを作成して管理し、複合アプリケーションやビジネス・プロセスに組み込むことができます。 さらに、プロジェクト単位で段階的に採用でき、共通のセキュリティ、管理、デプロイ・アーキテクチャおよび開発ツールをそのまま使用できるという利点もあります。

Oracle SOA Suiteは、次の機能で構成される標準ベースのベストオブブリード・テクノロジ・スイートです。

図1-1に、Oracle SOA Suiteのアーキテクチャを示します。

図1-1 Oracle SOA Suiteのアーキテクチャ

図1-1の説明は次にあります。
「図1-1 Oracle SOA Suiteのアーキテクチャ」の説明

統合サービス環境

Oracle JDeveloper(JDeveloper)は、Oracle SOA Suiteの開発コンポーネントです。 サービスを開発して構成し、ビジネス・プロセスに組み込むための総合的なISEを形成します。 ビジネス・プロセスは、デプロイおよび登録して、デスクトップ・クライアント、ブラウザ、モバイル機器およびTelnet機器などの各種のユーザー・インタフェースから使用できます。

JDeveloperを使用すると、開発者は、サービスに基づいて複合アプリケーションをモデル化、作成、検出、収集、統合、テスト、デプロイおよび保守できます。 JDeveloperは、SOAの原則とXML Webサービス標準をサポートするのみでなく、従来のJava、J2EEおよびPL/SQLコンポーネントとモジュール化コード・メカニズムもサポートしています。

Oracle ADFは、モデルドリブンのSOAフレームワークです。このフレームワークによって、ビジネス・サービスやデータ・サービスが自動化および管理され、プロセス・フロー、ページ・フローおよびサービス起動で使用可能な、JSR 227に基づいた標準のデータおよびサービス・バインディング・レイヤーが提供されます。 また、Oracle ADFでは、SOAの設計方法が実装され、ユーザー・インタフェースがサービスと同程度に疎結合されます。

Oracle TopLinkは、リレーショナル・データおよびXMLデータへのアクセスを可能にするデータ・サービス・フレームワークです。 オブジェクト/リレーショナル・マッピングおよびオブジェクト/XMLマッピングを容易にするためのビジュアル・マッピング・ツールが提供されます。 TopLinkとOracle ADFの両フレームワークを使用することによって、ビジネス・サービスおよびデータ・サービスを簡単に作成できます。これらのサービスは、サービス指向アプリケーションの多機能なWebインタフェースから起動できます。

Oracle BPEL Process Manager(ヒューマン・ワークフローを含む)

Oracle BPEL Process Managerは、BPEL標準に基づくプロセスの設計、デプロイ、監視および管理を簡単に行うためのフレームワークを提供します。 Oracle BPEL Process Managerでは、次の機能がサポートされます。

Oracle BPEL Process Managerでは、JDeveloper BPEL Designerの次の機能をサポートして、BPEL機能の価値と使いやすさを高めます。

Oracle Enterprise Service Bus(ESB)

Enterprise Service Busによって、企業内外の複数のエンドポイント間でデータを移動できます。 この移動には、複数の異なるアプリケーション間でビジネス文書を(Extensible Markup Language(XML)メッセージとして)接続、変換およびルーティングするためのオープン標準が使用されます。 この機能によって、既存のアプリケーションへの影響を最小限に抑えながら、ビジネス・データを監視および管理できます。 Enterprise Service Busは、サービス指向アーキテクチャ(SOA)およびイベントドリブン・アーキテクチャ(EDA)を配布するための基礎となるインフラストラクチャです。ESBは、SOAおよびEDAを使用したサービスの基礎になります。 その核心にあるのは疎結合のアプリケーション・フレームワークで、業界標準を使用する分散化された異機種間のメッセージ指向環境におけるビジネスに、高度な柔軟性、再利用性および全体的な応答性を提供します。

Oracle Business Rules

Oracle Business Rulesを使用すると、実行時の動的な決定が可能になり、特に、アプリケーションで、規制および競争の切迫した要求に迅速に対応できます。 この敏捷性の向上が可能であるのは、Oracle Business Rulesを使用するビジネス・アナリストが、ビジネス・ルールをアプリケーション・コードから切り離して作成および変更できるためです。 Oracle Business Rulesを使用すると、ビジネス・アナリストは、ビジネス・プロセスを停止せずにビジネス・ルールを変更できます。 また、ビジネス・ルールを外部化することによって、プログラマを介さずにビジネス・ルールを直接管理できます。

OracleAS Integration Business Activity Monitoring

OracleAS Integration Business Activity Monitoring(BAM)によって、ビジネス経営陣はそのビジネス・サービスをリアルタイムで監視し、KPI(キー・パフォーマンス・インディケータ)を実際のビジネス・プロセスに関連付けることができます。 Oracle BAMを使用すると、サービス・メトリックを集計して、重要なビジネス・サービス・パラメータに関するアクション可能な情報をユーザーに配信できます。 Oracle BAMでは、ビジュアルなダッシュボードおよびアラートを介してユーザーに情報が配信されるため、操作性が向上するとともに、情報に基づいた決定を下すことができます。 また、ビジネス環境が変化した場合に、ユーザーがビジネス・プロセスを変更し、修正措置を講じることができます。 Oracle BAMは、リアルタイムの経営ダッシュボードの作成、アプリケーションの監視とアラート通知のための完全なソリューションです。

Oracle Web Services Manager

Oracle Web Services Managerは、Webサービスへのアクセスを保護し、保護されたWebサービスで実行されるアクティビティを監視するように設計された、セキュリティ管理者用の環境です。

Oracle Web Services Managerには、ポリシー決定点(PDP)とポリシー実行点(PEP)の2つの主要部分があります。 PDPには、セキュリティ・コンポーネントと管理コンポーネントがあり、これらには、Oracle Enterprise Managerのルック・アンド・フィールを備えたWebベースの管理コンソールからアクセスします。 PEPはインターセプタであり、エージェントまたはゲートウェイのいずれかです。 エージェントは、保護するWebサービスと同じコンテナで実行されるのに対して、ゲートウェイは、プロキシ・サーバーに類似した独立プロセスです。 エージェントとゲートウェイは、エンドツーエンドのWebサービスのセキュリティが確実に機能するように、組み合せて使用できます。

通常、セキュリティ管理者は、保護および管理するWebサービスを登録することによって環境を設定します。 その後、登録した各サービスに対して宣言セキュリティ・ポリシー(コーディングなし)を定義します。たとえば、認証用の資格証明の抽出方法、メッセージの暗号化、復号化、署名方法、イベント・ログの作成方法などを定義します。

PEPによって、登録Webサービスへのリクエストが捕捉され、管理者が定義したポリシーが実施されます。 また、セキュリティおよび管理情報が収集され、これらはPDPに転送されます。 PDPではその情報が管理メトリックに集計され、参照しやすいようにグラフィカル・チャートでの表示用にフォーマットされます。 管理メトリックは、管理コンソールを使用して管理者が定義したサービス・レベル契約(SLA)から取得されます。

Oracle Web Services Managerは、Oracle BPEL Process ManagerおよびESBとシームレスに統合されます。つまり、Oracle Web Services Managerは、BPELおよびESBプロセスを保護できます。 さらに、Oracle Web Services ManagerはOracle Identity Managementスイートと統合されます。特に、Oracle Web Services Managerは、Oracle Access ManagerのCookie情報を抽出および変換できるため、Webサービスのブラウザからネットワークまで、エンドツーエンドのセキュリティ・ソリューションが提供されます。

OracleAS UDDIレジストリ

OracleAS UDDIレジストリは、SOAの主要コンポーネントに対して、構成可能で、拡張性がありセキュアなWebサービスのリポジトリを提供します。このリポジトリは、Oracle Fusion Middlewareで管理、検出および制御できます。 OracleAS UDDIレジストリは、あらゆる企業の主要なサービス管理ニーズを満たします。

Oracle Fusion Middlewareファミリの他の製品(Oracle BPEL Control、Oracle Web Services Manager、JDeveloperなど)との統合が可能であるため、ユーザーは公開されたサービスについてレジストリを問い合せることができます。

OracleAS UDDIレジストリでは、最新のUDDI V3仕様が完全にサポートされており、現在使用可能なSOAレジストリの最大範囲の機能が提供されます。

Oracle Application Server

Oracle Application Serverは標準ベースのアプリケーション・サーバーであり、Webサイト、J2EEアプリケーションおよびWebサービスを実行するための総合的で完全に統合されたプラットフォームを提供します。

1.3 SOA Order Bookingアプリケーションの概要

SOA Order Bookingアプリケーションによって、企業内外の他の場所に存在する多数のアプリケーションをSOAアーキテクチャ・パラダイムを使用して統合し、1つの統合注文システムを作成する方法の例が示されます。 このサンプル・アプリケーションで、Global Companyは、Webベースのクライアント・アプリケーションを介して電子機器を注文するための小売店です。 Global Companyは、MP3プレーヤやテレビなどの電子機器をWebベースのクライアント・アプリケーションを使用してコンシューマに販売します。 次のOracle SOA Suiteコンポーネントが利用されます。

具体的には、SOA Order Bookingアプリケーションは次のアプリケーションで構成されます。

SOA Order Bookingアプリケーションの中心にあるのは、SOAOrderBooking BPELプロセスです。 このプロセスでは、プロセス内のビジネス・ルールに基づいて、適切なサプライヤで注文を履行するために、企業内のすべての既存サービスが統合されます。

図1-2に、SOA Order Bookingアプリケーションの概要を示します。図の後に、アプリケーション・フローの各ステップの説明があります。

図1-2 SOA Order Bookingアプリケーションの概要

図1-2の説明は次にあります。
「図1-2 SOA Order Bookingアプリケーションの概要」の説明

新規顧客がWebクライアントで登録すると、Webクライアントによって顧客の情報が内部の顧客サービス・アプリケーション(CustomerService)に送信され、顧客サービス・アプリケーションでは、顧客情報がデータベースに格納されます。 認証された顧客は、製品を参照し、その製品をオンライン・ショッピング・カートに追加して注文できます。

登録済の顧客がWebクライアントにログインしようとすると、顧客サービス・アプリケーション(CustomerService)が起動され、認証が提供されます。

新しい注文が発行されると、次の処理が実行されます。

  1. Webクライアントによって、メッセージがOrder Booking ESBプロジェクト(OrderBookingESB)に送信されます。 ESBでは、これらのメッセージに関心があることを登録しているサービスに、メッセージがルーティングされます。 このケースでは、通知されるのはOrder Booking BPELプロセス(SOAOrderBooking)のみであるため、BPELプロセスが起動されます。

  2. BPELプロセスでは、注文が「pending」に設定され、注文データベース表に書き込まれます。

    登録プロセスによって、デフォルトの顧客ステータスは「Gold」に設定されます。 データベース管理者は、登録顧客に対して次のいずれかのステータスを適用できます。

    • Platinum

    • Gold

    • Silver

  3. BPELプロセスによって顧客サービス(CustomerService)がコールされ、顧客ID、名前、住所およびクレジット・カード情報が取得されます。

  4. さらに、BPELプロセスでは、識別された顧客のクレジット・カードが有効であることを検証するために、与信サービス(CreditService)に対してその顧客がチェックされます。 与信サービスから顧客の関連評価が戻されます。

    与信が承認されない場合は、プロセスによって注文が取り消されます。

    与信が承認された場合は、プロセスによって注文金額、顧客ステータスが取得され、Oracle Rules Engineが実行されて、注文に管理者による承認が必要かどうかが判断されます。

  5. BPELプロセスでは、判断のためにデシジョン・サービス(Oracle Rules Engine)が使用されます。

    デシジョン・サービスでは、次の内容が記述されたOracle Rules Engine内のルールが使用されます。

    • 顧客のステータスが「Platinum」の場合、手動による承認は必要ありません。

    • 顧客のステータスが「Gold」の場合は、$1000を超える注文に対してのみ手動による承認が必要です。

    • 顧客のステータスが「Silver」の場合は、注文金額に関係なく、すべての注文に対して手動による承認が必要です。

    このようなデシジョンはBPELプロセスで実装することもできましたが、設計時の変更または再デプロイの必要なしに、実行時の変更が可能になるように、かわりにルール・エンジンが使用されました。 さらに、ビジネス・アナリスト、または技術者や管理者以外のユーザーがルールを変更できます。

  6. 手動による承認が必要な注文の場合は、BPELプロセスによってヒューマン・ワークフローが起動され、ヒューマン・ワークフローによってメッセージがマネージャにルーティングされます。

  7. 注文が承認されると、価格見積りのために2つのサプライヤに送信されます。

    • Select Manufacturerサービス(SelectManufacturer)は、直接製造業者であるため低い見積金額を提示する傾向がありますが、レスポンスが戻ってくるのに時間がかかります。 見積りは非同期で送信されます。

    • Rapid Manufacturerサービス(RapidService)は、価格見積りに対するレスポンス・サービスが自動化されているため、高い見積金額を提示する傾向があります。 見積りは同期で送信されます。

  8. BPELプロセスによって見積りが収集され、注文先のサプライヤとして最低見積価格が選択されます。

  9. BPELプロセスによってFulfillment ESBプロジェクト(FulfillmentESB)が起動されます。このプロジェクトは、メッセージ・フローを使用して注文を次のように完了します。

    • 金額が$500未満の場合、その注文情報はUSPSに送信されます。 USPSのシステムでは注文がディレクトリから取得されるため、ファイル・アダプタを使用して、指定したディレクトリ内のファイルに注文を書き込みます。

    • 注文が$500以上の場合、その注文情報はFedexに送信されます。 Fedexのシステムでは表に行が挿入されるのを待機するため、データベース内の指定された表に注文を書き込むためにデータベース・アダプタが使用されます。

    • 出荷ベンダーに関係なく、すべての注文が一時キューに格納され、夜間バッチ・モードでFulfillmentシステムにアップロードされます。 指定されたJMSキューに注文情報を書き込むために、JMSアダプタが使用されます。

  10. 注文が履行されると、BPELプロセスによって注文が「complete」に設定され、通知サービスが開始されます。通知サービスでは、発注情報が含まれた電子メールが顧客に送信されます。