[Seasar-user:1086] Re: S2Axis 1.0.0 (alpha) リリース

[Taro Kato]

お返事ありがとうございます。加藤です。
ちょっと眠いですが取り急ぎ。

> ・WSDD を書きたくない
> 
> というものでした．
> この時点で加藤さんの考えとはかけ離れてしまっていたようです．(^^;
おお！ほんと真逆ですね。(＠ｏ＠）／
なるほど、その設計思想なら理解できます。

結局、Seasar を意識させて Axisを意識させないツクリ → 小林さん
Axisを意識させて Seasar を意識させないツクリ → 加藤

…ということの違いだということが分かりました。
私の方は非常にAxisに密着しようとしているけど、小林さんの方はなるべく
疎にAxisと関わる感じというのも特徴ですね。

私のしたかったことは既にAxisで作った物がありきで、Seasarをちょっと
組み込んでみようかな…という姿勢からだったんですよ。
Seaserありきで開発を進めるのであれば、たしかに小林さんの方が
良いですね。軽いし。ムリにAxisライクにすることは無いのですけどね。

> 一方，加藤さんは <service> 要素を記述するのは当然と
> 考えておられるようですね．
> 今のところ，私にはその理由が理解できていません．

了解です。なぜ WSDDに<service>ありきかですね。

実はjwsの代用もオーバースペックかなぁと思いながらも、現行の機能を
ある程度、折衷案で盛り込んでいただけで実は本当にやりたいものでは
ありませんでした。

パッケージパラメータありきのクラス指定にしたのは妥協する上での、
私の考えを守る最低限のラインでした。

なぜかと言えば、app.diconが一枚岩の巨大なものになりますので、
（コンテナが分かれたりすると扱いづらいトランザクションも連結しないし）
name さえ付いていれば、どんなものも、たとえば xaDataSource さえ
Webサービスになってしまうんですよね？

私の方は一枚のWSDDを見れば全部の定義状態が把握したかったんですね。
サービスにしているのはこれとこれとこれ、ちゃんとビーンはマッピング
しているかな？うんうんしている。…というような感じで。

このサービスは特にトランザクション関係ないから普通のAxisにしといた。
しかしある時点で、ちょっとAOP引っかける必要がでてきたから、
そんじゃDICONに早速コンポーネント定義して、RPCからS2に変更するか…
という小さな修正での開発スタイルも入れたいんです。

以上の３点がWSDDにまとめこみたい理由です。

現状のものはとてもシンプルで良いとは思っていますが、そんな感じです。


> 実際のところ，サービスはステートレスにすべきなのではないでしょうか？
> request および application に関しては，dicon ファイルに記述する
> コンポーネントが prototype か singleton かで同等になります．
うーん「想い」は分かりますが、なんかいろいろと、代替策、代替策…と
いう感じですよね。それとできない理由を「すべきだから」って、Axis設計者
もなにそれって思いませんか？Axis使う意味がなくありませんかね？
ステートレスにするために相当Axis頑張ってますよ。そんな仕様SOAPにないのに。

ボクはこのクッキーをうまく使ったステートレス対応に感動して、どうにか
DelphiのSOAPクライアントでAxisサーバーと共有できるようにって、Delphiの
システムソースに手を入れてまで実現したんですけどね。
言うなればスタティックメソッドの固まりが、メンバを持ったオブジェクトにな
るわけですから劇的な変化だと思いません？
Webサービスはすぐに、パラメータとリターンが巨大化するんですよねー。
通信経路を通る量は減りますし。必要に応じて何手か前で渡していた物を得て
いたものの結果を得るということができますから、まさしくリモートオブジェク
トのイメージで扱えますよ。


> > 　・URIが変わるので、Webサービスのインターフェースを利用
> > 　　しているものまで修正が発生する。
> > 　　→修正コスト配布コストを抑えられない
> 
> これは理解できませんでした．
> もう少し詳しく説明して頂けないでしょうか．

もうすでにクライアントプログラムは、動的に ?wsdlで取得して操作するように
しているものがありますので、配布済みのものを差し替える必要が出ちゃうって
ことです。やりたいのはサーバーサイドの、クライアントサイドの預り知らない
ところの若干の修正なのに、それが波及しちゃうって感じです。

もともと S2Axis ありきで、最初に全部サービスはDICONに定義する！って
ことが徹底されていれば、この限りではありません。


> ここからは私の想像なのですが，もしかして加藤さんのところでは，
> 
> ・Axis を使って (S2 は使わず) 実装したサービスがある．
> ・それは (当然) WSDD に <service name="" provider="java:RPC"> で記述している．
> ・そのサービスを S2 ベースに移植した．
> 
> という流れがあるのではないでしょうか？

当たりでーす。S2に移植したというかこれからなんですけどね。
めんどくさがりやなんですよ。私。
Axis触るのにブラウザベースでコンソールがいらない快感を覚えてしまったので。
Eclipseの便利さ覚えたら、テキストエディタで目デバッグには戻れないのに
近いです。
哲学とか設計思想を飛び越えても楽で便利に漬かりたいのです。(^-^;



> さらにさらに想像ですが，開発の手順というか流れも次のようだったりは
> しないでしょうか？
> 
> ・サービスの実装 class を作成する．
> ・Axis にデプロイして WSDL を生成する．
> ・余計なメソッドが出てくるので allowedMethods で取り除く．

こっちは違います。前述したとおり、インターフェース決めてからですね。
でもスパイラルに開発しているので変更にインパクトを無くしたいのがあるん
ですよ。

でももし本当にSeasarが主でAxisが従なら、もっと軽量のSOAP実装を使った
方が良いような気がするんですけどね？

WSDDいらないなら、FileProviderも無駄だし、WSDL吐き出すところなんかも
小林さんから見たらオーバースペックなわけですよね？

ま、今のシンプルなのも賛成ですので、だから私は全然今のままでも
良いと思いますよ。
アプローチの方向が違っていただけで、理解できます。賛成です。
なので、コミットの話は無しってことで。

ただ多かれ少なかれ、他のS2シリーズも同様だと思いますが、
seaserを新規導入するために既存のフレームワークと同調してほしいという
要求はあると思います。
「インパクトが大きいなら採用を見送る！」なんていうことが無いように。
究極は「え！何も変更箇所はないけど、seaser入っているんですか？」って
のが理想です。

S2Tapeなども、PageじゃなければAspectできるから、イベントリスナーを
外部POJOへ！Cycleさえあれば、Pageじゃなくたっていいじゃないですか〜！
とか、栗原と熱いトークしたりとかもありました。
私なんてかなり無茶いってましたよ。listeners.XXXXX で、まずは
そのメソッド名を持つインターフェースを探し出して、それを使っている
コンポーネントの当該メソッドを呼び出す。そんなのなければようやく自身の
Pageのメソッドと見なす…なんて。しかも、global. 無しで…とか。
そうなるとPageへの変更無しで、後から差し込める芸当もできちゃいますよね
（ただメソッド名にユニーク性が求められちゃうのが難点）。
さすがにそれはムリだったけど、栗原がすぐに２時間ぐらいで近い物を実装して
くれました。社長なのに。
Page以外が捕らえられるからAspectの対象がPage内から委譲コードを書かずとも
できちゃうってやっぱ良いですよねー？
＃って全然Tapeでの開発、私自身はノータッチなんですが。。。。

たとえるなら、「commons.langのライブラリを黙って入れて使って納めた。
別に他にチームの他のメンバーに迷惑掛かってないからいいじゃん」ぐらいの
インパクトが最高です。で、実際にそれぐらいから始められるんですよね。
seasarってば。

そういう利用についての安心と理解が広がると良いですねー。


■■■ Gluegent,Inc.  [http://www.gluegent.com/]
■■■ System Development Division
■■■ Taro Kato      [kato ＠ gluegent.com]