初めての人は「(序)」から読んでね☆

ミドルウェアをどうするか

実は、かなり後まで(と言っても初期なんだけど)、あまりミドルウェアに力を入れるつもりはなかった。というのは、ミドルウェアに力を入れ過ぎることは、アプリケーション開発のプロジェクトでは、邪魔になることが多いからだ。

特にこのプロジェクトのように、「とにかく成果らしいものを早く出す」ことが求められていると、ミドルウェアをゆっくり設計して… というのは、むしろ邪魔だからだ。なので、「とりあえずのデモ」の時には、私のミドルウェアは一切使っていない。デモが成功すれば、本格的な開発に入れるから、そのための用意として開発は始めていたが、それにしてもあまり複雑なものを作るつもりはなかった。

通常、ミドルウェアを新しくすると、アプリケーションは書き換えになる。また、ミドルウェアのAPI設計がちゃんとしていないと、アプリケーション開発の不安要素になるので、このあたりは本当はちゃんとしておかないといけない。幸いなことに、アプリケーション開発の連中は昔の職場で外注で働いていたり、元の同僚だったりしたこともあって、「その当時」の私のアプリケーションプラットフォームを知っている。なので、それを使うことにした。もちろんその時点ではまだ陰も形もないものではあるけれど、仕様は存在していたしそれは十分枯れていたので、仕様説明は、

某「プラットフォームはあれですか」
私「そうだ」

という、たった一言の会話で済んでしまった。もっとも、その時点では「あれ」はないのであるが、「あれ」を使うつもりでプログラム設計をするということになった。

「あれ」

「あれ」というのは、私が昔の会社に勤めている時に使っていた、富士通AIM DB/DCのラッパになるミドルウェアだ。元々、「画面単位でREAD/WRITE」を基本としたトランザクションモニタであるAIMを、イベントドリブンにアプリケーションが開発出来るようにしたもので、オリジナルのコードは富士通名古屋支店の人が作ったものだ。新人の頃の私はそのプロジェクトで名古屋テレビの放送システムを作っていた。

READ/WRITEを基本とした処理だとどうもコードが汚くなりがちなのだが、イベントドリブンにしてしまうと論理もすっきりと書きやすい。そういったメリットもあったので、当時の上司が「輸入」して、いろんなプロジェクトに使っていた。当時の私は主にメインフレームの開発だったのだが、その後オフコンでのシステム開発をするようになった時に、「あれ」は移植され、さらに他の環境にも移植され… ということで、私が業務で主にCOBOLでの開発をやっていた頃は重宝に使っていたものだ。

途中、著作権の問題で一度コードはクリアされてしまっているし、別のプラットフォームに移植する時もほぼ書き直しになっているため、コードそのものの継承関係は全くなかったのだが、APIやアーキテクチャは同じままでずっと持ち歩いていた。とは言え、ORCAのプロジェクトが始まった時点ではそのコードはない(某社を始めた頃はいくら何でもそんなものが意味を持つとは思ってなかった)ので、記憶に頼って作ることになる。でもまぁ「あれ」のインターフェイスで作れるというのは、アプリケーション開発の連中にとっては有難かったはずだ。

「あれ」on dotCOBOL

その当時、それ程複雑なミドルウェアにするつもりはなかった。そもそものターゲットが「内科の開業医」なので、端末もせいぜい2台もあれば十分だ。だから、凄く高度なトランザクション管理が必要でもないし、高負荷に耐える必要もない。だから、当初のデザインでは

端末を起動する毎にアプリケーションを起動する

という、ごく普通のことを思っていた。その程度であれば、イベントドリブン云々のところは、ほとんどの処理が画面インターフェイスの操作になるし、データベースアクセスに関しては、定型的なことで済む。だから、「ミドルウェア」とは言うものの、単なる「アプリケーション呼び出しフレームワーク」で良いはずだった。

またその場合、C <-> dot COBOLのインターフェイスをどうするかという問題があったのだが、いろいろ実験をしてなんとか使えるものが出来た。なので、ほとんどのコードはCで書き、dot COBOLのアプリケーションモジュールをCALLする部分だけをdot COBOLで書くことに。

とりあえずテストプログラムがちゃんと動くようになったので、これでいいと満足していた。これ以上の工数をかける余裕は私にはない。ところが実戦投入となると、これが甘い見通しだったことを思い知らされる。

アプリケーション開発チームの要求

アプリケーション開発では、もっと高度な処理を期待していた。メインフレームのトランザクション管理にある—とゆーかAIMにある—諸々の機能が使えることを期待していたのだ。一番大きかったのは、

アプリケーションをいくつかのグループに分ける

ということだった。元々、この機能は負荷分散のために実装されたらしいものだったのだが、プログラムを論理的に整理するにも都合がいい。

ところが、それを実装するとなると、「1ユーザ1プロセス」という設計では、難しくなる。となると、リソースの有効利用という観点から、「複数ユーザ1プロセス」か「複数ユーザ複数プロセス」という設計にならざるをえない。いずれにせよ、何らかの形で1つのプロセスが複数のユーザからの要求を処理出来るようにしなきゃいけなくなり、セション保持の論理がまるっきり変わる。つまり、

本格的なトランザクションモニタ

を作ることを要求されることになったのだ。

とは言えさすがに、それは荷が重い。そもそも、私はこのプロジェクトに関しては「立ち上げだけしてしまって、あとはよしなに」というスタンスでいた。また、常識的に考えて、いくら開発環境がないとは言え、アプリケーション開発のプロジェクトで本格的にミドルウェアを開発するのは、ありえないことだ。それに、ここでさらに高機能なミドルウェアを作るということは、それだけアプリケーション開発の足を引っぱることになるし、それはまたリリースを遅らせる元になる。さらに、バグの量はコードの量に強い相関があるわけだから、信頼性の確保だって馬鹿にならない。

他方、アプリケーションは既にかなりの量作ってしまっている。今さら改めて書き直すというのは、その工数が馬鹿にならない。ミドルウェアを改修するだけであれば、私一人が死ぬ思いをすればいいのだが、アプリケーションを書き直すとなると、10人くらいが作業しなきゃいけない。つまり、どっちが工数が少なくて済むかと言えば、

私が泣く方が安い

わけだ。また、「いずれ病院システムも」という話もくすぶっていたので、いつかは本格的なトランザクションモニタが必要になり、オープンソースで調達して来なけりゃいけない。そういった諸々のことを考えると、結局私が泣く方がいいということになり、要求されていた仕様を入れたミドルウェアにすることになってしまった。

そんなわけで、当初は単なる「アプリケーション呼び出しフレームワーク」だったはずが、アプリケーション側からの要求に合わせる格好で「本格的なトランザクションモニタ」になることになってしまった。