OSGiコミュニティ大会

3337 ワード

先週OSGiコミュニティ大会がロンドンで開催され、JAXロンドン大会とともに開催されました.講演の内容はJava EEの移行やクラウドコンピューティングから組み込み機器やAndroidまで幅広い.
OSGi上のエンタープライズJavaアプリケーション
ここ数年来、サーバ上でOSGiを使用する人が増えています.OSGiは、ほとんどのJava EEアプリケーションを実装するために使用されるだけでなく、OSGiの実行時に直接実行できるように、アプリケーションのモデルにも深く入り込んでいます.上記の状況はEnterprise Specificationのリリースに由来し、いくつかの汎用Java EEサービスとOSGiサービス(JTA、JPA、JNDIなど)とのマッピングを実現しています.これにより、プラットフォーム・プロバイダ間で共通性が形成され、Apache AriesとEclipse Gemini(Eclipse Virgo、すなわち以前のSpring DMサーバ)があれば、開発中のJava EEアプリケーションに移行する方法を提供することができます.多くのチュートリアルとスピーチの目標は、Ian RobinsonのApache AriesやGlyn NormingtonのEcipse Virgoの更新のように、これらの内容を聴衆に伝えることです.
OSGiへの実行時の移行については、多くの真実の物語があり、移行したい人々にもいくつかのアドバイスを提供しています.まずSAPのKatya TodorovaはNetWeaverプラットフォームからOSGiへの移行について議論した.最初の方法は、すべてのプログラムをカプセル化し、高レベルからOSGiを非表示にしようとしたが、アプリケーションの動作を組織OSGiに変換しようとしたため、動作できないことが証明された.第2の試みは上記に比べてもっと成功しているように見えます.意図的にOSGiを使用し、コンポーネントと対話するためにOSGiサービスを提供します.(Peter Kriensは、彼が長い間持っていた信念はOSGiのものだと言った.μサービスは規範の中で最も重要な部分であり、多くの人が注目しているモジュール性よりも重要です.)
Gerd Kachelは,JBossからOSGiへのアプリケーションの移行方法について議論した.彼は、モジュールを分割する作業が完了したため、アーキテクチャの良いプロジェクト(複数のコンポーネントを持つ)は、通常、「大泥団」式のコンポーネントよりもOSGiに移行しやすいことを発見した.しかし、OSGiに移行すると、コンパイル時と実行時に実行されます.Gerdの例では、彼のアプリケーションはMBeanサービスを使用して隔離されており、OSGiサービスに対する簡単なマッピングを実現することができ、特性をサービス属性とし、方法をサービスインタフェース上の方法とし、依存関係を関連するサービスとして使用することができる.KatyaとGerdは、OSGiに移行した経験を以下にまとめた.
  • 開発者は1ヶ月ほどOSGiに慣れる必要があります.
  • 既存のモジュールについては、OSGiサービスに変換するのに1日程度かかる.
  • OSGiモデルに対抗すると失敗します.それを使えば成功します
  • アプリケーションアーキテクチャが良好であれば、アーキテクチャの悪いアプリケーションよりもbundleにマッピングしやすくなります.
  • MBeanを使用すると、OSGiサービスにマッピングできる簡単なポリシーがあります.
  • アプリケーションでclassloaderを使用している場合は、OSGiへの移行時にclassloaderの処理に問題があります.
  • 動的クラス・ロード(class.forName)を使用している場合は、通常は変更する必要がありますが、OSGiサービスとしてマッピングできます.
  • IOCモデル(Guice,Sprintなど)をすでに使用している場合は、通常の移行はずっと簡単です.
  • もう一つのテーマ
    今回の大会のもう一つのテーマは埋め込み式とマイクロデバイスについてです.いくつかの講演では、Bernhard Dormingerの工業化アプリケーションでのOSGiの使用経験、Dimitar Valtchevのホームオートメーションシステム向けOSGi、Takefumi YamazakiのOSGiベースi-House試験など、OSGiの工業または組み込みアプリケーションでの使用に注目している.ProSyst's mBSの実行時のようなより小さな組み込みシステムを使用しています.
    Andy PiperのOSGiやAndroid、Andre BottaroのOSGi MEなど、モバイル分野でも議論されています.これらの講演も弱電設備に注目しているが,より多くはモバイル分野に注目している.Apache Harmonyプロジェクトのモジュール化特性は、J 2 SE-1.5よりも小型のprofileを大量に持つことを非公式に提案し、更新された実行時(java.beansのような)のパッケージでより少ないprofile(Foundation-1.0のような)を装飾することができる.OSGiは、java.*のネーミングスペースからパッケージを導入しないことを意味するため、Import-Packageを使用してこれを行うのは容易ではありませんが、更新されたOSGi 4.3Require-Capabilityというヘッダ宣言を使用して行うことができます.
    基調と更新
    Jim Colsonは、OSGiの発展の歴史を語り、1999年のJSR 8からEclipse 3.0での採用を経て、現在企業で応用されている状況に至った長い曲がりくねった道路演説を発表した.また,初期のEclipseでOSGiと共に発展したことを振り返り,過去5年間でOSGiの採用がどれほど進展したかを示した.現在、Java EEの各ベンダーは、JBossを除いて独自のOSGiランタイムを作成しているOSGiに基づいてランタイムを作成しています.
    Jimはまた、Apache HarmonyプロジェクトのTim Ellisonを招待して現在の状態を説明した.現在、Java 5 APIの99%とJava 6 APIの96%の改造作業が完了しており、Java実行時にEclipseベースのRCPアプリケーションやwebサーバなど、多くのアプリケーションを実行することができます.さらに重要なのは、all-in-one Oracle JDKとは異なり、Harmony xDKのクラスライブラリとVMは最小10 Mbに達することができます.Harmony Select、Harmony Core、Harmony More、Harmony Outという名前の複数のグループにカプセル化されています.Harmony OutにはUIコードがすべて含まれているだけで(このようにSWTの使用には十分ではない)、依存関係が増加しています.
    James Governorは情熱的なスピーチを発表した.テーマはOSGiの顕著な点である(その主な内容は彼のブログJava the Unipolar Momentに反映されている).同時にPeter KriensはOSGiの将来についてのスピーチを発表した.その中には以前のbundleが含まれている.updateで提案された観点.
    後で、特定のスピーチのさらなる情報を続々と発表します.
    OSGi Community Event