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

Koichi Kobayashi koichik
2004年 10月 7日 (木) 02:45:48 JST 

小林 (koichik) です．

加藤さん，こんにちは．

コミッタの座うんぬんは直接お会いしたときにご相談させて頂くとして (笑)，
S2Axis に対する要件について話をしておきましょう．
とはいえ，毎日この話題をするのも大変そうなので，二日で一往復あるいは
それ以下のペースでのんびりと議論できればと考えています．

# などと言っている間に Axis 1.2RC1 がリリースされていますが．．．

まず，現在の S2Axis(alpha) のコンセプトについて説明をしておきます．
元々 S2Axis の開発に着手した際に要求されたことは，

・WSDD を書きたくない

というものでした．
この時点で加藤さんの考えとはかけ離れてしまっていたようです．(^^;

ですから，S2Axis(alpha) で <service> 要素を記述しないのは
意図的なものであり，開発者に Axis の存在を意識させないことが
ゴールでもあると考えています．
実際，S2Axis(alpha) として提供する S2Handler を一度 WSDD に
組み込みさえすれば，もはや Axis 側の設定は何もしなくてよくて，
気にするのは dicon だけという状況にしたかったのです．

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


On Tue, 05 Oct 2004 17:43:03 +0900
Taro Kato <kato ＠ gluegent.com> wrote:

> > ・S2Axisのalphaに不足していると考えたもの
> 
> 　・wsddファイルの<service>要素で細かな設定ができないこと。
> 　　不可能な場合は、S2対応を現状諦めないとならない。
> 　　（例えばスコープの変更などがある）

スコープというのは，request，session，application のことと
考えてよろしいでしょうか？
このうちの session に関しては，alpha でもサポートすることを
検討していたものの，ひがさん達と相談した結果，Axis 固有の
機能 (ですよね？) であることからサポートしないという結論に
至ったものです．
実際のところ，サービスはステートレスにすべきなのではないでしょうか？
request および application に関しては，dicon ファイルに記述する
コンポーネントが prototype か singleton かで同等になります．
よって，スコープを理由に <service> 要素の記述が必要というのは
疑問が残ります．

> 　・URIが変わるので、Webサービスのインターフェースを利用
> 　　しているものまで修正が発生する。
> 　　→修正コスト配布コストを抑えられない

これは理解できませんでした．
もう少し詳しく説明して頂けないでしょうか．

> 　・serviceに記述しなくても動作するものの提供としては
中略
> 　　しかし、/services/ の下にありながら、サービス一覧では
> 　　見ることが出来ないしWSDLが見れないし前述した様に<service>
> 　　定義がないなど、Axisの他のサービスと異なる動作を行っている。

Axis は拡張可能なものですから，標準で提供されているハンドラと
異なった動作をするものがあっても，それが「異なる」という理由だけで
問題視すべきとは思えません．
利用者にとって「望ましい」か「望ましくないか」が問題ではないかと
思います．

また，/services でのサービス一覧や ?wsdl での WSDL の提供といった
Axis 固有の機能をそのまま外部に公開することにもかなりの疑問を感じます．
外部に提供するインタフェースが Axis の実装に強く縛られると思えるためです．
サービスの一部を .NET で実装したくなった場合など，どうするのでしょう？
よって，サービス一覧や WSDL の取得といった一見便利な Axis の機能は，
せいぜい内部での利用にとどめるべきではないでしょうか？
ということは，外部へのサービス一覧や WSDL を提供する手段は別途必要であり，
内部利用としても Axis 固有機能の必要性はあまり無いということに
ならないでしょうか？

> 　　そもそもWSDDに書かれていない、WSDLがどこにも無いという
> 　　状態から、メソッドを伴って突如として呼び出せることになって
> 　　いる。これは「サービスを公開している」とは言い難い。

WSDD は Axis という実装における固有の定義情報に過ぎず，
「サービスを公開している」か否かとは何の関係もないのでは
ないでしょうか？
サービスの利用者にとっては，それが Axis を使って実装されているか
どうかは関係ないはずですから．
本来というか昔々の意図としては，UDDI で検索できることが
「サービスを公開している」要件だったと思われますが，現在は
どうなっているんでしょうね？

> 　　これを満たすために、別のページを作成しなければならない。
> 　　別のページを作成するということは、どこにWSDLを置いたか
> 　　管理しないとならない。サービス公開リストページも含み、
> 　　コンピュータがしてくれることをわざわざ人間がしなければ
> 　　ならなくなって、ヒューマンエラーが増える（更新を数カ所に渡って
> 　　行わなければならないため）。

これはちょっと違うのではないかと思いました．
これを Web サイトに例えると，サイトマップを人間が記述するのは
面倒だし間違いやすいから，(Apache でいうところの) Indexes を有効に
して，ファイル一覧を参照させればいいだろう，といっているのと
同じように感じます．
それは，ごく普通に考えると望ましいものではないでしょう．
この場合には，サイトマップの作成を自動化するのがより好ましい
アプローチではないでしょうか？
Web サービスにおいては，WSDL ファイルおよびサービス一覧の生成と
WAR/EAR へのパッケージングのようなビルド・デプロイの自動化というのが
より好ましいアプローチではないかと私には思えます．
WSDL の生成に関しては，java2wsdl を実行するように Ant の build ファイルを
記述するだけのように思えます．テスト環境と本番環境で URL (ドメイン等) を
変更するなどの工夫は必要ですが，あまり問題になるとは思えません．
サービスの一覧については，すぐに使えるものは思いつきませんが，
次のような Ant タスクを作ればいいのではないかと思います．
・ファイルセットから得た WSDL よりサービス一覧に必要な
  情報を抜き出した XML (DOM ツリー) を作成する．
・パラメータで指定されたスタイルシート (XSLT) を適用し，
  サービス一覧 (HTML) を生成する．

Axis のハンドラを作るより簡単ではないかと．(^^;

> > ・それに対して、こうしたらどうだろうか、という提案
> 
> 　・wsddへ記述するserviceを提供する S2Providerがあれば
> 　　DICON上のコンポーネントはprototype固定で提供さえすれば、
> 　　scope管理はaxisの機能が享受できるようになるので良いと思う。
> 　　

私はむしろ，dicon において prototype/singleton の記述だけが
有効になるようにした方が S2 の開発者には自然だし，間違いも
少ないと考えます．

> 　・WSDD上の他の<service>定義と自然に共存する形をとれば、
> 　　違和感がないと思う。ここでDICONへのアクセス方法として、
> 　　クラスでもnameアクセスでも可能ならば扱いやすいし、
> 　　<service>でわざわざ定義した理にも適う。

すみません，理解できませんでした．
何との違和感がないのか，何が扱いやすいのか，どう理にかなっているのか，
もう少し詳しく説明して頂けないでしょうか？

> 　・WSDDへの定義をすっとばして手軽に提供する機能としてAxisは
> 　　「.jwsを置く」としている。
> 　　/services/に記述しないものは、このservlet-mappingを用いる
> 　　方がAxisへの融合に近いと思う。

私はサービスを実装している手段が URL から類推できることは
望ましくないと考えます．
よって，それが S2Axis (alpha) によって実装されていようが，<service> で
記述されたものであろうが，同じような URL を提示すべきであり，実装の
手段により URL を使い分けることには反対です．

> 　・Axis-S2 で.jws URIに対するアプローチを統合するには、
> 　　WSDDに１行程度の定義の追加で扱えるという手軽さが望ましい。
> 　　この定義がなければAxis通常のJWSハンドラが使われると良いでしょう。
> 　　.jws では物理ファイルがあればAxisを、DICON内にあればS2を
> 　　使うというようにダイナミックに切り替わると嬉しい。

上で書いたように，そもそも .jws という URL をサービスとして
公開すること自体に疑問を感じます．
JWS は，「ちょっとしたプロトタイプ」くらいに使うのならまだしも，
それ以上の目的で使用するのはいかがなものかと思うわけです．
よって，JWS の使用を後押しするような機能を S2Axis として
サポートすることにも抵抗を感じます．


ということで，否定的なコメントばかり並べてしまいました．すみません．m(__)m
決して加藤さんをねじ伏せたいのではなく，私を納得させて欲しいということで
書いてますので，そのあたりご理解ください．

ここからは私の想像なのですが，もしかして加藤さんのところでは，

・Axis を使って (S2 は使わず) 実装したサービスがある．
・それは (当然) WSDD に <service name="" provider="java:RPC"> で記述している．
・そのサービスを S2 ベースに移植した．

という流れがあるのではないでしょうか？
そうであれば，

On Tue, 05 Oct 2004 13:00:25 +0900
Taro Kato <kato ＠ gluegent.com> wrote:

> とにかく最初は、"java:RPC" を "java:S2" に変えるだけで
> 良いようにしたいというのが狙いです。

という発想も理解できなくはない．．． かな？

さらにさらに想像ですが，開発の手順というか流れも次のようだったりは
しないでしょうか？

・サービスの実装 class を作成する．
・Axis にデプロイして WSDL を生成する．
・余計なメソッドが出てくるので allowedMethods で取り除く．

加藤さんのところが実際にどうかは分からないのですが，あまり
望ましい開発手順とは思えません．
私的には次のような流れの方が好ましいのではないかと考えます．

・サービスの interface を記述する．
・Java2Wsdl で WSDL を生成する．
・サービスの実装 class を作成する．

サービスとして公開するメソッドしか interface に記述しなければ，
WSDL に含まれるメソッドを制御するための allowedMethods は必要なくなると
思います．

実際には，誰もが WSDL に記述されているメソッドだけを叩いてくると
あてにするわけにもいかないので，セキュリティ的な意味合いでの
allowedMethods (相当) については必要性があると思いますが，
その手段が <service> 要素による記述だけだとは考えていません．


ということで，ここまで話を伺っている限りでは，<service> 要素を
記述することの意義を見いだすことが出来ていません．
その必要性について，もう少し詳しく教えて頂けないでしょうか？


-- 
<signature>
    <name>Koichi Kobayashi</name>
    <e-mail>koichik ＠ improvement.jp</e-mail>
</signature>

Seasar-user メーリングリストの案内