Scala+Liftによる超実用開発
オブジェクト指向と関数型の機能をすべて提供し、さらにRubyに代表される動的言語の柔軟性と静的型付け言語の信頼性をも兼ね備え、JavaVMの上で開発実行できる新時代の言語がScalaだ。Scalaとその上で使える強力なWebフレームワークLiftを用いた実システム開発が世界的に広がっているが、今回は日本での実システム開発の事例とScala採用の理由をインタビュー＋プレゼン形式で語ってもらう。
News
Java EEにおける不要物のプルーニング
作者 Charles Humble , 翻訳者 ガーナー 淳子 投稿日 2009年4月15日 午前6時29分
Java EEプラットフォーム成功の主要な背景はそのカバー範囲の広さであるが、その採用を望んでいるディベロッパやベンダにとっては、仕様を成しているAPIと技術の数が問題ともなっている。Java EEアプリケーション・サーバの構築を希望する新規ベンダにとってその仕様一式が参入の実質的な妨げとなっており、その分野での競争を削減している。また、その膨大な数のAPIと頭字語がJava EEに取り組む新規ディベロッパを及び腰にしている。これがJava EEが複雑であるという噂の理由の1つとなっているのだが、より複雑なシステムの構築のほか、ベーシックなCRUDウェブ・アプリケーションといったシンプルなシステムを構築するのに適していることをこのプラットフォームに注目しているディベロッパが必ずしも理解しているわけではない、ということも言える。公言されているJava EE 6の目標の1つは、3つの異なる技術、つまりプロファイル、プルーニング、そして拡張性を利用してこれらの問題に取り組むことである。
プロファイルはJava EEプラットフォーム技術のサブセット、またはベースのJava EEプラットフォームの一部ではない追加のJCP技術、あるいはこれら両方の可能性がある。これらはJava EEに準拠した製品を作るのにより敷居の低いエントリ・ポイントを提供するのでベンダの助けとなり、またこのプラットフォームに取り組みたいディベロッパにとっても有用である。このコンセプトをエンタープライズJava向けに形にするのはもちろんのこと、Java EE 6は以前のInfoQ記事で詳細を紹介した(参考記事)最初のJava EEプロファイル、すなわちウェブ・プロファイルを取り入れている。
Java EE 6はベンダやディベロッパの間に低い採用度合いをもたらしてきたAPIの除去プロセス、つまりプルーニングと呼ばれるプロセスを開始している。これはいくつかの段階を踏むプロセスとして実行されており、候補が1つのリリースにおいて示されJavadocのような形で印をつけられる。そして、コミュニティのリアクションにもよるが、続く次のリリースでオプションのコンポーネントに分類される。
初期のJava EE 6検討ドラフトでは、2つのプルーニング候補が提案されていた。1つはJAX-RPC（XMLベースRPCのJava APIであるJSR 101(リンク)）で、これはRPCを介してSOAPウェブ・サービスにアクセスするためのクライアントAPIおよびウェブ・サービスのエンドポイントを実装する技術を定義している。JAX-RPCは相当数の制限、とりわけウェブ・サービスのアノテーションやインジェクションがJAX-RPCサービス・エンドポイントとハンドラをサポートしていないことに煩わされている。このAPIはJava EE 5のリリースにてJAX-WSに事実上取って代わられた。初期ドラフトおける2つ目のプルーニング候補はJAXR（XMLレジストリ向けのJava APIであるJSR 93(リンク)）であった。これはWeb Serviceのビルド、デプロイ、ディスカバーのために様々な種類のXMLレジストリにアクセスする標準的な手法をもたらし、そしてebXML RegistryとUDDI Registry v2.0仕様のバインディングを搭載している。JAXRはまだ廃れてはいないが、限定的な採用しかされていない。
EE 6の公式なドラフトはさらに2つのAPIをプルーニングのリストに追加している。現在JavaパーシスタンスAPI（もともとはJSR 220(リンク)、すなわちエンタープライズJavaBeans 3.0の一部として定義された）に置き換えられているEJB 2.x コンテナ管理パーシスタンスと、デプロイメント・ツールのランタイム環境とJava EEアプリケーション・サーバが提供しているプラグイン・コンポーネントとの間のインターフェイスを定義しているJava EEアプリケーション・デプロイメント（JSR 88）(リンク)である。このAPIは名目上どのJava EEアプリケーションでも同じデプロイメント・ツールを使うJava EE互換環境にデプロイできるが、残念ながらベンダはあまりサポートしていない。
JSR 88も同様で、エキスパート・グループは、現在のステータスやデプロイされたアプリケーションなどを調べるためJava EEアプリケーション・サーバに問い合わせを行う管理ツール用のAPIを提供するJava EE Management（JSR 77）(リンク)を除去することも検討している。これらのAPIで構築されたサーバ管理ツールはベンダ間共通の方法で動作し、システム管理者に管理ツールやプロセスの変更なくアプリケーション・サーバを切り替える手段や、複数ベンダのプラットフォーム実装から構成される多数のJava EEサーバのネットワークを管理する方法を提供している。JSR-88と同様、このAPIもベンダのサポートが十分でないことに悩まされている。
APIが削減されているため、エキスパート・グループは、仕様の範囲内でより拡張性の高い特徴を備えることで限られたアピール性しかもたないAPIの必要性を削減することを望んでいる。このインターフェイスやプラグインの特質は、うまく結合されたままになっている間にプラットフォームを拡張する技術の構築を容易にし、この仕様が対象としてきたところを取り戻すのに役立つだろう。
関連情報
豆蔵：コンサルタント・エンジニアの採用セミナーを毎月開催します
【豆蔵】組込み系オブジェクト指向開発者（Ｃ＋＋、ＵＭＬ）募集
【豆蔵】Android、iPhoneのアプリケーション開発者募集
No comments
スレッド表示 返信