Hatena::ブログ(Diary)

Fly me to the Juno! このページをアンテナに追加 RSSフィード

2009-11-20

業務システムで使うSpring Dynamic Modulesを発表してきました!

今回のテーマは「クラウド」という事でしたが、空気を読まずに熊沢先生の「Modularityを考える - 複雑系のアーキテクチャ」への自分の考えを発表してきました。多分に電波を含んでいたので、質問されるとしどろもどろになっていましたが、今回伝えたかった「モジュール化(Modularity)はオブジェクト指向から抽象化を一歩すすめたもの」と言うあたりには納得していただけたようです。

で、結局のところ日本のSIerがやっている業務システムへモジュール化はどうやってやっていくのがいいか、という事に対してうまく答えられなかったわけで、くやしいのでブログに書こう。

モジュールは必要か

自分はシステムが小さいうちからモジュールを意識して作っておく事は保守の面でいいと思ってます。DIの普及により、インターフェースに対してプログラミングを行う作法で実装が行われるようになりました。モジュールを意識して実装を行うと、本来ならば関係のないクラスとメソッドを、同じような処理だから、既にある実装を利用する、という悪しき習慣を改めることができます。例えば

package system.db.utils;
class DBUtils{
  public static boolean isNull(Object obj){
    return obj == null;
  }
}

というDBUtilsがあったとして、UIレイヤからこのstaticメソッドを呼ぶ、なんてことはモジュールで区分けされていたらできなくなります。DRYの原則ではコピペを悪とされますが、それとこれは話が違います。概念的に違うものを一緒くたに扱う事ですから。もしやるのであれば、

package system.ui.utils;
import system.utils.DBUtils;

public class UIUtils{
  public static boolean isNull(Object obj){
    return ObjectUtils.isNull(obj);
  }
}
package system.utils;
public class ObjectUtils{
  public static boolean isNull(Object obj){
    return obj == null;
  }
}
package system.db.utils;
import system.utils.DBUtils;

public class DBUtils{
  public static boolean isNull(Object obj){
    return ObjectUtils.isNull(obj);
  }
}

というように、両方のクラスから参照できるクラスを用意するのがいいんじゃないでしょうか。モジュール化にはそういう効果があると思うのです。

他にもモジュール化のメリットとして、例を出した方がいいと発表後に思ったのが、バージョンです。リリースしているバイナリが、本当に最新版かどうか、確実な方法を用意していますか?自分はJARなりWARなりの中のメタ情報には必ずビルド日時を入れるようにしています。実行環境にデプロイした時に、確実に動いているものがいつのバージョンのものか、分かるようにしたいからです。

いや、運用でカバーできる、と言う声は絶対あると思うんですが、それって「確実」なんですかね。埋め込まれている情報は、「確実」ですよ。自動的に埋め込まれる訳ですから。(後からメタ情報を入れ替える、という事もなくはないですが、JARなりWARに固めるときに書名情報を埋め込む事もできますよね。そこまではなかなかやらないけども。)

モジュール化のデメリット

モジュール化を行うとオーバーヘッドがかかる部分があります。それは開発時ではなく、パフォーマンスです。モジュールのロードを行う、というフェーズが増えるからです。これは抽象化の弊害とも言えます。だから、オーバーヘッドはそういうものだと思って切り捨てた方がよさそうです。

ところで、モジュール化は結局のところ、システムを機能などの側面から、人が認識しやすい大きさに分割し、わかりやすい名前をつけていくこと、と言いました。じゃ、うまく分割するにはどうしたらいいのか、そこに触れずに終わらせたんですが、この設計が結構大変。例えばオブジェクト指向で設計していてもよくあると思うんですが、Blob(別名GodObject)を作ってしまう事がないでしょうか?リンク先を見ていただくとわかると思うのですが、Blobとはあるクラスが肥大化していくパターンです。肥大化したクラスがあるとテストがしにくく、保守しにくい。そしてそもそも、システムをクラスという単位で分割することで認識しやすくしているのに、肥大化クラスがあるのは、分割がうまく行っていない証拠です。同じように、モジュールは肥大化しやすい訳です。全部入りモジュール。あればそれだけで全部の事ができる、というモジュールを作りたくなりますが、それは性能面でも問題になりますし、使われていない機能に脆弱性があるかもしれない、というセキュリティ面も問題をはらんでいます。

システムが小さな最初のうちに、いくつかのモジュールに分けておき、それを組み合わせることでシステムの稼働に必要な最低限の状態でリリースすることも考えてみるとよいでしょう。

Spring DMのデメリット

Springを使っているアプリケーションOSGiに載せるのであれば、Spring DMを使わない理由はないです。OSGiで稼働しているアプリケーションにSpring DMを追加した方がよいか、という面でみると、状況によります。Extenderの追加により、システムの複雑性は増します。どんなモジュールを追加しても複雑性は増すんですが、Extenderは他の全てのBundleの内容を走査し、Springの設定ファイルがあれば読み込みます。ロジックには問題ないですが、確実に起動速度に影響します。

今回はいつもやっていたデモは行いませんでした。やっても地味なので。でも見たかった、という声もちらほら。今回は、主張に重点を置きたかったので、ごめんなさいね。と言うわけで、ツッコミ等どうぞよろしくお願いします。

JSUG勉強会での発表資料

2009-11-13

Spring勉強会 2009年11月19日で話します

今年最後(と言われている)Spring勉強会で話をします。テーマはクラウドでしたが、8月の勉強会で熊澤さんが講演してくれた「Modularityを考える - 複雑系のアーキテクチャ」を聞いて、なぜソフトウェアにModularityが必要なのか、もんもんとしていたものをはっきりと言葉にして語ります。そもそも、Modularityが必要な理由が語られないまま、Spring Dynamic Modulesについて語ってもうれしさが伝わらないと思うので、重点を置くのはそちらです。頑張ってゆーすけさんからの期待に応えられる内容にしますので、ソフトウェアの構造について興味のある方、ソフトウェアアーキテクトを目指している方はぜひ来ていただければ、と思います。

申し込みはコチラから!

日時: 2009年11月19日(木) 18:30 - 21:00

場所: オラクル青山センター

定員: 先着70名

主催: 日本Springユーザー会(JSUG

協賛: 日本オラクル株式会社

プログラム

「Spring Cloudの全貌」

土岐 さん(現場指向)

「Springとモジュールの行方 by OSGi

こんぴろ さん(株式会社 チェンジビジョン)

「G*なクラウド 〜雲のかなたに〜 ショートバージョン」

山本剛 さん(ニューキャスト)

申し込みはコチラから!

2009-06-28

JSUG+JGGUG合同勉強会で話してきました

 空気を読めないこんぴろです、こんにちは。JSUG+JGGUG合同勉強会で、Rod氏がQconTokyo 2009で語っていたことを話してきました。

 Oracleさんのセミナールームをなめてました。フリードリンクとか。あの広さとか。無線LANスポット提供とか。いや、すばらしかった。

2009-05-28

JSUG+JGGUGで話してきまつ。

来る6/24、JSUG+JGGUGの合同勉強会で話をすることになりました!

先月のQConでずうずうしくもRod Johnson氏にインタビューしてきました。JSUGの主催者の長谷川さんもいらしていたので、またしゃべることになりました。と言ってもインタビューの内容はそんなに話せないので、Spring Tool SuiteっていうRod氏が一押しのツールを動かしてみたぜ!みたいな話もするつもりです。

http://www.springframework.jp/

にそのほかのセッションも概要があがっているのでぜひご参加ください。

2008-09-23

Springのサポート有償化に思う、オープンソースで飯食うにはどうしたらいいのか?

SpringFrameworkのサポートが有償化により、無償版を作るためにfork(枝分かれ)しようぜ的な流れがあるようですね。たぶんそうなったとしたら無償版をサポートしていく人たちはボランティアなのかもしれませんが、その人たちの飯食う手段は別にあるんでしょうね。SpringSourceの方々は、SpringFrameworkのメンテナンスも飯の種にしたくて、サポートの有償化という話でしょう。でもそこで飯を食うのってお金を誰が払ってくれるのかっていうと、誰も払いたがらないところなんでしょうね。タダで使っている奴らもいるのに、なんで俺らがお金を払わなきゃならんの?って、なっているのが、今の炎上すかね。

SpringFrameworkって既にとても多くの企業で使われているから、そこにお金を払うことって公共性が高い事ですよね。ほんとはもっとでかい枠組み(例えば国とか。)からお金が出てくれるといいんでしょうね。Ubuntuのように極端にカネをもった1個人から出資されるのでも良かったんです。

他にも営利目的の企業になるのではなく、非営利団体を設立して、そこでお金を集める、Mozilla FoundationとかEclipse Foundationとかのように出来なかったんでしょうか。(余談ですが、Eclipse FoundationはIBMからの風当たりが強くなったのか、最近スピンオフしたベンチャー企業の設立が増えている気がする。)VCから資金を調達したことが間違いだったんでしょうか。このままの流れでSpringFrameworkが使われなくなってしまうことはないと思いますが、勢いが弱まってしまうのは残念ですね。

そんなことを思いつつ、どうやったらオープンソースで飯食えるんだろうと考えてみました。ソフトウェアから得られている利益は見えづらい上、コピーのコストはないと考えられます。でも作成するコストは結構かかる。(再利用とかできるようにしたところで、それをうまく使うための学習コストは無視できません。)ソフトウェアを創造するコストに至っては、芸術家と同じレベルで時間がかかる。と、書いてみて思ったのは、芸術の分野とソフトウェアの分野ってコスト構造が似てるのかもしれないなと。新進気鋭の芸術家を保護するのと同様、ソフトウェアを創造する人たちも保護すべきなんでしょうね。それを企業レベルでやってるのがGoogleとかだと言えそうです。

オープンソースに一番お金を払うべき企業はどこなんでしょう?エンドユーザー?もしかするとその叡智を借りている企業かもしれません。いわゆるSI企業と呼ばれる企業とか。コストな圧力がお客さんからもツールからも来るのは苦しいです。自分達の生活を守んなきゃやってられないですもの。

なんかお金が循環しない業界なのかもしれないですね。