- PR -

「リッチクライアント時代の到来」について

参照元記事 | 同じ記事を参照しているスレッド一覧
«前のページへ 1|2|3 次のページへ»
投票結果総投票数：136
Flash orFlex 30票 22.06%
SmartClient 23票 16.91%
Curl 6票 4.41%
Biz/Browser 6票 4.41%
Java Web Start 55票 40.44%
NexaWeb 14票 10.29%
DHTML 2票 1.47%
  • 投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。
  • 投票結果の正当性や公平性について、＠ITは一切保証も関与もいたしません。
投稿者投稿内容
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2004-05-14 12:01
このような返答をまってました。
今回の投票項目は参照元記事＋DHTMLで編成されています。
引用:

●スマートクライアント（マイクロソフト）
Webサービスを利用し、サーバより配布・展開・アップデートを行うWindowsアプリケーション。

と紹介されていますので、そのまま載せています。

引用:

ただリッチクライアントが失敗したので次の標語を出してきただけの印象もあります。

まさにスーパーポジティブ・エバンジェリズム・標語戦略ですよね。
業務AppletからJavaをはじめた私としても、言葉先行はどうかと思います。

ただ、今のGUI充実の方向性は間違っていないと思います。
DHTMLでのGUI充実は多くの人がウンザリしてますし、
CIOの号令でHTMLのUIで業務アプリを作ってしまったユーザは
その使いにくさにウンザリしています。
特に日本ではEXCEL/Lotus123信者やHOST信者が根強く残っており、
ぱぱっとグラフも出せないのかと言われてしまうことがあります。

・・・MS-OfficeがもっとWebクライアントとして動けばいいのか
なにかが違う・・・

[ メッセージ編集済み 編集者: zaxx_MD 編集日時 2004-05-14 12:04 ]
sugimoto
常連さん
会議室デビュー日: 2002/12/05
投稿数: 45
投稿日時: 2004-05-14 13:49
杉本です。

引用:

zaxx_MDさんの書き込み (2004-05-14 12:01) より:

ただ、今のGUI充実の方向性は間違っていないと思います。
DHTMLでのGUI充実は多くの人がウンザリしてますし、
CIOの号令でHTMLのUIで業務アプリを作ってしまったユーザは
その使いにくさにウンザリしています。
特に日本ではEXCEL/Lotus123信者やHOST信者が根強く残っており、
ぱぱっとグラフも出せないのかと言われてしまうことがあります。

・・・MS-OfficeがもっとWebクライアントとして動けばいいのか
なにかが違う・・・


MS-Officeというのでしたら、Webクライアントというより、
Webサービスのクライアントとしてというのはどうでしょうか？

もちろん、クライアント環境にMS-Officeがインストールされている
環境が前提になってしまい、使用される業務も、Webアプリケーションに
比べると限定されるでしょうが、
Tomcat＋Axis＋MS-Office InfoPath（Office2003)という構成も有りかなと・・・

もしくは、IBM WebSphere（のようなミドルウェア） + InfoPath なんてのも
一つの案としてどうでしょうか？

もし、このような構成でやってる方がいたら、感想を聞いてみたいです。


_________________
Kazuya Sugimoto
http://kamedane.com
Ｇ
会議室デビュー日: 2003/10/07
投稿数: 9
お住まい・勤務地: 神戸
投稿日時: 2004-05-14 14:19
こんにちは。Gです。
いまリッチクライアントというわけではありませんが、
JavaApplet→Servletの環境を
JavaSeingApplet→Servlet
にしようという案件を受け持っています。
（まぁ実際はまだSwingのJAppletにするべきかどうか客先と
検討中の段階ですが・・・）
そのため、もし、Swingにするなら「JavaWebStart」も
考えていこうかと考えている次第だったのですが。
どうもまだ、面倒な手順が多そうですね。

[quote]
zaxx_MDさんの書き込み (2004-05-14 12:01) より:
Javaの世界ではやはりJavaWebStart+Java DesktopSysytemあたりの動向が
注目されていますが、実際にJavaWebStartアプリケーションのほとんどが
証明書でサインする必要があるのに、
標準ツールがいまだにコマンドラインで使い勝手が悪いとか、
証明書の取得手続きが非常にまだるっこしい上に期限付きとか、
開発者にとって改善してほしいところが解決されていないように感じます。
また、サーバアプリケーションとの通信にHTTPClient機能を利用しようと
する場合にJakartaのHTTPClientがあるような状況ですし、
そもそもそのような低LVの通信手段ではなく、ミドルウェア的なものが
必要ではないでしょうか？


スマート
会議室デビュー日: 2004/03/15
投稿数: 9
投稿日時: 2004-05-14 14:21
引用:

sugimotoさんの書き込み (2004-05-14 13:49) より:
もちろん、クライアント環境にMS-Officeがインストールされている
環境が前提になってしまい、使用される業務も、Webアプリケーションに
比べると限定されるでしょうが、

確かに全ての業務アプリがWebである必要性はないので、
そのようなアプリには良いのかもしれません。

以下はあくまでもWebアプリを考えた場合ですが、
前提がある時点で本来のリッチクライアントの方向から逸脱しているような気がします。

本来求められているものは、
・C/Sなみの機能と操作性
・HTMLのようなマルチプラットフォーム性
・プラグイン等ユーザーが気にする必要がない
・WEBのメンテナンス
・WEBのスケーラビリティ
・etc
といった事を実現できる技術だと思います。

現在日本で取り扱われているリッチクライアント技術は
マルチプラットフォーム、プラグインといった観点では？がつきます。
プラグインのバージョン互換性やJavaベースならJDKのバージョン依存、OSへの依存が存在しているためです。
現時点における現実解・妥協策という意味では十分なのかもとは思いますが、
問題を将来に先送りしている印象が否めません。

Nexawebのホームページにこれを解決しているような記述があるため、
私個人としてはもうちょっとNexawebを深堀してみたいと思っています。
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2004-05-14 15:48
引用:

本来求められているものは、
・C/Sなみの機能と操作性
・HTMLのようなマルチプラットフォーム性
・プラグイン等ユーザーが気にする必要がない
・WEBのメンテナンス
・WEBのスケーラビリティ
・etc
といった事を実現できる技術だと思います。

うーん・・・求められているものと技術的な要素を混同しているように感じます。

勝手に分解すると

・C/Sなみの機能と操作性
　→・機能（コピー＆ペースト＋DnD）
　→・操作性（Fキー、コンビネーションキー、ショートカットキー）
・HTMLのようなマルチプラットフォーム性
　→・マルチプラットフォーム＝(Windows系列/MacOSX/Linux)での互換性
・プラグイン等ユーザーが気にする必要がない
　→システム部門がしっかり管理しましょう
・WEBのメンテナンス
　→・集中・一元管理されたメンテナンス性
・WEBのスケーラビリティ
　→・GRIDの方がスケーラビリティは良い
　→・安いサーバより最新のPCの方が速い
・etc
　→・対故障性（Webの一番良い点かも）

として、MS-Officeも条件を満たしていませんか？
　→Windows系列はSMSで管理する
　→MacOSXはMac版がV.UPしたので導入してもらう
　→LinuxはSUNのStarOffice(OpenOffice)の互換性を向上してもらう
立派なマルチプラットフォームですよね。
運用・維持体制をしっかり構築できれば・・・

MS-Officeが中規模以上の業務アプリには適用できない理由は
１．データのアクセス制御・取得範囲制限
２．ロジックの集約定義
３．ユーザ個別のデータ保存
４．セキュリティ
このようなWebチックなデータフローが成り立たない点だと思います。

SOAPクライアントになったとしても、
EXCEL側で全件取得とか走られるとサーバの資源がいくらあっても足りないですし、
EXCEL信者は多次元処理とかレイアウト変更とか平気でやりますからねぇ。

一元集中管理のメンテナンス性とかロジックの集約定義なんて
実はあんまり意味(ROI/TCO)がないのかも・・？

そうするとリッチクライアントの適用範囲ってかなり狭いんじゃないでしょうか・・・
即時性業務とPUSH型業務だけかもしれませんね。
だったら、せめてタスクトレイ常駐型にしてほしいものです
スマート
会議室デビュー日: 2004/03/15
投稿数: 9
投稿日時: 2004-05-14 16:38
引用:

zaxx_MDさんの書き込み (2004-05-14 15:48) より:
運用・維持体制をしっかり構築できれば・・・


“してもらう”＝“現在はできない”ということですよね。
なればよいですね。
マイクロソフトさん頑張って下さい！

引用:

zaxx_MDさんの書き込み (2004-05-14 15:48) より:
MS-Officeが中規模以上の業務アプリには適用できない理由は
１．データのアクセス制御・取得範囲制限
２．ロジックの集約定義
３．ユーザ個別のデータ保存
４．セキュリティ
このようなWebチックなデータフローが成り立たない点だと思います。

SOAPクライアントになったとしても、
EXCEL側で全件取得とか走られるとサーバの資源がいくらあっても足りないですし、
EXCEL信者は多次元処理とかレイアウト変更とか平気でやりますからねぇ。


MS-Officeの問題でリッチクライアント全体の問題ではありません。
私はMS-OFFICEでの開発経験は乏しいので良くわかりませんが、
MS-Officeでのリッチクライアントはあまり有効ではないというご意見と認識してよろしいですか？
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2004-05-14 18:28
引用:

“してもらう”＝“現在はできない”ということですよね。

いいえ、システム運用・維持部門の人にお金をかけてしっかり管理すればよいということです。
日本ではCIOとかにあまり権限が無いように感じます。
組織としてちゃんと機能してほしいものです。

引用:

MS-Officeでのリッチクライアントはあまり有効ではないというご意見と認識してよろしいですか？


いいえ。
ユーザはリッチクライアントなんて望んでいません
MS-Officeのような融通の利くアプリケーション
をそのままエンタープライズで使えるのを望んでいます。

じゃあ、我々ができる範囲は何かというと、
即時性業務とPUSH型業務に関しては
ようやくリッチクライアントのような形式でユーザの個々のロジックを
設定できるようになったというわけです。

ネットワークコンピューティングのリッチの方向性がドンドン進んでいけば、
いつかはOfficeをリプレースできるかもしれません。
そのとき我々は別の仕事を探さないといけないかもしれませんね。

[ メッセージ編集済み 編集者: zaxx_MD 編集日時 2004-05-14 18:37 ]
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2004-05-18 10:28
もうイイ？かもしれませんが、関連情報を２点ほど・・・

スマート・クライアントの傾向と対策
―　Webアプリケーションの不満は解消できるのか？　―
http://www.atmarkit.co.jp/fdotnet/special/smartstrtg/smartstrtg_01.html

Notesの運命
http://www.atmarkit.co.jp/news/index.html#notes
http://www.atmarkit.co.jp/news/200405/18/ibmlotus.html

リッチクライアントに関して先駆者だったはずのJava陣営が後塵に拝している気が・・・

話が変わるかもしれませんが、
HTTP+HTMLのようなインフラのブレイクスルーがリッチクライアントには必要だと思うのです。
それがWebServiceだとしたら(jnplのような)共通定義が不足しているのではないでしょうか？
JavaWebStartもeclipseもAutoUpdateやDeploymentを独自仕様でやってますよね・・

[ メッセージ編集済み 編集者: zaxx_MD 編集日時 2004-05-18 10:46 ]
«前のページへ 1|2|3 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）