前の記事 に続いてSeasar Conferenceをレポートする。
セッション3
- DB-sideのほうは「DBを256倍活用する方法 S2Dao PHP/.NET/Java」
- Seasar-sideのほうは「企業システム進化論 - Seasarファミリー for SOA」
- ミニセッションのほうは「EJB3Unit」「S2Dao.PHPデモ」
私は「企業システム進化論」を聞いてきた。発表者は 和田卓人さん 。なんか、いろんなSeasarプロダクトのコミッタをやってらっしゃる。
このセッションの主題であるワークフローの管理、その変化への対応、企業システムの統合といった分野は私は経験があまりなくて、S2Buriもあまりピンと来ていなかった。だからこそ聞きに行った。S2Daoは自前で勉強すればなんとかなるもの。
結果として、S2Buriの凄さがちょっとだけ分かった気がする。
- Seasarは分散システムの領域にどうやって立ち向かうのか
- ワークフローの世界
これがこのセッションの主題である。
分散について
DI基盤(S2Container), プレゼンテーション層(Teeda, J2JSF), DB系(S2Dao他)をSeasarはサポートしているが、残るは分散である。Seasarはこれにどうやって立ち向かうのか
関連する主なプロダクトは、
S2Axisは上記参照。S2RMIも名前の通りJava RMIのgood wrapper。S2RemotingはS2AxisとS2RMIを隠蔽し、クライアントコードをプロトコルから独立にする。
S2JMSはこんな感じ。
基本的にPOJOで実装できる。メッセージを送信するにはメソッドから返り値を返すだけ。
- 返り値をInterceptorが横取りして送信してくれる。
明示的に送信用コンポーネントを呼び出すこともできる。
JMSを利用した非同期通信をActiveMQ上で実現
S2JMS-Container
J2EEコンテナに依存せずにJMSを利用できるようにするための、自前のJMSコンテナ。
- JMSの非同期通信は必ずしもUIを持たない基幹系でも有用だから、そういうところで便利
えっと、私も前にちょっと読んだだけでJMSについてうろ覚えだったので一応復習。
まずMOMっていうのがある。非同期通信用のミドルウェアで、実装にはIBMのWebSphere MQとか、オープンソースのActiveMQとかがある。送信側はは非同期メッセージを一度MOMにキューイングして、受信側はMOMからそれを取り出す。構造はProducer-Consumerパターンっぽい?
MOMが間に入って送信側と受信側を互いに抽象化することで、
で、JMSとはJavaからMOMを扱うためのAPI。DBに対するJDBCのような低水準のAPIである。
業務プロセス、ワークフロー
業務において個々の局面で為すべき個々の作業はあまり変わらない。つまり、個々のビジネスロジックというのはあまり変化しない。変わるのは、そのビジネスロジックをどういう手順で進めていくのかというワークフローである。「業務ロジックよりも業務プロセスのほうが寿命が短い」。
ロジックの中に、プロセスが入り込んでしまうと厄介である。例えば、会計処理において項目を計算するロジック自体は変わらないのに、「こういう場合はどの部署に」というような業務プロセスがif文のような形で会計処理に入り込んでしまうと厄介である。
これはプロセスをロジックの中に、寿命の短い要素を再利用可能な要素の中にハードコードしていることになる。そして、プロセスに関する処理がロジックの中に散在してしまう。プロセスが変化した時の改修が困難となる。
従って、業務プロセスを業務ロジックから外部化しなければならない。SeasarプロダクトにあってはS2Buriがこれを実現する。S2Buri勉強会も沢山の人が集まり、Seasarプロダクトの中でもTuigwaaなどと並んで注目を集めているものの1つである。
S2BuriはSeasar発のワークステートエンジンであり、GUIによって簡単にプロセス（業務フロー）を管理できる。
POJOの価値
- S2Containerはコンポーネントの間の依存関係を外部化する。依存関係をハードコードしなくて済むようになる。
- S2Remotingはコンポーネントの分散プロトコル（中継層）への依存関係を外部化する。分散処理をコンポーネントにハードコードしなくて済むようになる。
- S2Buriはコンポーネントの業務フロー（プロセス層）への依存関係を外部化する。業務フローをコンポーネントにハードコードしなくて済むようになる。
そして、業務ロジックからも通信プロトコルからも独立で互いに依存しない、純粋なロジックだけが残る。それは、フレームワークにも依存しない、POJOである。
Javaにおいてもっとも寿命が長いのは、どんなフレームワークでもない、POJOであろう。それは「Javaである」ことしか要請しないのだから。POJOは中継層やプロセス層のような「うつろいゆくもの」に依存しない。
POJO（と、POJOのためのJUnit）を蓄積していくことが資産の蓄積である。Seasarファミリーはそれを可能とする。
