3RISING4の技術RISING4では多様な業務要件に応えるために、マルチテナントに対応するシステム・アーキテクチャやアプリケーション・フレームワークという注目すべき独自の仕組みを導入している。マルチテナント対応とHigh・LowのセキュリティRISING4は、立命館大学の次期事務情報システムの基盤として構築されたが、大学のグローバル化やキャンパス単位の教務運営、さらには他校での利用なども想定して、当初からマルチテナント型で設計された。他校での利用というのは、システム基盤やアプリケーション基盤の共同利用を指す。RISING4は、同一法人内の他校の利用を見据えたシステム基盤でもあるのだ。その意欲的な構想が、システム基盤の構成や「アプリケーション・フレームワーク」と呼ぶ独自の仕組みに反映されている。それがRISING4の大きな特徴である。図表1は、RISING4を複数のテナント(マルチテナント)が利用するときの運用イメージである。各テナントは個々に専用アプリケーションを使うが、その専用アプリケーションは後述のアプリケーション・フレームワークにより提供される標準機能や共通コンポーネント、データベースなどのシステム基盤を利用する。テナントごとのデータの機密性を担保するために、テナント別にライブラリを設け論理的に分割する仕組みを採用している(図表2)。システムを利用するユーザーをセキュリティを考慮して2種類に大別し、それぞれのセキュリティレベルに応じた仕組みを設けているのも特徴である。入学志願者に代表される不特定多数のユーザーがアクセスするアプリケーションやデータは「Lowレベル」、学生や教職員がアクセスするアプリケーションやデータは「Highレベル」で、それぞれが利用できるシステムを論理的に分けている(図表3)。Control)機能を活用した独自のデータフィルタの実装方式を標準化し実現した。インターフェースと業務ロジックの完全分離RISING4の最も特筆すべき特徴は、アプリケーション・フレームワークに含まれるWeb画面生成機構である。ユーザーがRISING4のWeb画面を操作し、その結果表示される画面の構成や表示形式を規定するものであり、画面を構成する部品や動作を開発するための方法論である。簡単に言えば、フロントエンドのWebインターフェースとバックエンドの業務ロジックを完全に分離するための仕組みだ。立命館大学では、このアイデアに最初期から終始こだわり続けてきた。現・課長)は、次のように説明する。現・課長)「バックエンドの業務ロジックは一度作ってしまえば、そう頻繁に変わるものではありませんが、フロントエンドのWebインターフェースは、Webブラウザの進化によって大きく変化していきます。今後デジタルネイティブな学生が増えてくれば、Webインターフェースに対するニーズが高度化していくことも予想されます。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型での設計に決定しました。iには、SQLによる問い合わせ結果をXML形式で取得する機能があるので、実現したかったXMLデータへの変換は簡単にクリアできました」(服部氏)ポイントはXML-Bridgeまた、アプリケーションサーバー上のXML-Bridgeは、2014年4~9月の日本IBM/IBMシステムズ・エンジニアリング(ISE)とのシステム基盤の実現方法を検討する「アーキテクチャ策定セッション」のなかで紹介されたものだが、服部氏は「XML-Bridgeの採用がRISING4の一番の肝で、XML-BridgeによってWebインターフェースと業務ロジックを完全に分離するという当初の目標に向かって大きく前進することができました」と話す。課長)も、「XML-BridgeはRISING4プロジェクトにとって画期的でした」と、次のように語る。iから直接XMLデータを出せることと、XML-Bridgeを使ってデータとXSLとを組み合わせればHTMLを生成できることがわかった時点で、今後になすべきことが大きく展望できました。課長ただし、その時点のXML-Bridgeは、Web画面の構成要素と定義をフロントエンド側にもたせる仕様であったので、「フロントエンドには何ももたせない」という立命館大学の目標とは異なる点もあった。「Web画面の構成要素をフロントエンドにもたせず、すべてバックエンド側に配置して処理させることによって、バックエンド側だけでWeb画面開発が行える環境が整います。画面設定と汎用的機能の組み合わせの定義をバックエンド側に送信すれば、それらの要素をセットしたアプリケーションがたちどころに開発できる環境です。バックエンド側の処理で得られたXMLデータを、XSLだけで処理することを目標にしていました」と、服部氏は述べる。フロントエンドには何も置かず、ほとんどのものをRPGプログラムやデータベースとしてバックエンドに詰め込む。iがもつアプリケーション継承性の恩恵を最大限に受けるための工夫でもある。その後、立命館大学側の要望が叶い、フロントエンド側にXSL以外は何も配置しない機能拡張がXML-Bridgeで行われた。現在のXML-Bridgeの標準機能という。Web画面の定義情報をデータベースに格納するアプリケーション・フレームワークのもう1つの特筆すべき特徴は、クライアントから処理要求を発すると、その都度、新規にWeb画面を構成し、処理結果のデータを表示することである。iのテーブルに格納しておき、業務ロジックの処理結果と合わせてその都度引き出し、画面の構成要素を決定するXMLデータとして受け渡すことにより実現している。これにより、プログラムをモノリシックに作り込んだシステムよりも、システム基盤およびアプリケーション基盤としての汎用性が飛躍的に高まる。アプリケーション・フレームワーク上で動作するプログラムは、共通レイヤ、業務ロジック・レイヤ、テンプレート・レイヤの3つのレイヤで構成される(図表6)。共通レイヤは、ジョブ制御やセッション制御、トランザクション制御、ロギングなど、システムの最初と最後で共通的に利用される部品である。次の業務ロジック・レイヤは、各業務のメインロジックやデータの生成・格納・エラーチェック用の部品を配置するレイヤで、個別の業務案件ごとに開発する。1つのテンプレート・レイヤは、ある画面を構成するための部品がどのような順番で表示されるかをまとめた部品(テンプレート)が置かれるレイヤである。業務プログラムは3つのレイヤで構成されるオンライン業務では、図表7のようなシーケンスで処理が行われる。1つのレイヤで処理された結果が次のレイヤに受け渡され、最終的に共通レイヤの処理を経て、Web画面に表示される。Web画面に表示させる要素・動作の部品化とフレームワーク化について、2014年4~9月の「アーキテクチャ策定セッション」のなかでIBM側から示唆されたが(ISEの箕手幸広氏から「画面をコンポーネント分割して、部品を作り込んでいくとよい」との示唆があった)、それを聞いた服部氏は、「やはりそうなのか」と納得したという。将来を視野に入れた汎用的なシステム基盤に合致するアプリケーション開発方法とその構成方法を、「部品化によって実現できないか」と考えていたからである。iのテーブルに格納されている。それを業務ロジックの処理結果として表示するイメージが図表8である。RISING4のアプリケーション・フレームワークとして用意した部品数は約100個。「どれを部品化し、どの粒度で部品化すると汎用的な利用が可能になるかは、試行錯誤の連続でした」と、服部氏は言う。「この部品化によって、RISING4の入学システム、学生システムのそれぞれの開発を大規模に並行して進めることができました」と、上山氏は語る。「RISING4のシステムは機能数が多いので、並行開発にしないとスケジュールに間に合わなくなると考えていました。そこでメインの業務処理からサブルーチンを探し出し、プロシージャだけを切り出して分業で並行開発できるようにしました。S814でシステムが構成されている(図表9)。情報システム課)は以下のように話す。「RISING4では業務ロジック基盤とデータベース基盤を1つのサーバーに収め、マルチテナントも可能な構成としたので、適切なリソース配分が非常に重要になりました。E880を選定しました。業務ロジック基盤とデータベース基盤を稼働させる本番環境のCPUについては通常6コアとし、ピーク時はテスト環境の余剰資源を割り当てる運用としています。当初の想定では最大11コアで足りると考えていましたが、実際のピーク時には11コアでも不足し、最大16コアまで割り振る結果となりました。E880で構成していたため、想定以上のリソース消費にも柔軟に対応できました。図表10は、RISING4のハードウェア上のアプリケーション・フレームワークで提供される主な機能と、それらを何で対応したかの一覧である。立命館大学による独自開発が多数を占める。magazineとは?会社概要CONTACT。