PR

 Apache Sotware Fundationのインキュベータ・プロジェクトにThe Apache Beehive Projectが誕生したのをご存知だろうか。

SOAのためのフレームワーク,通常の開発にも効果

 Beehiveは,J2EEアプリケーションでSOA(サービス志向アーキテクチャ)プログラミングを行うためのアプリケーション・フレームワークだ。SOAは,Webサービスなどのネットワークを介した様々なサービスの組み合わせでアプリケーションを構築する手法ととらえられがちだ。しかし,実はSOAはプログラミングでも有効である。サービスを提供するモデルを組み合わせてアプリケーションを構築してゆくのだ。

 Beehiveプロジェクトは,今までApache Sotware Fundationが支援してきたTomcatやStrutsといった開発プロジェクトとは少し毛色が異なる。オープンソース・コミュニティから発生したプロジェクトというよりは,企業が開発していたプロダクトがオープンソース化されたものだ。その企業とは,米BEA Systemsである。

BEAがApache Foundationに寄贈

 BEAは,自社内で開発していた,BeehiveのベースとなるテクノロジをApache Sotware Fundationに寄付した。現在,Beehiveの開発はBEAの手を離れ,Apache Sotware Fundation内で行われている。BEAは,Beehiveの啓蒙と,対応するIDE(統合開発環境)「BEA WebLogic Workshop」とアプリケーション・サーバー「BEA WebLogic Server」の提供を行っている。

 BEAが目指したのは,フレームワーク,構築ツール,実行時環境を含めたJ2EE構築環境をSOAによって行う事だ。そのため,BEAは 自社IDEであるWorkshopとWebLogicをBeehive対応とした。そして,これらの仕様をオープンソースの力を利用してデファクト・スタンダードにしようとしている。Eclipseの成功を目の当たりにしてオープンソースの力を再認識したのであろう。

EJBが超えられなかった壁をオープンソースで乗り越える

 EJBが登場した当初,EJBコンポーネントを流通させ,それを組み合わせることでアプリケーションを構築する,という似通った未来像が語られていた。しかし,現時点においてその像はまだ実現していないように思われる。

 EJBコンポーネントが流通しない原因はいくつか考えられるが,その1つにコンポーネントインタフェースの自由度の高さと,ツールサポートの問題がある,と筆者は考えている。コンポーネントは所詮,自由に設計可能なプログラムの1部品であり,作り手によって粒度やインタフェース仕様,初期化方法などが異なってしまう。

 この問題は各種団体や会社などが策定したガイドラインがフレームワークなどに準拠することである程度克服可能だが,デファクト・スタンダードが存在するまでにはいたっていない。また,ツールサポートに関しても,様々なコンポーネントを自由に組み合わせてアプリケーションが組み立てられるようなものは登場していない。特定のベンダが定める規約に基づいて作成したコンポーネントが扱えるといったものが多い。

 今回取り上げるBeehiveも,基本的には,特定の規約に基づいて作成したモデルのみを扱う。その意味では既存のツールの域を出ていない。しかし,このプロジェクトがオープンソース・プロジェクトとして活動し始めたことに,今までとの違いがある。オープンソース・コミュニティで開発されることで,特定ベンダ独自の仕様から,誰でも採用できる仕様となり,多くのベンダが採用しやすくなる。そればかりではなく,様々なツールでのサポートがボランティアの手によって行われる可能性が生まれたのだ。

 この流れは決して悪いこととは思わない。むしろ歓迎すべきことだ。多くの優れたアイディアやプロダクトが,特定の会社の独占状態で公開(もしくは,販売)されていたとしても,それは必ずしも世界中に受け入れられるとは限らない。広く受け入れらるためには,ベースとなる仕様やテクノロジをオープンソースとして公開し,採用または利用しやすくして門戸を広げることも大切だ。収益は,先行優位性や+αの付加価値から捻出できれば理想的だろう。

 やや前置きが長くなったが,Beehiveの概要を紹介しよう。