WebObjectsは、Enterprise Objects Frameworkというフレームワークを内包しているが、EOFとして参照されるものだ。非常に大きなフレームワークであるが、1つの大きな仕事は、リレーショナルデータベースをオブジェクトとして利用できるようにする諸機能を包括しているということだろう。また、そうしたデータベースとのかかわりにおいて、ビジネスロジックを組み立てるもとになるものとも言えるが、まずは、データベースをオブジェクトとして扱えるようにするための基本機能だと考えてもらえば良い。そして、データベースをどのようにオブジェクトとして扱うかを定義したものが「モデル」と呼ばれる。そのモデルを定義するアプリケーションがEOModelerなのである。WebObjectsのアプリケーションは、このモデルを手がかりにしてデータベースを利用する。つまり、WebObjectsアプリケーションは、自分自身からSQLステートメントを発行してデータをくちくちと取り出すということはしない。ある種の初期化プロセスを経れば、アプリケーション内では、インスタンス化されたオブジェクトとして、テーブルの中身を取り出したり、追加したり、あるいは変更できるのである。
伝統的なデータベースプログラミングになれている人は、SQLくらいはどうってことないと思うかも知れないし、わざわざモデルを作るというのもかえって面倒と思うかも知れない。しかしながら、オブジェクトとして扱えるということは1つには、開発ツール上で自由にデータベース処理を組み込むということにつながっている。これは、今後紹介するWebObjects Builderでの作業を見てもらえば、オブジェクトとして扱う意味がまず見えてくるだろう。また、オブジェクト指向という点を考えれば、自由度の高いオブジェクトの設計が、柔軟に複雑な要求に適用できるという方向性を持つことになる。もちろん、住所録のような単純なアプリケーションだとそうした柔軟性は見ることはできないが、複雑なテーブル構成を持ったもので、単純には行かないビジネスロジックを組み込むような場合、オブジェクト指向がベースになっていることがのちのちの開発効率やメンテナンス性に響いてくるということになるだろう。
ところで、こうした「データベースの中身をオブジェクトとして扱う」というメカニズムで有名なのは、むしろJava2 EEのEnterprise JavaBeans（EJB）だろう。EJBをサポートしていれば、「アプリケーションサーバ」と名乗ることができるというのが一般的なコンセンサスとなっている。EJBの基本的な仕様は同一のものであるので、EJBに対応したコンポーネントはたとえばアプリケーションサーバの製品に限定されないというメリットもあり、こうしたコンポーネントの流通を促すと言う側面もあるため、業界では高く注目されているのである。いや、言い方を変えれば、EJBに対応していないものはアプリケーションサーバとは言えないという空気さえある。WebObjectsのEOFは、このEJBにおおむね対応するものと考えて良いだろう。詳細は違いはあるだろうが、大局的な目的な同じものだ。どちらが優れているかという点についての評価は筆者にはできないが、EJBに比べてEOFが劣っているということはないという話は聞く。たぶん、標準ということを意識したいのならEJBということになるのかもしれない。一方で、こうしたエンタープライズな開発素材は相互互換性があるからといって結果的に別の製品に変えるのには多大な労力がかかることもあるため、その意味では互換性はあまり高いプライオリティで考えない場合も多々あるだろう。結果的にデベロッパーが責任を持って選択をしないといけないのであるが、EJB全盛の時代ではあるけども、EOFでも必要十分な機能が提供される点は言えることだと思う。もっとも、WebObjectsも将来的にはEJBをサポートするが、おそらく現在のEOModelerやWebObjects Builderの機能を考えると、EOFでのデータベース利用が中心になると思われる。もっとも、EJBをサポートすることによって別のアプリケーションサーバからの移行を促すという側面が強いと考えられる。
アプリケーションを実際に作るには、Project Builderの作業から始めることになるのだが、今回はまずはEOModelerでモデルを定義したファイルだけを作成し、後からプロジェクトに納めることにする。というのも、Project Builderから新規にモデルを作るような機能は今のところはないので、モデル作成作業は今のところ独立して行うことになると思われるからだ。
では、まずはEOModelerを起動しよう。/Developer/Applicationsフォルダにあるので、アプリケーションのアイコンをダブルクリックして起動する。
◇EOModelerは普通にアプリケーションとして利用できる
EOModelerが起動すると、単にメニューだけが表示される。「モデル」を定義すると説明したが、物理的にはモデルを定義した結果を、ファイルとして保存しておく。このファイルを開発時や実行時にツールあるいはフレームワークが利用して、データベースのオブジェクト化を行うのである。だから、EOModelerでは結果的にモデル定義ファイルを作成することになる。
では、FileメニューからNewを選択しよう。もちろん、Command+Nでもかまわない。すると、いきなり文書ウインドウが開くのではなく、次の図のようなNew Model Wizardが開く。モデル定義ファイルには、必ずデータベースへの接続情報が込められる。これがないことにはデータベースに接続しようがないわけで、その設定をモデルファイルに埋め込むわけだ。また、データベースに接続しないと意味がないと言うこともあるので、モデルを新規に作る時にはデータベースに接続を行うのである。最初はアダプタの指定だが、OpenBaseに限らずWebObjects 5ではほぼ例外なく（今後は分からないけど）JDBCアダプタを選択することになるだろう。
◇アダプタはJDBCを選択する
Nextボタンをクリックすると、以下のようなJDBCアダプタでの接続設定を行うダイアログボックスが表示される。ここでは決められた通りに入力をしなければならない。まず、URLは複数の設定が入り交じるが、いずれにしても、接続するデータベースの場所を定義しておく必要がある。基本的にはJDBCでの接続URLとして定義されたものだ。プロトコルは「jdbc」なのは当たり前として、サブプロトコルに「openbase」を指定する。続いて区切って、サーバが稼動しているマシンのホスト名を指定するが、同一マシンで稼動しているOpenBaseに接続する場合はホスト名は「localhost」でほぼOKだろう。そして、スラッシュで区切って、データベース名を指定するここでは起動しているデータベースの名前「Address」を指定した。
そして、UsernameとPasswordは、OpenBaseに設定されたアカウントを指定する。Mac OS X野アカウントとは別のもので、OpenBaseManagerを使うなどして定義されたものだ。この一連のシリーズでは、前回に、最初から登録されているadminというアカウントにパスワードを設定した。従って、今現在はadminという1つのアカウントが設定されているだけなので、Usernameにはもちろん「admin」と指定する。そして、そのadminのパスワードをPasswordに指定をするわけだ。
Optionalには、Driverのところに図にあるように「com.openbase.jdbc.ObDriver」を間違えないで指定する。この通りでなければならない。PlubInは指定はしなくていい。
◇データベース接続に対する指定を行う
なお、こうした設定をどうすればいいのかといった説明は、/Library/OpenBase/DocumentationにあるREADME-JDBC-WO5.0.rtfというファイルを参照すれば子細が記載されている。いずれにしても、上記の設定はJDBCのプログラミングを知っている人にとってはどんなプログラムか想像できてしまう範囲だと思う。
なお、OpenBaseのJDBCドライバは、/Library/Java/OpenBaseJDBC.jarにある。/Library/Javaが追加するJavaのライブラリファイルを入れる代表的な場所としてMac OS Xは用意している模様だ。