- PR -

リッチクライアントにおける設計について

1
投稿者投稿内容
彷徨える開発者
常連さん
会議室デビュー日: 2004/07/15
投稿数: 31
投稿日時: 2004-07-15 23:54
初登場で、ディープな質問ですが

１年半ほど前からEJBを使用したWebアプリケーションの開発に携わってきました
Windowsで作られたC/Sの既存のシステムのリニューアルだったんですが、開発当初から
ブラウザのGUIの表現力の貧弱さに悩まされていました。ことある毎にユーザからは
「既存のシステムでできていたGUIができない」と言われ続けていました。(今でも)

そんなこんなで、次期は是非リッチクライアントで開発しようかと考えています。

リッチクライアント製品にもいろいろあって、資料を調べているのですが、EJBと
組み合わせているケースが多いようです。

Webアプリケーションにおいては、クライアント側でセッションの維持ができない
のでサーバ側でセッションの管理をしていたのですが、リッチクライアントに
なると、画面遷移はクライアント側の分担で、DBアクセスなど必要に応じて
サーバ側にアクセスすることになるので、サーバ側のセッション管理は不要なの
ではないかと思うのです。

そうなると、クライアント側とサーバ側の機能分担はどうなるのでしょうか？

リッチクライアントの製品紹介の資料はあってもこの辺の資料はなかなか見あたり
ません。

今のところ、リッチクライアントの製品の候補としてcurl、Nexaweb、Eclipse、
Biz/Browserを考えています
ASA
会議室デビュー日: 2004/05/27
投稿数: 6
投稿日時: 2004-07-16 10:53
こんにちは。

私も今リッチクライアント（Biz/Browser）の検証を行っています。

現在の方針としては、Biz/Browser側ではロジックなどを極力実装せず、単純にブラウザの代わりとして使用しているので、サーバーサイドのEJBやセッション管理機能を使っています。

サーバーのセッション管理機能を使わない場合は全てのステート情報をクライアント側に保持する必要がでてきますが、Javaに比べて貧弱なCRS言語（Biz/Browser用専用言語）でステート情報に対して様々な処理をするのはかなりつらい気がします。

では。

彷徨える開発者
常連さん
会議室デビュー日: 2004/07/15
投稿数: 31
投稿日時: 2004-07-16 12:23
引用:

私も今リッチクライアント（Biz/Browser）の検証を行っています。

現在の方針としては、Biz/Browser側ではロジックなどを極力実装せず、単純にブラウザの代わりとして使用しているので、サーバーサイドのEJBやセッション管理機能を使っています。

サーバーのセッション管理機能を使わない場合は全てのステート情報をクライアント側に保持する必要がでてきますが、Javaに比べて貧弱なCRS言語（Biz/Browser用専用言語）でステート情報に対して様々な処理をするのはかなりつらい気がします。


返信ありがとうございます
各リッチクライント製品のこの辺の話を色々聞きたかったんです。

そうですか、Bizの場合はクライアント側でのセッション維持はつらいですか・・・

自分が今思い描いているのは、クライアント側でセッションの維持と画面遷移の
制御を行い、クライアント側からはDBからデータを取得/更新する場合のみ
サーバにアクセスが発生するのかな、と・・・

これじゃ一昔前のODBCやSQL*Netを使ったC/Sと何も変わらないんじゃ・・・と
思えますがサーバ側はEJBの部品を組み合わせて、処理の単位を形成し、
クライアント側はそれを呼び出す・・・てな感じ。

だから、サーバ側はほとんどStateless　SessionBeanがEntityBeanをラップ
するような形になるのかな？と思っていますがどうなんでしょう？

他のリッチクライアントの開発経験者の方の意見も聞いて見たいです。
よろしくおねがいします
ASA
会議室デビュー日: 2004/05/27
投稿数: 6
投稿日時: 2004-07-16 13:06
こんにちは。ASAです。

引用:

自分が今思い描いているのは、クライアント側でセッションの維持と画面遷移の
制御を行い、クライアント側からはDBからデータを取得/更新する場合のみ
サーバにアクセスが発生するのかな、と・・・


確かにそれも可能だと思いますが、クライアント側で維持しているデータ（ステート）に対して、データ更新できる直前までBizのCRS言語で操作するのはちょっとつらいかな？と。

CRS言語はJavaScript互換で宣言した変数の型がないので、実際動かしてみないと構文エラーがあるかわからなかったり、エラーメッセージが不親切で意味不明だったりしますので。

でも、このあたりがしっかりしていればクライアント側でゴリゴリ処理するもの一案かと思います。その場合、BizならWebサービスを呼び出す形で実装するのがよいような気がします。

では。



とし５１
会議室デビュー日: 2004/06/25
投稿数: 6
投稿日時: 2004-07-16 17:40
こんにちは。

私は、今回のプロジェクトでCurlを導入することになりました。
実際に作りこみを行うわけでないのであまり詳しいことはわかりませんが、
参考になればなによりです。

クライアントとサーバー側の機能分担ですが、
基本的には、クライアント側は、画面遷移やセッションの維持などを行い
データの保持ができるようです。
（自分のローカルにもパーシスタンスデータといってデータを保持するこ
とができるようです。→マスタデータなんか変動しないものを保持する
のにはいいかと。。）
サーバー側は、データの取得や更新なんかを行う部分です。
ただ、今まで複数の画面にまたいでいた処理（検索→一覧→登録・更新・削除
・詳細）が１つの画面（ポータル）で済んでしまうことが多いんであんまり、
ステートかどうかなんかは考慮しなくていいかもしれませんね。

ただ、実際はクライアント側に処理を集約したいのはやまやまですが、実際
ソース管理（バージョンなど）などのことを考えるとクライアント側にあま
りロジックを集約するのは恐いですね。（設計次第なんでしょうけど）
1

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