InfoQ

News

OSGiはモバイルJavaのソリューションか?

作者 David Beers , 翻訳者 編集部 投稿日 2007年9月4日 午後9時46分

コミュニティ
Java
トピック
モバイル
タグ
Java ME,
OSGi,
Java One
2007年のJavaOneカンファレンスは、モバイルコンピューティングが導入の初期から大量市場へと変化しつつある、という事実を反映した。しかしそれにもかかわらず、Java ME開発者はサーバーまたはデスクトップJava開発者がかつて取り組んだことのない多くの問題に直面している。 その課題とは以下の通りである。
  • Java Meプラットフォームのフラグメンテーション
  • 進歩した「多機能電話」機器の能力を適切に利用するモバイル実行環境の不在
  • 一度機器が切り離されたモバイルアプリケーションの管理・構成の難しさ
  • 共通のJavaウェブ開発技術やAPIと、特化されたリッチクライアントのモバイル機器用に応用された技術を隔てるアーキテクチャの亀裂

JavaOneセッションでは、Nokia、Sprint、IBMが協力し合い、OSGiを基にしたサービス指向アーキテクチャを通して、これらの問題を解決する方法の概説が行われた。OSGiは元々、遠隔管理、抜き挿し可能性、「ホット」なソフトウェアやファームウェアの更新(再起動なし)が要求されるテレマティックスアプリケーションのために開発された。常時接続のアプリケーションプラットフォームとして、とりわけ運搬機器として携帯電話機がますます使われるようになるにつれて、開発者は、ゆるく結合したコンポーネントアーキテクチャの動力学の一部を、今のところ静的なモバイルJava環境に導入する方法についての取り組みを開始し、携帯電話機はOSGiにとって広大な新規開拓分野となった。

この作業はJSR 232(Mobile Operational Management)という標準規格のもとで行われている。NokiaにおいてモバイルソフトウェアのJava設計者のチーフをつとめるJon Bostrom氏の表現によると、この規格の構想はWeb2.0の指針である「組み立て部品の技術革新」に基づいている。それによると、オープンコンポーネントモデルを導入し、そのモデルにおいてプラットフォームに組み立てられたサービスは、柔軟ながら非常に管理しやすい方法で、開発者によって提供された他のサービスとお互いにプラグインすることができる。OSGiは、機器をOSにとらわれないポケットサイズのアプリケーションサーバーに変える。それによって、新しいコンポーネントはすぐさま配布できるようになり、ライフサイクルやアクセス可否が管理され、監視や記録といったサービスと同様に共有イベントバスが提供される。実際には、OSGiにはサーブレットコンテナがあるので、OSGiバンドル(抜き挿し可能なコンポーネント)を必ずしもJava MEアプリケーションとして書く必要はない。ネットワークのどこかに標準サーブレットとして存在しているかもしれないのである。

この広範囲な構想から、JSR 232作業グループ内の異なる参加者は少し違う方向に進んでいるようである。たとえばNokiaの場合、構想はモバイルマッシュアップを促進する「モバイル革新エンジン」を作ることである。これは、今日よく見かける、ウェブサービスをただ混ぜ合わせたものではないだろう。一例として、他のプラットフォームからアクセスしやすい、ポートが利用可能な代替GUI表示エンジンのようなコンポーネントを持つかもしれない。モバイルJava開発者はCLDC/MIDPが提供する限られたUIツールキットに長い間制約されてきた。JSR 232を搭載する機器では、さらに強力なCDC/FPランタイムとクラスライブラリを作業に使って、SWTの埋め込みバージョンやEclipseリッチクライアントプラットフォーム(eRCP)だけでなく、AGUIやSwing GUIを作ることも可能である。Bostrom氏によると、ActionScript/Flash、OpenLaszlo,およびFlex/Apolloのようなエンジンもプラグインできないわけがないと言っている。最も重要なのは、開発者がもはやJavaコミュニティプロセス(JCP)もしくは機器メーカーがこれらのコンポーネントを携帯電話機に導入するのを待つ必要がないことである。一旦OSGiバンドルに組み込まれてしまえば、EclipseのプラグインがUpdate Manager経由でインストールされるように、機器へのインストールは電波を使って行われ、サービスとして登録される。実際、OSGiはEclipseにおいてこれを可能にした技術であり、インストール後に作業環境を再起動する必要はない。モバイル開発者にとっては胸がおどる将来性であるに違いない。

ポケットサイズのサーバーを有するIBMの場合は、かつてないほど広い視点で提案し、IBMの著名な技術者であるJim Colson氏は、それを「シンメトリック(対称)ポータルモデル」と呼んだ。このモデルにおいて、OSGiはセンサーから多機能電話、ラップトップ、デスクトップまで文字通りすべてにわたるサービス層を有効にし、いずれの場合にもこれらのサービスはJMSやサーブレットといった一般的な技術でアクセスされる。この統合されたアーキテクチャにはいくつかの利点がある。明らかに、企業のIT部門の技術者として一般的な技術を有する数多くの開発者グループにモバイル機器の道を開くし、また、受信地域の限界やワイヤレスネットワークの待ち時間の長さなど、モバイル機器を対象とする標準的なウェブ技術を使うことを妨げていた問題を解決する。IBMのOSGiベースの製品である「Lotus Expeditor managed client software」は、切断モードであってもアプリケーションをクライアントまたはサーバーで実行できる。IBMはLotus ExpeditorをWindows、Windows Mobile、Nokia S60からMac OSにいたるまで、「オープンに対応する、.Netに代わるもの」と考えている。NokiaのモバイルOSGiの実装方法と同様に、IBMの実装は抜き挿し可能なGUIライブラリを使うことでリッチクライアントアプリケーションを可能にし、コンポジションによる開発を促進する。しかし事業の命題は、既存のSOA技術を「データセンターを越え、人、場所、物にまで」広げることである。

OSGiはより動的なモバイルJava環境へのドアを開いた。NokiaのAsko Komsi氏はこのように述べる。構築、監視、条件付の特権といったOSGiサービスとともに「(OSGiは)CDCを使えるものにするために必要だと思われる多くの機能を提供します。」しかし、それはまた問題を提起する。新たな問題は高度なモバイルサービスアーキテクチャの仕様であるJSR 249といった仕様においてJCPによって解決されなければならない。Kosmi氏はこのように説明している。

携帯電話機に送信できるようにするには、どのようにアプリケーションやミドルウェアコンポーネントをパッケージすればよいか、といった最初のインストレーションの仕組み、アプリケーションモデル、パッケージングモデルのような重要な機能の解決策を、高いレベルでみると、JSR 249は環境、アプリケーション、その上で動作するサービスを管理する解決策を見出さなければなりません。将来は複数のアプリケーションを実行できる強力なクライアント環境も手に入れるかもしれません。だからアプリケーションが協力し合う仕組みも定義しなければなりません。これらはJSR 249が解決策を見つけなければならない機能なのです。やらなければ、まだ半分しか来ていないことになり、またフラグメンテーションの問題と向き合わなければならないでしょう。

しかし、Nokiaは携帯電話機にOSGiが搭載されるのをもう待ってはいられない。Sprintと組んでJSR 232の実装を開発した。それはTitanプラットフォームと呼ばれ、近々出荷される。Sprintの3G Software Platforms for Customer EquipmentグループのマネージャであるBrandon Annan氏は、Titanを利用できる「PDA」(おそらくEVDO 無線通信が使われる)4つのうち3つが立ち上がる今年の第4四半期から「モバイルJava技術の黄金時代」が始まると予測する。JSR232携帯電話機は2008年半ばに続いて登場するだろう。Sprintの4G製品部門も、ネットワーク展開への熱い期待に答えてリリースされるWiMax機器用のJSR 232を「真剣に考えている」。Sprintの他には、OSGiおよびeRCPを搭載したNokiaのE90携帯電話機もまた、近々ヨーロッパの市場に出荷される。この高級な多機能電話が北アメリカの岸を見るかどうかはまだ明らかではない。

年内を待てないモバイルJava開発者は、CDC/OSGi上のアプリケーションのデプロイを今日から開始できるが、Windows MobileやLinuxといったオープンOS機器を選択する必要がある。たとえば、Sprintの4Gグループのシニア技術ストラテジストであるBrian Coughlin氏は、インターネット情報端末であるNokia N800にOSGiモバイルマッシュアップのデモをまとめたが、この端末はNokiaがいずれWiMax版を出すと示唆しているLinux機器である。開発者はN800用CDC Java実行環境や、実装されたEquinox OSGiやマッシュアップサーブレットバンドルといった他のコンポーネントをこのサイトから得ることができる。

(原文は2007年5月21日にリリースされました)

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
slashdot+
Hatena

特集コンテンツ一覧

Flex 4の新機能トップ10

今週(2009年6月1日)AdobeはFlex 4の正式な初ベータ版をリリースしました。Flex 4はGumbo(オクラ)というコードネームで開発されています。今回のリリースには大きな変更が多数含まれています。このRIAフレームワークの最新バージョンにおいて変更された事柄についての概要を以下のリストで見ていきましょう。

Domain Driven Design(ドメイン駆動設計) Quickly 日本語版

ビジネス領域の深い理解を反映したドメインモデルを設計するための、ヴィジョンとアプローチです。この本は、Eric Evans氏の「Domain Driven Design」の主要点を短く読みやすく要約しました。

JavaプログラマがFlexとBlazeDSを学んだ方がいい13の理由

この記事ではJavaプログラマがなぜFlexとBlazeDSを学ぶべきなのかについて13の理由を述べています。なぜ高度にインタラクティブなWeb サイトからJavaで開発されたバックエンドをもつエンタープライズ・アプリケーションまでを含む、リッチ・インターネット・アプリケーション(RIA)の開発にFlexとBlazeDSの組み合わせが最適な選択肢となるのかについて述べています。

仮想パネル: バックログは重要な成果物とプラクティスか、それとも無駄か?

Mary Poppendieck氏、Ron Jeffries氏、Jeff Patton氏、David West氏、Steve Freeman氏、Jason Yip氏が、バックログに関する彼らの意見とアジャイルチームを成功させるために必要な事を語った。

Perf4Jを使ったパフォーマンス解析とモニタリング

この記事ではAlex Devine氏が、Java開発者がPerf4Jをどのように利用できるかと、タイミングステートメントにコードを追加し、ロギング、結果の解析とモニタリングを行うオープンソースツールセットの説明をします。

複雑な外部DSLを開発する

本稿では、Vaughn Vernon氏が内部DSLと外部DSLの違いを説明し、複雑な外部DSLを開発する際のステップを示します。

J2EEアプリケーションにおけるAOPを使ったフェッチ戦略の実装

この記事では低レベルのサービス・レイヤやリポジトリ・レイヤを肥大化させることなく、フェッチング・ストラテジによってモジュール化された方法でバックエンドにあるシステムからデータを取得する処理を最適化する方法について説明します。

実証済みのアイデアの融合: S#arp Architectureの裏側

この記事では、Web開発における多数の成熟傾向と、クライアントに価値を提供することに対するそれらのメリット、およびS#arp Architecture(最善の手法と技術を活用しようとするASP.NET MVCをベースとしたフレームワーク)内でのそれらの使用について取り上げます。