Comments
Description
Transcript
Oracle FormsからSOAへ：モダナイゼーションの事例
Oracle Forms から SOA へ：モダナイ ゼーションの事例 Oracle Forms Community ホワイトペーパー Steven Price Griffiths Waite 2008 年 6 月 Oracle Forms から SOA へ：モダナイゼーションの事例 はじめに .............................................................................................................. 3 モダナイゼーション（現代化）....................................................................... 4 レガシー資産................................................................................................. 4 積極的な維持................................................................................................. 5 サービス指向アーキテクチャ..................................................................... 5 Oracle Forms と SOA..................................................................................... 5 Web へのアップグレード .................................................................................. 6 クライアント/サーバーの Oracle Forms ..................................................... 6 Web Forms ...................................................................................................... 7 Java を使用した新しい Oracle Forms UI..................................................... 7 セルフサービス・アプリケーション ......................................................... 8 サービスの共有............................................................................................. 9 サービスの世界への第 1 ステップ................................................................. 10 Oracle Forms コードのメッセージ指向へのリファクタリング ............ 10 Oracle Forms からの新規サービスのオーケストレーション ................ 10 SOA の世界でのさらなるステップ................................................................ 10 ビジネス・プロセスの管理....................................................................... 10 BPEL............................................................................................................. 10 BAM ............................................................................................................. 11 ビジネス・ルール....................................................................................... 12 成長へのプラットフォーム............................................................................. 13 既存スキルの活用....................................................................................... 14 Oracle Application Development Framework............................................... 14 豊かなユーザー・エクスペリエンス............................................................. 15 UI サービス ................................................................................................. 15 Oracle Forms の使用終了 ............................................................................ 16 JSP ソリューションの変更........................................................................ 17 Oracle Business Rules を使用したデシジョン・サービス ...................... 17 まとめ ................................................................................................................ 18 Oracle Forms から SOA へ：モダナイゼーションの事例 2 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 Oracle Forms から SOA へ：モダナイゼーションの事例 はじめに 最近の分析レポートおよびオラクル自体による"Oracle Forms のモダナイゼーショ ン（現代化）"の動きを受け、テクノロジー資産をいかにして現代化できるか、そ してビジネスと IT 両方の変化をいかにして生かすことができるかを把握するため、 テクノロジー資産を検証しようという顧客が増えています。 このモダナイゼーション・アプローチの重要なメッセージは、以下のとおり明白 です。 投資の保持 レガシー・アプリケーションのテクノロジーに対して継続的なサポートと投資を おこなうことで、安定したプラットフォームでのモダナイゼーションが可能です。 テクノロジーの採用 サービス指向アーキテクチャ（SOA）により、新たなプラクティスとテクノロジー を段階的に実現できます。 統合 レガシー・システムと新しいシステムはサービスの統合および共有が可能であり、 新たなシステムとサービスが構築されるなか、レガシー・アプリケーションによ るビジネスの実行は継続されます。 1994 年に設立された Griffiths Waite は、 Oracle テクノロジーと Oracle アプリ ケーションを基盤とする SOA およびビ ジネス・アプリケーションの導入を専門 とする会社です。 このように、多くの人にとってモダナイゼーションのメッセージとは明確なもの です。次のステップは、実用性を把握し、すでに道を切り開いている先駆者の"実 "体験から学ぶことです。Griffiths Waite はこの分野に長年携わっています。本文 書では Oracle Forms を使用して構築されたコア・ビジネス・アプリケーションの 事例と、クライアント/サーバーから Web、そしてサービス・ベース・アーキテク チャに至るその進化について紹介します。 事例では、イギリスの 2 つの金融サービス組織における Application Processing System（APS）の導入について取り上げます。APS は消費者金融市場向けの信用 供与システムであり、初期申込から信用度採点と保証人の認定、見積と承諾、そ して最終的には契約の締結に至る貸付依頼の処理をおこないます。APS が最初に 導入された組織は、5 つのコール・センターと 450 を超える支店の国内ネットワー ク、そして 5,000 人を超える従業員を有し、イギリスの非標準的な消費者金融市 場に金融サービス商品を提供する最大手企業の 1 つです。2 番目に導入したのは、 イギリス全土に支店をもち、イギリス、インドにコール・センターを抱えるロー ン・ブローカーです。 Oracle Forms から SOA へ：モダナイゼーションの事例 3 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 モダナイゼーション（現代化） 既存のアプリケーションは、過去の資本投資の結果として存在するものです。ア プリケーション資産の価値は、ビジネスとテクノロジーのコンテキストが変化す るにつれて時間とともに減少していく傾向があります。ライフ・サイクルの初期 にはビジネスとの調和を保つための拡張投資がおこなわれますが、最終的にはそ れも困難になる段階が訪れます。基盤のインフラストラクチャが時代遅れになっ たり、Web アクセスが必要となったり、アプリケーション変更の大きさやノウハ ウの欠如によって拡張が不可能になったりした場合などです。 レガシー資産 レガシー・システムは長年にわたる経験、開発、そしてカスタマイズの結晶であ り、競争上の優位性を常に生み出すコア・ビジネス・プロセスが含まれています。 多くの場合、この事実がレガシー・システムの信頼性や安定性とあいまって、シ ステム交換計画を低価値で高リスクなものにしています。交換および再書込みが 必要な場合もありますが、既存のレガシー・アプリケーションが現在のビジネス・ ニーズを満たす場合、将来におけるビジネスのニーズを引き続き満たすよう、こ のレガシー資産を効果的に変換できる可能性があります。 図 1 - アプリケーションのライフ・サイクル Oracle Forms から SOA へ：モダナイゼーションの事例 4 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 積極的な維持 システムが徐々にレガシー・システムになっていくのを防ぐためには、積極的な 維持が必要です。目的は、システムが"使えない状態"になり、その結果、交換作 業が必要になる状況を防ぐことです。維持は、システムの大規模な交換を回避し、 リスクの軽減につながります。ソフトウェアの維持は会社の長期的な繁栄を目的 としたものであり、短期的な効果を目指すものではありません。システムの陳腐 化を防ぐためには、変化するテクノロジーと進化するビジネス・ニーズに遅れる ことなくシステムを維持し続ける必要があります。メンテナンス作業には、既存 ユーザー・インタフェースの改良や新規プラットフォームへの移行、コード・ベー スの再設計といった現代化プロジェクトも含めることを推奨します。 サービス指向アーキテクチャ サービス指向アーキテクチャ（SOA）では、システムは'サービス'と呼ばれる再利 用可能なコンポーネントで構成されています。サービスは、データベースからの 顧客情報の読出しなど、独自の機能を実行するソフトウェア構成要素です。 ラップして再利用 SOA では標準ビジネス・アプリケーションが使用され、それが各種ビジネス・ア クティビティをサポートするために使用および再利用する個別のビジネス機能ま たはサービスに分割されます。SOA では、サービスをほぼオンデマンドで構築、 デプロイ、再利用し、複数のプラットフォームにまたがり企業全体で容易に統合 できるように、'rip and replace（撤去して置換え）'ではなく'wrap and reuse（ラップ して再利用）'することによって既存のレガシー・アプリケーションを使用します。 Oracle Forms と SOA SOA ロードマップでは、Oracle Forms のレガシー・システムを基本構成要素に分 解し、それらを莫大な数の新しいアプリケーション・サービスへと再構築します。 図 2 - Oracle Forms から SOA へのロードマップ Oracle Forms から SOA へ：モダナイゼーションの事例 5 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 オラクルが公開したロードマップに従っ た新しいテクノロジー・プラクティスを 段階的に採用するモダナイゼーション・ アプローチによって、リスクの抑制と投 資の保護が実現します。 Oracle Forms クライアント/サーバーから SOA への移行は、より長期的なものにな り、単なる 1 つの変換とはわけが違います。モダナイゼーションの段階的な （フェーズに分かれた）作業は、Oracle Forms アプリケーションを長時間にわたっ て移行します。そのため、Oracle Forms がアーキテクチャの要素としてとどまる 期間は長引くものの、その期間中の全体的な移行リスクは軽減されます。最初の フェーズでは、顧客の既存資産を保持することに焦点を絞り、アプリケーション の安定化と、サポートされるプラットフォームでアップグレードを実施します。 その後の変換フェーズにおいて、そのアプリケーションは徐々にサービス指向 アーキテクチャへと展開させていきます。 SOA への移行においてもっとも重要かつ困難なステップは、データベースとクラ イアント・アプリケーションに依存しないビジネス・ロジックを構築することに 焦点を当てた n 階層アーキテクチャへの移行です。この移行が完了すれば、ロー ドマップの上位レベルへの移行は大幅に容易になります。システム・モジュール/ ビジネス・プロセスを 1 つずつ移行し、異なるスピードでロードマップを進める ことができる点は非常に重要です。 Web へのアップグレード クライアント/サーバーの Oracle Forms 最初に 2 カ所のコール・センターで、Oracle Forms のクライアント/サーバー・ソ リューションとして APS の稼動を開始しました。導入の成功を受け、アプリケー ションをイギリス国内の何百もの支店に緊急にロールアウトする必要が出てきま した。支店はイギリス全土の主要な都市に散在しており、その多くは小さな事業 所でした。こうした支店は、比較的速度の遅いネットワークで本社サイトと接続 されていました。 図 3 - クライアント/サーバーAPS 待ち時間が長いネットワークで継続的にデータベースにアクセスするというパ フォーマンス上の問題を考えると、支店のネットワークを利用して APS をクライ アント/サーバー・アプリケーションとして運用するのは不可能でした。フォーム Oracle Forms から SOA へ：モダナイゼーションの事例 6 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 のすべてのオペレーション（項目のチェックなど）により、ネットワーク上では ユーザーの PC で稼動するフォームとデータベースとの間で数多くのリクエスト やリプライが多々発生するのです。 Web Forms Oracle Forms のクライアント/サーバー から Web へのアップグレードは、モダナ イゼーションへの確かな第 1 歩でした。 このアップグレードによって多くのビジ ネス利益がもたらされ、顧客は最新バー ジョンの認証済みテクノロジー・スタッ クを利用できるようになり、その後のモ ダナイゼーション・ステップの基盤とな るプラットフォームが提供されました。 SOA ロードマップの最初のステップは、Web Forms を採用し、基盤となるプラッ トフォームに大きな変更を加えることなく、APS へのインターネット・アクセス を提供することでした。このステップは、APS を Web サーバー上で稼動させ、ク ライアントの汎用アプレットで GUI をエミュレートすることによって達成されま した。ユーザーには、従来の Oracle Forms クライアント/サーバー・ソリューショ ンではなく、Java UI がブラウザ上で表示されるようになりました。Web Forms の 3 層アーキテクチャは、クライアント/サーバー・アーキテクチャと比較すると、 巨大な会社ネットワーク上でははるかに反応がよく、クライアントとデータセン ターとの間のネットワーク・トラフィックが減少します。 論理中間層の構築 Oracle Forms の Web へのアップグレー ドは技術的には難しいものではなかった ため、アプリケーションにアーキテク チャの変更をおこなう余裕もありました。 クライアント側の Oracle Forms に存在したすべてのビジネス・ロジックは、デー タベースにおいてモジュール化されたコードとして抽出され、実装されました。 Web に配置された Oracle Forms により、ほぼ修正を加えることなく 3 層モードで Oracle Forms を稼動させることができるようになりますが、この処理をアプリケー ションの別の場所で、またはほかのシステムでも再利用できるように、データベー スで Oracle Forms からビジネス・ロジックをリファクタリングすることにしまし た。データベース内にビジネス層が作られ、APS が n 層アーキテクチャとなり、 新たなビジネス構想をより柔軟に導入できるようになりました。 同様に重要なことは、オラクルのミドルウェアと Java ツールの統合機能を活用す るための基盤を構築することでした。インターネット配置モデルへの移行は、テ クノロジー・スタックやアプリケーションの移行の必要がなく、一元化された管 理とデプロイメントが可能になるという利点もありました。 Java を使用した新しい Oracle Forms UI 何百もの支店に APS のクライアント/サーバー・バージョンをロールアウトするに あたり、技術的な制約とともに懸念事項となったのが、アプリケーションが支店 のユーザーにどの程度受け入れられるかということでした。多くの Oracle Forms アプリケーションのように、APS は内容には問題がなかったものの、見た目は現 代的ではありませんでした。 時代遅れのユーザー・インタフェースは、グループ全体に APS を導入するうえで 大きな障害になると思われ、大きな反発が予想されていました。システムはその デザインを、基盤となるデータベース構造に頼っており、その結果、似たような ウィンドウが並び、複雑な情報が多数のマスター/ディテール画面に詰め込まれ、 ナビゲーションも扱いにくいインタフェースが構築されていました。 APS のユーザー・インタフェースは、刷新する必要がありました。開発者とユー ザーにより多くの選択肢が与えられ、よりグラフィカルになり、機能が豊富なユー ザー・インタフェースになるにつれ、デザインの重要性は増しています。ソフト ウェアは視覚媒体であるため、スタイリッシュなデザインと魅力的な外観によっ て APS を'手直し'することにしました。 Oracle Forms から SOA へ：モダナイゼーションの事例 7 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 UI のモダナイゼーションはバックエン ド・ロジックにほとんど影響が及ばない ため、アプリケーション変更によるリス クをほとんど伴わず、ユーザーに即座に インパクトを与えることができました。 APS のユーザー・インタフェースのデザインを変更するにあたっての目標は、複 雑な業務処理を簡素化する洗練されたソリューションを設計して、アプリケー ションの'ルック'だけでなく'フィール'を改善することでした。そのために、User Consoles のコンセプトを開発しました。User Consoles は、特定のアクティビティ を完了するための基盤となるものです。ビジネス・アクティビティに関連するす べてのオブジェクトとタスクをまとめることにより、User Consoles はテーブル主 導のデザインを用いた原始的なアプローチから脱却し、使いやすく、理解しやす い直感的な体験をユーザーに提供します。 図 4 - Web Forms の Java UI 魅力のあるデザインは刺激と興味をもたらします。これが'必要である'という雰囲 気を支店ネットワーク全体に生み出すことで、APS がより容易に受け入れられ、 採用されることが必要でした。APS に必要な新しい'ルック・アンド・フィール' を作り出すため、Web Forms で使用できる Java 拡張機能を活用し、JavaBeans およ び Pluggable Java Components（PJC）によって Oracle Forms ユーザー・インタフェー スをカスタマイズして、魅力的な Web ユーザー・インタフェースを構築しました。 セルフサービス・アプリケーション Oracle Forms はバックオフィスのプロ フェッショナル・データ入力アプリケー ションの要件に適していますが、そのほ かのツールやテクノロジーは非定型のセ ルフサービス的なアプリケーションによ り適しています。 APS の内部での成功を受け、ディストリビューション・チャネルを増やす必要性 が出てきました。初めの動きは、オンライン・ローン申込を送信し、その進捗状 況を追跡できるサービスを提供して、小規模のブローカーとより密接に連携する ことでした。そのためには、こうしたブローカーに APS によって実行されるもの と同じビジネス・プロセスへのアクセスを提供する必要がありました。 ブローカーの多くは小規模企業であり、当時のインターネット接続環境は貧弱で した。そのため、Oracle JInitiator と Web Forms を稼動させるための関連 JAR ファ イルのダウンロードにかけられる時間が制限されており、それが障害となりました。 Oracle Forms から SOA へ：モダナイゼーションの事例 8 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 こうした選択が行われたのは、Oracle ADF が開発される前の話です。 対象者に APS 機能を提供する別の方法が必要となりました。慎重な検討の結果、 データベース・アクセスについては Java Server Pages（JSP）とオープン・ソース の Struts フレームワークをシンプルな SQLJ ベースのクラスと組み合わせ、APS Broker Portal を構築することにしました。JSP の大きな利点は、出力が標準 HTML であるため、クライアントには互換性があるブラウザ以外ほぼ何も必要ないとい う点です。クライアント側では JVM が稼動していないため、ローカル PC には Java ランタイム・ファイルや Java アプリケーション・ファイルは必要ありません。 アプリケーションは純粋な HTML ユーザー・インタフェースを使用して Web ブ ラウザ上で稼動し、追加ソフトウェアのインストールやメンテナンスは必要あり ませんでした。Web ページは、JSP のレンダリングを制御する Struts フレームワー クを使用して動的に生成されました。Struts/JSP プログラムでは、ほかの Java コン ポーネントのサービスが使用されますが、そのうちいくつかは Enterprise Java Beans（EJB）として実装されました。こうしたコンポーネントは、APS PL/SQL ストアド・プロシージャによって提供されるコア・ビジネス・サービスを使用し ます。 サービスの共有 Broker Portal は Oracle JDeveloper を使用して開発され、Web Forms アプリケーショ ンと同じアプリケーション・サーバーにデプロイされました。そのため、Web Forms アプリケーションと相互運用され、共通のインフラストラクチャとサービスを共 有できました。さらに、Oracle Forms と J2EE アプリケーションは、データベース PL/SQL ストアド・プロシージャを使用して既存のビジネス・ロジックを共有でき ます。 図 5 - セルフサービス APS - Broker Portal Web Forms の移行による APS の n 層アーキテクチャは、既存のビジネス・ロジッ クを新しいビジネス・チャネルと共有するための基盤を提供し、新たなスタイル のビジネスを展開するために必要な時間を大幅に短縮しました。このアーキテク チャによって、既存のコードを最大限再利用できるようになりました。 Oracle Forms から SOA へ：モダナイゼーションの事例 9 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 サービスの世界への第 1 ステップ この金融業者は、新たな 5 カ年ビジネス・プランの発表に続いて、3 カ年の変更 プログラムに着手しました。プログラム変更としての最初のビジネス・イニシア チブ(Electronic Leads)として委託されたことは、申込プロセスを自動化して、サー ド・パーティの戦略的パートナーから紹介された大量の業務を APS が一括して受 け入れられるようにすることでした。 Oracle Forms コードのメッセージ指向へのリファクタリング アプリケーション処理を、明確に定義された自己完結型のサービスにリファクタ リングすることにしました。各ビジネス・サービスは、PL/SQL プロシージャの自 己完結型のグループとして実装されました。各サービスで受け渡しがおこなわれ るデータを決定する明確なインタフェースが存在し、サービス間の直接的なイン タラクションはありませんでした。代わりに、サービスが終了すると制御権は次 の動作を決定する単一のオーケストレーション・プロシージャに戻されました。 Oracle Forms からの新規サービスのオーケストレーション Oracle Forms Java クライアントのアーキテクチャにより、外部プログラムまたは キューと Oracle Forms とのインタラクションの機会が提供されます。この能力を 活用して Oracle Advanced Queuing（Oracle AQ）メカニズムからのイベントをリス ニングし、Oracle Forms ランタイム・プロセスに渡されるコードを書き込みました。 各アプリケーション・ステージは、異なる速度で進行します。ときにはステージ が一時的に利用できないこともあります。そのため、ステージ間でデータを"バッ ファ"し、フローの速度を制御する必要がありました。Oracle AQ によってこれが 実現し、処理されるアプリケーション・ボリュームが大幅に増加しました。 Electronic Leads により、APS データベースでメッセージ・ベースの Oracle AQ ソ リューションを使用し、イベント・ドリブン・アーキテクチャ（EDA）が効果的 に導入されました。これにより、後の BPEL への移行が大幅に容易になりました。 SOA の世界でのさらなるステップ ビジネス・プロセスの管理 各パートナー独自の要件に対してより的確に対応するため、Griffiths Waite は Business Process Execution Language（BPEL）、Business Activity Monitoring（BAM）、 および Business Rule Management System（BRMS）を活用した Business Process Management（BPM）プログラムに乗り出しました。 BPEL Electronic Leads のモジュールにより、APS に疎結合のプロセス設計が提供される ことになりましたが、このアーキテクチャをサポートするために BPM が APS デー タベースに組み込まれました。これにより、相互に関連している要素が特定のプ ロセスのために機能するようにすることが、APS の役割になりました。BPM は中 間層にあるすべてのネイティブ・システムの外側に設置し、システム変更の影響 を受けないようにする必要があります。 Oracle Forms から SOA へ：モダナイゼーションの事例 10 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 プロセスの管理とオーケストレーションを APS データベースから中間層に移動さ せ、業界標準に基づくアーキテクチャを採用する必要がありました。そのため、 エンド・ツー・エンドのビジネス・プロセスにサービスをオーケストレーション するための標準的な高移植性言語である BPEL を選択しました。BPEL は XML と Web サービスを中心として構築されており、Oracle、IBM、Microsoft および BEA がそろって力を注いでいるため、業界標準として認識されています。 Electronic Leads の処理により、アプリケーション・サーバーに移動し、Web サー ビスとしてデータベースから公開され、BPEL で調整される領域に BPEL が実装さ れました。BPEL を使用する APS ソリューションは、APS 内の下位レベル・サー ビスと、外部サービスおよびパートナー・システムへの呼出しをオーケストレー ションし管理する役割を担いました。 BPEL によってミックス・アンド・マッチの柔軟性が開発者に提供され、パートナー の要件が変化しても、開発者は個別の APS コンポーネントを修正するか、または 新規コンポーネントをプラグインするだけでよくなりました。これにより、戦略 パートナー・プログラムが急速に拡大しました。 図 6 - BPEL プロセス・オーケストレーション BAM Electronic Leads オペレーションに迅速な可視性を実現するため、Pipeline Manager が開発されました。Pipeline Manager はグラフィカルな Business Activity Monitoring （BAM）ツールであり、これによって Electronic Leads におけるプロセス・フロー をリアルタイムで監視および管理できます。 Oracle Forms から SOA へ：モダナイゼーションの事例 11 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 Oracle BAM により、ビジネス・ユーザーはアプリケーション処理中に発生するイ ベントおよびイベント・パターンを定義し、監視できるようになりました。イベ ントを XML 形式で表現するセンサーが、データを BAM エンジンにフィードする BPEL プロセスに追加されました。追加後、レポートから分かるように、このセン サーは BAM で照合されました。ユーザーは、パートナーSLA を含む重要なビジ ネス指標を示すリアルタイム更新のダッシュボードを参照し、詳細情報にドリル ダウンすることが可能となりました。 Oracle BAM アーキテクチャにより、イベントやステータス変更の発生後数秒以内 に要求された情報を提供できます。データのおもなソースはメッセージであるた め、Oracle BAM はアーキテクチャの中心であるメモリー・ベースの永続キャッ シュに、1 秒間に何万もの更新を受け入れることができます。 Pipeline Manager は、ビジネス・ユーザーに対して、コストの削減とプロセスの改 善に必要となる詳細な分析をビジネス・イベントの進行中に提供します。これに より、パートナーSLA が満たされ、より積極的な顧客サービスが可能となります。 図 7 - BAM によるリアルタイム分析 ビジネス・ルール APS がビジネスの変化に敏感に反応できるよう、申込者の事前審査や商品割当て などの主要なビジネス・ルールをソース・コードから抽出し、それを実行するた めの独自のルール・エンジン Metis を構築しました。Metis は、Business Rule Management System（BRMS）です。 Oracle Forms から SOA へ：モダナイゼーションの事例 12 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 BRMS により、ユーザーは IT 部門のサポートを必要とせずに本稼動システムでビ ジネス・ルールを変更できます。このアプローチでは、ビジネス・ルールは頻繁 に変更され、業務部門のスタッフが修正する必要があることが事前にわかってい ます。ルール開発をビジネス・ユーザーに委ねることにより、従来のアプリケー ション開発に見られがちな開発およびテスト・プロセスの長期化を防ぐことがで き、ビジネス・ユーザー自身がルールの開発と修正をビジネスに要する速度で、 効率的におこなえます。 Metis ルール開発環境には、ビジネス・ユーザーがワークフロー、ウィザード、そ して事前審査ルールを迅速に設計できるグラフィカル・ユーザー・インタフェー スを備えた直感的で使いやすい Rule Builder が提供されました。Rule Builder によ り、データ項目関して意味をもつビジネス用語がユーザーに提供されました。さ らに、英語に似た構文を使用することで、複雑なルールを容易に作成できるよう になりました。 Metis を使用すると、ルール定義から PL/SQL パッケージが生成され、そのパッケー ジは生成後に APS データベースにロードされます。そして、BPEL プロセスで使 用されるサービスとして提供されます。生成されたコードは APS データベース内 で実行され、APS スキーマを直接参照するため、Metis は構築が比較的容易でパ フォーマンスが高いルール・エンジンとなりました。 Metis により、ビジネス・ユーザーはソフトウェアの書換えをおこなうことなく APS をカスタマイズし、劇的な結果を生み出すことができました。Metis 実装前の 6 ヶ月間で実施したポリシー・リリースは 1 度で、200 のビジネス・ルールが含ま れていました。一方、Metis 実装の 6 ヵ月後には 30 のリリースがデプロイされ、 稼動しているビジネス・ルールの数は 22,000 にも達していました。Metis により、 ビジネス・ユーザーはより'クリエイティブ'になり、市場での機会を生かすと同時 に規制遵守を促進できるようになりました。 成長へのプラットフォーム 最初の顧客での成功に続き、全国規模のローン・ブローカーに APS ソリューショ ンの導入を委託されました。この会社は、急速な成長を遂げています。成長の要 因には、有機的なものと買収によるものの両方が含まれていましたが、さらなる 成長のためには当時のシステム環境が障害となりつつありました。 最初にデプロイされることになった APS モジュールは、既存の Broker Portal アプ リケーションでした。このアプリケーションは、このブローカーのパートナー、 グループのイギリス国内の支店、そしてインドのコール・センターでデプロイさ れました。Broker Portal は、初めは変更を最小限にとどめてデプロイされましたが、 Oracle Forms アプリケーションに大量の新機能が必要になり、後に第 2 世代の Broker Portal が必要となりました。 この顧客は、魅力的で優れたマルチチャネルのユーザー・インタフェースを備え、 ビジネスを前進させる経営情報を提供するソリューションを求めていました。 Broker Portal の初期導入に続き、新しい要件、およびその先 10 年間使用する予定 であることを考慮して、APS のテクノロジー・プラットフォームの全面的な見直 しをおこないました。 Oracle Forms から SOA へ：モダナイゼーションの事例 13 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 現代の企業開発は、オープン・スタンダードで結合された異機種環境で作業を伴 うケースが増えています。ビジネスは、内部および外部の一連のサービスとして 捉えることができます。それらのサービスは、多様な方法で再利用またはオーケ ストレーションして複合アプリケーションを構築でき、従来のアプリケーション および企業の境界を越えて機能します。このようなアプリケーションでは、こう したサービスを組み合わせてオーケストレーションし、それにアクセスするため に、関心を引く豊富な機能のユーザー・インタフェースを構築することが重視さ れるようになっています。 既存スキルの活用 APS もそうした方向へ急速に向かっており、APS の現在および将来のニーズを満 たすために Oracle Forms が最善の選択かどうか検討しました。先に進むにあたり、 SQL と Java に関する既存のスキルをできるだけ活用し、投資レベルと生産性実現 までにかかる時間を最小限に抑えようとしました。内部と外部両方で利用可能な スキル・プール、そして現世代および次世代の段階のスキル・セットについて検 討しました。n 層アーキテクチャの方向へ進んでいましたが、開発環境における テクノロジーの数をできるだけ減らす必要がありました。 Oracle Forms はオラクルが独自に開発したものですが、オラクル自体、自社の長 期的なテクノロジー戦略は Java プラットフォームを基盤としており、SOA の世界 でも Oracle Forms は通用するものの、より現代的な次世代環境の方が適している ことを認めています。10 年以上の使用が求められていることを考慮すると、Oracle Forms は最善の選択肢ではありませんでした。 Oracle Forms を選択肢から外し、'セルフサービス'アプリケーションである Broker Portal の拡張を検討しました。パートナーと顧客に対面するアプリケーションの場 合、ユーザー・エクスペリエンスが重要になります。軽量の HTML を出力する JSP ページの大きな強みは、同時に大きな弱点でもあります。従来の HTML ページ・ ベースのインターネット・アプリケーションは、インタフェース上でのインタラ クションが不可能であり、ページのロードが遅く、プロセスには複数のステップ を要します。レコード一覧でのスクロール・ダウン、レコードの削除、情報のソー ト方法の変更といった単純な機能でもページのリフレッシュが必要です。小規模 な標準的制御セットにより、開発者は真に魅力的でユーザー・フレンドリーなア プリケーションを思うように作ることができません。こうした制約により、ユー ザーがタスクを完了できずにプロセスが放棄され、不満が募り、ダイナミックな ユーザー・エクスペリエンスが得られず生産性も低下します。 従来の Web アプリケーションに使用されているありきたりの"クリック・アンド・ ウェイト"型インタラクションが受け入れられなくなっていることは明らかです。 ユーザーは、リアルタイムの更新とデスクトップのような機能を求めています。 そのため、既存の Web アプリケーション・モデルという制約の範囲内で、デスク トップのような機能を実現するための方法を見つける必要がありました。 Oracle Application Development Framework その論結は、Oracle Application Development Framework（Oracle ADF）および Oracle JDeveloper となりました。Oracle JDeveloper は、Java、XML、Web サービスおよび SQL の最新の業界標準を使用してサービス指向アプリケーションを構築するため の'Forms 系'の統合開発環境に進化しました。また、豊富な機能をもつ UI を構築 し、ビジネス・サービスを開発してオーケストレーションする単一プラットフォー Oracle Forms から SOA へ：モダナイゼーションの事例 14 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 ムを提供しました。 Oracle ADF は J2EE 標準を基盤とするエンド・ツー・エンドのアプリケーション・ フレームワークです。Model-View-Controller（MVC）デザイン・パターンを実装 し、異種のテクノロジーからビジネス・サービスを公開できるモデル・レイヤー を提供します。さらにそれを拡張することにより、サービス指向アプリケーショ ンの開発を簡素化します。アプリケーションをこれらのレイヤーに分離すること により、アプリケーション全体におけるコンポーネントのメンテナンスと再利用 が容易になります。各レイヤーは他のレイヤーから独立しているため、疎結合の サービス指向アーキテクチャが実現します。また、Oracle ADF では、開発者が各 レイヤーの実装時に使用するテクノロジーを選択できます。 図 8 - Oracle ADF のテクノロジー・オプション データベース・インタラクションの主要テクノロジーとして、Oracle ADF Business Components を採用しました。Oracle ADF Business Components は、オブジェクトの 作成に焦点を当てたフレームワークです。このオブジェクトにより、データベー スの上にビジネス・サービス・レイヤーが実装されます。Oracle ADF Business Components により、CRUD スタイルのアプリケーションを Oracle Forms に近い生 産性レベルで開発できるようになり、プログラマーは慣れ親しんだ SQL'中心'の開 発スタイルで作業できます。 豊かなユーザー・エクスペリエンス UI サービス プロセス・オーケストレーションに BPEL を採用したと同時に、UI 開発に標準ベー スのアプローチを採用するよう望んでいました。UI テクノロジーの選択にあたり、 Web ブラウザの遍在性と従来のデスクトップ・アプリケーションで見られた豊富 な機能をもつユーザー・インタフェース要素を組み合わせ、最小限の修正作業、 または修正作業なしでも複数のプラットフォームで実現できる、真にインタラク ティブで魅力的なユーザー・エクスペリエンスを目指しました。 Oracle Forms から SOA へ：モダナイゼーションの事例 15 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 Java Server Faces（JSF）は、Java EE 5 スタックで Web ユーザー・インタフェース を構築するためのコンポーネント・ベースの UI 仕様です。IBM、Oracle、BEA、 Sun そして RedHat はすべて JSF を UI テクノロジーとして使用することを表明し ており、JSF は急速に Web UI 開発の業界標準となりつつあります。 Oracle ADF には、ビュー・レイヤーに豊富な機能をもつ JSF コンポーネントが含 まれています。これは Oracle ADF Faces と呼ばれ、標準 JSF API 上に構築されま す。また Oracle ADF により、以前よりも生産性が高く、宣言的な AJAX 開発が可 能になりました。 JSF はさらに、コンポーネントの動作と表現の疎結合を定義する非常にフレキシ ブルなレンダリング・アーキテクチャを提供します。これにより、開発者はさま ざまな出力デバイスに対応する、クライアントに依存しない UI を構築できます。 Web アプリケーション、ポータル・アプリケーション、ワイヤレス・アプリケー ション、そして動的でインタラクティブな AJAX ユーザー・インタフェースの構 築に、同じプログラミング・モデル（JSF）を使用できます。 Oracle Forms の使用終了 ADF の選択に続き、Oracle Forms を Oracle ADF Faces に変更し、残りのクライア ント・サイド・コードは PL/SQL ストアド・プロシージャにリファクタリングさ れました。同時に、BPEL の使用が拡張され、APS におけるすべてのプロセスを オーケストレーションするようになりました。 図 9 - APS の Oracle ADF Faces Oracle Forms から SOA へ：モダナイゼーションの事例 16 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 JSP ソリューションの変更 紹介する側と顧客にとって必須であったユーザー・エクスペリエンスの改善のた め、JSP ソリューションで欠けていたインタラクティビティとユーザビリティを 取り戻し、APS の Web エクスペリエンスをデスクトップに近づける必要がありま した。また、顧客がアプリケーション・プロセスを完了せずに放棄しないように するため、オンライン・プロセスをできるだけ簡素化することも重要でした。 そのため、Customer Portal 専用の新しい画面を構築することにしました。ADF の おもな利点は、より豊富な機能で魅力的なユーザー・インタフェースを作成でき ることだけでなく、複数のチャネルでビジネス・サービス・レイヤーから主要な 検証ロジックおよびビジネス・ロジックを再利用できることです。 図 10 Customer Portal の Oracle ADF Faces Oracle Business Rules を使用したデシジョン・サービス Oracle ADF へ移行すると同時に、Metis ではなく Oracle Business Rules を採用する ことにしました。Metis は BRMS がもつ多くの利点をもたらしたものの、アーキ テクチャの制約が多いという難点がありました。 Oracle Business Rules は完全に個別のデシジョン・サービスとして機能し、コーポ レート・データ・モデルではなく独自のメタモデルを使用します。つまり、APS データ・モデルの変更から保護されています。さらに重要な点は、ビジネス・ルー ルがほかの業務システムでも再利用できるようになることです。 Oracle Forms から SOA へ：モダナイゼーションの事例 17 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 Oracle Business Rules では、ルールを定義するアプローチも Metis とは大きく異な ります。これまでは手続き型のアプローチだったのに対し、より宣言型のアプロー チです（たとえば Oracle のルール・エンジンではルールを宣言する順序は関係な いため、あとのルールが"起動"し、それから先のルールが適用されるといったこ とも可能です。このプロセスは"推論"と呼ばれます）。この大きな利点は、Oracle のルール・エンジンによってルールを最適化でき、関係のなくなったルールの評 価を回避できるという点です。 Oracle Business Rules では GUI Rule Author が提供されますが、これはエンドユー ザーにはあまり適していません。そのため、これをスプレッドシートの集まりか ら、メタモデルとルールを読み込み、Oracle SDK を使用してそれらをルール・リ ポジトリにロードするプログラムで置き換えました。これによって、より親しみ やすいユーザー・インタフェースがユーザーに提供され、またルール定義の基本 的な検証を実行できるようになりました。 図 11 - Oracle Business Rules まとめ どんなソフトウェアでも、機能、アーキテクチャ、およびテクノロジーに対して 継続的にバランスの取れた投資をしなければ、その質と価値は自然に落ちていく ものです。われわれは自分達が構築したアプリケーションの性質が変化しており、 課題に対処するには SOA が最良の道であることに気づきました。 クライアント/サーバーから SOA への進化は、多くの段階を経て数年間かけてお こなわれました。提供までの時間とリスクを最小限に抑え、投資回収率を最大化 するため、各段階では既存のソリューションとスキル・セットを最大限活用する ことに注力しました。 Oracle Forms から SOA へ：モダナイゼーションの事例 18 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 段階的なアーキテクチャ主導のアプローチを使用して、そうした目標を達成し、 低下していたソフトウェアの質を再び高めることができました。SOA によるアプ リケーションのモダナイゼーションによって、これまでもっていた力を生かし、 それを現代的なテクノロジーが提供する機会と結びつけることにより、既存のシ ステムに対する投資の価値が最大化されます。 レガシー・モダナイゼーションは終わることのない旅のようなものであり、われ われは現在、BPEL のプロセス・ブループリントを構築するため、APS への Oracle Business Intelligence の実装と Oracle BPA Suite のデプロイを進めています。 図 12 - 間もなく実現する Oracle ADF と Business Intelligence の統合 Oracle Forms から SOA へ：モダナイゼーションの事例 19 Oracle Corporation 発行「Oracle Forms to SOA: A Case Study in Modernization」の翻訳版です。 Oracle Forms から SOA へ：モダナイゼーションの事例 2008 年 6 月 著者：Steven Price Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口： 電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 www.oracle.com Copyright © 2005, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容 は予告なく変更されることがあります。本文書は一切間違いがないことを保 証するものではなく、さらに、口述による明示または法律による黙示を問わ ず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含 み、いかなる他の保証や条件も提供するものではありません。オラクル社は 本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的ま たは間接的に確立される契約義務はないものとします。本文書はオラクル社 の書面による許可を前もって得ることなく、いかなる目的のためにも、電子 または印刷を含むいかなる形式や手段によっても再作成または送信すること はできません。Oracle は米国 Oracle Corporation およびその子会社、関連会 社の登録商標です。その他の名称はそれぞれの会社の商標です。