ホーム > 未分類 > Start with JBoss AS 7

Start with JBoss AS 7

OSS が好きで OSS に育てられ OSS でご飯を食べている技術者としてブログ書きたいなと思いつつも書かずに数年。。。

JBoss AS 7 の登場!いい機会なので技術的なことを書いていきます。

しばらくは AS7 や EE6 について書くことになりますが、他の言語やツール, F/W, M/W, アルゴリズム, Tips 等々興味のある主に OSS 関連技術や開発プロセスについても書いていきます。

始めるからには、定期的にコツコツとやっていくつもりではいますが、お腹が痛くなったり PC の調子が悪くなったり死んだじいちゃんの遺言により休まなきゃいけない日があるかもしれませんが、温かい目で見て下さい。

書く内容のレベルは、初心者からお年寄りまでをモットーに入門的な内容からマッドサイエンティスト的な内容まで書いていくつもりでいます。

そうそう、赤い帽子の会社で JBoss コンサルタントのお仕事をしていますが、僕個人は間違いの塊みたいなもんです。

内容におかしなところがある場合は優しくご指摘をお願いします。

それでは、 JBoss AS  7 いってみましょう!

JBoss AS 7 について、『6とは違うのだよ、6とは!』的な内容をてっとり早く知りたければ、あるいは準備体操という観点で JBoss AS 7 概要 を読んでみるのがいいかもしれません。

プロジェクトのトップページ JBoss AS 7 概要 に書いてあることを意訳すると次のような感じになります。

※ 意訳部分は こんな感じの書式 を使用してます。

無類のスピード!

ハンパない高速起動!

AS7 では起動プロセスの並列化による wait の削減やマルチコア CPU への対応を行っています。また、主要でないサービスは最初に使用されるまで稼働を遅延させます。

また、2回目以降の起動ではキャッシュ/インデックス化されたメタデータを使用し余分な起動時間が削られます。

ここで言うところの 主要でないサービス? や キャッシュ/インデックスって? については追々書いていきます。

これらの改善により AS7 はこれまでのバージョンより起動時間が10倍短縮されているとのことです。

10倍短縮ってどういうことなんでしょうね??? AS7 の起動時間を 1s とすると、その10倍は 10s 、つまり以前のバージョンは 11s ということでしょうか。

僕の環境(MacBook Pro Early 2011)だとピュアな状態の 7.0.1(standalone)の起動が 1.5s なのに対して、 5.1.0(default プロファイル) の起動が 18s 程度なのでまぁそんなもんですかね。

クイックターンアラウンド

高速化や柔軟なデプロイ構造による並列デプロイメントや静的リソースの編集等効率の良い開発が可能!

詳細は別途解説するとして、AS7 の性能/機能ではありませんが EJB lite(Web Profile) 等も相まって今後は EE も真の開発効率の向上が期待できます。

JSP や ManagedBean もしくは SFSB / JPA Entity 等々をちょっと変更しただけなのに、 EAR にビルドしてデプロイして。。。場合によっては AS を再起動して。。。アプリケーションがロードされるのをひたすら待つというのは精神衛生上非常によろしくないです。

これまで3分かかっていた作業が10秒に短縮されれば、これまで回避していた作業を頻繁に行うことになります。

これまで回避していた作業が何か。。。コードの小さな部分の検証や UI のデザイン変更等ですかね、これまでは検証に時間がかかるのである程度コーディングをためた状態で動作検証ということをしていたのですが、これだと一つ一つの事象に目がいき難くなるのとコーディングに対する妥協の入り込む隙が生まれてしまいます。まぁこれは僕の個人的な性格によるものかもしれませんが。。。

コードの小さい部分を実際に動かして検証すること、それを行いやすい開発環境や開発プロセスとするために工夫や改善を行うことは非常に重要です。

少し話しが AS7 の紹介からそれました、 AS7 では Arquillian というテスティングフレームワークによりコンポーネントのテストが容易になっています。これについては凄く興味深いのですが鋭意勉強中です。

Arguillian のロゴを見てるとかっぱ寿司の CM に登場する宇宙人を思い出します。

モジューラー設計

No more jar 地獄

階層型クラスローダには問題があり、デプロイメントの失敗や奇妙な振る舞いをしばしばします。親委譲モデルに別れを告げモジュラリティの方法を探しましょう。

というのがモジューラー設計考察へ至る問題提起として挙げられています。

AS7 では JBoss Modules により依存性におけるアプリケーションの隔離、サーバ実装クラスのアプリケーションからの隠蔽、オンデマンドクラスローディングを実現しています。 Module はクラスのコレクションをパッケージングしたもので、明示的に別のモジュールからの依存関係を指定しない限り依存性が隔離されます。この可視性規則はデフォルトでありカスタマイズ可能です。

この部分については高速化/軽量化(※ 後述)に並ぶ重要な変更点です。モジューラー設計に関連する概念として、module, extension が設定ファイルや AS7 内部のディレクトリに登場します。依存性のカスタマイズも一元管理可能な設定ファイル上で柔軟に変更可能です。

オンデマンド クラス ロード

JBoss Modules はアプリケーションが必要としたタイミングでクラスを(並列処理により)高速にロードします。

OSGi 的な?

AS7 は OSGiとの設計上の類似性により JBoss Modules および Module Service Container(MSC)上のレイヤーとしてのふるまいにより OSGi のサポートを提供します。

OSGi の補足を簡単にしておくと、 OSGi はモジュール(ソフトウェアにおける一般的なモジュールの概念を指しています、 JBoss Module 固有の Module ではありません。)の動的な追加/実行やネットワーク経由のやりとりを行うためのフレームワークで JVM 上のレイヤーとして動作します。(※ OSGi 実装の有名なものとして、 Equinox, Felix 等があります。Eclipse のプラグインがまさに OSGi バンドルなのでご存知の方も多いかもしれません。)

OSGi ではモジュールをバンドルと呼びます、OSGi を使用することにより Java の通常のパッケージング形式(jar)よりも柔軟(動的変更、バージョニング)なモジュール管理が可能です。

AS7 は前述の通り、 AS7 コア上のレイヤーとして OSGi をサポートするため、 OSGi バンドルを使用することが可能です。

非常に軽量

メモリダイエット

AS7 は GC の停止時間を最小限にするためにメモリ管理にアグレッシブな改善が加えられています。 jar ファイルに関するインデックスデータや必要に応じてロードする仕組み等がそれにあたります。これらのアプローチによりメモリ使用量が劇的に削減されています。

僕の環境(MacBook Pro Early 2011)だとピュアな状態の 7.0.1(standalone)で 140MB のメモリを使用するのに対して、 5.1.0(default プロファイル)が 470MB のメモリを使用するので AS を単に起動しただけの状態であれば 2/3 強のメモリが削減されていますね。

JMS, EJB, Mail 等を使用した場合どうなのかを今後は見ていきましょう。

前述の最適化により、 AS7 はこれまで蓄積した JVM 設定の使用やハードウェアリソースの少ないスモールデバイスでの使用も可能です。

スモールデバイスはさておき AWS 等のクラウド上で動かしやすくなることは素晴らしいですね。

また、 profile のカスタマイズにより不要な機能(mail, messaging 等)の削除を行う等のカスタマイズにより健全な状態のサーバを運用することが可能です。

サービスのカスタマイズが可能なこの機能自体は JMX コンテナ上でサービス(機能)が構成されていたこれまでのバージョンと同様ですね。

MSC(Modular Service Container)

AS7 の各種機能は個別のサービスにアレンジされ、サーバ実行時に構成/管理されます。

各々のサービスの起動/停止は隔離され、サービス間の最小限の依存性は実行時に調整されることによりサービスの並列制御を可能にしています。(マルチコア向きの管理方式万歳!)

MSC(Modular Service Container)アーキテクチャが起動/デプロイメントが高速された最も重要な要因です。

モジュール管理の仕組みとして新たに JBoss Modules (プロジェクトとして立ち上がっています。JBoss Modules Project )が定義されていて、その実行エンジンが MSC という感じです。

当然、これまでの AS コアである JBoss Microcontainer が JBoss Modular Service Container(MSC) に置き換えられています。JBoss Modules は非常に興味深いものがあるので今後 Deep Dive したいと企んでいます。

JBoss Modules に興味がある方へ! ドキュメントはこちら! JBoss Modules Documtnts

エレガントな管理

一元化された 設定 & 管理

AS7 の設定は一元化され、簡潔でユーザフレンドリーなものになっています。設定ファイルは domain モデル向きのものになっており、理解しやすく AS の内部構造が露出しない形式(AS の内部構造が設定ファイル中に存在すると本質的な部分が読み難くなります。)となっています。

一元化された設定は管理作業も統合します。 domain 中の複数の server では同一の設定ファイルを共有することが可能です。

上述の文では色々なことをぼやぼやっと説明しているのですが、ポイントは次の通りです。

・設定ファイルは domain/standalone モードに関係なく一元化

・domain モードでは domain 中の server で設定の共有が可能

これまでの設定ファイルはサービス毎(JBoss Web, DataSource 等)に色んな XML ファイルに分散されていたのですが、それらが一箇所(domain.xml, standalone.xml, host.xml)にまとめらています。

管理はかなり楽になるんではないでしょうか、これまでの運用手順書等のドキュメントや運用プロセスの対応がちょっと面倒ですが。。。

domain モードについては待望の新機能です、クールです。

コマンド中心の管理方式

AS7 ではこれまでのものに比べ洗練されユーザフレンドリーな web コンソールや CLI 、スクリプトや外部プログラムのための AS 管理用 Java API, HTTP API を使用しての設定の永続化や管理が可能です。

管理用 API がスクリプトやツール作成用のプログラム向けの API であるのに対して、 web コンソールは実行時の AS の簡潔なビュー(DataSource, Deployment, …)を提供します。

AS7 の管理インターフェース改善で最も便利なのが、設定の変更が永続化されるということであり、これにより設定ファイルへの面倒な修正の手間が軽減されます。

web コンソールは今のところ DataSouorce設定、JNDI照会、ロギング設定、アプリケーションのデプロイ/アンデプロイ、IPアドレス/ポート設定、システムプロパティ設定が行えるようになっています。

他のアプリケーションサーバ製品に比べ機能や UI が見劣りするのは開発中だからだ!と信じてます。

管理ツール面での大きな変更が、 twiddle から CLI へコマンドラインツールが変更されたことです。twiddle は JMX の MBean に対して属性値を照会/変更するものでしたが、 CLI は全くの別物です。

CLI を使用して、 JMC, DataSouce, Deploy/Undeploy といったリソースの管理や設定ファイル(XML)中の要素(属性)のノード構造にアクセスして値を変更することができます。

あと、web コンソールもしくは CLI 経由で行った設定変更は設定ファイルに(一元的に)永続管理されるところが素晴らしい。

標準仕様への対応

Java EE 6 Web Profile

JBoss はこれまでベンダーロックインを避けるためアプリケーションのポータビリティを念頭に開発が行われてきました。 AS7 も当然このポリシーのもと開発され Java EE 6 Web Profile の認定を受けています。

そして、 Full Profile の認定に向け鋭意開発中です!

AS7 は Arquillian ベースの内部テストを行うことにより、コミュニティユーザが期待するポータビリティのための厳格な標準準拠を成し遂げています。

アプリケーションが Java EE 使用に準拠していれば、そのアプリケーションは AS7 で動作すると考えられます。アプリケーションが AS7 で動作しな場合、アプリケーションがポータビリティの面で問題を抱えている可能性を示唆しています。

Full Profile の認定はまだ取得されていません、一般的にあまり使わない機能の未サポートはまぁいいとして Full Profile バージョンで EJB を動かしてもタイマー等が動かないのには注意は必要です。

標準化についての話題についてはあまり興味が無いので解説を割愛します、なぜあまり興味が無いかは追々話します、何をもって標準とするか。。。それだけで保守性や開発効率がどこまで効率するのか。。。難しいところです。

OSGi Core 4.2 

AS7 は Java EE 適合とおなじように OSGi 適合が考慮されています。

AS7 コアのモジュラー設計により、 OSGi 準拠が自然な形で対応しており、 OSGi 準拠だけでなく OSGi と Java EE コンポーネントの統合も可能です。

OSGi は素晴らしいです、何故素晴らしいか?アプリケーション開発者や運用面でどんなメリットがあるのか?についての調査検証も追々やっていきますよ、追々ね。

テスト容易性

Arquillian

AS7 は開発初期の段階からテスト容易性の考慮が行われています。Arquillian – 実行環境中で実行可能な統合テストのためのコンポーネントモデル がそれを可能にしました。

Arquillian は開発/テストから煩雑性を排除することにより、アプリケーションが直面するユースケースにフォーカスしたテストが可能にします。

AS7 が高速化されたことにより、 Arquillian によるテストはユニットテストと同等の速度で実行可能です。

スマート開発

開発に Arquillian を使用することにより、 Java EE 等のコンポーネントに対する 変更、コンパイル、テスト のサイクルが効率化されます。

これにより、テスト駆動開発がこれまで以上に容易になります。

AS7 は Arquillian を使用した開発がいかに効果的かあるいは(あなたの開発する)ソフトウェアがいかに堅牢かの証明です。

テスト容易性の向上はかなりクールなポイントですね。 何とかコンポーネントはテストし難いというネガティブな台詞が根絶されるためにも色々検証していきます。

今回は JBoss AS7 の概要をみてみました。次回以降はドキュメントの意訳/解説とドキュメントに書いてあることを実際に検証していこうと思います。

広告
タグ: ,
  1. まだコメントはありません。
  1. 2011/09/1819:15

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。