|
|
オープンソースJ2EE APサーバ JBossの可能性 |
第6回:JBoss Inc.の各種製品について
著者:ダイテックC&D 高橋 康弘 2005/6/3
|
|
|
1 2 3 4 次のページ
|
|
JBoss Inc.が提供している製品
|
今回が連載の最後となりますが、今回はアプリケーションサーバであるJBoss Application Server(JBoss AS)から少し離れて、JBoss Inc.が提供しているその他の製品について紹介していきます。
JBoss Inc.では提供している製品群をJBoss Enterprise Middleware System(JEMS)と呼んでいます。現在JBoss Inc.が提供並びにサポートしている製品は、JBoss AS、Tomcat、Hibernate、JBoss Cache、JBoss jBPM、JBoss Portal、JBoss Eclipse IDE、EJB 3.0(早期アクセス版)、Javassist、JBoss AOP、JBoss Mail、JGroupsといったものになります(注1)。
これら製品のうち、今までの連載の中で触れてこなかったものを中心に概要を説明しようと思います。
|
JBoss jBPM
|
この製品は、昨年まではjBPM単体の別プロジェクトとして開発が続けられていましたが、現在はJBossの傘下に入り、名前もJBoss jBPMとなりました。現在の正式リリース版はバージョン2ですが、現在開発中のバージョン3もベータ版までこぎ着けてきています。
|
http://www.jbpm.org/index.html
|
この製品は、jBPM(Java Business Process Management)という名前からもわかる通り、ビジネスフロー、あるいは、仕事上のワークフローを管理するためのJavaライブラリです。
Javaライブラリですので、動作するフレームワークやコンテナといったミドルウェアは特に必要ありません。ですから、JBoss ASをはじめとするJ2EEコンテナ上でも動作しますし、スタンドアロンのJavaアプリケーションでも動作します。つまり、EJBやサーブレットからも問題なく利用できます。
JBoss jBPMを利用する目的は、複雑になりがちなビジネス・アプリケーション開発において、最小限のプロセスとして定義できるプログラムと、それの流れをコントロールする部分とを分離する、ということになります。
この分離によって、プログラムの単位が小さくなり、再利用もしやすくなります。また、フローの定義がプログラムから分離されますので、プログラムの修正を行うことなく(あるいは最小限の変更で)ビジネスフローの変更が行えるようになります。
jBPMはビジネスフローの定義をXMLで行います。XMLを手書きで用意することもできますが、GUIツール(注2)を用いて絵を描くことによってビジネスフローを定義することができます。
ビジネスフローを定義するために、UMLのアクティビティ・ダイアグラムのような図を記述することで直観的にわかりやすく定義することができます。そのため、プログラマやSEといった専門的な知識や技能を持った人でなくても、例えばビジネス・モデリングの専門家や、あるいはシステム利用部門の担当者がビジネスフローを比較的簡単に定義することができるようになります。そして、上流において定義されたビジネスフローを元にプログラミングが行われます。
このようなシステム開発(プログラミング)手法をGOP(Graph Oriented Programming)と呼んでいます。つまり、図(グラフ)に書いたビジネスフローを起点としてプログラミングを行っていこうという考え方です。
この考え方の特徴は、従来ではシステム開発作業の中にスムーズに取り込むことのできなかった作業者(ビジネス・モデリングの専門家や業務に精通しているがシステム開発には詳しくない担当者など)を、図を用いてビジネスフローを定義させるという手法によって巻き込みやすくなります。またその成果物(図)からビジネスフローを定義したファイルが自動的に生成され、実際に動作するアプリケーションでそのまま利用することができます。
ここで、簡単な例を使って説明しようと思います。次のようなフローの社内の決済システムを構築する場合を考えます。
- 有給休暇申請書を提出する
- 上長が承認/不承認する
- 承認された場合は、人事部の勤怠管理システムの情報を更新する
- 申請をした人のスケジュール管理システムを更新する
- 申請した人に承認されたことを通知する
上記のようなフローをシステムの利用者に定義してもらいます。その結果できあがった定義ファイルと、プログラマが作成したプログラムを組み合わせて最終的な業務アプリケーションが完成します。
この場合に注意して欲しい点は、上記(1)〜(5)の処理を実行するプログラムはそれぞれお互いのことを意識する必要がないということです。(1)〜(5)をひとつのトランザクションとして管理させるようにjBPMを定義することができますし、それぞれの単位でログを出力させることもできますので、ソースコード上にそれらを処理する記述がいりません。また、上記例では省略しましたが、入力値がエラーの場合の処理遷移を定義することもできます。
次に、上記のフローに対し「年間利用可能有給休暇数のチェック」というプロセスを追加する必要が生じたとします。この場合、既に存在する(1)〜(5)のプログラムに変更は必要ありません。「年間利用可能有給休暇数のチェック」を行うプログラムを作成し、このプロセスをビジネスフロー上に定義するために、ビジネスフローを表している図の変更を行うだけです。
最近ではこういった比較的小さな単機能を組み合わせることでシステムを構築する考え方をSOA(Service Oriented Architecture)と呼んでいます(先のGOPという考え方はSOAを実現するためのひとつの手段ともいえます)。
SOAという考え方は非常に流行っているようです。いくつかの大手ミドルウェア・ベンダーが各種ツールをこぞって提供していますし、雑誌などでも記事をよく見かけますので、聞いたことがある人も多いと思います。
一般的にはSOAの考えに基づいてシステムを構築することで、既存資産を生かした形で、素早く柔軟なシステムを構築することが期待されています。とりあえずどのような効果があるかを考える、という意味でも一度JBoss jBPMを試してみてはいかがでしょうか。
|
1 2 3 4 次のページ
|
|
|
|
著者プロフィール
株式会社ダイテックC&D 高橋 康弘
入社以来Windowsを中心としたアプリケーション開発に従事。2000年頃からJavaを扱うようになり、2年ほど前からオープンソースを利用したシステム開発を開始。最近はJBoss+オープンソースの組み合わせでWEBアプリケーション開発に携わることが多い。
資格:JBoss認定コンサルタント
|
|
|
|