(このトピックは編集中です。)

アクティビティ(英：Activity)はDTRへ対する変更の開発及び移送の管理単位です。ABAPスタックにおける変更依頼に相当します。

アクティビティはOpenとClosedとの二つのステータスがあります。

• Open Activity 
  変更中のアクティビティです、ここで行う任意の変更を元に戻すことができます。
• Closed Activity 
  チェックインした後のアクティビティです。これらのアクティビティを変更することはできなくなります。

このセクションはアクティビティ のライフサイクルを順次説明します。

DTRはファイルバージョン管理を提供するリポジトリです。SAP のカスタマサイトやパートナサイト、および SAP 自社開発で使用されます。

DTRは以下のコンセプトがあります。

• ソースコード及びバージョンを一元管理 
  DTRでは、すべてのソースプログラム及びバージョンはセントラルデータベースで一元管理され、 標準DeltaVおよびWebDAVアクセスプロトコルによってDTR クライアントに階層ファイルシステムを公開されます。 
  そのため、DTRはCVS、SVNと同じ、集中型バージョン管理システムといえます。
• 変更を確実に管理 
  ソースコードに改修が発生する時に、まず変更依頼を作成しておかないといけない、改修はすべて変更依頼に記録されます。 
  これは本来プロジェクト管理システムの一部機能であり、よくチケットやチケット駆動開発と呼ばれています。DTRに統合されることにより、システムの変更がすべて確実に管理されることになります。
• ライフサイクルの各フェーズを統合的にサポート 
  開発やテストの各フェーズの間にソースの変更と移送が一元管理されます。

(source: sap help portal)

DTRリポジトリは、複数の論理開発ロケーション(仮想リポジトリ)から構成されます、その論理開発ロケーションはワークスペースと呼ばれます。

ワークスペースはDTR構造の基本要素であり、以下のような仕組みで機能しています。

• ソフトウェアコンポーネント単位でワークスペースが分けられます。
• 4システムランドスケープの中でDEVとCONSが異なるワークスペースを使用、TESTとPRODが持たないことが多い
• 各システム(DEV、CONS）を無効と有効との二つのDTRワークスペースで表現。全ての変更は無効なワークスペースで実行し、ビルドが完了したソースのみが有効なワークスペースに格納されます。有効なワークスペースはCBSで利用可能なアーカイブと常に同期します。
• 同じソースはワークスペースに跨ってDTR全体で一元管理されます。そういう意味で、ワークスペースはSVN、GITなどのような一般のバージョン管理システムにおけるブランチに相当するものと考えられます。

以下、DTRの構造のイメージです。 

 
system-tools 
-|administration 
-|reports 
--|Activity Search 
--|Conflict Search 
--|File/Folder Search 
--|Resource Lookup 
--|VersionSet Comparison 
--|Workspace Comparison 
--|Workspace Integrations 
ws 
-|track_1 
--|sc1 
---|cons 
----|active 
----|inactive
---|dev   

サポートツールでは、CMS管理用の幾つかのツールが提供されております。

URL:http://host:port/CmsSupportTool/

CMSシステムで発生していた各プロセス(インポート、ビルド、承認)の情報を照会できます。

CMSシステムで作成されていたアクティビティを検索することができます。

指定ソフトウェアコンポーネント(SC）が取り込まれたトラックを検索することができます。

指定トラックに取り込まれたソフトウェアコンポーネント(SC)の情報を照会できます

システムステートを削除できます。

以下の図でトラック内移送の概要を示します。 

開発者側の作業はすべてNWDSで実施されます。

開発者が作成又は変更したソースをチェックインしたら、該当ソースはDTRのinactiveワークスペースからactiveワークスペースに反映され、有効化されます。 
ソースが有効化すると、元開発者が保持したロックが解放されるため、同じ開発設定を使用するすべての開発者から再度修正をかけることができます。 
有効化されるソースは、CBSにより再ビルドされます。

有効化及び開発システムでのテストが正常に完了すると、開発者はアクティビティをリリースし、CMSに変更を転送します。 
これによって、開発者に選択された全てのアクティビティが一つのリリースに纏められ、コンソリデーションシステムのインポートキューに格納されます。

ABAPスタックの移送ディレクトリと異なり、インポートキューはファイルシステムではなくデータベースにされます。 
CMS_TQUEUE：インポートキュー 
CMS_THISTORY:インポート履歴 
CMS_RCHANGELIST: 変更依頼の割当

管理者側の作業は、WEB画面のTransport Studioで実施されます。

インポートは、インポートキューに入っている変更依頼を選択してコンソリデーションシステムに取り込みします。 
CMSによって、自動ビルドと関連する実行時システムへの自動デプロイが行われます。

ログファイルです。 
CMS/log：　エクスポート及びインポートのログ 
CMS/archives:　エクスポート時に生成されるscaファイルおよびpraファイル 
CMS/CBS`: デプロイのためにCBSによって生成されるsdaファイル

アセンブリは構築のことです。 
この間に変更依頼が収集され、それに基づいて、すべての変更依頼を含めたSCバージョンが作成されます。 
個々の変更依頼はこれ以降の転播に使用されません

承認とは、テストシステムで検証が完了したSCを本稼働システムへの移送を許可することです。 
承認によって、本稼働システムのインポートキューにSCが格納されます。

現場レベルのシステム開発環境は通常、連続する複数の開発トラックで構成されます。以下の理由がよくあげられます。

• 複数の検証環境が存在するため、複数のトラックを定義する必要
• 開発と保守を分けるため、複数のトラックを定義する必要
• ソフトウェアコンポーネントを別々開発するため、複数のトラックを定義する必要

(source:SAP Help Portal)

トラック間移送を行うには、トラック間の接続を設定しておく必要があります。

開発トラックとは、1つの開発の流れを定義します。

開発トラックには、開発されるSCのさまざまな開発ステータスの開発設定及び実行時システムが含まれます。

(source: SAP Help Portal)

セントラル開発システム(DEV)では、開発者のローカルPCで作成したソースを個々の開発者がさらにテストをします。

コンソリデーションシステム(CONS)は、特定の固定ステータスのSCの統合とそのSCの追加テストに使用されます。

その後、本稼働システム(PROD）へ適用する前に、テストシステム(TEST)でSCの新規バージョンを最終テストをします。

必要に応じて、これらの4つのシステムロールを実行時システムに割り当てることができます。実行時システムでは、インポート時に自動的にデプロイが実施されます。

• 開発トラックを使用した作業 - SAP Help Porta

CMSはソフトウェアの変更を一元で管理可能にするサービスです、JavaシステムのCMSはABAPシステムのCTSと同等します。

CMSのコンセプトは主に以下になります。

• ソースの改修を開発システムに限定します。
• 手作業ミスをなくし、システムにより改修内容を確実に開発システム→テストシステム→本番システムの間に移送します。
• ソフトウェアの構築とデプロイを自動化可能にします。

開発ドメインは、システムランドスケープ全体の構成を定義します。

開発ドメインには複数の開発トラックを含めることができます。

開発トラックは一つの開発の流れを定義します。 
一つの開発トラックには、一つ以上のソフトウェアコンポーネントの開発、テスト、本稼働に必要な開発設定と実行時環境がすべて組み込まれます。

CMSにおけるシステムは、厳密的にはシステムロールのことであり、開発設定と実行環境から構成され、各フェーズ(開発、コンソリデーション、テスト、本稼働)に対応します。 

CBSはシステムの構築作業を集中管理可能にして、 NWDIにおいて中心的な役割を果たしています。

CBSは主に以下の機能を提供しています。

• オンデマンドのビルド 
  変更のセントラルビルドは依頼によりリアルタイムで発生します。変更がチェックインして有効化される際に自動的に依頼されることもあれば、管理者が明示的に指示することもあります。
• ビルド結果およびビルドツールの一元的な保管
• 有効化コンセプトの保証 
  開発オブジェクトの無効および有効ステータスが区別されます。無効ステータスのオブジェクトから有効ステータスのオブジェクトに変更を渡すには、これらを有効化しなければなりません。この前提条件は、変更された開発コンポーネントのセントラルビルドが正常に行われていることです。

NWDIの管理ツールを利用するフロントエンドは、おもにNWDSとWEB画面との2種類があります。

NWDSでは、NWDIをアクセスするためのフロントエンドツールとして、さまざまなパースペクティブとビューが組み込まれています。 

• Component Browserビュー 
  以下の作業を実施することができます。
  • SC/DCを照会
  • DCをローカルに取り込み、プロジェクトを作成
  • SCをscaファイルにExport
  • DCをビルド、デプロイ
• Component Propersビュー 
  以下の作業を実施することができます。
  • コンポーネントの構成や依存関係を照会

• Repository Browsesrビュー 
  以下の作業を実施することができます。
  • ソースファイルの内容及び履歴などを照会
• Open Acvitiesビュー 
  以下の作業を実施することができます。
  • 未チェックインのActivityを照会
  • 変更をチェックイン
  • 変更を廃棄
• Closed Acvitiesビュー 
  以下の作業を実施することができます。
  • チェックイン済のActivityを照会
• Integration Conflictビュー 
  以下の作業を実施することができます。
  • ワークスページ統合時に発生したConflictを照会、処理
• Version Graphyビュー 
  以下の作業を実施することができます。
  • ソースファイルのトラックに跨ったバージョン履歴を図で表示

• Transport Viewビュー 
  以下の作業を実施することができます。
  • 未リリースの変更依頼をリリース
  • 未リリースまたはリリース済の変更依頼を照会

• Activation Viewビュー 
  以下の作業を実施することができます。
  • チェックイン済のActivityを有効化
• Activation Requestビュー 
  以下の作業を実施することができます。
  • 有効化リクエストのステータスを確認

URL:http://domain:port/devinf/main 

URL:http://domain:port/dtr/

URL:http://domain:port/webdynpro/dispatcher/sap.com/tc~SL~CMS~WebUI/Cms 

URL:http://domain:port/webdynpro/dispatcher/sap.com/tc.CBS.WebUI/WebUI 

NWDIを使用した開発の流れは製品・リリース毎に設計、管理され、通常、開発準備→開発→移送及びテスト→本番稼働→運用保守などのフェーズに分けられます。
NWDIで開発流れは開発トラックで定義されます。
製品が本番稼働後、大きなアップグレードは別のリリースをとり、新しい開発流れを起こしますが、不具合修正やある程度の機能改善は、運用保守フェーズとして、同じ開発流れで対応するのが一般的です。

NWDIを使用した開発を始めるまえに、まず下記のようにNWDIの環境を整える必要があります。

• 構成要素(DTR、CBS、CMS、SLDなど)のインストール
• システムランドスケープに関する情報の更新

開発準備は以下のステップがあり、基本は管理者の作業となります。

1. ユーザ及びロールの登録　UMEAdmin
2. 製品及びソフトウェアコンポーネントの作成　SLD
3. 名称領域の予約　ネームサーバ
4. CMSドメインの作成　CMS
5. システム、トラック、開発設定の作成　CMS 
   トラックによって1つ以上のSCで構成されるリリースの開発フェーズが定義されます。 
   開発設定は、SCの特定のステータス(DEV、CONS）の開発に必要です。
6. 必要なソフトウェアコンポーネントの確認とインポート　CMS
7. ローカル開発環境の設定　NWDS

開発は、開発者の作業であり、ローカルのNWDSを使ってNWDI各サービスに接続して実施します。

開発作業は主に以下のステップになります。

1. チェックアウト
2. ソースの作成又は変更
3. ビルド
4. ローカルテスト
5. チェックイン
6. セントラルビルド、有効化
7. デプロイ
8. リリース

CMSを使用して、移送、テスト、アセンブリを行います。 
移送、アセンブリは管理者の作業であり、テストは開発者又はテスタが実施します。

CMSを使用してソフトウェアコンポーネントのバージョンを出荷します。

NWDIのコンポーネントモデルは、製品、ソフトウェアコンポーネント(SC)と開発コンポーネント(DC)の三つのレイヤから構成されます。 
開発コンポーネント(DC)にはさまざまな開発オブジェクトが含みます。

製品は、 価格設定と販売の単位であり、一つ以上のソフトウェアコンポーネントを集めたものです。1つのソフトウェアコンポーネントを複数の製品に含めることができます。
SAP社が販売した「製品+バージョン」は3000近くあり、その中に一番有名なのはSAP ERPに違いがないです。 
SLDの「製品とソフトウェアコンポーネントの照会」画面から、SAP社の製品を確認することができます。 

ソフトウェアコンポーネント (SC) は出荷およびインストールの単位であり、開発コンポーネントを重複せずにまとめたものです。 
通常のファイル形式はSCA形式です。

MDM(Master Data Management)という製品を例として、SLDの「製品とソフトウェアコンポーネントの照会」画面から製品の中身を確認してみます。

上記の図で示した通り、MDM製品には数多くのソフトウェアコンポーネントが含められております。 

開発コンポーネント (DC) は開発およびビルド、デプロイの単位です。 
開発コンポーネントは、明確な外部インタフェースとカプセルされた内部実装があり、他のコンポーネントのパブリックインタフェースを参照して相互使用することができます。そのため、基本的な再利用可能な単位になります。

通常のファイル形式はSDA形式です。

以下はNWDSから取得したDCのコンポーネントプロパティビューのイメージです。 

開発オブジェクトは、コンポーネントの構成要素で、機能部分を提供します。

ソフトウェアの保守は、パッチ、サポートパッケージ、アップグレードの3つのレイヤに分かれます。

パッチ(英：Patch)は開発コンポーネント(DC)レベルで配布されます。主に発見されたプログラムバグを修正するために開発、適用されます。

パッチにソースが含まれている場合、CMSのリソースを使用してインポートする必要があります。

サポートパッケージ(英:Support Package、略：SP)は、ソフトウェアコンポーネント(SC)レベルで配布されます。、幾つかのパッチを含みます。

サポートパッケージにソースが付属している場合は、CMSを使用して、トラックにサポートパッケージをチェックインして移送する必要があります。 
サポートパッケージにアーカイブのみが含まれる場合、SDMを使用して関連するシステムに直接インポートすることができます。

製品にどんなサポートパッケージが提供されているかは、SLDの「製品とソフトウェアコンポーネントの照会」画面から確認できます。

アップグレードは製品単位で実施されます、製品に大きな機能強化や新規機能の追加があった場合、新しいリリースが配布されます。 
アップグレードはCMSを使用しません。

開発の視点からは、開発モデルの基本構成となるものは、ソフトウェアコンポーネント(SC)と開発コンポーネント(DC)になります。

• SCは複数のDCを纏める大きい単位になり、SC情報とSC間の依存関係はSLD上に登録する必要があります。
• 開発設定はソフトウェアコンポーネント(SC)単位で管理されます。
• SC名はシステム全体としてユニークである必要があり、最初に設定した名称を変更することはできない。
• 移送はSC単位で分けられます。
• DTRのワークスペースはSC単位で分けられます

• DCは最小の開発単位（Web Dynpro JAVA, CAF等）でSCの配下に定義します。
• DC毎にNWDS環境でJAVA開発プロジェクトが作成されます
• DC間の再利用定義は利用される側からはPublicパーツを定義して利用する側は該当Publicパーツを参照するようになります。
• DC名はシステム全体としてユニークである必要があります。
• DCの参照設定はNWDSの「Development Infrastructure」パースペクティブウィンドウから行います。
• 参照対象のDCを「Component Properties」Viewの「Dependencies」タブから追加します。
• 「Dependency Details」は「Design Time」「Runtime」を設定して「Deploy Time」は外すようにします。

製品には、リリース番号がバージョンになります。 
例えば、NetWeaver AS Java は7.0、7.1、7.2、7.3、7.4などのバージョンがあります。

ソフトウェアコンポーネントのバージョン番号には、製品のバージョン、サポートパッケージのバージョンが含められます。 
システム情報画面からインストール済のソフトウェアコンポーネントのバージョンを確認することができます。

NWDIは、システムの開発作業を一つのプラットフォームに統合することにより、集中管理が可能になります。

NWDIでは以下の作業がすべて集中管理できるようになっております。

• ソースプログラムの集中管理化⇒DTR
• 構築配置作業の集中管理化⇒CBS
• 変更管理移送作業の集中管理化⇒CMS

(source: sap help portal)

上記のアーキテクチャ図で示したとおり、NWDIを構成する要素は、NWDS、DTR、CBS、CMSがあります。

• NWDS
  NWDSにおけるJavaアプリケーションの開発は、ソフトウェアコンポーネントモデルを基準としております。従ってソフトウェアプロジェクトが、開始時から管理しやすい再利用可能な単位に体系的に構造化されます。
• DTR
  DTRでは、バージョンニングソースコードを管理できるため、チームにおけるソフトウェアの分散開発、及びソースの移送と複製が可能です。
• CBS
  CBSは、ソースコードのセントラルビルドに使用されます。開発者の操作はNWDSに統合されます。CBSはビルドプロセスのために自動的にDTSと通信います。
• CMS
  CMSは、JAVA開発ランドスケープ、及びソフトウェアライフサイクル全体に渡る移送を集中管理するため、に使用します。CMSの機能は、DTR、CBS及びSLDに緊密に統合されています。

NWDIは開発者と管理者のためにそれぞれロールを用意しています。

• 管理者ロール 
  NWDI.Administrator
• 開発者ロール 
  NWDI.Developer

SLD は、HTTPでアクセスできるサーバアプリケーションであり、AsJava上で動作します。

SLDに登録されているシステムは、デフォルトで12時間毎に自システムの情報をSLDに送信するようにしています。

以下の機能をもっております。

• サーバ情報管理
• ソフトウェア情報管理
• 名前予約管理

SLDの管理機能をアクセスするには、以下の方法があります。

• 管理インタフェース：
  URL: http://host:port/sld
• WebDynroアプリケーション
  http://host:port/webdynpro/dispatcher/sap.com/tc~sld~wd~main/Main

URL：http://host:port/sld

サービスやサービスグループを定義します。

サービスを提供するプロバイダーシステムのサーバ情報を定義します。

Webサービスには広義と狭義の二つがあります。

広義の「Webサービス」は、WEB通信を利用した、プログラミングでアクセス可能なサービスのすべてが含められます。
一方、狭義の「Webサービス」は、SOAP(Simple Object Access Protocol)やWSDL(Web Services Description Language)ベースのWebサービスに限定されます。SOAP/WSDLサービスと呼ぶことができます。
Webサービスという名前も、このSOAP/WSDLサービスから初めて使われたものと考えられます。

WEBサービス(広義)を実現する基礎技術としては、古典的な技術を代表するこのSOAPとWSDLのほかに，昨今急速に普及してきたREST(Representational State Transfer)があります。RESTベースのWEBサービスはRESTfulサービスと呼ばれております。
http://www.ibm.com/developerworks/jp/webservices/library/ws-restful/

高機能で複雑のSOAP/WSDLサービスと比べると、RESTfulサービスはシンプルで簡単に利用可能であるため、現在、後者のほうがWeb全体で広く受け入れられるようになっています。
とはいえ、歴史のこともあるため、とくに企業向けの大規模なシステムは、まだまだSOAP/WSDLサービス技術で構築されているほうが多いと考えられます。

このトピックやカテゴリは、狭義の「Webサービス」のみを対象としているため、特別な説明がない限り、文書に記述されている「Webサービス」という用語はすべて狭義の「Webサービス」を指しております。

Webサービスは、主に以下のような特徴があります。

• プラットフォーム独立　
  HTTP、SMTP、XML等の標準仕様を積極的に活用しているため、Webサービスの実装は特定のプラットフォームや言語に依存しません。　
  異なるプラットフォームで実装されているWebサービスは標準仕様に従って簡単に相互接続ができます。
• 実行時に動的に連携
  WEBサービスは実行時に動的に連結されます。よってサービス指向アーキテクチャ(SOA)に従えば柔軟性、敏捷性（agile）とも優れる疎結合分散アプリケーション環境が簡易に実現できます。

WEBサービス連携の流れは以次の三つの部分からなります。

1. 登録
   サービスを提供する側は、サービスの接続情報をどこかに登録しておきます。
2. 接続情報の検索　
   サービスを使用する側は、サービスを利用するための接続情報をどこかで検索します。開発時と実行時の二つの場面があります。
3. 接続
   サービスを使用する側は、サービス接続情報を利用して、サービスを提供する側に接続して、サービスを利用します。

WEBサービスの関連仕様は以下のものがあります。

• SOAP
  メッセージフォーマットに関する仕様
• WSDL
  サービス界面仕様の記述フォーマットに関する仕様
• UDDI
  サービス連携をサポートするディレクトリに関する仕様および実装
• WSIL
  UDDI の代替であり、また UDDI に対する補足でもあるサービス・ディスカバリー機構

SOAP(Simple Object Access Protocol)とは、非集中、分散環境における情報交換のための軽量のプロトコルです。SOAPのメッセージはXMLを用いて符号化します。
SOAPは次の3つの部分から成ります。

• SOAPエンベロープ構成要素
  何がメッセージの中にあるのか、誰がそれを処理すべきなのか、それは選択可能か必須かどちらなのかといったことを表現するための全体の枠組みを定義しています。
• SOAP符号化(encoding)規則
  アプリケーションが定義したデータ型のインスタンスをやりとりするための直列化(serialization)のメカニズムを定義しています。
• SOAP RPC表現
  RPCとそのレスポンスを表現するための規約を定義しています。

WSDL(Web Services Description Language)とは、Webサービスを記述するための、XMLをベースとした言語仕様です
WSDLサービス定義仕様で用いられる概念は以下のものがあります。

• サービス(service)
• ポート(port)
• バインディング(binding)
• ポートタイプ(portType)
• 操作(operation)
• メッセージ(mssage)
• タイプ(types)

UDDI(Universal Description, Discovery and Integration)とは、Webサービス用の検索システムのことです。
Webサービス公開者はUDDIレジストリにWebサービスの情報（どういうサービスか、どこにあるのか、誰のものか、など）を登録し、Webサービス利用者はUDDIレジストリに対して検索をし目的に合致したWebサービスを探し出すという仕組みです。

インターネット上で一般に公開するパブリックUDDIと、企業のイントラネット内などの閉じたネットワーク上で使用するプライベートUDDIに分類されます。

WSIL(Web Service Inspection Language)とは、大掛かりなUDDI検索と手軽なWSDL交換の中間で、簡便で使いやすく、かつ、拡張可能なネットワーク上でのサービス検索の手段を提供するものです。

Java EEとは、Java言語の機能セットの一つで、サーバや企業の情報システム、大規模システムなど向けの機能をまとめたもの。J2EEはバージョン5.0までの旧称で、以降はJava EEと呼ばれる。

• JavaSE
• JavaME
• JavaEE

Java EEにはJava SEの機能がすべて含まれるほか、サーバなどで利用されるEJB（Enterprise JavaBeans）やサーブレット（Java Servlet）、JSP（Java Server Pages）、JSF（Java Server Faces）、JNDI（Java Naming and Directory Interface）、JTA（Java Transaction API）など数多くの機能が規定されている。

JavaEEが初めて登場したのは1999年のことです。当時は「Java 2 Platform, Enterprise Edition（J2EE）」と呼ばれており、最初のバージョンは1.2でした。

JavaEEの最新バージョンは、2013年6月にリリースされたJava EE 7です。また現在、世界中の企業システムで広く利用されているのは、2009年12月にリリースされたJavaEE6です。

JavaEE仕様を準拠したサーバ製品はおもに以下のようなものがあります。

JavaEEアプリケーションは，複数の，EJB-JAR，Webアプリケーション，ライブラリJARと，一つのDD（application.xml）で構成されます。
JavaEEサーバで実行できるJavaEEアプリケーションは，アーカイブ形式のJavaEEアプリケーション，および展開ディレクトリ形式のJavaEEアプリケーションです。

• EJB-JAR
  EJB-JARは，EJB-JARファイル形式でパッケージ化されています。複数のEnterprise Beanと一つのDD（ejb-jar.xml）で構成されます。なお，Enterprise Beanでアノテーションを使用している場合は，DD（ejb-jar.xml）は不要です。
• Webアプリケーション
  Webアプリケーションは，WARファイル形式でパッケージ化されています。複数のサーブレット，JSP，HTMLと一つのDD（web.xml）で構成されます。
• ライブラリJAR
  ライブラリJARは，JARファイル形式でパッケージ化されたものです。複数の共通ライブラリから構成されています。共通ライブラリはJ2EEアプリケーション中のJ2EEコンポーネントが共通で使用できるライブラリです。JavaEEアプリケーションのDD（application.xml）の<module>タグ以下に定義されているファイル以外で，拡張子が小文字（.jar）のJARファイルがライブラリJARとみなされます。

下記のリンクをご参考ください。

http://codezine.jp/article/detail/5698

JavaEE5は以下の仕様から構成されます。

• Web Services Technologies
• Implementing Enterprise Web Services (JSR 109)
• Java API for XML-Based Web Services (JAX-WS) 2.0 (JSR 224)
• Java API for XML-Based RPC (JAX-RPC) 1.1 (JSR 101)
• Java Architecture for XML Binding (JAXB) 2.0 (JSR 222)
• SOAP with Attachments API for Java (SAAJ) (JSR 67)
• Streaming API for XML (JSR 173)
• Web Service Metadata for the Java Platform (JSR 181)
• Web Application Technologies
• Java Servlet 2.5 (JSR 154)
• JavaServer Faces 1.2 (JSR 252)
• JavaServer Pages 2.1 (JSR 245)
• JavaServer Pages Standard Tag Library (JSR 52)
• Enterprise Application Technologies
• Enterprise JavaBeans 3.0 (JSR 220)
• J2EE Connector Architecture 1.5 (JSR 112)
• Common Annotations for the Java Platform (JSR 250)
• Java Message Service API (JSR 914)
• Java Persistence API (JSR 220)
• Java Transaction API (JTA) (JSR 907)
• JavaBeans Activation Framework (JAF) 1.1 (JSR 925)
• JavaMail (JSR 919)
• Management and Security Technologies
• J2EE Application Deployment (JSR 88)
• J2EE Management (JSR 77)
• Java Authorization Contract for Containers (JSR 115)

J2EE 1.4は以下の仕様から構成されます。

• J2EE Connector Specification 1.5
• J2EE Deployment API Specification 1.1
• J2EE Management Specification 1.0
• Enterprise JavaBeans Specification 2.1
• Enterprise JavaBeans to CORBA Mapping 1.1
• Java API for XML Processing Specification 1.2
• Java API for XML Registries Specification 1.0
• Java API for XML-based RPC Specification 1.1
• Java Authorization Contract for Containers 1.0
• Java IDL API
• Java Naming and Directory Interface Specification 1.2.1
• Java Message Service Specification 1.1
• Java Servlet Specification 2.4
• Java Transaction API Specification 1.0.1B
• Java Transaction Service Specification 1.0
• JDBC Specifications, 3.0, 2.1, and Optional Package API (2.0)
• JavaBeans Activation Framework Specification 1.0.2
• JavaMail API Specification 1.3
• JavaServer Pages Specification 2.0
• RMI over IIOP
• SOAP with Attachments API for Java Specification 1.2

J2EE 1.3は以下の仕様から構成されます。

• JDBC Extension 2.0
• Java Naming and Directory Interface Specification (JNDI) 1.2
• Java API for XML Processing (JAXP) 1.1
• Java Servlet 2.3
• JavaServer Pages (JSP) 1.2
• JavaServer Pages Standard Tag Library (JSTL) 1.0
• Enterprise JavaBeans (EJB) 2.0
• J2EE Connector Architecture 1.0
• Java Message Service API (JMS) 1.0
• Java Transaction API (JTA) 1.0
• JavaMail API 1.2
• JavaBeans Activation Framework (JAF) 1.0
• Java Authentication and Authorization Service (JAAS) 1.0

JavaVMのメモリ構成はかきにようになります。

• OS固有領域
  • Cヒープ領域
    JavaVM自身が使用する領域です。JNIで呼び出されたネイティブライブラリでも使用されます。
  • スタック領域
    Javaスレッド毎に保持するスタックの領域です。
• JavaVM固有領域
  • Permanent領域
    ロードされたclassなどの情報が格納される領域です。
  • Javaヒープ
    JavaVM上で起動するJavaプログラムのリソースを管理する領域。New領域
    • New領域
      新規オブジェクトと閾値（-XX:MaxTenuringThreshold）未満のオブジェクトが配置されます、Young領域とも呼ばれるます。
      • Eden領域
        新規のオブジェクトが配置されます。
      • From領域
        CopyGC(ScavengeGC、マイナーGC)が実行された際に、使用中のオブジェクトはここへコピーされます。
      • To領域
        CopyGC(ScavengeGC、マイナーGC)が実行された際に、使用中のオブジェクトはここへコピーされます。
    • Old領域
      New領域で閾値（-XX:MaxTenuringThreshold）を超えたオブジェクトが配置されます、Tenured領域とも呼ばれるます。

Javaでは、「Scavenge GC」と「Full GC」という2種類のガベージ・コレクションが実行されます。Scavenge GCはNEW領域のみを対象とした短時間で終了するガベージ・コレクションであり、頻繁に実施されます。一方、Full GCはNEWとOLD両方の領域を対象とした大がかりなガベージ・コレクションであり、比較的低い頻度で実施されます。

以下のタイミングでGCが実施されます。

• ヒープメモリ中に新規オブジェクトを作成するために必要な空き領域が足りなくなったとき
• プログラム中でSystem.gc()が実行されたとき
• JavaVMで実行する処理がなくなってアイドル状態になったとき

下記オプションで定期的なGCを設定することができます。

• -Dsun.rmi.dgc.server.gcInterval
  JDK6デフォルト3600000（1時間））
• -Dsun.rmi.dgc.client.gcInterval
  JDK6デフォルト3600000（1時間））

メモリを割り当てる必要があるが、割り当てられるメモリが存在しないとき、OutOfMemoryErrorが発生します
例として、OutOfMemoryErrorが発生するケースを取り上げます。

• New領域が溢れた場合
• Old領域が溢れた場合
• 参照されつづけるオブジェクトが大量に存在する場合に溢れる。
• Cヒープが溢れた場合
  Javaのスレッドが大量に作成された場合に溢れます、Cヒープが溢れてOutOfMemorryErrorが発生した場合、スタックトレースの先頭が「Native Method」です。
  スレッド数はOSのパラメタで設定されており、それが大きな値で設定されている場合に発生します。