Ajax/Railsを用いた大規模

シミュレーションコードのWeb化

江本雅彦＠核融合科学研究所

共同研究のための環境整備

共同研究者の為の基盤整備

共同研究者が、遠隔地からLHD実験に参加しやすいように、環境整備を進めてきた。

計算サーバ

データーベース

生データ表示

基本設計

対象ユーザ = 短期滞在の共同研究者 LHDの実験システムを常時使用していないため、データの参照の方法や、解析ツールの使い方に不慣れ

必須項目 ユーザーフレンドリーなGUIの提供

状況に応じたメニュー表示で直感的に必要なデータを入力することができる。

インストールが不要 短期滞在者には、インストールする手間も惜しい。

メンテナンスが容易

WEBアプリケーション

WEBブラウザは今日のOSでは、基本的なアプリケーションであり、個別にインストールする必要がない。

ソフトウェアはWEBサーバ上に置いてあり、接続の度にダウンロードされるため、インストールに必要がなく、バグフィックスやバージョンアップに伴うアプリケーションの再配布が必要ない。

公開中のWEBサービス

解析データ取得・表示 (Java アプレット)

長時間リアルタイム表示 (Javaアプレット)

制御室大画面表示 (Java アプレット)

磁気面可視化 ( HTML + FORTRAN(CGI) )

実験データ検索 (PHP + JavaScript)

生データ表示 (Ruby on Rails + FORTRAN )

磁気面計算(Ruby on Rails + FORTRAN )

シミュレーションコードのWEBインタフェイスの開発

既存のシミュレーションコード

多くが大型計算機で動作するFORTRANコードであるため、普段GUIベースのOSを使っている人には使い辛い

実験データから必要な入力形式への変換が必要

（PC用のコードの場合）各自の環境で実行されることを前提に作られており、他の環境や不特定多数の人が同時に実行されることを考慮されていない。

↓

WEB化によりユーザビリティを向上させ、多くの研究者に使ってもらう。

比較

Java アプレット HTML +

CGI

JavaScript

+ α

ブラウザ以外に必要なソフトウェア

JVM なし なし

柔軟性 高 高 低

ダウンロードファイルサイズ 大 最小 小

プラットフォーム間の互換性 中 高 中

GUIの操作性 高 低 中

各WEBアプリケーションの特徴

Javaアプレット

クライアント側で複雑な処理を必要とする場合

HTTP以外のプロトコルを必要とする場合

HTML+ CGI

処理の大部分はサーバで行う。

HTMLの提供するGUI(フォーム)のみのため、高度なGUIアプリケーションを作成するには向いていない。

JavaScript + α

軽量アプリケーション(クライアント側では、比較的単純な処理)

主たる処理はサーバ側で行い、よりインタラクティブな処理を提供する。

シミュレーションコードのGUIインタフェイス

FITコード（デポジション計算）のWEB化

計算は既存のFORTRANコードを利用

GUIにはRuby on Railsを利用し、インタラクティブに必要なパラメタを入力できるようにする。

大型計算機とはSSHでコマンドを発行

中間ファイル、計算結果等はデータベースにRubyのオブジェクトを永続化

WEB

browserRuby on

Rails

FORTRAN

Code

RDB

HTTP

SSH

SFTP

Persistent

Object

Object

LighttpdFast CGI

SX-8

GFS

Job

Control

Web Server

(Linux)

Gateway

Server

(Linux)

Client

HTTP

AJAX

HTTP

HTTPはSynchronous （同期）で呼び出されるため、CGIを使った旧来のWEBアプリケーションでは、サーバから結果を取得するまで待ち合わせる必要があり、スムーズな画面書き換えを行うユーザインタフェイスを実現の障害となっていた。

AJAX

Google map

WEBブラウザだけで、地図の滑らかな移動・拡大を行うことができる。

Asynchronous JavaScript + XML

それ以前の既存に技術の組み合わせであるが、AJAXという名前をつけられて紹介されたことで注目を浴びる。

一般に使用されているWEBブラウザの標準機能だけで、滑らかなユーザインタフェイスを実現

JavaScript の問題点

HTMLのコード（表現)とJavaScriptのコード(ロジック)が混在し、ソースコードが読み辛く、開発・メンテナンスが難しい。

クライアント・サーバ間のデータ送受信には定まった方法がないため、複雑なデータの受け渡しにはプログラマが責任を持つ必要がある。

Ruby on Rails

Rubyを用いたアプリケーションフレームワーク

CGIはRubyのメソッドとして実装されている

Webのページは動的に生成される

MVCアーキテクチャ

JavaScriptをラッピング

ActiveRecord によるデータベース操作の抽象化

CoC

Convention over Configuration = 設定よりも規約

Ruby on Rails が提供する名前の規則に沿うことで、個別の設定をしなくてもデフォルトの動作でプログラムを記述することができ、大幅にコード量を減らすことができる。

テーブルやクラスのネーミングルール等

テーブル名：クラス名の複数形 (Cars, Trains, etc.)

DRY

Do not Repeat Yourself = 同じことの繰り返しを避ける

Ruby on Rails のAcriveDirectory では、クラス定義をSQLのスキーマから動的に取得するため、データベース、クラスのそれぞれで定義する必要がない。

Using AJAX by Ruby on Rails

AJAXの実現に必要なJavaScriptのコード(Protocol.js)はRubyのメソッドでラッピングされているため、JavaScriptのコードを（基本的には）一切書かずに、AJAXを実現することが可能である。

AcriveRecord

リレーショナルデータベース上のテーブルとクラスのマッピングが自動的に行われるため、変換のためのコードを書く必要がない。

テーブル間のリレーション、検索キュエリが抽象化され、Rubyのメソッドとして実現されている。

実現するためには、Ruby on Railsのネーミングルールに沿った名前付けが必要

Ruby の Class : Car, Train

テーブル名 (Class の複数形) : Cars, Trains

問題点

リクエスト毎にコネクションが張られるため、同一クライアントからのリクエストに対しても、初期化処理が行われる。

解析データのようにデータの取得、ファイルの解析が毎回行われる。

↓

Marshal.dump / load による永続化

まとめ

共同研究者の利便性を高めるため、WEBを利用したアプリケーションを開発中である。

AJAXは、軽量かつインタラクティブなアプリケーションの作成に向いている。

JavaScriptを直接使用したアプリケーション開発は困難であるが、Ruby on Railsを利用することで、開発効率が大幅に向上する。