Red Hat JBoss BRMSにてルールやイベント用のデプロイメント アーキテクチャーを考察する(パート2)

原文: Examining Red Hat JBoss BRMS deployment architectures for rules and events (part II) by Eric D. Schabell

(North America在住の Red Hat Senior Middleware Consultantである John Hurlockerとの共著)

今週の Tips&Tricksはペースを落とし、Red Hat JBoss BRMSのデプロイメントアーキテクチャーについて可能性を探っていきます。

デプロイメントアーキテクチャーですが、ルールやイベントを利用するプロジェクトを業務用の本番環境にデプロイしなければならない状況を想定しています。

実行環境のデプロイメントアーキテクチャーは、プロジェクトの設計時に考え始める必要があります。あなたの企業やインフラにとって、アプリケーションをデプロイする為の最適な方法を検討しなかればなりません。殆どの場合、ビルドしたいアプリケーションの設計に影響します。よって、選択できるオプションを認識しておくことは、プロジェクトの成功に役立つはずです。

記事の連載を通して、デプロイメントアーキテクチャーを段階的に紹介していきます。先週分の記事を読まれていない方は、すでに2つのアーキテクチャーについて説明していますのでぜひキャッチアップしてください。

 選択肢

ルール管理者やアーキテクトはアプリケーションチームと共同でルールの実行環境を設計します。組織のニーズに応じて、アーキテクチャは以下のいずれか1つまたは複数を組み合わせたものになるでしょう。

連載を通し、4つの異なるデプロイメントアーキテクチャーを紹介します。それぞれ長所と短所を紹介することで、あなたのニーズにあったアーキテクチャーをご検討いただけるはずです。

以下に紹介する基本コンポーネントが、アーキテクチャー図で使用されます:

• JBoss BRMSサーバー
• ルール開発者/ビジネスアナリスト
• バージョン管理システム(GIT)
• デプロイメントサーバー(JBoss EAP)
• アプリケーションの利用者

ルール実行サーバー

このアーキテクチャーでは、JBoss BRMSをアプリケーションとして別途 用意します。それをサービス(例えば JMS、SOAP、etc)として公開することで、企業の本番環境で稼働するアプリケーションは、ルールやイベントをリモートで実行することができます。

イラスト1: ルール実行サーバー

イラスト1でご確認いただけるように、JBoss BRMSのルール/イベントコンポーネントを既存のアプリケーション開発プロセスから切り離すことができます。ルールやイベントを実行する為にアプリケーションがすべきことは、外部サービスの実行のみです。

長所

• 完全に切り離されたアーキテクチャー
• ルールをセットアップし実行する一般的な実装方法
• BRMSのバージョンをあげる際、企業内でフォーカスするべきポイントが1箇所のみになる

短所

• アプリケーションの一部を外部へ切り出す為、パフォーマンスの影響が懸念される場合もある
• 実行サーバーは複数アプリケーションから利用される可能性がある
• アプリケーションのオーナーシップを持ち、メンテナンスをするチームが必要

ハイブリッド系ルール実行サーバー

最後の例として、先程ご案内したルール実行サーバーに前回(パート1)ご紹介した KieScannerコンポーネントを追加した、ハイブリットアーキテクチャーをご紹介します。

イラスト2: ハイブリッドアーキテクチャー

このアーキテクチャーは先程と同様、外部サービスの呼出しを実施するアプリケーションを開発すれば良いです。外部サービスは、ルールやイベントを実行します。さらに、実行サーバーを変更せずともルールやイベントパッケージを更新することができます。

復習になりますが、JBoss BRMS APIには KieScannerが用意されており、リポジトリーで管理されるルールパッケージのバージョンアップを監視します。新規バージョンが確認されしだい、KieScannerによりピックアップされ、アプリケーションにロードされます。

Cool Storeデモプロジェクトにて、JBoss BRMS KieScannerの使用例をご確認いただけます。プロジェクトの実装例では、ルールリポジトリーから最新のビルドされたパッケージをスキャンしています。

イラスト2でご確認いただけるように、ルール実行サーバーは KieScannerをホストし、ルールやイベントパッケージの更新を監視します。更新が確認されしだいパッケージはピックアップされ、次回アプリケーションから呼び出された際に利用れます。

長所

• 完全に切り離されたアーキテクチャー
• ルールをセットアップし実行する一般的な実装方法であり、BRMSのバージョンをあげる際、企業内でフォーカスするべきポイントが1箇所のみになる
• 実行サーバーのメンテナンスが容易になる

短所

• アプリケーションの一部を外部へ切り出す為、パフォーマンスの影響が懸念される場合もある

次回は

デザインタイムアーキテクチャーと、ルールやイベントをデプロイする為のオプションについて考察します。

原文: Examining Red Hat JBoss BRMS deployment architectures for rules and events (part II) by Eric D. Schabell