2014年7月11日金曜日

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

原文: Examining Red Hat JBoss BRMS deployment architectures for rules and events (part I) 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)
  • アプリケーションの利用者
イラスト1:ルールをアプリケーションに同梱

アプリケーション内にルールをデプロイ

最初のアーキテクチャーは、最も基本的で静的(static)な方法を使いルールやイベントを業務環境にデプロイします。

デプロイ可能なルールパッケージ(e.g. JAR)をアプリケーションのアーカイブ(e.g. EAR, WAR)に同梱します。

このアーキテクチャーでは、JBoss  BRMSサーバーはルールを保持するリポジトリーと、デザイン時のツールとして機能します。イラスト1にて、JBoss BRMSサーバーが実行サーバーから完全に切り離されていることをご確認いただけます。

長所


  • 一般的に、ルール実行サーバーを用意するよりもパフォーマンスが良いです。なぜなら、アプリケーションと同一の JVM上でルールが実行されるからです。

短所


  • 本番環境のアプリケーションにルールの更新を pushすることができません
    • アプリケーションの再構築が必要です
    • アプリケーションの再テストが要求されます(開発 - QA - 本番)

イラスト2:KieScannerを使ったデプロイメント


アプリケーションからルールをスキャン

2つ目のアーキテクチャーでは、アプリケーションにスキャナーを追加します。ルールやイベントの更新が監視され、本番環境にデプロイされるかのように pullされます。

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

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

長所


  • アプリケーションサーバーを再起動する必要はありません
    • 一部の組織では、デプロイメント処理にとても時間がかかる場合があります
    • この方法により、リアルタイムでアプリケーション(複数も可)にルールの更新をプッシュすることができます

短所


  • 更新されるルールとアプリケーションをテストする為のデプロイメントプロセスを作成する必要があります
    • このプロセスによりしっかりテストされる仕組みが用意できない場合、不正なロジックをアプリケーションにプッシュするリスクがあります

次回は

残る2つのアーキテクチャーである ルール実行サーバーへのデプロイメントや、ハイブリッドモデルへのデプロイについて見ていきます。最後に私達は設計時のアーキテクチャーについて触れます。あなたのチームにとって、企業内でルールやイベントを作り、維持する際に必要な環境です。

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

1 件のコメント:

  1. 経験豊富な Red Hatエバンジェリストとコンサルタントが、JBoss BRMSを導入する際に考慮すべきデプロイメントアーキテクチャーについて説明しています。経験に裏付けされた内容ですので、ぜひチェックしてください

    すでにパート2も公開されているので、翻訳が待てない方はこちらをご覧ください。 http://www.schabell.org/2014/07/redhat-jboss-brms-examine-deployment-arch-part-II.html

    返信削除