このトピックでは、DTRのアクティビティを取り上げて説明します。 

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

概述

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

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

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

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

作成変更の記録チェックイン有効化リリース照会

NWDSやWEB-UIからアクティビティ一覧を照会することができます。アクティビティ一覧からワークスペース全体の変更経緯を確認することができます。

デザインタイムリポジトリ (DTR) はファイルバージョン管理を提供するリポジトリ及びそのシステムです。
同じバージョン管理システムとして、オープンシステム開発系の世界では、以下のオープンソースソリューションがよく利用されています。

CVSSVNGit

歴史的には、最初はCVSがはやっていて、次はSVN、いまはGitが一番流行っているに間違いないです。

コンセプト

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の構造

以下、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照会

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

システムステート削除

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

間違って追い越しして後のリリースが先に移送されてしまった場合、対象システムのシステムステートをクリアしておけば、古いリリースが再び移送可能になります。

このトピックでは、トラック内移送とトラック間移送に分けてNWDIにおける移送プロセスを説明します。

 トラック内移送

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

開発者側作業

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

1.有効化

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

2.リリース

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

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

管理者側作業

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

3.インポート

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

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

4.アセンブリ

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

5.承認

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

6.出荷トラック間移送

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

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

(source:SAP Help Portal)

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

このトピックでは、開発トラックを取り上げて説明します。

概述

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

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

構成

(source: SAP Help Portal)

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

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

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

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

外部リンク開発トラックを使用した作業 - SAP Help Porta

変更管理サービス(CMS)は、ソフトウェア変更のシステム間の移送管理を行います。システムは開発設定と実行システムのどちらかまたは両方で構成することができます。
システムはシステム開発のフェーズ(開発、コンソリデーション、テスト、本稼働)に対応します。CMSはABAPシステムのCTSに相当します。

コンセプト

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

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

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

構成要素開発ドメイン

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

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

開発トラック

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

システム

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

システムロールは、開発設定のみ、または実行環境のみのものとしても定義することができます。

CBSはDTRと密接に連携しています。DTRからソースコードを取得して、ビルドします。アプリケーションサーバの設定があれば、ビルドできたアカイブ(ear,sdaファイルなど)をサーバへデプロイします。

コンセプト

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

実現アーキテクチャ画面機能

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

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

 

このトピックでは、NWDIの管理ツールを纏めて説明します。 

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

NWDS

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

DIComponent Browserビュー 
以下の作業を実施することができます。SC/DCを照会DCをローカルに取り込み、プロジェクトを作成SCをscaファイルにExportDCをビルド、デプロイComponent Propersビュー 
以下の作業を実施することができます。コンポーネントの構成や依存関係を照会DTRRepository Browsesrビュー 
以下の作業を実施することができます。ソースファイルの内容及び履歴などを照会Open Acvitiesビュー 
以下の作業を実施することができます。未チェックインのActivityを照会変更をチェックイン変更を廃棄Closed Acvitiesビュー 
以下の作業を実施することができます。チェックイン済のActivityを照会Integration Conflictビュー 
以下の作業を実施することができます。ワークスページ統合時に発生したConflictを照会、処理Version Graphyビュー 
以下の作業を実施することができます。ソースファイルのトラックに跨ったバージョン履歴を図で表示CMSTransport Viewビュー 
以下の作業を実施することができます。未リリースの変更依頼をリリース未リリースまたはリリース済の変更依頼を照会CBSActivation Viewビュー 
以下の作業を実施することができます。チェックイン済のActivityを有効化Activation Requestビュー 
以下の作業を実施することができます。有効化リクエストのステータスを確認WEB画面メイン画面

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

DTR

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

CMS

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

CBS

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

このトピックでは、 NWDI を使用した開発の流れを抜粋して説明します。

概述

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

前提条件

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

構成要素(DTR、CBS、CMS、SLDなど)のインストールシステムランドスケープに関する情報の更新各フェーズ開発準備

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

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

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

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

チェックアウトソースの作成又は変更ビルドローカルテストチェックインセントラルビルド、有効化デプロイリリース移送及びテスト

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

本番稼働

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

運用保守

運用保守フェーズで変更が発生するたびに、アクティビティ作成⇒修正⇒ローカルテスト⇒リリース⇒品証機移送⇒品質テスト⇒本番機移送という作業を繰り返します。

このトピックでは、NWDIを使用して開発、運用されるソフトウェアのコンポーネントモデルを取り上げて説明します。

モデルの構成

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などのバージョンがあります。

ソフトウェアコンポーネント

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

パーツ値意味11000固定27.20製品のバージョン35.2サービスパッケージ(SP)のバージョン420110906181900リリースのタイムスタンプ

 

NWDI(NetWeaver Development Infrastructure) は、 NetWeaverプラットフォームの上に動作するJavaベースのアプリケーションを開発するための基盤であり、アプリケーションのバージョン、構築、およびライフサイクルを管理する機能を備えています。

NWDI自体もNetWeaver Javaプラットフォームに稼働するものですので、NetWeaverインストール時に利用タイプDIを選択してインストールを行うことで、 NWDIに必要な機能がインストールされます。

コンセプト

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(System Landscape Directory,システムランドスケープディレクトリ) は、システム間連携を行うシステムの情報を一元管理するためのもので、システムの技術情報（サーバ名など）やソフトウェアカタログ情報（利用ソフトウェア製品、リリースなど）を保持しています。

SLD はシステムランドスケープにインストールされているすべてのシステムコンポーネントの集中情報プロバイダとして機能します。

SLDサーバはすべての SAP Web Application Server Java のインストールにおいてインストールされますが、機能させる場合には明示的に有効化される必要があります。

実現形態

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

連携

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

機能

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

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

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

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

ホーム

URL：http://host:port/sld

製品とソフトウェアコンポーネント

システムとサーバ

サービス提供側とサービス消費側を分けてそれぞれ説明します。

サービス提供側

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

システム

分類

サービス

サービスグループ

サービス消費側システムプロバイダ定義

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

このトピックでは、標準技術としてのWebサービスの基礎知識を取り上げて説明します。

Webサービスとは

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サービスの特徴

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

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

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

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

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

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

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

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

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

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

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

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

WSIL

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

WSILは、直接、Webサービスを記述するのではなく、Webサービスを記述したWSDLへの参照や、Webサービスを登録したUDDIへの参照を記述したXMLドキュメントです。いわば、WSDLやUDDIを経由すれば、利用可能なWebサービスの一覧表を提供しようという試みです。

このトピックでは、JavaEEの概要を取り上げて説明します。

JavaEEとは

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

JavaSEJavaMEJavaEE

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の歴史

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

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

主な製品

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

No.製品最新バージョン(2015)ベンダー1Tomcat-オープンソース2Jetty-オープンソース3Weblogic-Oracle4JBoss-オープンソース5Websphere-IBMJavaEEアプリケーション

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とみなされます。

JavaEE6

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

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

JavaEE5

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

Web Services TechnologiesImplementing 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 TechnologiesJava 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 TechnologiesEnterprise 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 TechnologiesJ2EE Application Deployment (JSR 88)J2EE Management (JSR 77)Java Authorization Contract for Containers (JSR 115)J2EE 1.4

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

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

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

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

 

このトピックでは、JavaVMのメモリ管理の仕組を取り上げて説明します。

メモリ領域の構成

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領域とも呼ばれるます。GC種類

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が発生します
例として、OutOfMemoryErrorが発生するケースを取り上げます。

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

ソフトウェアの品質特性は大きく６つに分類され、それぞれの英語の頭文字をとってFRUEMP特性とも呼ばれています。

機能性

機能性とは、必要な機能を満たしているかということです

信頼性信頼性とは、指定された条件の下で正しく動くかということです。使用性使用性とは、使いやすさを表します。効率性率性とは、スピードとサイズに関する性能です。保守性保守性とは、修正のしやすさです。移植性移植性とは、実行する環境の移行のしやすさを表します。