サーバサイドJava開発では、長らくJavaScriptはオマケ的な扱いを受けてきて、あまり真面目に勉強してこなかったJava開発者は多いと思います。でも、もうそれでは顧客要求に応えられなくなりつつあります。JavaScriptを避けたとしても、結局はFlex・SilverlightのようなRIA技術を使うことになるでしょう。最早、以前のようなクラシックなWebアプリケーションでは顧客はOKを出してくれない時代となってしまいました。
あんまり悲観はしていない．今は開発環境が整っていないから高効率で開発が出来ないだけかと．
だって，Webアプリやる前はみんな3層式やC/Sで普通にリッチなクライアントで開発してたでしょ．当時でDAOとかビジネスロジックの分離がしっかり出来ていたとは思いにくいけど，それが出来ていた人なら何も難しくはないかと．
だから，Webアプリからの流れで開発するより3層式からの流れで考えたほうがいい．当時と違うのはクライアントとサーバーサイドの開発環境や言語が違う可能性が高いこと．Javaと.NETだけがターゲットならSOAPがやっと互換性が出来て非常に開発効率もよく便利になったのだが，ちょっと遅すぎた感じがする．社内専用ならばSOAPは一番開発しやすいけど，今後はのみこまれていくだろう．
とはいえ，一番厄介なのがクライアントサイドとサーバーサイドの言語が違うという問題．クライアントサイドをJava＋WebStart，サーバーサイドもJavaだと開発効率はよかった．これが別物になると考え方やらライブラリを覚えたりするのに時間がかかる．どうしても2つの言語をマスターするというのはなかなか無理だから習熟の差が出てしまいやすいのも問題か．たとえばJavaを10年触ってきた人は多いと思うが，JavascriptやFlash等がメイン言語並みの知識と技術のレベルまで使いこなせるようになるにはあと何年かかるだろうか．思想を理解するとかツールのサポート具合とかもあるので1，2年で解決するようには見えない．
また，社内アプリなどの閉じたところではいいのだが，開かれたWebの場合セキュリティですね．エンティティ単位ではやり取りが出来なくなるのでどうやってサーバーサイドのロジックとクライアントサイドとのやり取りに使うDTO（ここでいうのはJSONとかSOAPとかのこと）の変換等を効率よく開発が出来るかどうか．もしかすると1つのテーブルで公開する部分と非公開する部分とでエンティティを分けると意外と転送単位が小さくなって解決するのかもしれない．
たとえばJPAでの継承戦略のシングルテーブルとかエンベデッダブルアノテーションとかそういう方向で解決するというか．このへんの転送する項目をどうするかというフレームワーク等もたぶん使いやすいのがでてくるだろう．
もうひとつでかい問題があって，携帯電話対応が厄介なこと．やっぱりさまざまな携帯電話を対応するにはHTMLベースのWebアプリしか今のところ解決手段がない．それも機種ごとにあまりに差が大きいので最大公約数的機能を切り詰めてやっと．
もっとも，すべてのパターンに対応できるものを考えるから苦しいのであって，業務アプリの場合8割くらいは表に出ない社内アプリだと思うので，やはり社内だけならJavaや.NETによるリッチクライアントでいいやと，それ以外ならば規模は小さい（コンポーネントの数がアホみたいにある画面が大量とかは少ないはず）のが多いからJavascript，Flexと，携帯電話はHtml等と分けて考えたほうがいいかな．
