上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
コミュニティ検索 »
Web2.0 | 2006/06/29(木) 03:21
結構踏み込んだいい感じのGWT解説記事がありました。
まあIBMのdeveloperWorksの記事なわけですが、わかりやすく、かつ実用的でした。

GWT単体でちゃんと機能するValidationのやり方や、Yahoo! Whether APIの呼び出しを通じたサーバサイドのサービスの作り方なんかも載っていて、GWTを使うならしばらくは登竜門的存在の記事になりそうです。
サーバサイドのコードは、どうやらHttpServletになるみたいですね。
StrutsやSpringMVCとうまく適合する、と書いてありましたが、なぜにServletと適合するのかはまだちょっと不明。
(ちなみに最初から入っているサンプルの一つDynaTableでは、RemoteServiceServletを継承したServletでビジネスロジックを実装しているように見えるけど、これが自分で作るべきクラスなのか、生成されたものなのかは不明)

ビジネスロジックであるサービスは、RMIを使ってサービス実装とプロキシを分けられるみたい。
サービスIF(extends RemoteService)、サービス実装、AsyncサービスIFの3つ一組で作る。
クライアント側から使うときに、AsyncIFの引数であるAsyncCallbackクラスを実装することで、JavaScriptによる非同期処理を実装できるようです。


JNIの新たな使い方?

クライアントサイドには、Javaコード上にJNIライブラリの一つであるJSNI(JavaScript Native Interface)を利用して、JavaScriptを直接記述できるみたい。
サンプルではScript.aculo.usのEffectを呼び出す例を挙げてます。
こんな感じでJNIを書くと、クライアントコードにJavaScriptがそのまま反映されるらしいです。

private void displayHtml(String html) {
weatherHtml.setHTML(html);
applyEffect(weatherHtml.getElement(), "Appear");
}

private native void applyEffect(Element element, String effectName) /*-{

// Keep reference to self for use inside closure
var weather = this;

// Trigger named Scriptaculous effect
$wnd.Effect[effectName](element, {
afterFinish : function () {

// Make call back to Weather object
weather.@developerworks.gwt.weather.client.Weather::effectFinished()();
}
});
}-*/;

JNI使うという発想がすごい。Syntaxは以下。@class-nameはFQCNで。

[instance-expr.]@class-name::method-name(param-signature)(arguments)



GWTの痛い部分

記事によると、以下の点が痛いらしいです。一部は回避できています。

・ JavaScript無効だと、何も表示されない

・ JavaScriptから多言語対応用リソースファイルにアクセスできないので、多言語対応ができない

・ Java-to-JavaScriptソースコード生成というコンセプトが、サーバ/クライアント両方のソースを生成するall-or-nothingアプローチになっており、一部のみ適用といった使い方ができない

・ サービス実装のサーバサイドValidationで、意図しないパラメータを送ると、意図しない例外が発生する
  ⇒ 自分でパラメータチェックを書けば回避可能

・ ランタイムライブラリはApache License 2.0で提供だが、Java-to-JavaScriptコンパイラはバイナリ提供しかされておらず、改変も不可
  ⇒ 新たなブラウザが出てきたら、GWTの対応を待つのみ

うーん、確かにどれも痛い・・・



作り方が変わってきたWebアプリケーションとスキル重要度の変化

ページ遷移中心の作りから、AJAXによる(非同期というより)イベントドリブンアーキテクチャ(EDA)に変わってきたと感じます。

①クライアント: データ取得のためのイベント起動
②サーバ:    イベント処理&データ返送
③クライアント: データ受信&UI制御(描画や画面遷移)

これらの3つが一組で、かつそれぞれのイベント処理が独立しているというのが特徴です。
SOAでいうEDAも同じですが、サーバ側が提供するイベント処理=サービスは独立しているべきだということですね。その独立したサービスは、いつ呼び出しても大丈夫なので、クライアント側でもそれぞれのサービスを非同期に(というよりいつでも)呼び出せます。
FlashがWebService対応したときからこうなって行くだろうと思っていましたが、AJAXのおかげで急速に変化しそうですね。

実はこの傾向が進むと、サーバ側のサービス実装作業は、かなり単純化します。
ということは、誰でも出来ちゃう > 供給量が増える > ニーズが減っていく
という図式が成り立ってしまいます。

逆に、クライアント側での画面遷移や描画のコントロール、データ送受信、入力チェックなどが出来る人が、重宝される傾向が続く可能性があります。
JavaScriptでの処理は、サーバサイドの実装に依存しないため、適用・応用の幅は広く(JavaでもPHPでもPerlでも大丈夫)重宝される機会が多くなる可能性があります。
サーバサイドのスキルから、クライアントサイドのスキルへ重心が移りつつあるのかなと。


こういったニーズの変化を捉えておくと、常に売り手市場にポジショニングできるかも知れないですね。
スポンサーサイト
コメント (0) | トラックバック (0)
コミュニティ検索 »
トラックバック
この記事のトラックバックURL
http://completemirage.blog55.fc2.com/tb.php/20-a51eaf00
この記事にトラックバックする(FC2ブログユーザー)
コメント







非公開コメント
プロフィール
 

miyazima

Author:miyazima
常に変化を好み、面白いことを探しています。次の次は?

カレンダー
 
05 | 2017/06 | 07
- - - - 1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 -
カウンター
 
天気予報
 

-天気予報コム- -FC2-
ブログ内検索
 
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。