- PR -

ミドルウェアを使用できない環境でのC/S通信の選択肢

1|2 次のページへ»
投稿者投稿内容
Gazelle
会議室デビュー日: 2006/07/28
投稿数: 3
投稿日時: 2006-07-28 21:19
皆様はじめまして。

現在とあるシステムのアーキテクチャ策定を行っております。
おおまかな形としては、ＤＢ、サーバ、クライアントの３層構造を
考えております。
（開発環境としては.Net 2005、言語はC++です）

制限事項として
・クライアントにはなんらミドルウェアをインストールしなくても
動作すること（できればExe＋設定ファイル程度をコピペするだけで動作すること）
があげられています。

サーバ側の機能としては、
・DBの検索、更新
・バイナリファイルの送信、受信、更新
が必要です。
（サーバ側の環境については自由なので.Netを使用予定）

クライアントにDB接続ミドルウェア、JRE、.Net等を
インストールすることは出来ないので
現状考えているC/S通信選択肢としては
・ソケット通信（自前実装）
・Webサービス（ATL＋MFC）
を、通信の内容としては将来の拡張を見据え
XMLを考えています。

生産性の高さからはWebサービスがよいのですが、
ATLクライアントも内部ではMSのXMLパーサを使っているようなので
環境を限定してしまいますし、パフォーマンスに関しても不安があります。
しかし自前実装では工数、バグ等が不安です。。。

このような場合C/S通信はどのような方式をとったらよいのでしょうか？
便利なミドルウェア群を使うことができない状況での設計は初めてなので
非常に悩んでおります。

こんな選択肢がある、こうすればある程度は楽に実装出る等
どの様な情報でも良いのでアドバイスしていただけると助かります。

よろしくお願いします。
囚人
ぬし
会議室デビュー日: 2005/08/13
投稿数: 1019
投稿日時: 2006-07-28 22:10
それだけクライアントに対して制限があるならWebブラウザを使ったらどうでしょうか？それはなし？
_________________
囚人のジレンマな日々
小僧
ぬし
会議室デビュー日: 2002/08/14
投稿数: 526
投稿日時: 2006-07-28 22:25
インタラクティブ性の話が出てきて、メジャーなプラグイン程度はOKという
ことでしたら、Flashをクライアントにしてしまうというのも有りかと思います。
実績の面でハンデはありますが、もう少し待てるようならばFLEX2という手も
有りかと。（教育コストは置いといて・・・）

クライアント環境とか実績などを考えると、やはり囚人さんの言うように
Webブラウザ＋HTMLが良いのではないでしょうか、枯れた技術ですし。
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2006-07-29 00:17
クライアントを VC++2005 で作成すると、msvcr80.dll を配布することが必要になりませんか？
囚人
ぬし
会議室デビュー日: 2005/08/13
投稿数: 1019
投稿日時: 2006-07-29 00:43
>クライアントを VC++2005 で作成すると、msvcr80.dll を配布することが必要になりませんか？

スタティックリンクしたら一応いけるかな。
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2006-07-29 08:24
引用:

ATLクライアントも内部ではMSのXMLパーサを使っているようなので
環境を限定してしまいますし、パフォーマンスに関しても不安があります。


どのくらいの量のデータを扱う予定で、程度の性能が必要なんですか？

パフォーマンスが重要なら

引用:

通信の内容としては将来の拡張を見据え XMLを考えています。


は早々にあきらめるべきです。

逆に拡張性や保守性を重視するなら、XML の採用は妥当と思います。

XML 使う場合、MSXML3 以降はかなり速いです。
同等以上の代替物を探すのはかなり難しいと思います。

SOAP の重さが気になるなら、REST や JSON 辺りを使うもよしです。

引用:

こんな選択肢がある、こうすればある程度は楽に実装出る等
どの様な情報でも良いのでアドバイスしていただけると助かります。


既にコメントがついてますが、Ｗｅｂアプリで組める程度に要件が落とせるなら、Ｗｅｂアプリにしてしまった方がいいでしょうね。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2006-07-29 11:13
私だったらこうするかな、という案ですが、まず、Web サービスのサーバーとクライアントの両方を普通に .NET かなにかで を作って動かし、その通信をパケットキャプチャーします。
本番用に作るクライアントは VB で WinInet.DLL などを使って HTTP が使えるものを作ります(VB でも VC++ でもなんでもいいですが)。WinInet.DLL ぐらいならどんな PC にもインストール済みなのではないかと期待します。VB も VB5 あたりなら同様です(VB6 あたりもいけるかも？ちょっと苦しい？)。
request の送信は、上記で、キャプチャーした電文の一部だけを文字列置換で差し換えるようなことをして作り出します。response の受信も、XML として解釈せず、タグの不等号記号を文字列検索する程度のものを作って使います(正規表現でもいいけど正規表現にはこだわりません)。
Web サービスの XML の構造は、オブジェクトが別のオブジェクトを集約していたりすると、複雑になるので、禁止です。
Gazelle
会議室デビュー日: 2006/07/28
投稿数: 3
投稿日時: 2006-07-29 17:15
皆様返信ありがとうございます。

Webアプリに関して検討はしたのですが、
管理しているデータの印刷、複数の表示モードでの表示、スクロール等の
要件があり厳しいのかと思っております。

表示モードごとの画像を動的に生成してクライアントにHTMLで返す
パフォーマンステストをすべきかもしれませんね。

> インタラクティブ性の話が出てきて、メジャーなプラグイン程度はOKという
> ことでしたら、Flashをクライアントにしてしまうというのも有りかと思います。
> 実績の面でハンデはありますが、もう少し待てるようならばFLEX2という手も
> 有りかと。（教育コストは置いといて・・・）
Flashはいいですね。検討してみます。
採用するのであればPMをコスト面で説得しなければ(^_^;

msvcr80.dllは、スタティックリンクにてNTへ単一のExeを配置して
動作確認済みです。MSXMLはIE4以降が入っていればいけそうな
雰囲気でした。

> パフォーマンスが重要なら
通信の内容としては将来の拡張を見据え XMLを考えています。
> は早々にあきらめるべきです。
やはりそうですよね。
扱うデータ件数は最大で５０万件、
検索結果はページング処理して、５０００件程度を返す予定です。

データ内容は頻繁に変わってしまうらしく、
今のところXML以外である程度簡単に実現できる方法が
思いついていないのが実情です。

実際XercesやOracle XDK等も試してみましたが、確かに
DOMで処理すると重いようでした。
結局これもパフォーマンステストを実施してみる、
という形ですかね。。。

> SOAP の重さが気になるなら、REST や JSON 辺りを使うもよしです。
これは知らないものでした。調べてみますね。

unibonさんに頂いた意見は、SOAP処理を文字列置換イメージの
自前実装するということでしょうか？
なるほど、それなら確かにミドルウェアは必要ないかもしれませんね。

なんだかかなり厳しいプロジェクトのような気がしてきました。
むぅ。。。
1|2 次のページへ»

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