既存システムという制約とアーキテクチャ――どうつなぎ、うまく再利用するか：戦う現場に贈る分散システム構築−開発現場編（10）（2/3 ページ）

[岩崎浩文，楽天株式会社]

既存システムという「厄介者」

　SOAなどに代表されるシステム連携作業において、最も難度が高いのが既存システムの調査とその対処である。連携して活用する以上、既存システムがどのように動いているのかを知り、それを踏まえてどう対処すべきなのかを設計する必要がある。

　ところがこの既存システムの調査が厄介である。「資料が残っていない」「構築に携わった人間がすでにいない」「ソースコードが残っていない」「技術が古すぎて技術者を確保できない」などの問題が山積みになる場合も多いだろう。近年では日本版SOX法への対応で管理不能なシステムの淘汰が進んでいると思われるが、まだまだ改修が可能な程度の高精度な資料が散逸して手が付けられないケースもあるかもしれない。

　特に今回の豆成くんの例にもあったように、旧来のホスト系システムが動き続けているものの改修が難しいというケースは典型例である。潤沢な投資と時間が確保できる場合であれば、システム連携などという複雑な構成を採らずにイチから1つのシステムとして再構築してしまえばよい。しかし増える一方のシステム投資が抑制・削減傾向にあることが、こうしたシステム連携による既存システムの再利用を後押ししているのだ。ここが技術者の望む美しい世界と複雑な現実世界との壁である。これをどう乗り越えるのか。

既存システムを素直に再利用できない一枚岩のアーキテクチャ

　仮に資料が残っている場合であっても再利用が容易でない場合がある。純粋なデータ処理と、画面表示の処理が一緒くたになって実装されている場合である。

　例えば、あるデータを演算して更新し、結果を返す機能があったとしよう。その処理を行っている関数（メソッドなど）の中では、データを更新する処理と結果画面を丸ごと構築する処理とが混ぜて記述してあるとする。この機能を外部APIとして公開し、ほかの機能からデータ更新処理のみを使いたい場合、結果画面を返す処理が邪魔になってくる。

　分かりづらいので具体的な例を挙げよう。COBOLなどで記載されているホスト系のシステムの場合、端末画面への出力処理をデータ演算や更新処理などと一緒に扱っていることが多々ある。近年のJava EEで構築されたシステムであっても、JSPの中に直接データ更新処理が書いてある場合、あるいはStrutsなどを利用してActionクラス相当の中でデータベース処理とセッション処理、出力処理を混ぜて書いてある場合がある。これを外部から呼び出そうとすると、データ処理だけを行いたいのに余計な画面処理が存在するために正常に動作しないか、もしくは生の画面データが返ってきてしまう。

　機能の再利用を前提としたアーキテクチャが採用されている場合、画面処理とデータ処理（ビジネスロジック）を分離した層構成となっており、SOAPなどを通じて機能の再利用が容易に行えるように作られている。だが、そこまでの先を見越した対策が採られていない、再利用が極めて困難な一枚岩（モノリシック）の構成となっている場合には画面処理との分離作業が必要となり、それが不可能な場合には出力画面情報を丸ごと取ってきて強引にデータ部分だけを抜き出すといった厄介な対処を施さねばならない。

図1　再利用できない既存システムと再利用できる既存システム

既存システムだけでは要件を満たせない場合

　仮に既存システムに対して、うまく外部API相当のものを準備できたとしよう。それらの外部APIだけですべての変更要件を満たせれば次のステップに進めるが、そうしたことはまれだろう。新たな要件が加わったり、業務そのものが変更されたりして、処理そのものを修正しなければならない場合があるからだ。

　この場合の選択肢として考えられるのが「該当機能に直接手を入れて修正する」、あるいは「該当機能を包む機能を別に用意し、内部で該当機能を呼び出して変更に対処する」などだろう。後者は書籍『オブジェクト指向における再利用のためのデザインパターン』におけるラッパーパターンなどで知られる方法である。

参考図書
『オブジェクト指向における再利用のためのデザインパターン〈改訂版〉』 エリック・ガンマ、ラルフ・ジョンソン、リチャード・ヘルム、ジョン・ブリシディース＝著／本位田真一、吉田和樹＝監訳／ソフトバンクパブリッシング／1999年11月

　このラッパーを実装する場所は同一既存システム内でもよいが、外部の新規システムを用意してそこで実装するという方法も考えられる。特に既存システムが旧式で機能の増設がさまざまな理由で難しい場合に採用されるケースだ。別システムで対処する場合、通信コストが発生するためにパフォーマンス劣化を気にしなければならないが、現代の洗練された言語やプラットフォームの恩恵を受けることができる利点もある。

　このときに気を付けるべきは、データのトランザクションの観点だ。複数システムにまたがった更新処理を行う際にはオンライン型で分散トランザクション処理を行うか、それが不可能であれば補償トランザクション処理を備えなければ、理論的にデータ構造が壊れてしまう（これらについては多分にテクニカルな内容となるため本稿ではこれ以上触れない）。この観点は主に非機能要件としてまとめられる内容となるため、いずれにせよそれに従ったアーキテクチャとする必要があるだろう。