InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

Bundle.update: Java EEがOSGi化し、JSR 294 が凍結に

作者 Alex Blewitt , 翻訳者 編集部N 投稿日 2009年12月17日

セクション
デベロップメント
トピック
Java ,
JCP Standards
タグ
IntelliJ IDEA ,
OSGi ,
Glassfish ,
Java SE ,
カンファレンス ,
Websphere ,
Maven ,
JSR 294 ,
JSR 291 ,
Java EE ,
JSR 277

原文(投稿日:2009/12/11)へのリンク

前回の bundle.update 以来、OSGiとモジュールJavaの世界に、いくつかのおもしろい事が起きた。JSR 294が凍結とマークされ、Enterprise Expert Groupがドラフト4をリリース、WebSphereで、OSGiアプリケーションが直接動作するようになり、次回のOSGiコンファレンスの早期ディスカウントと講演者の募集がまもなく終わる。

JSR 294の凍結

モジュール性 (JSR 294、Java言語における改善されたモジュール性のサポートと JSR 277、Javaモジュールシステム) に関する2つのSun主導のJSRが、今や凍結状態になった。これで、 JCP 承認の モジュラティ システムは、 JSR 291だけで、これは、ちょっと古い OSGi 4.1をベースにしているが、広く多くの様々なシステムで活発に使われている。この中には、Sunが最近リリースした GlassFish v3 アプリケーション サーバも入っている。

JSR 294が最近凍結状態にされた、理由ははっきりしない (JSR 277は、1年間凍結されている)。 グループへの最後のメッセージ から推察されるのは:

  • JSRの実装に加えて、JDK7は、実装特有のフィーチャ、例えばa) クラスパス(いかなるJSRの一部ではない) b) Jigsawモジュール・システムを持つ。
  • JDKのモジュール化には、Jigsawモジュール・システムが使われている。モジュールの可視性は、プロトタイプ的なmodule-info.javaファイルによりコントロールされる;これは変わるかもしれない。モジュール-非公開のアクセスビリティは、実際このモジュール化で使用されておらず、部分的にブースト・ストラップを助けている。
  • Jigsawのあらゆる面での更なる議論は、 Jigsaw-dev listにある。

simple module system (シンプル・モジュール・システム)が提案されてから進歩がなかった。 バージョンのセマンティクスがJSR294によって管理されると、ほのめかされたが、明らかにそうは、ならなかった。開発は、JSR 294の専門家メーリング・グループ外である jigsaw-devのメーリングリスト上で行われたからである。それ自体が、称賛に値する目標である、JDKをモジュール化するために、Jigsawは、実装特有のフィーチャであり、一度書けば、どこでも走るという、結果にはならない、ことが上に述べたことから推察される。このことは、将来、いかなる場合でも影響してこないだろう。JDK7は、早くても2011年までリリースされそうにない。アップ・サーバは、すでにOSGiに賭けている。

アップデート: この記事が載ってから、Alex Buckley氏が 確認した のは、プロジェクトを終わらせるためにではなく、最初の提案が出ててからある期間過ぎると、自動的に、凍結に成る、と言うことである。

WebSphere, GlassFish, DM Server OSGiベースのサーバ

Kirk Knoernschild氏は、 OSGi化しているエンタプライズ ソフトについて述べている; 最近の公表によると、 WebSphere V7 α版 では、OSGiのバンドルがWebSphere中にデプロイできるようになった(WebSphereは、2006年以来OSGiのカーネル上で走っているが)。

今週リリースの GlassFish v3 もまた、SunのエンタプライズJavaサーバにOSGiのランタイムを持ち込んだ。GlassFishは、OSGiのバンドルを直接、そのままで走らせることは、できないが、Equinox やFelixにホストすることができるので、GlassFishサーバを走らせて、同時に他のバンドルを走らせることができる。

SpringSourceの dmサーバ 2.0.0.M6 は、すでに バンドル・レポジトリとともにOSGi のwebバンドルを走らせることができ、エンタプライズ用のランタイムに向かう道を示している。

Maven 3とTychoのビルド、リポジトリとMarketplace

OSGiベースのアプリケーションのために、Tycho のビルドとともにMaven 3 のリリースが近づいている。 Eclipseで EGitTigerstripe をビルドするのに使われている。

リポジトリ対P2リポジトリのクエリ能力について議論がこれまであった。しかし、実際は、 Mavenリポジトリもクエリすることができる。おそらく、Mavenリポジトリは、Mavenのビルド・プロセス全体で最も成功した点の1つであり、成果物を依存性の要求に基づいて、自動的にダウンロードできる。Pack200圧縮と非JARのコンポーネントを更新できる点では、 P2 は、もっと進んでいる。Mavenの üuber リポジトリは、EclipseのP2リポジトリを幅において、はるかに優っている。さらに、P2リポジトリは、しばしばいくつも、別々のリポジトリに断片化するが、一方、Mavenは、すべてのプロジェクトが共有する単一のグローバルなリポジトリである。

最近、 Eclipse foundation が成功している Eclipse Plug-In Centralサイトから成長したEclipse Marketplaceを公表した。 EPICは、元々 FindbugsCheckstyleのような基幹のEclipse.orgサイトにホストされない人気のプラグインをダウンロードする中央サイトを提供する手段として作られた。

The Eclipse foundation が2006年に EPICの権利を買った が、それからEclipse marketplaceの最近の展開までほとんど何も変わらないままだった。その間、集中したダウンロード用の構造がないので、Update Site からP2に切り替える苦痛のために、プラグインを見つけ、ダウンロードする目的の中央サイトに関して、提案されたフィーチャや利益が損なわれている。

プラグインに加えて、新Marketplaceは、(フリーと商用の)RCPアプリケーションやトレーニングやコンサルの提供者のためのマーケットも扱う。

最後に IntelliJ 9 がリリースされた。コミュニティ版も商用版もOSGiアプリケーションのビルドをサポートしている。最高のJavaIDEでOSGiアプリケーションをネイティブにビルドできるし、OSGiアプリケーションのヘッドレス・ビルドもサポートしているので、モジュール化されたJavaアプリケーションの開発は、これまで以上に容易になった。

OSGi 4.2 EEGのドラフトが公開

OSGiの Enterprise Expert Group早期ドラフト4を公開した。EEGの目的は、JEEスタイルのアプリケーションがOSGiランタイムで、バンドルとしてネイティブにホストされるように、仕様を定義することである。

  • Web appsは、今やバンドルとしてインストールできる。これにより、OSGiランタイムがWARをホストできる(Jettyのようなサーバと同じ方法で)し、WARもまた、実行時にバージョン付きの依存性を持つことができる。以前は、 Pax Webによりこのようなことができたが、標準ができたために、どんなOSGiのランタイムも使えるようになる。
  • JMX は、OSGiフレームワークにおいてバンドルやPackage AdminやCofniguration Adminなどを管理する。
  • トランザクション は、JTAバインディングの一部として提供され、トランザクションは、OSGiサービスから獲得できる。
  • JNDI アクセスは、OSGiサービスからとOSGiサービス間で、できる。
  • JDBC factoryは、OSGiコンパチである( Class.forName()違って)。

これらのサービスにより、エンタプライズ アプリケーションは、全JEEスタックを必要とせず、OSGiの環境内で動作できる。 JEE6がリリースされたが、これは、承認された最後のJSRの一つになりそうである。と言うのは、 Mark Reinhold 氏がクロージャのQ&Aでコメントしている:

Q なぜ今、クロージャのJSRがスタートしないのですか?専門家グループに新しい提案をまとめる仕事をさせないのですか?

A 同じ理由で、Project CoinのJSRもまだありません。すなわちJCP 執行会議で 現在の論争が終わらないと新しいJava SE JSRは、承認されません。

次回のOSGiコンファレンス

ロンドンで2010年2月23日に OSGi DevCon LondonJAX Londonといっしょに開催される。 コンファレンスのプログラムは、決まり、Kirk Knoernschild氏が基調講演を行う。12月17日木曜日まで早期登録ができる。

サンタクララで、2010年3月22~25日に OSGi DevConEclipseCon 2010 と一緒に開催される。 Robert "Uncle Bob" Martin 氏が基調講演を行う。早期登録は、12月末で終了。講演者をまだ募集中だ。もしOSGiについて語りたければ、提案書を提出するとよい

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。