Sun GlassFish Enterprise Server v3 は、Java Platform, Enterprise Edition (Java EE プラットフォーム) アプリケーションを開発および配備するためのサーバー、ならびに Java テクノロジを基盤とする Web テクノロジを提供します。
ここでは次の Enterprise Server の新機能について説明します。
Java EE 6 ではプロファイルの概念が導入されます。「プロファイル」は、特定の開発者コミュニティーとアプリケーションタイプを処理する Java EE テクノロジおよび API のコレクションです。
Sun GlassFish Enterprise Server v3 の配布を通じて実装されるプロファイルは次のとおりです。
「フルプラットフォームプロファイル」。このプロファイルは、エンタープライズアプリケーション開発で Java EE API のフルセットが必要な開発者向けに設計されています。フルプラットフォームプロファイルは、Sun GlassFish Enterprise Server v3 のインストール時にインストールされます。このプロファイルは Java EE 6 SDK インストールの一環としてもインストールされます。
「Web Profile」。このプロファイルにはフルプラットフォームの一部である Web テクノロジが含まれ、Java EE API のフルセットを必要としない開発者向けに設計されています。Web プロファイルは Sun GlassFish Enterprise Server v3 Web Profile のインストール時にインストールされます。このプロファイルは Java EE 6 Web Profile SDK でもインストールされます。
Java EE 6 SDK の配布は Java EE 6 SDK ダウンロードページで提供しています。
各プロファイルの API の一覧は、「Java EE 6 規格」で確認できます。
Sun GlassFish Enterprise Server v3 では、GlassFish コードをモジュールに分割して、柔軟性の提供とランタイムのパフォーマンス向上を実現しました。このモジュラーアーキテクチャーは OSGi Alliance 規格に基づいて実装され、Enterprise Server v3 モジュールおよびその他のモジュールの再利用を可能にします。
この設計変更により、配備するアプリケーションに必要なモジュールのみを使用することができます。ランタイムはそれを使用するアプリケーションのみに使用され、システムを完全に再インストールしなくてもアップグレードを実装することができます。 この変更により起動時間、メモリー消費、必要なディスク容量が最小化されました。
モジュラー設計により、次のことが可能になります。
OSGi バンドルを配備する
ライブラリ Java アーカイブ (JAR) ファイルを配備する
既存機能を別の実装と置き換える
新しい Sun GlassFish Enterprise Server v3 コンテナのシステムプロバイダインタフェース (SPI) では、コンテナ開発者が実装する必要があるインタフェースを定義して、Enterprise Server から適切なタイミングで呼び出せるようになります。この変更により、Enterprise Server ユーザーは管理コマンドとグラフィカルなアドオンコンポーネントを追加することで、カスタムアプリケーションサーバーを構築できます。
また、Enterprise Server は Ruby on Rails などの新しいモジュールタイプにも合理的に対応しています。
更新ツール が Sun GlassFish Enterprise Server v3 管理コンソール に組み込まれました。このツールによって、Enterprise Server v3 機能を拡張するアドオンコンポーネントおよび関連アプリケーションを簡単に管理できます。
管理コンソール では、ナビゲーションツリーによって 更新ツール ページにアクセスすることができます。更新ツール ページには、次のものを表示するタブがあります。
インストールされているコンポーネント
インストールされたコンポーネントに使用できる更新
使用可能、インストール可能なアドオンコンポーネント
更新ツール を 管理コンソール に統合すると、管理者は容易に Enterprise Server を拡張し、入手可能な更新を確認することができます。updatetool コマンドを使用すると、更新ツールのスタンドアロンバージョンも入手できます。更新ツールの詳細については、『Sun GlassFish Enterprise Server v3 管理ガイド』の「更新ツール」を参照してください。
管理コンソール で更新ツールのインタフェースを使用して既存のコンポーネントを更新することはできません。インストール済みのコンポーネントを更新または削除するには、スタンドアロンのコマンド行バージョンまたは pkg コマンドを使用する必要があります。
更新ツールは、Update Center プロジェクトによって開発されました。管理コンソール では Update Center 2.3 API を使用して使用可能なコンポーネント、バージョン、および日付のリストを表示します。Update Center 2.3 の詳細については、Update Center 2.3 のリリースノートを参照してください。
更新ツールはアップグレードツールとは別のものです。後者は設定と配備済みアプリケーションを Enterprise Server の以前のバージョンから現行バージョンに移行するために使用されます。アップグレードツールの詳細については、『Sun GlassFish Enterprise Server v3 Upgrade Guide』を参照してください。
Sun GlassFish Enterprise Server v3 では、アプリケーション開発と配備の高速化を促進するために、さまざまなスクリプト作成言語をサポートしています。スクリプト作成言語を使用することで、Enterprise Server を Java テクノロジを中心とする開発以外にも適用することができます。サポートされるスクリプト作成言語には、次のようなものが含まれます。
JRuby と Rails: Web アプリケーション開発用のスクリプト言語およびフレームワークです。
Grails: Groovy プログラミング言語を活用して Java による Web 開発を補完する、Web アプリケーションフレームワークです。
Jython と Django: Python 言語の Java 実装と、Python および Python 実装 (Jython など) のための Web フレームワークです。
jMaki: Ajax Web アプリケーション作成のためのフレームワークです。
これらのスクリプト作成言語のサポートは、更新ツールを通じて利用できるコンポーネントによって提供されます。
Sun は Microsoft と密接に連携して、メッセージ最適化、高信頼性メッセージング、およびセキュリティーなどの Web サービスエンタープライズテクノロジの相互運用性を実現しています。WSIT はこの連携業務による製品です。これは Microsoft .NET 3.5 との相互運用性を提供する高性能かつ拡張可能な Web サービススタックである Metro 2.0 の一部です。Metro 2.0 は完全版の Enterprise Server v3 に含まれています。
WSIT は、エンタープライズ機能をサポートする多くのオープンな Web サービス仕様を実装したものです。メッセージ最適化、信頼できるメッセージング、およびセキュリティーに加えて、WSIT にはブートストラップと設定のテクノロジも含まれています。現在 Java プラットフォームに組み込まれているコア XML サポートを基本にして、WSIT は既存の機能を使用または拡張し、相互運用可能な Web サービスのための新しいサポートを追加します。それらには、次のサポートが含まれます。
ブートストラップおよび設定
メッセージ最適化テクノロジ
高信頼性メッセージングテクノロジ
セキュリティーテクノロジ
このリリースでは、appclient ユーティリティーに対して次の機能拡張が行われました。
appclient ユーティリティーで、Java アプリケーション起動ツール (java)の構文と同等の代替コマンド行構文が受け付けられます。
-targetserver オプションが追加され、ターゲットのサーバーとポート番号を指定できます。
アプリケーションクライアントのスプラッシュ画面がサポートされます。
詳細については、appclient(1M) マニュアルページを参照してください。
Sun GlassFish Enterprise Server v3 では Java Persistence API (JPA) 2.0 プロバイダとして EclipseLink が使用されます。EclipseLink は JSR 317 の参照実装でもあります。EclipseLink 機能の最新情報については、EclipseLink 2.0 のリリースノートを参照してください。
Sun GlassFish Enterprise Server v3 では、大半の HTTP サービス設定が新しいネットワークサービス設定に移行されました。詳細については、『Sun GlassFish Enterprise Server v3 Upgrade Guide』を参照してください。
Sun GlassFish Enterprise Server v3 のデフォルトでは、管理者資格認証を求められません。これは前回のリリースから変更されました。
ZIP ファイルを使用して Enterprise Server をインストールする場合は、管理コンソールを起動するとき、または asadmin ユーティリティーとリモートサブコマンドを使用して管理タスクを実行するときに、管理者資格認証を求められません。
自己抽出ファイルとグラフィカルインストーラを使用して Enterprise Server v3 をインストールする場合は、インストール時に「管理の設定」ページでユーザー名とパスワードを指定しない限り、管理者資格認証を求められません。このページでデフォルトを受け入れると、デフォルトの管理者ユーザーは admin となり、パスワードフィールドは空白のままとなります。
パスワードを持たない管理者ユーザーが 1 名のみであれば、認証なしでのログインが許可されます。管理者認証の詳細については、『Sun GlassFish Enterprise Server v3 管理ガイド』の「ドメインへのログイン」 を参照してください。
管理者認証の要件は Enterprise Server をインストールした後で変更される場合があります。管理コンソールを使用してこの作業および関連作業を実行する方法の詳細については、管理コンソールのオンラインヘルプを参照してください。コマンド行インタフェースの詳細については、『Sun GlassFish Enterprise Server v3 管理ガイド』の「パスワードの管理」 を参照してください。
asadmin ユーティリティーの動作が変更されて、asadmin ユーティリティー自体のオプションとサブコマンドのオプションとの違いが明確化されました。asadmin ユーティリティー自体のオプションは、サブコマンドの前に指定することができます。ただし、ほかのリリースとの互換性のため、asadmin ユーティリティー自体のオプションをサブコマンドの後ろに指定することもできますが、この構文は推奨されていません。
詳細については、『Sun GlassFish Enterprise Server v3 管理ガイド』の「asadmin ユーティリティーの使用」 を参照してください。
Sun GlassFish Enterprise Server v3 では、ファイルレイアウトが以前のリリースから次のように変更されました。
デフォルトのインストールディレクトリの場所は次のとおりです。
Solaris、Linux、Mac OS X システム: ユーザーのホームディレクトリ /glassfishv3
Windows システム: システムドライブ :\glassfishv3
glassfish サブディレクトリが、その配下のほかのサブディレクトリとともに追加されました。
プロダクトライブラリは glassfish/lib から glassfish/modules に移動されました。
osgi ディレクトリが追加されました。
法的ファイル用の指定ディレクトリが追加されました。ライセンスと著作権に関するファイルは glassfish/legal に収められています。
Sun GlassFish Message Queue はサブディレクトリではなく最上位のディレクトリにインストールされます。
Java DB はサブディレクトリではなく最上位のディレクトリにインストールされます。
Sun GlassFish Enterprise Server v3 ではサーバー固有の Ant タスクが提供されます。そのため Ant がインストールされている必要があります。このリリースには asant ユーティリティーは含まれません。
Enterprise Server はバージョン 1.6.5 以降の Apache Ant と互換性があります。Ant がインストールされていない場合は、更新ツールを使用してインストールできます。
更新ツールの詳細については、『Sun GlassFish Enterprise Server v3 管理ガイド』の「更新ツール」を参照してください。Ant タスクの詳細については、『Sun GlassFish Enterprise Server v3 Application Development Guide』の第 3 章「Using Ant with Enterprise Server」を参照してください。
Sun GlassFish Enterprise Server v3 はモジュール式で拡張可能であるため、domain.xml を静的な DTD ファイルに対して検証することはできません。その代わり、domain.xml はソースコード内の @Configured 注釈に対して検証されます。domain.xml ファイルの構造については、『Sun GlassFish Enterprise Server v3 Domain File Format Reference』を参照してください。
Enterprise Server v3 と Enterprise Server v2 との間にはアプリケーション関連の相違点があります。この節では、これらの相違点について説明します。
Enterprise Server v3 では配備用の force オプションのデフォルト値は false です。Enterprise Server v2 では、このデフォルト値は true でした。Enterprise Server v3 では、再配備のためにオプションを明示的に true に設定する必要があります。このオプションは、アップグレード処理中に自動設定されません。この変更の目的は、既存アプリケーションのコンテンツが誤って上書きされないようにすることです。変更は管理コンソールとコマンド行ユーティリティーの両方に適用されます。
Enterprise Server v3 では asadmin redeploy コマンドも新しくなり、--force=true と同等の機能を提供します。force オプションは deploy コマンド (コマンド行インタフェースの場合) と deploy 画面 (コンソールの場合) にのみ適用できます。redeploy コマンドおよび redeploy 画面には適用できません。
Enterprise Server v2 にはアプリケーションリポジトリ用にapplications/j2ee-apps と applications/j2ee-modules という 2 つのサブディレクトリがありました。Enterprise Server v3 にはこのようなサブディレクトリはありません (j2ee-apps や j2ee-modules というレベルが存在しません)。Enterprise Server v2 で applications/j2ee-modules/foo 内にあった foo.war などのスタンドアロンモジュールの配備は、Enterprise Server v3 では applications/foo に格納されています。エンタープライズアプリケーションとスタンドアロンモジュールは基本的に同じ名前空間を共有するので、中間的なディレクトリ層は必要なくなりました。
Enterprise Server v3 では web-module や ejb-module などの旧要素は廃止されて、新しい application 要素に置き換えられました。application 要素の詳細については、『Sun GlassFish Enterprise Server v3 Domain File Format Reference』の「application」を参照してください。
アップグレードの際、Enterprise Server v2 アプリケーションは新しい applications/ に再配備され、domain.xml に新しい application 要素が追加されます。Enterprise Server v3 に配備される新しいアプリケーションは、いずれも新しいディレクトリ構造と要素を持ちます。
Java EE 6 では Java EE 5 のときよりも厳格な JAR 可視性規則が課されます。この結果として、古いアプリケーションの一部に障害が発生する可能性があります。
Java EE 6 仕様 では、どの JAR ファイルをエンタープライズアーカイブ (EAR) ファイルから見えるようにするかということに関して、厳格な規則が課されています。特に、EE.8.3.3 の節を参照してください。具体的には、アプリケーションクライアント JAR ファイルのマニフェスト Class-Path に EJB JAR ファイルが明示されていない限り、アプリケーションクライアントモジュールはいかなる EJB JAR ファイルに対してもアクセス権を持つことができません。
これは Enterprise Server v2 からの変更点です。Enterprise Server v2 では、EAR ファイルに含まれるすべての EJB JAR ファイル、および EAR ファイルの最上位にあるすべての JAR ファイルへのアクセス権がアプリケーションクライアントに自動的に付与されていました。より厳格な仕様言語に従うため、ProductName; v3 ではアプリケーションクライアントに JAR ファイルへのアクセス権を自動的に付与することはできません。
Java EE 6 によって課されたこの新しい厳格な動作に対処する方法は、次のとおりです。
アプリケーションが Enterprise Server v2 ドメインに配備されている場合、アップグレードツールはそのドメイン内のアプリケーションに対して Enterprise Server v2 の動作を保持します。アップグレードの詳細については、『Sun GlassFish Enterprise Server v3 Upgrade Guide』を参照してください。
依存する JAR ファイルが明示されるように、クライアントのマニフェスト Class-Path を変更します。Class-Path に EAR ファイルのライブラリディレクトリ内の JAR ファイルを記述しないでください。仕様によって定められているように、このディレクトリ内のすべての JAR ファイルは EAR ファイル内のすべてのモジュールから利用できます。このディレクトリはデフォルトでは /lib です。また、application.xml 記述子で library-directory を使用してその他のディレクトリに設定することもできます。
オプションの --property compatibility=v2 設定によって EAR ファイルを配備します。これにより、該当のアプリケーションが Enterprise Server v3 に配備される場合でも Enterprise Server v2 の動作を保持できます。
この動作の変更については、『Sun GlassFish Enterprise Server v3 Upgrade Guide』の第 1 章「Application Server Compatibility Issues」も参照してください。
Sun GlassFish Enterprise Server v3 で deploy --retrieve コマンドおよび get-client-stubs コマンドを実行した場合、Enterprise Server v2 の場合のように 1 つの JAR ファイルをローカルディレクトリにダウンロードするだけではなくなりました。Enterprise Server v3 でも localdir/myAppClient.jar が作成されて appclient コマンド内でターゲットとして使用できますが、もう 1 つのディレクトリ (localdir/myAppClient ) も作成されて、ここにその他のファイルが格納されます。
いつも Enterprise Server v2 でダウンロードされた 1 つの JAR ファイルをコピーすることによってアプリケーションクライアントのコンポーネントを別の場所に移動させていた場合、この操作は Enterprise Server v3 では無効になります。このような場合には asadmin get-client-stubs コマンドを使用する方法がサポートされています。このコマンドの詳細については、get-client-stubs(1) を参照してください。
それでもコピーを選択する場合は (Enterprise Server v2 の場合のように) localdir/myAppClient.jar ファイルのみをコピーするのではなく、 localdir/myAppClient ディレクトリの内容すべてをコピーしてください。