レベル: 初級 Arun Chhatpar (arunchhatpar@gmail.com), Software Architect, Freelance
2008年 5月 27日 サービス指向アーキテクチャー (SOA) の幅広い支持は、企業がこの技術の将来性を十分に認識していることの証しです。SOA によってアジリティーが高められるという展望の根拠となっているのは、基本的なソフトウェア設計の原則である疎結合です。SOA はビジネス機能を独立したサービスとして公開することを可能にし、さらに SOA を実装する 1 つの手段である Web サービスによってあらゆるビジネス機能がインターネットで利用できるようになります。そしてこのようなアジリティーをビジネス・ユーザーにまで拡張することを約束するのが、もう 1 つの技術、ビジネス・ルール・マネージメント (BRM) システムです。BRM システムはビジネス・ユーザーにビジネス・ロジックを直接制御させ、IT がそれほど介入しなくてもビジネス・ユーザーがビジネス・ロジックを変更できるようにします。この記事では、変わり行く市場の状況にビジネスが一層機敏に、そしてコスト効率良く対応していく上で、SOA と BRM の 2 つの技術がどう役立つのかを説明します。
市場の状況が常に変化し続けているため、ビジネス・アジリティーを高める必要性がますます増してきています。ビジネスをアジャイルにするためには、企業全体のビジネス・ロジックに市場の変化を素早く実装できなければなりません。SOA は、企業のアジリティーを高めるための優れた技術としてすでに実証済みです。SOA がビジネス・ロジックとその実装とを切り離すことができるのに加え、現在 BRM システムが、SOA 革命の勢いをさらに加速させています。この記事を読んで、多数のビジネス・ルールで構成されるビジネス・プロセスについて、そしてこれらのプロセスをサービスとして公開する方法について学んでください。この記事では金融業界の例をもとに、SOA と BRM システムを併用して両方の利点を最大限に活用する方法を説明します。
SOA の概要
OASIS (Organization for the Advancement of Structured Information Standards) では、SOA を「さまざまな所有権ドメインで制御される分散した機能を組み合わせて利用するためのパラダイム」であると説明しています。
端的に言えば、SOA は、サービスとしてパッケージ化されるビジネス・プロセスを作成し、使用するための漸進的アーキテクチャー・スタイルです。SOA は測定可能な前提条件と期待する内容に一致する理想的な効果を生み出すためのサービスを提供、発見、操作、使用するための統一した手段となります。これらのサービスが第一の目標とするのは、ビジネス機能をその作成基盤としているオペレーティング・システムやプログラミング言語にできる限り依存させずに公開することです。このような疎結合の手法を使えば、サービスをネットワークに分散させ、異なるアプリケーションでさまざまに組み合わせて再利用することが可能になります。次のセクションで説明するように、SOA には密結合システムに勝る明らかな利点があります。
SOA の利点
SOA をエンタープライズ・アーキテクチャーで使用する最大の利点は、異種混合システム環境で非常に有効に機能することです。異なる複数のアプリケーションを Web サービスとして公開し、HTTP over XML などの標準プロトコルで通信すれば、開発者がアプリケーションの統合に骨を折る必要はなくなります。もう 1 つの重要な利点は、どのビジネスでも技術に投資する際に目標とすること、つまり高い投資利益率 (ROI) です。SOA はサービスを再利用可能なコンポーネントとして設計することで、ROI の達成を約束します。
SOA ではまた、これまでの投資も有効に生かされると同時に、他のアプリケーションを使って、より少ない投資で済ませられる場合もあります。ビジネス・アプリケーションに関する SOA の利点は以下のとおりです。
- 疎結合アーキテクチャー
- 異なるシステムが呼び出すことのできる統一インターフェース
- より簡単な統合とアジリティーが高められることによる ROI の上昇
- ロケーションへの非依存性 (サービスがどこでホストされているかを気にする必要がありません)
- 標準化されたアクセス・プロトコル (WSDL によってインターフェースが公開されます)
- アプリケーションの他の部分に影響を与えることなく更新、修理することが可能
- 複数のクライアント・タイプをサポート (J2EE™、.NET、J2ME、レガシー SOA サービス)
- スケーラビリティーの強化と可用性の向上
BRM システムの概要
BRM システムは、ビジネス・ルールを作成して管理するために使用するソフトウェア・システムです。ビジネス・ルールは特定業界の特定ビジネス機能に関するビジネス・ロジックを表現します。すべてのビジネスにはルールがあり、ビジネス・ユーザーは通常、これらのルールを完全にコントロールしたがるものです。このコントロールをビジネス・ユーザーが IT エキスパートから取り戻すことを可能にするのが、BRM システムです。BRM システムでは、アプリケーションのビジネス・ロジックをアプリケーションのデータ検証ロジックおよびフロー制御とは切り離すことができます。切り離されたビジネス・ロジックは独自のコンテナー、つまりルール・エンジンで実行されます。BRM システムのコアとなるのは中央ルール・リポジトリーです。このリポジトリーのなかに、アプリケーションが使用する判定ロジックが配置されます。BRM システムのその他のコンポーネントには、以下のものがあります。
- 統合開発環境 (Integrated development environment: IDE)。ルール開発者がビジネス・ルールに必要なフレームワークを作成するために使用します。
- ルール保守アプリケーション (Rule management application: RMA)。このユーザー・インターフェースでは、ビジネス・ユーザーが英語のような言語でルールを作成することができます。
- ルール・エンジン (Rules engine) 自体。ビジネス・ロジックを実行し、他のアプリケーションとインターフェースを取るために必要な関数を提供するコンテナーです。
図 1 は、典型的な BRM システムがどのように機能するかを示した図です。
図 1. BRM システムの基本コンポーネント
図 1 に示されているように、IT スタッフ (IT staff) とビジネス・アナリスト (Business analysts) が連携して作成、管理するビジネス・ルールは中央ルール・リポジトリー (Rules repository) に保存されます。作成されて中央ルール・リポジトリーに保存されたルールは、判定サービス (Decision service) が他のビジネス・アプリケーション (Business application) をサポートするために使用します。このようなアーキテクチャーには、以下の明らかな利点があります。
- ビジネス・ロジックを外部化することによって、アプリケーションのアジリティーを高めます。
- IT をほとんど、あるいはまったく介入させずにビジネス・ロジックの頻繁な変更に対応します。
- ビジネス・ユーザーがビジネスの変更を管理できます。
- ビジネス・アナリストは英語のような言語で記述されたビジネス・ロジックを取り込むことができるため、監査能力および可視性が向上します。
- ビジネス・ルールを外部化して共通ビジネス・ルール・リポジトリーに配置することによって、対象となるビジネスのエキスパートにとってビジネス・ルールが見やすくなるため、彼らが管理するビジネスにどのようにビジネス・ポリシーとルールが適用されるかを一層深く理解することができます。
現在の企業では、従来の開発言語で作成されたプログラムよりも効果的に変化に対応することが可能なサービスが強く求められています。多数の複雑なルールを実装するサービスの場合、ビジネス・エキスパートが初期設計に加わるとともに、以降の保守を行うことが必要となります。そうでないと、アプリケーションが進化せずに、設計部門の技量に頼って全体的なビジネス・アジリティーをサポートするしかなくなってしまう恐れがあります。
BRM システムと SOA ― その相性の良さ
BRM システムは判定ロジックを極めて効果的かつ効率的に管理するメカニズムを提供すると同時に、判定動作を調整するコンダクターとしての役割も果します。BRM システムでは、ビジネス・ルールはルール・セットと呼ばれるグループへと合成され、さらにルール・セットはルール・フローと呼ばれる手続き型判定フローの中で合成されて、目的のビジネス決定を実現します。これらの成果物はすべて 1 つにまとめられ、特定のビジネス決定ロジックを表すルール・サービスとして公開することができます。ここからは、金融業界での例を検討していきます。
MyBank, Inc.
図 2 に示すのは、仮想上の MyBank, Inc. のクレジット・カード承認システム (Credit card approval system) と抵当承認システム (Mortgage approval system) の設計です。この図を見るとわかるように、2 つの承認システムは独立した縦型システム同様に機能しています。つまり、ビジネス・ユーザーには企業情報の全体像が見えません。層はほとんど分離していませんが、それでも主にポイント・ツー・ポイントの接続となっています。
図 2. MyBank Inc. のクレジット・カードおよび抵当承認システム
図 2 から考えられる単純なワークフローを説明すると、まず、カスタマーが MyBank の Web インターフェースを使用してクレジット・カードを申し込むと、その申し込みは自動的にクレジット・カード承認システムに送られます。クレジット・カード承認システムが基本的なデータ検証を行った後、申し込みはビジネス・ロジック (Business logic) コンポーネントに転送されます。ビジネス・ロジックには、申し込みを承認するかどうかを決定するために個人の現在および過去の情報をチェックする機能があると考えられます。その一例は、過去のクレジット・ヒストリーをチェックする関数 (Credit-history check function) です。ご覧のように、この関数はクレジット・カード承認システムと抵当承認システムの両方で重複しています。したがって、このシステムのビジネス・ロジック・コンポーネントはそれぞれに検証を行って決定を下し、その結果を申し込みに対して返すことになります。このアーキテクチャーを分析すると、設計自体が完全に欠陥であるというわけではないことがわかります。単に最適な設計ではないというだけです。申し込みを承認または拒否するためのビジネス・ルールは、別々のビジネス・コンポーネントにありますが、ロジックは依然としてコードに組み込まれています。
このワークフローで明らかなのは以下の点です。
- 極めて密結合されたシステムになっているため、システムの保守とアップグレードが困難です。
- ビジネス・ロジックはプログラミング言語を使用して開発およびコンパイルされるため、ビジネス・ユーザーがビジネス・ロジックの変更を制御することが不可能です。
- CheckCreditHistory 関数は両方のシステムに必要であることから、2 回作成されています。
以上の点がこのアーキテクチャーの決定的な制約で、これらの制約によって企業は大々的な変更を迫られる可能性があります。それを回避するにはどうすればよいかは、次のセクションを読めばわかります。
MyBank Inc.、Ver. 2.0
ここでは、BRM と SOA を使用した拡張性と柔軟性の高い設計を紹介します。図 3 は、改善後の承認システムです。
図 3. SOA と BRM を使用して設計した MyBank Inc. の承認システム
図3 のアーキテクチャーを見ると、図 2 に示した以前のアーキテクチャーに比べ、3 つの違いがあることがわかります。まず第 1 に、ビジネス・ルールを作成して管理するためにビジネス・ルール・エンジン (Business rules engine: BRE) が導入されていることです。第 2 に、ビジネス・ロジックを実装した関数はサービスとしてビジネス・サービス層 (Business services layer: BSL) 内で公開されています。そして第 3 の違いとして、エンタープライズ・サービス・バス (Enterprise services bus: ESB) をアプリケーション層 (Application layer) とビジネス・サービス層との間の通信層として使用していることに注目してください。この設計のアプリケーション層はサービスにすることもできますが、この点については記事の範囲外です。また、ビジネス・コンポーネントは変更され、ビジネス・サービス層に進化しています。コードに組み込まれ、ビジネス・ロジックを実装していた関数は、すべて独立した呼び出し可能サービスに変換されました。
この新しい手法の利点について、次のセクションで説明します。
設計を改善することで高めるアジリティー
BRM システムを導入して、ビジネス・ルールをアプリケーション内にある他の制御コードから抽出し、切り離すことで、ビジネス・アナリストが単純な if-then-else 文と英語のようなビジネス言語を使ってビジネス・ルールを構成できるようになります。もちろん、ビジネス・ルールをプログラマー以外の手に委ねても、それによってプログラマーの作業がなくなるというわけではありません。実のところ、BRM システムの第一の利点は、ユーザーと開発者の全員が理解できるルール言語を両者で共有できるようにすることによって、プログラマーとアナリストの間で意思の疎通が取りやすくなり、互いの作業が遥かに円滑に進むようになることです。優れた BRM システムが果す目的は 2 つあります。その1 つは、プログラマーがルール・ベースの作成とアプリケーションのデプロイメントに効果的に使用できるツールを提供すること、そしてもう 1 つは、ビジネス・アナリストがルールを作成、変更する際に使いやすいツールを提供することです。
BRM システムを使うもう 1 つの利点は、このシステムにはルール・セット、ルール・フロー、判定テーブルといった各種の成果物が含まれるため、判定ロジックを再利用するにしても、複数サービスで共有するにしても、最大限の柔軟性がもたらされることです。図 3 の CheckCreditHistory サービスのように、いくつかのアプリケーションには共通ルール (サービスとして公開されるルール・セット) が必要になることがあります。この場合、SOA を介して異なるアプリケーションでルールを再利用できるようにすれば、サービス・ベースの設計からもたらされる改善だけでなく、開発時間の短縮、そして保守コストの削減も実現することができます。
さらに上記の改善された設計に示されているように、ESB を使用して異なるプラットフォームでの (そしておそらく異なるインターフェースのセマンティクスを使った場合でさえも) サービスの接続と構成を可能にする統合層を提供することにより、アジリティーはさらに高まります。新しいサービスとブローカー・サービス間メッセージ交換を比較的簡単に追加できるようにする ESB は、サービス指向を原則としたサービス・レベル・アプリケーションによって確立されるアジリティー・レベルを達成することができます。
SOA と BRM の組み合わせによる ROI の改善
現在、ソフトウェア・サービスを有料で提供するサード・パーティー・ソフトウェア会社が増えてきています。今後は、このようなサード・パーティーのサービスと社内で作成した他のサービスとが組み合わせられて SOA システムが構成されるようになるでしょう。例えば、上記の改善した設計に含まれる CreditCheckHistory サービスは、他の外部アプリケーションからも利用することができます。この場合、多数のカスタマーとカスタマーの使用にコストが分散され、その結果、業界内あるいは業界をまたいでの標準化が促進される可能性があります。これはつまり、IT 投資の利益率が伸びる可能性があるということです。
SOA を使用すれば、かなり大規模な機能の塊をつなぎ合わせて臨機応変なアプリケーションを形成し、それをサービスとして公開することが容易になります。これらの機能の塊は、本質的に異なるシステムから使用する場合も、さらにはレガシー・システムから使用する場合もあります。塊が大きくなればなるほど、特定の機能セットを実装するために必要なインターフェース・ポイントは少なくなります。各インターフェースにはある程度の処理オーバーヘッドが伴うため、サービスの粒度を決める際にはパフォーマンスを考慮しなければなりませんが、SOA が非常に有望な点は、n 番目のアプリケーションの実質的コストがゼロになることです。なぜなら、すでに存在する必要なソフトウェアのすべてが他のアプリケーションの要件を満たすからです。
まとめ
BRM システムとSOA を併せて使用すると、判定ロジックをアプリケーションの機能から切り離すことができるため、この 2 つの組み合わせには明らかな利点があります。市場が競合している状況では、ビジネスはそのアジリティーを高めることで、カスタマーの要求に素早く対応できなければなりません。ビジネスが暗黙的手法を取ろうとすると、結局のところビジネス・ロジックはバラバラに断片化したコードになり、たちまち保守作業が悪夢へと変わってしまいます。一連のルールの変更をロールアウトするのに数週間も数ヶ月もかかるといった事態を想像してみてください。毎日、さらには時間単位で変化するビジネスについていくことは到底できないでしょう。BRM システムは、組織がレガシー・システムから SOA へと段階的に移行する手段を提供します。特に、膨大な数のルールや頻繁に変更されるルール、あるいは非常に複雑なルールを使用する組織にはプラスになるでしょう。それは、複雑な規則や広範な規則に適合していることを実証しなければならない人々にとっても同じことです。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | | | IBM developerWorks 記事の著者としてお馴染みの Arun Chhatpar は、デシジョン分析、計略性ルール・マネージメント・システム、コア Java、UI フレームワーク、ワークフロー・オーケストレーションを含め、これまで 10 年以上、ソフトウェアの設計および開発に携わっています。彼は Sun 認定エンタープライズ・アーキテクト、そしてビジネス・ルールのエキスパートでもあります。 |
記事の評価
| 
