WebサービスでSOAの実装方法
ついに、このブログのタイトル通り、我が社でSOAプロジェクトが動き出しそう。
しかし、プロジェクトメンバーは、SOAというバズワードに懐疑的なメンバーがいる。その気持はわかる。
しかも、ESBの導入という手段をとるという動きもあり、その手段はうちに合うのかもまだわかってないではないか。
調査会社にSOAの事例を見せてもらうと、O村製作所 Kセラ などはSOAの参照モデルを作成してそれに基づいてSOAを実現したとか。
大体、既存の業務とシステムを
- プレゼンテーション（UI)層
- ビジネスプロセス層
- サービス層
- データ層
の４つに分けて、各層を疎結合にする。（なお、各層の中も、レベルによって複数の層に分かれている）
いや、それは凄いんだけどさ。
実際導入するとなるとそんな参照モデルとかどうてもいいところで苦労する気がする。
今のところメンバーの疑問とか課題は、
小さいサービスをラップして、大きいサービスとするとなると、Webサービスが多階層となるんだが、その際に性能が出るのかどうか。
また、データ層は複数のDBが混在するため、例えばJOINとかはどうすんの？サービス層でいちいち複数のハッシュをJoinするの？それってメモリ食うんじゃないの？
という疑問。
前者は、XMLだとパース処理は確かに遅いので、XMLやめてJSONにすりゃいーじゃん。というのがありなのかなーと。
クライアントは、WebじゃないVBアプリとかもあるんだけど、JSONってVBでも読めるみたいだし。
でも、データ層の別々のDBだった場合、サービス層のWebサービスでデータをJOINしたりするのは、相変わらずコストがかかりそうだなぁ。
と、思ったらまさにそんな課題が紹介されてた。
http://www.oracle.com/technetwork/jp/articles/index-089833-ja.html
解決策1
RAC等によるデータベース統合を行うことで、共通マスタと業務データを同じデータベースに配置する。
データベースを共有することで、データベースを介したシステム間の密結合が懸念されるが、スキーマを使って各システムが使用できるオブジェクトを論理的に分離する。
解決策2
共通マスタから検索に 必要なデータを個別のシステムに配信する。
つまり、どちらの解決策も、１つのサービスは、１つのデータ層から呼び出せということ。
なんだよ、じゃ、そもそもDB統合とかMDMとかしなきゃダメやないかい。
というツッコミには解決策２が用意されているけど、DBを統合する代わりに、データを配信して必要なデータは全てのDBに置け。と。
つまり、データ層をEAIなんかでバッチで連携してるのはそのままにしろ。ってことですね。
あぁ。それって今のバッチ処理が複雑に連携しているのをSOA（ESB)で解決できないってことですやん・・・。
それって、いくら層を４つに分けたところで、サービス層と業務ロジック層は分けた意味ねーんじゃねーか？概念的に業務をレベル分けするためのもの？？
今後の検討としては、XMLでどんだけ性能出ないのか、JSONにするとどんだけ性能出るのか。そして、Webサービスの多階層の呼び出しは何階層までが性能的に許されるのか。（感覚的に３回くらい？？）
理想としては、プレゼンテーション層は、HTMLやJavascript・物理デバイスと密な連携をしなければいけないシステムはVBで画面だけを作って、業務ロジック以下は、全てサービス側に置きそれを呼び出す。
これにより、今までのシステムの枠組みなどが、なくなってシームレスなシステムとなる。
これもバズワードだけど、マッシュアップ。画面統合。
でも、それだと、ESBではなく、ポータルとかいう製品をベンダーにアピールされるんだよなぁ。なに、コレ、攻め方間違ってるんだろうか。
SOAという言葉はさておいて、Webサービスを使用した疎結合の仕組みって、どう実装しているのだろうか。
Webサービスの前に、DBの層を整理するほうが先なのだろうか。
悩む。
