Skip to content

Instantly share code, notes, and snippets.

@froop
Last active December 18, 2015 03:29
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save froop/5718677 to your computer and use it in GitHub Desktop.
Save froop/5718677 to your computer and use it in GitHub Desktop.
デスクトップアプリケーションのWeb化提案

デスクトップアプリケーションの Web 化提案

2層アーキテクチャーのクライアント・サーバーシステムである Windows デスクトップアプリケーションを、Web アプリケーション(ブラウザ上で動作するアプリケーション)として再構築することを提案致します。

近年の Web アプリケーションは、デスクトップアプリケーションと遜色のない操作性を持てるようになっています (例: Google Docs, Gmail)。Web 化により、操作性は現状の水準を維持したまま、Web の利点(費用の削減、技術リスクの低減、環境変化への素早い対応など)を取り込むことができます。

Web 技術の現在

従来の Web アプリケーションは、操作性の制限からデスクトップアプリケーションの代替としては不足でした。しかし、近年の技術の進化・成熟により、Web の標準技術のみでも、OS ネイティブと遜色のない操作性を実現することが可能になっています(※)。

新しい技術の登場

新技術の活用で操作性が向上します。

  • 画面表示の更新にページ全体を差し替え ⇒ Ajax により部分更新が可能に
  • クライアント側にデータを保存できない ⇒ HTML5 の LocalStorage により保存が可能に

技術の成熟によるコスト低下

Ajax, HTML5 といった技術が普及して数年が経ち、JavaScript ベースのアプリケーションが一般化したことで、事例が増えてノウハウが蓄積し、実現するコストが下がっています。

  • フレームワークやライブラリの充実
  • 技術を身に付けた開発者の増加
  • ブラウザの仕様や実装の安定

※ Web 標準に十分準拠したブラウザ(モダンブラウザ)が前提。具体的には、Internet Explorer 8 (Windows 7 標準) 以降や Firefox、Chrome、Safari など。

現行システムの問題点と Web 化の利点

現行システムの問題点 Web 化の利点
アプリケーションの配布 各クライアント PC の存在を把握し、インストールを管理する必要がある。新規インストール時だけでなく、バージョンアップ時も必要になる クライアントへのインストールは不要。バージョンアップはサーバー側でアプリケーションを更新するのみ
ユーザー PC の負荷 ユーザーの PC 上にデータを保持し処理しているために負荷が高い データとそれに対する処理はサーバー側に持ち、クライアント側は画面処理に特化することで、クライアントの負荷を軽減できる
クライアント環境 Windows PC に限定される Web ブラウザが動作すれば、OS やデバイス (モバイル端末など) に制限はない
サーバー環境 クライアントを補助するサーバーがない。すべての処理がクライアントに詰め込まれるため、環境が開発・運用に適さず効率が悪い場合がある 制限の少ないサーバー環境で開発・運用できる。開発言語も Web API が開発できれば何でもよい (Java, PHP, Ruby, ASP.NET など)
プラットフォームの将来性 開発言語 (VB, VC++) やミドルウェアが特定ベンダー (Microsoft) に依存し、さらには旧世代の技術であるため、サポートが終わって利用できなくなるリスクがある。開発者の確保も難しくなる 広く普及した業界標準の技術であり、開発者の確保も容易
他システムとの連携 URL リンクによるクライアント側での連携、および、Web API によるサーバー側での連携
ユーザーの利便性 URL による個別画面への直接遷移ができるので、メールや掲示板等による情報共有が容易。また、ブックマークや履歴、タブブラウジングなどのブラウザ機能が活用可能

Web 方式のシステム構成

クライアント PC 上の Web ブラウザ環境で実行される JavaScript プログラムが主体となって、画面を表示します。現行クライアントが担っていたデータ処理の多くは Web/アプリケーションサーバーに分離し、背後のサーバー群との通信もこちらで行います。

クライアントとサーバー間のインターフェイスは Web API (REST) になります。

その他の方式との比較

当資料で提案している方式を、その他の一般的な方式と比較検討します。

現行 Web標準方式 Webブラウザ + プラグイン .NETベースのデスクトップアプリ
2層アーキテクチャー 当資料で提案の方式。HTML + CSS + JavaScript により構築 Adobe Flash, Microsoft Silverlight, Java Applet などのブラウザプラグインをベースに構築 C#, VB.NETなどの後継技術により3層アーキテクチャーとして構築
機能実現の柔軟性 △ Webブラウザのサンドボックスによる制限がある。ローカルファイルに触れないなど △ Web標準方式と同様の制限 ○ OSの機能にフルアクセスできる
アプリケーション配布の容易さ × ○ インストール不要 △ Webブラウザにプラグインをインストールする必要 × クライアントアプリをインストールする必要
プラットフォームの将来性 × ○ HTML5の普及により、これまでFlashが担っていた領域を取り込み拡大傾向 × iOSが非サポートを表明して以後は縮小傾向 △�Microsoftに依存する
クライアント環境の選択肢の多さ × ○ ほとんどのOSとブラウザの組み合わせで可 △ PCではほとんどのOSとブラウザの組み合わせで可。モバイル系OSは非サポートのため不可 × Windowsのみ

Web の制限

Web の原理的に、デスクトップの完全な代替ができない部分は残りますので、回避策が必要になります。

ファイルにアクセスできない

Web ブラウザのサンドボックス(外部から受け取ったプログラムを保護された領域で動作させることによって不正操作を防ぐセキュリティモデル)の制限によるものです。代替として下記の方式が考えられます。

  • データの永続化先を、ローカルのファイルシステムではなく、サーバーや LocalStorage にする
  • ダウンロード/アップロードのダイアログにより、ユーザーに明示的にファイルを選択してもらう

他のプログラムを呼び出せない

サンドボックスの制限です。OS 機能の呼び出しやクライアントプログラム同士の直接的な連携はできません。サーバー経由で連携する必要があります。

CPU やメモリーを多用する処理に時間がかかる

JavaScript はスクリプト言語であるため、重い処理には向きません。クライアント側は画面表示の処理に特化し、重い処理はサーバー側に移す必要があります。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment