Webシステムの操作性、レスポンスを低コストで改善 │ Visual WAO │ 株式会社チェプロ

担当者に課せられるテーマは
ビジネスに「貢献」をするWebシステムの開発

C/Sシステムの問題点であった、クライアント管理の撤廃。情報の一元化や、リアルタイム性の確保。セキュア―なデーターセンターへサーバーを移行するBPC対策、クラウド基盤の活用等、企業の経営陣やシステム部門からのWebシステムのニーズは高まる一方です。

また、間接部門に加え、直接部門においても、ITリテラシーが高まり、社内外のどこからでも企業システムへ迅速にアクセスし、情報を業務に活用する動きが進んできています。このように、今後、企業のWebシステムの普及はますます加速していくと考えられています。

「Webシステム開発」における課題とは?

Webシステムを開発するのはいくつかの問題点があります。
中でも特に問題点となってくるのが操作性とレスポンススピードです。

Webはもともとテキストの表現に用いられることを意図した技術で、ボタンや入力用テキスト・ボックスなどといったGUI部品を扱えるようになりブラウザでアプリケーションの実行を可能にしたのがWebシステムです。このためWebシステムの欠点はUIにHTMLの制約（UIがHTMLコンポーネントに制限される）を受けることです。テキスト重視のアプリケーションには適していて、特にテキストの書式化が必要なアプリケーションには向いています。

一方で、Webシステムは、Windowsフォームアプリケーションのような業務システムとして操作性に優れたUIの実現が困難です。例えば、連続入力処理を行うWindowsフォームアプリケーションでは、Enterキーを押すことで入力フォーカスが次のコントロールに自動的に移動し入力の生産性を高めることができますが、これを一般的なWebアプリケーションで似たように実現するのは容易ではなく、開発には工夫と時間を要します。

フォーカスの遷移と同期した入力チェックや入力補完、CtrlやAlt、Shiftなどの修飾キーやファンクション・キーの活用、編集可能な表、タブによる1画面内の表示切り替え、周辺機器との連動、といったWindowsフォームアプリケーションでは簡単に実現できる事柄のほとんどが、通常のWebアプリケーションでは簡単には実現しません。

Webシステムのもう一つの欠点がレスポンス速度です。
これは、クライアントサーバシステム（C/Sシステム）では、クライアント側の画面の「項目単位」にクライアントとサーバー間の情報交換を行っていたのに対し、ブラウザでは、一般的にクライアント側の「画面単位」となるためです。そのためWebシステム開発においては、レスポンスについても工夫と時間を費やすことになります。

Webシステムの操作性、レスポンスを改善するための選択肢は？

従来のWebシステムの問題点を解決するためにでてきたのがリッチクライアント技術です。
Ajax、特殊言語や特殊ブラウザを使いWebシステムを開発すると、リッチなUIが可能になり操作性を改善できます。レスポンスもクライアントにキャッシュを置く等の工夫により従来にWebシステムと比較すると高速化できますが、次のような課題が何かしら発生します。

「リッチクライアント技術」による開発の問題点

リッチクライアント技術による開発を行う場合は、操作性やレスポンスが改善する一方で以下のような課題が生じてしまいます。トレードオフなしに、レスポンススピードと操作性に優れたWebシステムを高い生産性で開発する選択肢は無いのでしょうか？

特殊な言語、新しい開発手法を習得する必要がある
クロスブラウザ問題（ブラウザの種類、バージョンに影響を受ける）
操作性とレスポンススピードのトレードオフ（操作性に重点をおくと、処理が重くなりレスポンススピードが落ちる）
クライアントにプラグインをインストールする必要がある

「Visual WAO」という選択肢

リッチクライアント技術が、Webブラウザを前提として、ブラウザに起因する問題点を改善するのに対し、Visual WAOは全く違ったアプローチで「Webシステム」を実現します。

業務用システム向けの優れたUIを高い生産性で開発ができるWindowsフォームを用います。
ただし、通常、Windowフォームを使ったC/Sシステムの開発では、Visual Studio上に1つのプロジェクトファイルを作るのに対し、クライアント側、サーバー側の2つのプロジェクトファイルを用意し3層構造のアプリケーション（クライアント、アプリケーションサーバー、DBサーバー）を開発します。クライアント側には画面、サーバー側にはビジネスロジックのプログラムを置きます。

3層のWindowsフォームアプリケーションができると、次は、無料でご利用いただけるVisual WAOの「開発ツール」を使って、Visual WAO のDLLを自動生成します。クライアント側とアプリケーションサーバー側のプログラムにVisual WAO関数を追記し、クライアント側プロジェクトとサーバー側プロジェクトにVisual WAOの DLLを配置します。するとVisual WAO のDLLがインターネット環境で通信I/Fモジュールとして働き「Windowsフォームアプリケーション」をインターネット環境で実行することが可能になります。

「Visual WAO」で開発する場合のメリット

生産性の高い「Windowsフォーム」で開発できる

Windowsフォームを使った画面デザインは高い生産性が得られます。Windowsフォームすべての機能をWebアプリケーションとして実現できるため、HTMLタグ内スタイル要素やCSSなどを意識する必要はありません。コーディング手法もWindowsフォームと同じです。ブラウザを使用せず、イベントハンドラにVB（Visual Basic)やC#で処理を記述するイベント駆動型です。ASP.NET Webフォームのようにクライアント側の動作をJavaScriptで記述する必要もありません。

Windowsフォームがそのまま「同期型」のWebシステムとして動作

Visual WAOは、開発時、Windowsフォームを使い、C/Sアプリケーション開発時のWindowsフォームの開発とまったく同じ手法で開発できますが、実行時もWindowsフォームをそのままWeb上で動作させることができるためブラウザのWebシステム特有の「戻る」ボタンによる様々な対処をする必要はありません。また、一般的なWebシステムは非同期型のため、クライアント側で問題が発生してもサーバー側ですぐに対処ができず、これを考慮するロジックを設計しなければなりません。Visual WAOは、同期型のWebアプリケーションを実現していますので、非同期を考慮したロジック設計も必要ありません。

Webサービス（IIS）が不要

Visual WAOで開発したWebアプリケーションは、Visual WAO DLLに独自のサービスを持っているため、Webサーバー（IIS）は必要ありません。JSPサーブレットのようなサーバー側の専用モジュールなども不要で、大きなメモリ空間を用意する必要がありません。さらに、純粋なWindowsフォームがWebシステムとして動作するので、ASP.NETのオブジェクトも使用しません。

Visual WAOを使用して3層化アプリケーションを開発すれば、サーバーとクライアントの役割を明確にする事ができます。例えば、サーバーはアプリケーションの状態管理とビジネスロジックの実行を担当。処理したデータはバイナリ形式でクライアント側の１フィールド単位に返す事が可能です。一般的なWebアプリケーションのようにサーバー側からHTML及びXMLデータを受け取る必要がなく、クライアントとサーバー間の通信は必要最小限のバイナリデータとなり軽快で快適な動作をユーザーに提供できます。

ブラウザを使用しないため、通信データ量を大幅に削減

クライアント側にインストールは不要

クライアント側には、Visual WAOのDLLと画面部品をダウンロードして配置するだけでインストールをする必要はありません。Visual WAOのDLLまたはアプリケーションの画面部品を改定した場合は、クライアント側からアプリケーションサーバーへアクセスする際に、最新のモジュール差異を確認し、自動的にクライアント側のモジュールを刷新します。よってクライアント側の管理は一切不要です。またSilverlightやFlashのようなプラグイン関係をインストールする必要もありませんし、ブラウザのバージョンアップ（自動更新）による影響もありません。