PART 3
RISING4の技術
RISING4では多様な業務要件に応えるために、マルチテナントに対応するシステム・アーキテクチャやアプリケーション・フレームワークという注目すべき独自の仕組みを導入している。
マルチテナント対応と
High・Lowのセキュリティ
RISING4は、立命館大学の次期事務情報システムの基盤として構築されたが、大学のグローバル化やキャンパス単位の教務運営、さらには他校での利用なども想定して、当初からマルチテナント型で設計された。他校での利用というのは、システム基盤やアプリケーション基盤の共同利用を指す。つまりRISING4は、同一法人内の他校の利用を見据えたシステム基盤でもあるのだ。その意欲的な構想が、システム基盤の構成や「アプリケーション・フレームワーク」と呼ぶ独自の仕組みに反映されている。それがRISING4の大きな特徴である。
図表1は、RISING4を複数のテナント（マルチテナント）が利用するときの運用イメージである。
各テナントは個々に専用アプリケーションを使うが、その専用アプリケーションは後述のアプリケーション・フレームワークにより提供される標準機能や共通コンポーネント、データベースなどのシステム基盤を利用する。ただし、テナントごとのデータの機密性を担保するために、テナント別にライブラリを設け論理的に分割する仕組みを採用している（図表2）。
また、システムを利用するユーザーをセキュリティを考慮して2種類に大別し、それぞれのセキュリティレベルに応じた仕組みを設けているのも特徴である。入学志願者に代表される不特定多数のユーザーがアクセスするアプリケーションやデータは「Lowレベル」、学生や教職員がアクセスするアプリケーションやデータは「Highレベル」で、それぞれが利用できるシステムを論理的に分けている（図表3）。
さらに、「Highレベル」に属する学生が教職員のデータを閲覧・操作したり、教職員が所属学部以外の学生のデータや担当業務とは関わりのないデータにアクセスするのを防ぐために、Db2 for iが備えるRCAC（行および列のアクセス制御：Row and Column Access Control）機能を活用した独自のデータフィルタの実装方式を標準化し実現した。
インターフェースと
業務ロジックの完全分離
RISING4の最も特筆すべき特徴は、アプリケーション・フレームワークに含まれるWeb画面生成機構である。ユーザーがRISING4のWeb画面を操作し、その結果表示される画面の構成や表示形式を規定するものであり、画面を構成する部品や動作を開発するための方法論である。簡単に言えば、フロントエンドのWebインターフェースとバックエンドの業務ロジックを完全に分離するための仕組みだ。
立命館大学では、このアイデアに最初期から終始こだわり続けてきた。その理由を、アプリケーション・フレームワークの発案者である服部陽介氏（情報システム部 情報システム課 課長補佐＝当時。現・課長）は、次のように説明する。
「バックエンドの業務ロジックは一度作ってしまえば、そう頻繁に変わるものではありませんが、フロントエンドのWebインターフェースは、Webブラウザの進化によって大きく変化していきます。また今後デジタルネイティブな学生が増えてくれば、Webインターフェースに対するニーズが高度化していくことも予想されます。そうしたときにRISINGⅢ時代のようにその都度外部へ依頼し対応するのでは、スピードやコスト面で追いつかないという思いが強くありました」
XMLでやり取りし
XSLでWeb表示させる
服部氏のアイデアは、システム内のデータインタフェースにXMLを採用するもので、バックエンド側のサーバーは要求された内容に対してXML形式で処理結果を返し、そのXMLデータにXSL（Extensible Stylesheet Language）を当ててWeb画面に変換し表示させる、というものだった。画面生成用のデータをバックエンド側からXML出力する機能さえ準備できれば、ユーザーからの画面デザインの変更要請に対して、XSLだけで吸収し対応できるという変化に強い仕組みである。
図表4は、服部氏が2013年末頃に描いたWebインターフェースと業務ロジックを完全分離するアイデアの図である。処理要求がアプリケーションサーバー（ビジネスロジック基盤）からデータベース基盤へと送られ、その処理結果がXML形式のレコードセットでアプリケーションサーバーへ返され、Webサーバー（Webフロント基盤）でXSLと合されてWebクライアントで表示される仕組みが描かれている。
図中に「？」とあるのは、WebサーバーからアプリケーションサーバーへのXMLの受け渡し方法や、データベース処理された結果のXMLデータをどのようにアプリケーションサーバーへ送り返すか、まだ不明だったからである。
服部氏は2014年2月に手元にあった環境を使い、このアイデアを検証した。のちに「服部PoC」と呼ばれるもので、「アイデアの実現可能性を確認できました」と服部氏は振り返る。そしてこれが発展し、RISING4の最終形となったのが図表5である。
「システム全体でXMLをベースにデータの受け渡しを行うので、データベースも一時期、XMLデータベースを検討しました。しかし、データの集計処理やEUCツールで抽出する際はSQLのほうが扱いやすい、さらに旧システムからのデータ移行も容易だと判断し、RDB型での設計に決定しました。Db2 for iには、SQLによる問い合わせ結果をXML形式で取得する機能があるので、実現したかったXMLデータへの変換は簡単にクリアできました」（服部氏）
ポイントはXML-Bridge
また、アプリケーションサーバー上のXML-Bridgeは、2014年4～9月の日本IBM／IBMシステムズ・エンジニアリング（ISE）とのシステム基盤の実現方法を検討する「アーキテクチャ策定セッション」のなかで紹介されたものだが、服部氏は「XML-Bridgeの採用がRISING4の一番の肝で、XML-BridgeによってWebインターフェースと業務ロジックを完全に分離するという当初の目標に向かって大きく前進することができました」と話す。
また、プロジェクトの最初期から関わってきたクレオテックの上山哲嗣氏（ICTソリューション部システム事業課 課長）も、「XML-BridgeはRISING4プロジェクトにとって画期的でした」と、次のように語る。
「アプリケーション・フレームワークの実現方法はさまざま考えられましたが、Db2 for iから直接XMLデータを出せることと、XML-Bridgeを使ってデータとXSLとを組み合わせればHTMLを生成できることがわかった時点で、今後になすべきことが大きく展望できました。XML-Bridgeによってデータとマークアップ・デザインを完全分離できる絵を初期段階で描けたことが、アプリケーション・フレームワークの本当のスタート地点だったと考えています」
ただし、その時点のXML-Bridgeは、Web画面の構成要素と定義をフロントエンド側にもたせる仕様であったので、「フロントエンドには何ももたせない」という立命館大学の目標とは異なる点もあった。
「Web画面の構成要素をフロントエンドにもたせず、すべてバックエンド側に配置して処理させることによって、バックエンド側だけでWeb画面開発が行える環境が整います。画面設定と汎用的機能の組み合わせの定義をバックエンド側に送信すれば、それらの要素をセットしたアプリケーションがたちどころに開発できる環境です。バックエンド側の処理で得られたXMLデータを、XSLだけで処理することを目標にしていました」と、服部氏は述べる。
フロントエンドには何も置かず、ほとんどのものをRPGプログラムやデータベースとしてバックエンドに詰め込む。これはIBM iがもつアプリケーション継承性の恩恵を最大限に受けるための工夫でもある。
その後、立命館大学側の要望が叶い、フロントエンド側にXSL以外は何も配置しない機能拡張がXML-Bridgeで行われた。現在のXML-Bridgeの標準機能という。
Web画面の定義情報を
データベースに格納する
アプリケーション・フレームワークのもう1つの特筆すべき特徴は、クライアントから処理要求を発すると、その都度、新規にWeb画面を構成し、処理結果のデータを表示することである。これは、Web画面の定義情報をDb2 for iのテーブルに格納しておき、業務ロジックの処理結果と合わせてその都度引き出し、画面の構成要素を決定するXMLデータとして受け渡すことにより実現している。これにより、プログラムをモノリシックに作り込んだシステムよりも、システム基盤およびアプリケーション基盤としての汎用性が飛躍的に高まる。
アプリケーション・フレームワーク上で動作するプログラムは、共通レイヤ、業務ロジック・レイヤ、テンプレート・レイヤの3つのレイヤで構成される（図表6）。
共通レイヤは、ジョブ制御やセッション制御、トランザクション制御、ロギングなど、システムの最初と最後で共通的に利用される部品である。そして次の業務ロジック・レイヤは、各業務のメインロジックやデータの生成・格納・エラーチェック用の部品を配置するレイヤで、個別の業務案件ごとに開発する。もう1つのテンプレート・レイヤは、ある画面を構成するための部品がどのような順番で表示されるかをまとめた部品（テンプレート）が置かれるレイヤである。
業務プログラムは
3つのレイヤで構成される
オンライン業務では、図表7のようなシーケンスで処理が行われる。1つのレイヤで処理された結果が次のレイヤに受け渡され、最終的に共通レイヤの処理を経て、Web画面に表示される。
Web画面に表示させる要素・動作の部品化とフレームワーク化について、2014年4～9月の「アーキテクチャ策定セッション」のなかでIBM側から示唆されたが（ISEの箕手幸広氏から「画面をコンポーネント分割して、部品を作り込んでいくとよい」との示唆があった）、それを聞いた服部氏は、「やはりそうなのか」と納得したという。将来を視野に入れた汎用的なシステム基盤に合致するアプリケーション開発方法とその構成方法を、「部品化によって実現できないか」と考えていたからである。
部品のカテゴリーとしては、メニュー定義、フォーム定義、コード定義、ボタン定義などがあり、Db2 for iのテーブルに格納されている。それを業務ロジックの処理結果として表示するイメージが図表8である。
RISING4のアプリケーション・フレームワークとして用意した部品数は約100個。「どれを部品化し、どの粒度で部品化すると汎用的な利用が可能になるかは、試行錯誤の連続でした」と、服部氏は言う。
また、「この部品化によって、RISING4の入学システム、学生システムのそれぞれの開発を大規模に並行して進めることができました」と、上山氏は語る。
「RISING4のシステムは機能数が多いので、並行開発にしないとスケジュールに間に合わなくなると考えていました。そこでメインの業務処理からサブルーチンを探し出し、プロシージャだけを切り出して分業で並行開発できるようにしました。これも、プログラムの構成をレイヤに分け、コンポーネントごとに部品化を進めたアプリケーション・フレームワークのメリットです」（上山氏）
Power E880など
IBM i 6台で構成
RISING4は、業務ロジック基盤とデータベース基盤の本番環境と各種テスト環境が稼働するPower E880、データベースのバックアップおよびWebQueryによるデータ分析に利用するPower S824、そしてXML-Bridgeを配置しアプリケーションサーバー／HTTPサーバーとして機能させる4台のPower S814でシステムが構成されている(図表9)。
システム構成の特徴について基盤担当の師井学氏（情報システム部 情報システム課）は以下のように話す。
「RISING4では業務ロジック基盤とデータベース基盤を1つのサーバーに収め、マルチテナントも可能な構成としたので、適切なリソース配分が非常に重要になりました。そのためメモリ、ディスク、CPUなどのシステム資源を最大規模搭載できるPower E880を選定しました。業務ロジック基盤とデータベース基盤を稼働させる本番環境のCPUについては通常6コアとし、ピーク時はテスト環境の余剰資源を割り当てる運用としています。
当初の想定では最大11コアで足りると考えていましたが、実際のピーク時には11コアでも不足し、最大16コアまで割り振る結果となりました。しかし、多くのシステム資源をあらかじめ保持可能なPower E880で構成していたため、想定以上のリソース消費にも柔軟に対応できました。このほかI/O処理を速くするためにSSDも採用しています」
図表10は、RISING4のハードウェア上のアプリケーション・フレームワークで提供される主な機能と、それらを何で対応したかの一覧である。立命館大学による独自開発が多数を占める。RISING4に賭けたプロジェクト・メンバーの意欲、独創性、画期性を如実に示す一覧でもある。
･･･････
PART 1 2013-2015 RISING4の始動
資産継承性の高いソフトウェア基盤と
内製主義を貫く体制確立に向けて
････････
PART 2 2015-2018 RISING4の実現
独自のアプリケーション開発標準と
アプリケーション・フレームワークを構築
････････
INTERVIEW
RISING4のプロジェクトで得た大きな財産が
今後の学園改革の礎となる
田尻 実氏 学校法人立命館 情報システム部 部長
［i Magazine 2018 Winter（2018年11月）掲載］
