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の概要を紹介しよう。