いまさらORB？ - 大川猛のスタスタ日記

私は2011年12月から宇都宮大学の情報工学科で助教をやっていて、4月からは色々と授業の担当がある予定ですが、それまでは研究のみをしていればよろしい、ということになっています。それで、今まで産総研でやったORBエンジンの仕事を論文にしていなかったので、この機会に論文にしようとしています。

ORBエンジンは、2007-2009年にNEDOの若手研究者向けの研究助成プロジェクトで作った、FPGA上で動作するCORBA（分散オブジェクト）プラットフォームで、日本版バイドール法により、現在は産総研の知財となっています。ORBエンジンのプロジェクトは、プロジェクトの途中で産総研での任期が切れることが決まったため中断しました。その後就職したベンチャー企業では、やはり会社の目標に直結する仕事を優先せざるを得ないため、ORBエンジンを活用する機会がありませんでした。

2009年に産総研を離れる際にORBエンジンはApacheライセンスにしたので、現時点ではオープンソースでありつつもGPLのように未来永劫オープンソースでなければならないものではありません。産総研が著作権を持つという表示を維持すれば、改造や再配布について制限はありません。ということで、先週やっと産総研からORBエンジンのソースコードの情報開示をしてもらいましたので、これから活用して研究開発していこう、と思っています。

で、「いまさらORB？」なのですが、ORBというのはObject Request Brokerの略で、オブジェクト指向の要求(リクエスト)すなわちメソッド呼び出しを、離れたプロセス間でやってくれるものです。プロセスというのは、メモリ空間が独立した処理のことです。簡単に言うと、離れたプロセッサ間でのメソッド呼び出しをする仕掛けなのです。

90年代にCORBA(Common Object Request Broker Architecture)というORBの共通規格が出来、分散システムを作る際に活用されてきました。95年頃からはインターネットの時代となり、00年代には、いわゆるエンタープライズ系の分散処理はWebServiceや.NETフレームワーク等にとってかわられました。実はCORBAはあまりインターネットと相性が良くなく、CORBA用のTCP/IPポートが複数必要なためファイアウォールを超えられないという問題があります。より本質的には、サーバントが1024番以上の高位ポートを開けてメッセージを待つというつくりになっているため、ポートを全開放しないといけないという問題です。そのため、クローズドなシステムの方が適していると言えます。

CORBAには非常の多くのプログラミング言語で相互に使用可能である、というメリットがあります。Java、C、C++、Python、COBOLなどなど・・・更にはErlangまで。また、CORBAそのものの仕様は膨大となっていますが、この先、更にCORBAを発展させようという機運よりも、CORBAの考え方でドメインスペシフィックなサブ仕様をつくるという動きが目立っているように思われます。例えば、自動車向けにはAUTOSAR、組込みシステム向けにCORBA/eという感じです。

そんな中で私がやろうとしている（いた）のは、ハードウェアをソフトウェアから駆動する際のインターフェイスの抽象度をORBの考え方でオブジェクトレベルに上げることで、情報システムの品質と設計生産性を上げよう、ということです。つまりプロセッサから、ハードウェア回路を駆動するのをオブジェクト操作メッセージの単位でやる、という試みです。

現在の普通のシステム開発ではデバイスドライバやAPIを用意して、C言語でハードウェアのレジスタやメモリを操作するというデバイスドライバの開発をするのですが、基本的にOS依存となります。つまり、Linux用とWindows用のデバイスドライバが必要ということです。

ハードウェアがORBの通信プロトコルを解釈できれば、OSに依存せずにハードウェアを駆動するソフトウェアを書くことが出来ます。ハードウェアが解釈すべき通信プロトコルは何だろう、と考えた時に、「オブジェクト指向ソフトウェアのメソッド呼び出し」というのは中立的で理想的なのではないかな、と思うのですが、いかがでしょう？

さて、分散ORBが威力を発揮するのは、「離れたソフトウェアプロセス間で、複雑なデータ構造を共有したい場合であったり、複雑な手順の操作を行いたい場合」です。つまり、「デバイスドライバが複雑で長大な場合」に、ハードウェアをORBで駆動するプラットフォームの有用性が発揮できます。

普通のAPI（プロセス間通信API）では、二つのプロセス間のデータの転送は、生データ転送（C言語であればchar、Javaであればbyte）にせざるを得ません。そうすると、アプリケーションに応じて、受信側プロセスが受信データを解釈可能な通信プロトコルを定め、送信側プロセスが送信データを作成して受信側プロセスが受信データを解釈する機能を設計し実装する必要があります。
アプリ（もしくはハードウェアデバイス）を作成するたびに通信プロトコルを定めて通信機能を実装するのは、通信を最適化できるので良いのですが、その分開発工数がかかります。

そこを解決するのがORBですが、通信プログラムを生成するプログラムを書く、という一段抽象度の高いプログラミングをする必要があり、余計に開発時間はかかります。なかなかバグフリーにすることも難しいです。