コメントは xxxxxxxx へ送ってください日本語版のコメントは送っても迷惑なので、やめましょう。
最新リリース - 2003/11/24 Bill Shannon
日本語版は、とりあえず読みたいのでSun Microsystemsの許可無く勝手に翻訳しています。原文はhttp://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf から入手できます。 日本語のコメントは、j2ee-spec-feedback@siisise.net へ送ってください。ひととおり翻訳してから微修正の予定です。
Java™ 2 Platform, Enterprise Edition (J2EE™) Specification
("Specification")
Version: 1.4
状態: 最終リリース
リリース: 2003年11月24日
Copyright 2003 Sun Microsystems, Inc.
4150 Network Circle, Santa Clara, California 95054, U.S.A.
All rights reserved.
翻訳: Copyright 2003-2004 佐藤 雅俊@しいしせねっと
(略)
(LFI#135810/From ID#011801)
(略)
今日、企業は顧客、従業員、サプライヤーに対して範囲を広げ、コストを引き下げ、またサービスのレスポンス速度を短縮する必要がある。
特徴的に、これらのサービスを提供するアプリケーションは、既存の企業情報システム(EIS)と広範囲のユーザにサービスを提供する新しいビジネス機能を組み合わせる必要があります。
サービスには次のことが求められます:
ほとんどの場合、企業サービスは多層アプリケーションとして実装されます。 中央の層は、ビジネス機能および新しいサービスのデータに既存のEISを統合します。
ウェブ技術を成熟させることは、最初の層ユーザにビジネス複雑さへの容易なアクセスを提供し、かつユーザ管理およびトレーニングを除去するか、徹底的に軽減するために用いられます。
Java™ 2 Platform, Enterprise Edition(J2EE™)は、多層、企業サービスを開発するコストおよび複雑さを軽減します。
J2EEは、次の要素を備えた標準のアーキテクチャーの定義によりこれらの利益を達成します:
この文書はJ2EEプラットフォーム仕様書です。それは、J2EEプラットフォーム製品が満たさなければならない要求事項を述べます。
この仕様は多くの人によって作られています。Vlada Matenaはトランザクション管理とNamingの章の最初のドラフトを書きました。Sekhar Vajjhala, Kevin Osborn, と Ron Monzillo はセキュリティの章を書きました。 Hans Hrasna はアプリケーションの組立と配備の章を書きました。Seth White はJDBC API 要件を書きました。Jim Inscore, Eric Jendrock と Beth Stearns は編集の手伝いをしてくれました。 Shel Finkelstein, Mark Hapner, Danny Coward, Tom Kincaid, と Tony Ng は、多くのドラフトに意見をくれました。 And of course this specification was formed and molded based on conversations with and review feedback from our many industry partners.
(略)
Version 1.4のこの仕様は、Java Community Processの下で JSR-151として作られた。(略)
この章はJava™2 Platform, Enterprise Edition (J2EE™)の概観を提供します。
J2EEプラットフォームのアーキテクチャ上の要素の必要な関係は、図J2EE.2-1の中で示されます。この図が要素の理論的な関係を表すことに注意してください; それは個別のマシン、プロセス、アドレス空間あるいは仮想マシンの中に要素を物理的に分割するということを意味するものではありません。
個別の四角形によって表わされたコンテナは四角形の上半分の中に表わされたアプリケーション・コンポーネントに必要なサービスを提供するJ2EE実行環境です。提供されるサービスは、四角形の下半分における箱によって表わされます。例えば、アプリケーション・クライアント・コンテナはアプリケーション・クライアントにJavaメッセージサービス(Java Message Service)(JMS)APIを提供し、他のサービスも同様です。これらのサービスはすべて後で説明されています。セクションJ2EE.2.6「J2EE標準サービス」を参照してください。
矢印は、J2EEプラットフォームの他の部品への必要なアクセスを表わします。アプリケーション・クライアント・コンテナは、データ・ベース・システム接続のためのJDBC™ API, Java APIによってアプリケーション・クライアントにJ2EEに要求されたデータ・ベースへの直接のアクセスを提供します。データベースへの類似したアクセスは、Webコンテナにより、JSPページおよびサーブレットに、それからEJBコンテナによってエンタープライズBeansに提供されます。示されたJava™ 2 Platform, Standard Edition(J2SE™)のAPIは、各タイプのアプリケーション・コンポーネントのためのJ2SE実行環境によってサポートされます。
図J2EE.2-1
以降のセクションは、各種類のJ2EEプラットフォーム要素のためのJ2EEプラットフォーム要求について記述します。
J2EE実行環境は、J2EE製品がサポートする必要のある4つのアプリケーション・コンポーネント・タイプを定義します:
J2EEサーバはアプリケーション・コンポーネントを順応させるための配備、取り扱いおよび実行サポートを提供します。
アプリケーション・コンポーネントは、J2EEサーバ上のそれらの依存による3つのカテゴリーに分類することができます:
コンテナは、J2EEアプリケーション・コンポーネントにランタイム・サポートを提供します。コンテナは、基本的なJ2EE API(の連合した見かた)をアプリケーション・コンポーネントに提供します。 J2EEアプリケーション・コンポーネントは他のJ2EEアプリケーション・コンポーネントと直接対話しません。 それらは、相互およびプラットフォーム・サービスとの対話のためにコンテナのプロトコルおよびメソッドを用います。 コンテナをアプリケーション・コンポーネントとJ2EEサービスの間にはさむことは、コンテナが、宣言的なトランザクション取り扱い、セキュリティ・チェック、リソースをプールすること、および状態管理のようなコンポーネントの配備記述子によって定義されたサービスを透過的に導入することを可能にします。
代表的なJ2EE製品は各アプリケーション・コンポーネント・タイプのコンテナを提供するでしょう:アプリケーション・クライアント・コンテナ、アプレット・コンテナ、Webコンポーネント・コンテナおよびエンタープライズBeansコンテナ。
この仕様は、コンテナがJava 2 Platform, Standard Edition、v1.4仕様(J2SE)によって定義されるようなJavaと互換性のある実行環境を提供することを必要とします。アプレット・コンテナはこの環境を提供するためにJava Plugin製品を用いるかもしれません。あるいは、それはその環境をネイティブに提供するかもしれません。 JDK 1.1 APIを提供するアプレット・コンテナを使うことはこの仕様の範囲外です。
コンテナ・ツールは、配備のためのアプリケーション・コンポーネントのパッケージングのためのファイル・フォーマットを理解する必要があります。
コンテナはJ2EE製品プロバイダによって実装されます。 セクション、「J2EE製品プロバイダ(J2EE
Product Provider)」J2EE.2.10.1で製品プロバイダの役割の記述を参照してください。
J2EEコンテナはサーバ上でその一部として動作します。J2EE製品プロバイダは通常、Java 2 Platform, Standard Edition (J2SE)技術と結合して既存のトランザクション処理の基礎を使用しながらJ2EEサーバサイド機能を実装します。J2EEクライアントの機能は、通常J2SE技術の上に構築されます。
リソース・アダプタは、外部リソースマネージャーへのネットワーク接続機能を持つシステムレベルのソフトウェア・コンポーネントです。リソース・アダプタは、J2EEのJ2EEの標準のサービスAPI(JDBCドライバなど)、あるいは外部アプリケーション・システムへのコネクターのためのリソース・アダプタの定義および実装によって、J2EEプラットフォームの機能性を拡張することができます。 リソース・アダプタはJ2EEサービス・プロバイダー・インターフェース(J2EE SPI)を通してJ2EEプラットフォームと接続します。 J2EEプラットフォームに付いているJ2EE SPIを使用するリソース・アダプタは、すべてのJ2EE製品で動作させることができます。
J2EEプラットフォームでは、ビジネス・データの記憶装置には、JDBC APIによってアクセス可能なデータベースが必要です。データベースはWebコンポーネント、エンタープライズBean、およびアプリケーション・クライアント・コンポーネントからアクセス可能です。データベースはアプレットからアクセスできる必要はありません。
J2EE標準サービスは、次のものを含みます(詳細はこの文書の後で定義されます)。これらの標準サービスの中には実際にはJ2SEで提供されているものもあります。
HTTP クライアント・サイド APIは、java.net パッケージで定義されています。HTTPサーバ・サイドAPIは、サーブレットとJSPインターフェースで定義されています。
SSLプロトコル上のHTTPプロトコルはクライアントとサーバのAPIで同じように定義されています。
Java Transaction APIは2つの部分から成ります:
RMI-IIOPサブシステムは下位プロトコルに依存せず、RMIスタイルを可能にするAPIで構成されており、実装ではJ2SEネイティブRMIプロトコル(JRMP)やCORBA IIOPプロトコルをサポートしています。J2EEアプリケーションは、CORBAサービスにアクセスするため、IIOPプロトコルサポートと共に、RMIプログラミング規定と互換性があるRMI-IIOPプロトコルを使うことができます(詳細はRMI-IIOP仕様を参照)。そのようなCORBAサービスは、通常レガシー・システムの中で、J2EE製品の外部で生きているコンポーネントによってよく定義されます。J2EEアプリケーション・クライアントだけがRMI-IIOP APIを使用して、自分のCORBAサービスを直接定義することができるために要求されます。一般的に、他のCORBAオブジェクトにアクセスした場合、そのようなCORBAオブジェクトはコールバックを目的として使用されるでしょう。
J2EEアプリケーションはエンタープライズJavaBeansコンポーネントにアクセスする場合にEJB仕様に記述されるようにRMI-IIOP
API(特にjavax.rmi.PortableRemoteObjectの狭い方法)を使用するために要求されます。
これは、エンタープライズBeanがプロトコルに依存しないことを可能にします。
さらに、J2EE製品は、IIOPプロトコルを使用しかつ、EJB仕様書中で指定されるようにIIOPプロトコルを使用して、エンタープライズBeanにアクセスして、エンタープライズBeanを輸出することができるに違いありません。
IIOPプロトコルを使用する機能はJ2EE製品間の相互運用を可能にするために要求されます。しかしながら、J2EE製品はさらに他のプロトコルを使用することができます。
Java IDLは、IIOPプロトコルを用いてJ2EEアプリケーション・コンポーネントから外部のCORBAオブジェクトの呼び出しを可能にします。これらのCORBAオブジェクトは、様々な言語で書かれています。J2EEアプリケーションはCORBAサービスのクライアントの役割をするためにJava IDLを使用するかもしれません、しかし、J2EEアプリケーション・クライアントだけがCORBAサービス自身を示すためにJava IDLを直接使用することを許されるために要求されます。
JDBC APIはリレーショナル・データベース・システムと接続するためのAPIです。JDBC APIは、2つの部分から成ります: アプリケーション・コンポーネントからデータベースにアクセスするために使われるアプリケーション・レベル・インタフェース、サーピスプロバイダ・インターフェース。J2EE製品ではサービス・プロバイダー・インターフェースのサポートは要求されません。
Javaメッセージ・サービスは、publish-subscribeモデルのような信頼できるpoint-to-pointメッセージ用の標準APIです。この仕様ででは、point-to-pointとpublish-subscribeメッセージングの両方が実装されたJMSプロバイダが必要です。
JNDI APIはネーミングとディレクトリ・アクセスの標準APIです。JNDI APIは、アプリケーション・コンポーネントからネーミングとディレクトリ・サービスを使うためのアプリケーション・レベルのインターフェースとネーミングとディレクトリ・サービスのプロバイダにアタッチするサービス・プロバイダ・インタフェースの2つで構成されます。
多くのインターネット・アプリケーションは、電子メールで通知を送ることが必要です。そのため、J2EEプラットフォームは、アプリケーション・コンポーネントがインターネットメールを送ることを可能にするJavaMailサービス・プロバイダーとJavaMail APIを含んでいます。JavaMail APIは2つのパーツを持っています: メイルを送るためにアプリケーション・コンポーネントによって使用されるアプリケーションレベルのインターフェース、およびJ2EE SPIレベルで使用されるサービス・プロバイダー・インターフェース。
JAF APIは、異なるフォーマットやロケーションからはじまる異なるMIMEタイプのデータをハンドリングするためのフレームワークを提供します。JavaMail APIはJAF APIを利用するため、同様に含まれていなければいけません。
JAXPは、XMLドキュメントを解析するための業界基準であるSAXとDOM APIのサポートと、XSLT変換エンジンのサポートを提供します。
J2EEは、WebサービスクライアントとWebサービス・エンドポイントの両方のフルサポートを提供します。それぞれのJava技術がWebサービスのサポートのため一緒に機能します。Java API for XML-based RPC (JAX-RPC) は、SOAP/HTTPプロトコルを用いたWebサービス呼び出しのサポートを提供します。JAX-RPC は、SOAP RPC 呼び出しを使ったJava class と XML間の対応付け(マッピング)を定義します。SOAP with Attachments API for Java (SAAJ) は、ローレベル SOAPメッセージを操作するためのサポートを提供します。Web Services for J2EE 仕様は、webサービス・エンドポイントを? エンタープライズBeanとして利用するための実装を含めてJ2EEでWebサービス・クライアントとWebサービス・エンドポイントの配備(deploy)のための機能をすべて定義します。Java API for XML Redistries (JAXR) は、クライアントがXMLレジストリ・サービスにアクセスする機能を提供します。
この仕様書は、J2EE製品がすべて提供しなければならない機能の最小のセットについて記述します。 ほとんどのJ2EE製品は、この仕様書によって要求された最小以上の機能を提供するでしょう。 この仕様書は、製品が拡張を提供する場合の若干の制限を含んでいます。 それは特にJ2SEにおいてのJava APIに対する拡張と同じ制限を含んでいます。 J2EE製品は、この仕様書に含まれたJavaプログラミング言語パッケージに対してクラスを加えないかもしれないし、メソッドを加えないかもしれないか、そうでなければ、指定されたクラスの記号を変更しないかもしれません。
しかしながら、他の多くの拡張は許容されます。
J2EE製品は追加のJava API、他の一方のJavaのオプションのパッケージあるいは他の(適切に指定された)パッケージを提供するかもしれません。
J2EE製品は、ここに指定されない追加のプロトコルあるいはサービスのサポートを含んでいるかもしれません。
J2EE製品は、他の言語で書かれたアプリケーションをサポートするかもしれないし、あるいは他のプラットフォームあるいはアプリケーションへの接続をサポートするかもしれません。
(略)
この章では、J2EE製品プロバイダが満たされなければならないJava 2 Platform, Enterprise Edition規約について記述します。
J2EE APIはJ2EEアプリケーション・コンポーネントとJ2EEプラットフォームの間の規約を定義します。規約はランタイムと配備の両方のインターフェースを規定します。
J2EE製品プロバイダは、この仕様に書かれたセマンティック(意味)とポリシー(方針)をサポートするJ2EE APIを実装しなければなりません。アプリケーション・コンポーネント・プロバイダは、これらのAPIとポリシーに従ったコンポーネントを提供します。
J2EE 1.3仕様はJ2EEプラットフォームにエンタープライズ(企業)統合機能を拡張します。コネクターAPIは、外部の企業情報システムとの統合をサポートします。JMSプロバイダは、今必要です。JAXP
APIはXMLドキュメント処理のサポートを提供します。JAAS APIはコネクタAPIのセキュリティ・サポートを提供します。EJB仕様は必要とされているIIOPプロトコルとの相互運用をサポートします。
EJB仕様にはかなりの変更がなされました。EJB仕様は新しいコンテナ管理の永続モデルを持ち、メッセージ駆動Beanとローカル・エンタープライズBeanをサポートします。
その他の既存のJ2EE APIも、更新されました。詳細については、各APIの仕様を参照してださい。J2EE1.3はJ2SE 1.3のサポートが必要です。
J2EE1.4の焦点はWebサービスのサポートです。JAX-RPCおよびSAAJ APIは基本Webサービスに相互運用支援を提供します。J2EEのためのWebサービス仕様は、Webサービスを提供し利用するJ2EEアプリケーションのためのパッケージングと配備の要求について記述します。EJB仕様はさらにステートレス・セッションBeanを使用したWebサービスの実装をサポートするために拡張されました。JAXR APIは、レジストリとリポジトリ(repositories)へのアクセスに対応しました。
(略)
この章では、J2EE製品で満たされなければならない Java™ 2 Platform, Enterprise Edition (J2EE)のためのセキュリティの要件について記述します。
J2EE要件に加えて、各J2EE製品提供者は、それらの実装で提供されるセキュリティとセキュリティの保証レベルを決定するでしょう。
大抵あらゆる企業はセキュリティに対応するためにセキュリティ要求および明確なメカニズムやインフラを持っています。多くのユーザがアクセスできたり、しばしば(インターネットのような)無防備のオープンなネットワークを通過することができる、敏感なリソースを守る必要があります。
品質保証と実装の詳細は変わるかもしれませんが、それらはすべて次の特性のうちのいくつかを共有します:
本章は、J2EEプラットフォーム必要条件がどうセキュリティ必要条件に取り組むか明示し、J2EE製品プロバイダによってアドレスされるかもしれない必要条件を識別します。最終的に、この仕様書の将来のバージョンを目的として熟慮した問題は、セクション J2EE.3.7、「将来の指示(Future Directions)」に簡潔に言及されます。
このセクションでは、J2EEセキュリティ・アーキテクチャ
次のものがJ2EEセキュリティ・アーキテクチャのゴールです。
次のものはJ2EEセキュリティ・アーキテクチャのゴールではありません。
コンポーネントのためのセキュリティはJ2EE環境中で上に指定されたセキュリティ用のゴールを達成するためにそれらのコンテナーによって提供されます。 コンテナーは、2種類のセキュリティ(次のセクションで説明しています)を提供します:
宣言的なセキュリティは、アプリケーションに外部形式にセキュリティ役割、アクセス・コントロールおよび認証必要条件を含むアプリケーションのセキュリティ構造を表現する方法を参照します。配備記述子はJ2EEプラットフォームの宣言的なセキュリティの主要な媒体です。
配備記述子はアプリケーションの構成要素のプロバイダー(Component Provider)とDeployerまたはアプリケーションのアセンブラーの間の契約です。
アプリケーション・プログラマはそれをアプリケーションのセキュリティが環境上の必要条件を関連づけたと言うために使用することができます。
配備記述子はグループのコンポーネントに関係していることができます。
Deployerは、特別の環境に特有のセキュリティ構造に配備記述子のアプリケーションのセキュリティ方針の表現を写像します。
Deployerは、配備記述子を処理する配備ツールを使用します。
実行時では、コンテナーが、配備記述子に由来し、認可(セクションJ2EE.3.3.6「認可、モデル化する」を参照)を強化するためにDeployerによって構成されたセキュリティ方針セキュリティ構造を使用します。
プログラムのセキュリティは、セキュリティによって作られたセキュリティ決定を参照します、知っているアプリケーション。
宣言的なセキュリティだけがアプリケーションのセキュリティ・モデルを示すのには十分でない場合、プログラムのセキュリティは有用です。
この仕様書によって要求されたプログラムのセキュリティ用のAPIは、EJB EJBContextインターフェースの2つのメソッドおよびservlet HttpServletRequestインターフェースの2つのメソッドから成ります:
(略)
J2EE承認モデルはセキュリティ・ロール(役割)の概念に基づきます。セキュリティ・ロールはユーザを論理的にグループ化したものであり、アプリケーション・コンポーネント・プロバイダーあるいはアセンブラ(組立者)によって定義されます。デプロイヤー(配備者)は運用上の環境の中で、セキュリティ同一性(例 プリシンパル(当事者)とグループ)にロールを割り当てます。セキュリティ・ロールは宣言的なセキュリティおよびプログラムのセキュリティの両方と共に使用されます。
宣言的な承認はエンタープライズBeanメソッドへのアクセスをコントロールするために使用することができ、エンタープライズBean配備記述子の中で定義されます。エンタープライズBeanメソッドは配備記述子の中でmethod-permission要素に関係していることができます。method-permission要素は、与えられたセキュリティ・ロールによってアクセスすることができるメソッドのリストを含んでいます。呼び出しプリシンパルがセキュリティ役割のうちの1つにある場合、メソッドへのアクセスを許可した、プリシンパルは、メソッドを実行することを許されます。反対に、呼び出しプリシンパルがロールの中になければ、呼び出し側はメソッドを実行することを認められません。Webリソースへのアクセスも類似した方法で保護することができます。
セキュリティ・ロールは、EJBContextのメソッドisCallerInRoleおよびHttpServletRequestのメソッドisUserInRoleの中で使用されます。呼び出したプリシンパルが指定されたセキュリティ・ロールの中にあれば、各メソッドは trueを返します。
J2EE製品プロバイダーは、ユーザ認証に関する次の要求を満たす必要があります。
全てのJ2EE Webサーバは、各Webユーザのログイン・セッションを維持する必要があります。(略)
全てのJ2EE製品は、3つのログインの仕組みをサポートする必要があります。: HTTPベーシック認証、SSL相互認証、フォーム・ベース・ログイン。アプリケーションは、どれかの仕組みを使わなければならないというわけではありませんが、どんなアプリケーションからでも使えるようにする必要があります。
全てのJ2EE製品は、HTTPベーシック認証(RFC2068)をサポートする必要があります。プラットフォーム提供者は、SSLでのBASIC認証もサポートする必要があります。
SSL3.02、および相互の(クライアントとサーバー)証明書ベースの認証を実行する手段は、この仕様によって要求されます。
全てのJ2EE製品はクライアントとの相互運用性を保証するため次の暗号スイートをサポートしなければなりません:
これらの暗号スイートは主なWebブラウザによってサポートされ、米国政府輸出制限に対応します。
2SSL 3.0 仕様書は http://home.netscape.com/eng/ssl3 にあります。
認証モデルを
この仕様はセキュリティの監査を目的として必要条件を指定しません、適切な出来事、および、監査レコードを生成するアプリケーション・コンポーネント用のAPI。この仕様書の将来のバージョンは、監査を提供することに決める製品用のそのような仕様を含んでいるかもしれません。
いくつかのアプリケーションは、単にデータのタイプではなく、データの内容に基づいたそれらのデータへのアクセスをコントロールする必要があります。 私たちはこれを参照します、として「実例に基づいた」「クラスに基づいた」アクセス・コントロールではなく。 私たちは、将来のリリースにこれをアドレスすることを望みます。
Webベースのインターネット・アプリケーションはユーザが新しい顧客として名簿登録することを可能にして、1セットの顧客をしばしばダイナミックに管理する必要があります。 このシナリオは、servletのエキスパートのグループ(JSR-53)で広く議論されました。しかし、私たちは、適切な解決についての一致を達成することができませんでした。 私たちは、J2EE 1.3のためのこの仕事を放棄しなければなり、J2EE 1.4を目的としてそれをアドレスすることができませんでしたが、将来のリリースの中でそれをさらに追求することを望みます。
この章は、Java 2 Platform, Enterprise Edition (J2EE) トランザクション管理および実行時環境の要件について記述します。
本章に記述されるように、製品プロバイダーは単一のJ2EE製品内の多数のコンポーネントおよびトランザクション(業務処理)リソース(資源)を含んでいるトランザクションを透明にサポートしなければなりません。 この要求は、単一のプロセス、同じネットワーク・ノード上の多数のプロセスあるいは多数のネットワーク・ノード上の多数のプロセスとしてJ2EE製品が実装されるかどうかにかかわらず満たされなければなりません。
次のコンポーネントは業務処理・リソース(資源)と考えられ、ここに指定されるように作用しなければならない:
XATransactionトランザクション・レベルを指定するリソース・アダプタのためのリソース・アダプタ・コネクションJ2EEプラットフォームは、
この章は、Java 2プラットフォーム、エンタープライズ・エディションのためのネーミング・システム要求について記述します。これらの要求はJNDI仕様書の中で定義された機能に基づきます。
メモ - 本章の大部分は、EJB仕様書の「エンタープライズBean環境」の章に基づきます。
J2EEプラットフォームのためのネーミング要求は次の2つの問題を扱います:
J2EEアプリケーション・クライアント、エンタープライズBeansおよびWebコンポーネントはJNDI ネーミング環境にアクセスできることを要求されます。これらのアプリケーション・コンポーネント・タイプのためのコンテナはここに記述されたネーミング環境サポートを提供することを要求されます。
配備記述子(deployment descriptor)はアプリケーション・アセンブラー(組立者)および配備者へビジネス・ロジックのカスタマイズのためのアプリケーション・コンポーネントの要求に関するアクセス情報、および外部仕様情報のアクセス情報を伝達するための主要な媒体です。ここに記述された配備記述子エントリーは、これらのアプリケーション・コンポーネント・タイプの各々のための配備記述子スキーマ中の同一の形式の中にあります。詳細に関しては、各アプリケーション・コンポーネント・タイプに対応する仕様書を参照してください。
アプリケーション・コンポーネントのネーミング環境は配備または組立中にアプリケーション・コンポーネントのビジネス・ロジックのカスタム化を許容する仕組みです。アプリケーション・コンポーネント環境を使うことで、アプリケーション・コンポーネントのソース・コードに触ったり変更する必要なしに、アプリケーション・コンポーネントをカスタマイズすることを可能にします。
(略)
この章は、Java 2 Platform, Enterprise Edition (J2EE)のためのAPI要求について記述します。J2EEは、J2EEアプリケーションによる使用のために、コアJava APIをはじめ、いくつかのJavaのオプショナル・パッケージ1を含む、多くのAPIの準備を要求します。
1メモ 「オプショナル・パッケージ」は以前は「標準拡張」と呼ばれていました。
J2EEアプリケーション・コンポーネントは、J2EEプラットフォームの部品であるコンテナによって提供される実行環境中で実行します。J2EEプラットフォームはJ2EEアプリケーション・コンポーネント・タイプに対応する4つのタイプのコンテナをサポートします: アプリケーション・クライアント・コンテナ、アプレット・コンテナ、サーブレットとJSPのページのWebコンテナ、およびエンタープライズBeansコンテナ。
コンテナーはアプリケーション・コンポーネントすべてに次のAPIを含むJava 2 Platform, Standard Edition, v1.4 (J2SE) APIを提供します:
アプレット実行環境は特にJ2SE 1.4と互換性を持たなければなりません。代表的なブラウザーがまだそのようなサポートを提供しないので、J2EE製品は必要なアプレット実行環境を提供するためにJava Pluginを利用するかもしれません。Java Pluginの使用は要求されないが、J2SEに1.4の互換性をもつアプレット実行環境を提供するために要求を満たす1つの手段です。
J2SEで含まれているJDBC APIのバージョンが以前に個別のAPIだったJDBC拡張API(JDBC Extension API)を含むことに注意してください。JDBCコアAPIおよびJDBC拡張APIの両方は現在J2SEの一部で、同様にJ2EEの一部でもあります。
J2SE APIの仕様書は http://java.sun.com/j2se/1.4/docs/ にあります。
J2EE プラットフォームはさらに多くのJavaのオプションのパッケージを要求します。 表J2EE.6-1は、それらの必要なオプションのパッケージとバージョンを示します。
| Optional Package | App Client | Applet | Web | EJB |
|---|---|---|---|---|
| EJB 2.1 | Ya | N | Yb | Y |
| Servlet 2.4 | N | N | Y | N |
| JSP 2.0 | N | N | Y | N |
| JMS 1.1 | Y | N | Y | Y |
| JTA 1.0 | N | N | Y | Y |
| JavaMail 1.3 | Y | N | Y | Y |
| JAF 1.0 | Y | N | Y | Y |
| JAXP 1.2 | Y | N | Y | Y |
| Connector 1.5 | N | N | Y | Y |
| Web Services 1.1 | Y | N | Y | Y |
| JAX-RPC 1.1 | Y | N | Y | Y |
| SAAJ 1.2 | Y | N | Y | Y |
| JAXR 1.0 | Y | N | Y | Y |
| J2EE Management 1.0 | Y | N | Y | Y |
| JMX 1.2 | Y | N | Y | Y |
| J2EE Deployment 1.1c | N | N | N | N |
| JACC 1.0 | N | N | Y | Y |
a. クライアントAPIのみ
b. クライアントAPIのみ
c. 詳細はJ2EE.6.18章 ページ109参照
J2EEコンテナーは、APIのための仕様書によって要求されたクラス、およびインターフェースをすべてを提供しなければなりません。
ある場合には、J2EE製品がインターフェースを実装するオブジェクトを提供するためには要求されません、アプリケーション・サーバーによってしかしながらインプリメントされるつもりだった、そのようなインターフェースの定義はJ2EEプラットフォームで含まれているに違いありません。
J2EEプログラミング・モデルは、アプリケーション・コンポーネント・プロバイダとJ2EE製品プロバイダで責任(義務)を分配します: アプリケーション・コンポーネント・プロバイダはビジネス・ロジックを書くことに集中し、J2EE製品プロバイダはアプリケーション・コンポーネントを配備することができる管理されたシステム・インフラの提供に集中します。
この区分は、アプリケーション・コンポーネントが含むことができる機能性に対する制限に結びつきます。アプリケーション・コンポーネントがJ2EEシステム・インフラによって提供される同じ機能性を含んでいる場合、機能性の衝突および取り扱いがあります。
例えば、もしエンタープライズ・ビーンズがスレッドを管理することを許されれば、J2EEプラットフォームはエンタープライズ・ビーンズのライフ・サイクルを管理することができることができません。また、それは正しくトランザクションを管理することができません。
J2SEプラットフォームをサブセット化せず、私たちが、J2EE製品プロバイダーにJ2EEプラットフォームの中で修正のないJ2SE製品を用いることができてほしいので、私たちはプログラムする制限がアプリケーションに構成要素のプロバイダー(Component Providers)を課したことということを表現するためにJ2SEセキュリティ許可メカニズムを用います。
この章では、私たちが、J2EE製品プロバイダが各アプリケーション・コンポーネント・タイプに提供しなければならないJ2SEセキュリティ・パーミッション(許可)を指定します。 私たちはこれらのパーミッションをJ2EEセキュリティ許可セットと呼びます。 J2EEセキュリティ許可セットはJ2EE API契約の要求された部分です。 J2EEコンテナーの完全を保証するために、J2EEコンテナーはすべてセキュリティ・マネージャーをインストールしなければならず、アプリケーションがセキュリティ・マネージャーを交換したり無視するのを防がなければなりません。
J2EEセキュリティ許可セットは、アプリケーション・コンポーネントが要求することができる許可の最小のセットを定義します。 J2EE製品はすべて、ここに記述された許可のセットを要求するアプリケーション・コンポーネントを展開させることができなければいけません。製品プロバイダ(Product Provider)は、アプリケーション・コンポーネントがJ2EEセキュリティ許可セットと矛盾する機能を使用しないことを保証しなければなりません。
特別の装置の使用中のアプリケーション・コンポーネントのためのセキュリティ許可の正確なセットは、この仕様書の範囲の外側の方針の問題です。いくつかのJ2EE製品は、コンポーネントに利用可能な許可のセットが、いくつかのコンポーネントにここに記述されたものより多くあるいはより少数の許可を供給して、輪郭をとることができることを可能にするでしょう。
この仕様書の将来のバージョンは、アプリケーション・コンポーネント用の配備記述子中でこれらのセキュリティ必要条件が指定されることを可能にするでしょう。
現在、この最小のセット中の許可を必要としないアプリケーション・コンポーネントはそれらのドキュメンテーションにそれらの必要条件について記述するべきです。
いくつかのJ2EE製品上ではこの最小のセットを越えるものを要求するアプリケーションを展開させることが可能ではないかもしれないことに注意してください。
J2SEセキュリティ許可は、http://java.sun.com/j2se/1.4/docs/guide/security/permissions.htmlに完全に記述されます。
この仕様では、J2EE製品がEJB 2.1仕様で定義されるエンタープライズBeanのサポートを提供することを必要とします。EJB仕様書は http://java.sun.com/products/ejb/docs.html にあります。
この仕様では追加の要件を規定しません。EJB仕様がRMI-IIOPに基づいたEJB相互運用プロトコルの仕様を含むことに注意してください。EJBクライアントをサポートする全てのコンテナは、エンタープライズBeanを呼び出すためにEJB相互運用プロトコルを利用できなければなりません。全てのEJBコンテナは、EJB相互運用プロトコルを用いて、エンタープライズBeanの呼び出しをサポートしなければなりません。J2EE製品は、さらにエンタープライズBeanの呼び出しのための他のプロトコルをサポートすることもできます。
J2EE製品は多くのオブジェクト・システム(たとえばRMI-IIOPとRMI-JRMP)をサポートするかもしれません。オブジェクトの参照を1つのオブジェクト・システムから別のオブジェクト・システム中のオブジェクトへ渡すことは、必ずしも可能ではないかもしれません。しかしながら、エンタープライズBeanがRMI-IIOPプロトコルを用いている場合、そのようなエンタープライズBeanについてRMI-IIOPやJava IDLをエンタープライズBeanのメソッドの引数として用いてオブジェクトの参照を渡したり、オブジェクトの参照をエンタープライズBeanのメソッドの戻り値としてすことは可能である必要があります。さらに、 RMI-IIOPベース・エンタープライズBeanのHomeまたはRemoteインターフェース参照をRMI-IIOPかJava IDLオブジェクトのメソッドに渡したり、エンタープライズBean戻り値
サーブレット仕様は、スタンドアロンでもJ2EEアプリケーションの一部としても、Webアプリケーションのパッケージングおよび配備について定義します。サーブレット仕様はスタンドアロンおよびJ2EEプラットフォームのどちらもセキュリティについて扱います。サーブレット仕様のこれらのオプションのコンポーネントは、J2EEプラットフォームでは要求条件です。
Servlet仕様はJ2EE製品の一部であるWebコンテナのための追加の要求を含んでおり、J2EE製品の一部であり、J2EE製品も同様にこれらの要求を満たす必要があります。
サーブレット仕様は分散できるWebアプリケーションを定義します。分散できるJ2EEアプリケーションをサポートするためにこの仕様は次の要求を加えます。
Webコンテナは、setAttributeまたはputValueメソッドを使用してjavax.servlet.http.HttpSessionオブジェクトに次の型のいずれのオブジェクトも入れることのできるJ2EE分散可能Webアプリケーションをサポートしなければなりません:
java.io.Serializablejavax.ejb.EJBObjectjavax.ejb.EJBHomejavax.ejb.EJBLocalObjectjavax.ejb.EJBLocalHomejavax.transaction.UserTransactionjava:comp/env コンテキストの javax.naming.Context オブジェクトWebコンテナは、同様に他の型のオブジェクトをサポートするかもしれません。上記のタイプ以外の型やその他のコンテナにサポートされた型が、J2EE分散可能セッションに対応するHttpSessionオブジェクトのsetAttributeまたはputValueメソッドに渡される場合、Webコンテナはjava.lang.IllegalArgumentExceptionを投げなければなりません。この例外は、WebコンテナがオブジェクトのVM間の移動をサポートしていないことをプログラマーに指示します。マルチVMオペレーションをサポートするWebコンテナは、セッションが1つのVMから他のVMに移動する場合、サポートされる型の全てのオブジェクトが対象のVMに引き継げることを保証する必要があります。
サーブレット仕様は、ローカル・エンタープライズBeanへのアクセスをオプション機能として定義します。この仕様は、全てのJ2EE製品がWebコンテナからローカル・エンタープライズBeanへのアクセスのサポートを提供することを必要とします。
サーブレット仕様は http://java.sun.com/products/servlet で入手可能です。
JSP仕様はサーブレット・フレームワークの上に構築され、依存しています。J2EE製品は、JSP仕様全体をサポートしなければなりません。
JSP仕様は http://java.sun.com/products/jsp で入手可能です。
Javaメッセージ・サービス・プロバイダはJ2EE製品に含まれていなければなりません。JMS実装は、両方のJMSのサポートを提供するに違いない、指示するポイント、また公表する、/、メッセージを寄付し、ConnectionFactoryと目的地のAPIを用いて、それらの機能をしたがって有効にするに違いない。(略)
JavaMail APIは、メッセージ・ストアに含まれている電子メールメッセージへのアクセス、およびメッセージ・トランスポートを用いた電子メールメッセージの生成と送信を可能にします。 インターネット標準のMIMEメッセージのための特定のサポートが含まれています。 メッセージ・ストアおよびトランスポートへのアクセスは、特定のストアおよびトランスポート・プロトコルをサポートする、プロトコル・プロバイダによって提供されます。 JavaMail API仕様は特定のプロトコル・プロバイダを要求しません。しかし、JavaMail リファレンス実装はIMAPメッセージ・ストア・プロバイダ、およびSMTPメッセージ・トランスポート・プロバイダを含んでいます。
JavaMail APIの構成は、静的なファクトリ・メソッドを用いて、javax.mail.Sessionオブジェクトを作成するために用いられるプロパティ・オブジェクト中でプロパティをセットすることにより特徴的に行われます。
J2EEプラットフォームがJavaMail APIセッションを形成し管理することを可能にするために、JavaMail APIを用いるアプリケーション・コンポーネントはJNDIを用いて、セッション・オブジェクトを要求するべきであり、リソース審判エレメントを用いて、その配備記述子におけるセッション・オブジェクトのその必要性をリストするべきです。
セクションJ2EE.5.4 、「リソース・マネージャー接続ファクトリ参照(Resource Manager Connection Factory References)」に記述されるように、JavaMail
APIセッション(Session)オブジェクトはリソース・ファクトリと考えられるべきです。
この仕様書は、そのセクションに記述されるようにJ2EEプラットフォーム・サポートjavax.mail.Sessionがリソース・ファクトリとして反対することを必要とします。
J2EEプラットフォームは、メッセージ・トランスポートがjavax.mail.internet.InternetAddress型のアドレスおよびjavax.mail.internet.MimeMessage型のメッセージを扱うことができることを規定されることを必要とします。
デフォルト・メッセージ・トランスポートをjavax.mail.Transportクラスのsendメソッドを用いて、そのようなメッセージを送信するために正しく形成しなければなりません。
デフォルト・トランスポートによって必要とされるいかなる認証も、アプリケーションがjavax.mail.Authenticatorを提供するかあるいはトランスポートに明示的に接続するべき必要なしに扱われ、認証情報を供給する必要があります。
この仕様書は、J2EE製品が任意のメッセージストア・プロトコルをサポートすることを必要としません。
ストア、フォルダーおよびトランスポート出来事の通知を伝えるために、JavaMail APIがスレッドを作成することに注意してください。
これらの通知機能の使用は、様々なコンテナーにおけるスレッドの使用に対する制限によって制限されるかもしれません。
EJBコンテナーでは、例えば、スレッドを作成することが特徴的に可能ではありません。
JavaMail APIは様々なMIMEデータ・タイプをサポートするためにJavaBeansアクティベーション・フレームワークAPIを用います。
JavaMail APIは、次のMIMEデータ・タイプ(テーブルJ2EE.6-4-の中で示されたJavaプログラミング言語タイプに対応する)のためのjavax.activation.DataContentHandlersを含んでいる必要があります。
(略)
JavaMail API 仕様書は http://java.sun.com/products/javamail にあります。
JavaBeans Activation(活性化) Frameworkは、JavaプラットフォームへMIMEデータ・タイプのサポートを統合します。MIMEバイト・ストリームはjavax.activation.DataContentHandlerオブジェクトを用いて、Java言語オブジェクト間で変換することができます。JavaBeansコンポーネントは、データを見るか編集するようなMIMEデータ上で作動するために指定することができます。JavaBeans アクティベーション・フレームワークはさらにMIMEタイプに対してファイル名拡張をマップするための仕組みを提供します。
電子メールメッセージに含まれたデータを扱うためにJavaBeansアクティベーション・フレームワークはJavaMail APIによって用いられます。電子メールの精巧な使用を行なうアプリケーションはそれを必要とするかもしれませんが、一般的なJ2EEアプリケーションはJavaBeansアクティベーション・フレームワークを直接用いる必要がないでしょう。
この仕様書は、J2EE製品がJavaMail APIのために上に指定されたDataContentHandlersだけを提供することを必要とします。これは、表J2EE.6-5の中でリストされたマップをサポートするjavax.activation.MimetypesFileTypeMapの要求を含んでいます。
| MIME型 | ファイル拡張子 |
| text/html | html htm |
| text/plain | txt text |
| image/gif | gif GIF |
| image/jpeg | jpeg jpg jpe JPG |
JavaBeansアクティベーション・フレームワーク 1.0仕様書は、http://java.sun.com/beans/glasgow/jaf.html にあります。
JAXPは、業界標準であるSAXおよびDOM APIを含んでいます、着脱可能APIはSAXとDOMのパーザ、XSLTエンジンをフレームワークの中で着脱し、アプリケーションに必要とされている機能をサポートしたパーサをアプリケーションが検索することを可能にします。
全てのJ2EE製品はJAXP適合要件を満たす必要があり、最新のSAX 2パーサー、DOM 2パーサーおよびXSLT変換エンジンを提供する必要があります。 それには全てのvalidation(確認)モードおよびnamespaceサポートの組み合わせをサポートするSAXパーサー(複数可)が必要です。 全てのvalidation(確認)モードおよびnamespaceサポートの組み合わせをサポートするDOMパーサー(複数可)が必要です。 JAXP 1.2仕様書に記述されるように、SAXおよびDOMパーサーはすべてDTDあるいはXMLスキーマ(XML Schemas)のいずれかを用いて、validation(確認)をサポートする必要があります。
JAXP仕様書は http://java.sun.com/xml/jaxp にあります。
すべてのEJBコンテナーおよびすべてのウェブ・コンテナは、フルセットのコネクターAPIをサポートする必要があります。そのようなコンテナはすべて、明示されたトランザクション能力のうちのいかなるものでも用いるリソース・アダプターをサポートする必要があります。コネクター仕様の中で定義されるように、J2EE配備ツールはリソース・アダプタの配備をサポートするに違いないし、リソース・アダプタを用いるアプリケーションの配備をサポートする必要があります。
コネクター仕様書は http://java.sun.com/j2ee/connector/ にあります。
J2EEのためのWebサービス仕様は、Webサービス終点の配備のためにJ2EEアプリケーション・サーバがサポートしなければならない能力を定義します。完全な配備モデルはいくつかの新しい配備記述子を含んで、定義されます。J2EE製品はすべて、Webサービス for J2EE 1.1仕様書(JSR-109)によって明示されるようなWebサービスの配備および実行をサポートする必要があります。
Web Services for J2EE仕様書は http://jcp.org/en/jsr/detail?id=109 および http://jcp.org/en/jsr/detail?id=921 にあります。
この章は、Java 2 Platform, Enterprise Edition (J2EE)のための相互運用要件について記述します。
J2EEプラットフォームは、様々なタイプのクライアントをサポートする企業環境によって用いられるでしょう。 企業環境は既存の企業情報システム(Enterprise Information Systems)(EIS)に対して新しいサービスを加えるでしょう。 それらは様々なハードウェア・プラットフォームおよび様々な言語で書かれたアプリケーションを用いるでしょう。
次の種類のアプリケーションのうちのいかなるものでもともにもたらすために企業環境におけるJ2EEプラットフォームは、企業環境の中で特に用いられてもよい:
それはJ2EEプラットフォームの相互運用要求です、本章へ明記する、それはそれが様々なタイプのクライアント、異なるハードウェア・プラットフォームおよび多数のソフトウェア・アプリケーションの間接のサポートを提供することを可能にします。 これらの部分をともに連結するのに必要な複雑さの多くを隠している間、J2EEプラットフォームの相互運用機能は根本的な異種のシステムがともにシームレスに働くことを可能にします。
現在のJ2EEプラットフォーム・リリースのための相互運用要求は許可します:
仕様書のこのバージョンでは、異なるプラットフォームの中で走るJ2EEアプリケーション間の相互運用が、HTTPプロトコル、恐らくSSLを用いること、あるいはIIOPに基づいたEJB相互運用プロトコルを通って遂行されます。
この仕様書は、J2EEアプリケーション間の、およびさらにこれらのプロトコルおよびフォーマットをインプリメントする、他のアプリケーションを備えた相互運用を保証するために、J2EE製品がプロトコルおよびフォーマットの標準のセットをサポートすることを必要とします。 仕様書は、プロトコルとフォーマットの次のグループのサポートを要求します:
ほとんどのこれらのプロトコルおよびフォーマットはJ2SE、および根本的なオペレーティング・システムによってサポートされます。
この章では、Java™ 2 Platform, Enterprise Edition (J2EE) アプリケーション・クライアントについて記述します。
アプリケーション・クライアントは、