クライアント/サーバモデルからRIAへ移行するタイミングと判断

アーキテクチャを変えると、リスク対応は向上するが、操作性が変わってしまう。だが、このタイミングをおいてほかに、システム変更に踏み切るチャンスは少なかったと飯田氏は語る

RTGSや次世代RTGSに対応した管理アプリケーションを提供している企業のひとつに電通国際情報サービス(ISID)がある。同社は「流動性管理システム」と呼ばれるシステムを提供している。このシステム、日銀がRTGSの取り組みを開始した当初は、Delphiベースで開発されたUIを使ったクライアント/サーバモデだった。しかし次世代RTGSに対応するにあたって、Flash/Flexを活用したRIAシステムに変更されている。

クライアント/サーバモデルからRIAへ移行した理由として、ISID 金融ソリューション事業部 金融事業企画部長 飯田哲夫氏は次の理由を挙げている。

  • クライアントモジュールのアップデートといったメンテナンス性を削減したかった。従来の方式ではサーバとクライアントの双方をアップデートする必要があり、すべてのクライアントをアップデートするのは大変な作業だった
  • 採用していた技術の将来性を検討し、別の技術を採用するタイミングと判断した
  • クライアント/サーバモデルを採用しなくとも、RIAで同じことを実現できるほどまでにRIA技術が成熟していた

2006年ごろにはアーキテクチャを決定し、1年ほどかけて開発を実施した。最終的に、AIXをベースにアプリケーションサーバとSeasarを稼働させ、SOAコンポーネントとして流動性管理システムを実装。データベースにはOracleを採用するなど堅固な作りになっている。

顧客の要望は「UIを変更しないで!!」

RTGSから次世代RTGSへの拡張にともない、顧客にシステムのアップグレードを通知すると、「とにかくユーザインタフェース(UI)を変えないでほしい」という要望を数多くもらったという。顧客にとっては、アーキテクチャの変更そのものも懸念事項ではあるのだが、UIが変わってしまうのはとにかく困るのだ。バックオフィスの手堅い業務においては、派手なUIは必要ない。使い慣れた画面が出てこなけらば仕事にならないのである。

さて、そうなると、クライアント/サーバモデルのときと同じUIをFlash/Flexで実現できるかどうかが、技術採用の検討事項となる。調査の結果、「当時のFlexで十分実現できるということがわかった」(飯田氏)ため、採用に踏みきったという。「実際には、最後まで"アーキテクチャを変えてほしくない"と主張し続けた顧客もいたが、こうしたシステムは中長期に渡って使われるため、こういうタイミングを逃してしまうと、より優れたアーキテクチャへの刷新が実現できない」(飯田氏)とし、思い切って変更を実施したという。

極力、UIの使用感を変更せず、Flex Builderで開発したRIAベースの流動性管理システム 決済データ管理画面

使えるコンポーネントは使う、開発を迅速に進めるために

開発の途中、Adobe LiveCycle Data Servicesを使いたいと開発者から要望が上がってきたという。流動性管理システムのサーバからRIAクライアントへと、リアルタイムにデータを配信する必要があるわけだが、この部分をイチから開発していては間に合わないことがわかった。レガシーマイグレーションという案件であり、画面は全部作り直しになる。工数的にかなり大変だったため、部品として使えるものは使いたいという、開発側の切実な願望だった。

Adobe LiveCycle Data Servicesは、AdobeがFlashの動画配信で培った技術とプロトコルが投入されたプロダクト。今回の事例のようにリアルタイムでの確実なデータコミュニケーションを求められる場合には最適なソリューションというわけだ。最終的に予定期間どおりで開発は完了したが、「該当部分にLiveCycle Data Servicesを採用せずに自社開発していたらどうなっていたか…と想像すると冷や汗が出る」と飯田氏は当時を回顧する。

次世代RTGSへ対応した流動性管理システムで、UIにFlash/Flexが採用されたこと、すでに同システムを導入した金融機関で活用されていること、従来のクライアント/サーバモデルの置き換えとして満足に機能していること、バックオフィスの堅牢な業務にも適用できていること……同事例がRIA採用について物語っている部分は興味深いところが多い。

システム構成の概略図。開発者がAdobe LiveCycle Data Servicesを望んだのはそのメッセージング機能からだ。大量の更新情報をリアルタイムかつ正確に通知するためには同機能が欠かせなかったという