SOA関連のマーケティングメッセージを仕入れようと、SAPが出版した「SAPエンタープライズサービスアーキテクチャ―変革の時代を勝ち抜く最新IT戦略」を読み中。ちなみに、SOA関連では、SAPのマーケティングメッセージが一番分かりやすいのではないかと考えている。なにせ、ERPが否定されている時代なので、他のSIベンダーに比べれば必死さが違う。それに、SOAになってくると、ビジネス分析で一日の長がある（はずの）ERPベンダーのノウハウが生かせるはずだ（あと、えらい人のいいくるめかたも）。ま、この本の感想は読み終わった後に。もう１冊あるので。
システムのESA準拠レベル
この本の途中に、SAPが考える「ESA準拠レベル」という指標があった（ESAは、エンタープライズサービスアーキテクチャの略で、"SOA"のSAP用語）。CMM（能力成熟度モデル）をもじったものだそうで、既存システムから、ESA対応システムに移行するまでをしめしている。CMMと同じで、レベル1-5がある。
- :全体の把握
システムが提供する企業にとって重要なデータ、オブジェクト、サービス、そしてプロセスを理解し、文書化します - :データサービス
アプリケーションの一貫性を保つような方法で、システムのオブジェクトを読み書きします - :ユーザインターフェースの抽象化
ユーザインターフェースをシステムのその他の部分から分離し、複合ユーザインターフェースや他のシステムからサービスをコンポーネントとして使用できるようにします。 - :疎結合されたコンポーネントとサービス
サービスとオブジェクトを、疎結合できるように設計されたコンポーネントにグループ化します。 - :プロセスの抽象化
プロセスが公開され、設定可能になります
なるほど、既存のシステムをESA対応するなら、こうするのねと感じるかもしれない。CMMを意識し、レベルという指標でしめすことで、マネージャーにはわかりやすいだろう。内容的には、SOAでよく言われているあたりをきれいにまとめている。本書内では、それぞれもっと詳しくかかれているので、興味があれば本を見て欲しい。
アプリケーションのESB準拠レベル
で、これを、思いっきり１つのアプリケーションという範囲に持ってこれないだろうか。つまり、アプリケーションのESA準拠レベルだ。たとえば、こんな感じ。
- :全体の把握
RDBスキーマ定義、画面定義、入出力チェック、ロジックを理解し、仕様書化します - :データサービス
DAOパターンを用いてデータアクセスを整理し、POJOで作られたオブジェクトモデルを利用して永続化を行います。また、O/Rマッピング・フレームワークを導入し、RDBとのやり取りを管理します。 - :ユーザインターフェースの抽象化
MVCによって、Viewをビジネスロジックから分離します。そのために、フロー制御フレームワークとUIレンダリングフレームワークを導入します。なお、DTOパターンを用いて、JavaのWebコンテナを使わない場合にも、ネットワークの転送コストを抑えられるようにしておきます。 - :疎結合されたコンポーネントとサービス
ビジネスロジックをうまく分割し、DIコンテナを用いてランタイムで組み立てます。また、AOPフレームワークを利用して、横断的な機能も外部化します。 - :プロセスの抽象化
？？？
ま、若干強引なところもあるが、なかなかいい感じではないだろうか。このように、SOAのアーキテクチャは、単一のアプリケーションから企業システム全体まで、スケールを変えながら適用できると感じている。ただ、SAPの用意した指標が、ここまできれいにはまると、なにか感じるものがあるのではないだろうか。最近は、システムの再構築が流行しているし、こんな指標で、再構築戦略をしめすと分かりやすいのかもしれない。
レベル5とは
で、興味深いのは、レベル5の部分。SAPの表では、EAIやBPMと呼ばれるエンタープライズレベルのソフトウェアが活躍しているところだ。最近では、BPELのように、もっと多機能で直接的なプロセスモデリングの手法もある。これらのソフトウェアでは、プロセスの実行以外にも、トランザクション管理、キュー制御、パラメタマッピングなど、いろいろな機能がある。
では、この概念をアプリケーションレベルに落としこむとどうなるだろうか。
いまどきのSSH（Struts＋Spring+Hibernate）開発を経験した方なら、StrutsのActionクラスに書くことが少ないと感じているはずだ。Injectされたビジネスロジックを使い、値を渡し、例外を処理してエラーを画面に返す。
では、それをXMLファイルにすることができればよい。設定ファイルに書かれるのは、呼び出すビジネスロジックの名前と順番、渡すパラメタの設定（型変換や外部情報の読み込みサポート付き）、そして例外に対応するメッセージキー。あとは、小型のBPMエンジンを組み込んで、動かすだけだ。
もちろん、開発時のデバックやテストなど問題はある。たぶん、ツールがないと無理だ（ていうか、struts-configも、applicationContextも、ツールがないと厳しくなってきた）。
しかし、メリットもあるはずだ。ロジックの変更も容易だし、型変換などは自動的に処理されるだろう。XMLファイルにすれば、ビジュアル開発、もしくはそのまま仕様書ということも不可能ではない。
アプリケーションの方向性
ま、結論はPOJOがしめすアプリケーションの形というエントリで表現した「現実的なMDA」と同じところに落ちてくる。できるかぎりメタ情報（設定ファイル）を増やし、出来るだけスクラッチコードを少なくするという流れ自体は、大きくは変わらないということだ。
 | SAPエンタープライズサービスアーキテクチャ―変革の時代を勝ち抜く最新IT戦略 ダン ウッズ Dan Woods 木下 哲也 福龍興業 オライリージャパン 2004-06 by G-Tools |
