WS-* 標準を果たすBEA Workshopコントロール

JSPで標準化されるWS-*は、SOAのために欠かせないものばかりだ。現在のWSDLを超えJavaが新次元へと向かうために、BEAはJavaベンダーの中心でSOAを叫ぶ。

[木田佳克，ITmedia]

　SOA（サービス指向アーキテクチャ）が効果的に働くためにはは、現在のところWS-*（WS-Security、WS-Reliable Messaging、WS-AddressingなどのWebサービスプロトコル）をさまざまなベンダーがサポートすることが不可欠だ。その構築には、昨今、Java開発統合環境（IDE）が欠かせず、BEAプロダクトの新版も近い（関連記事）。

　6月17〜18日まで東京・渋谷、セルリアンタワー東急ホテルで開催された「BEA eWorld JAPAN 2004」では、Java開発統合環境「BEA Workshop」のコントロールがどのような仕組みを持ち、どのようにインプリメントされているかが詳細に語られた。

講演を行った米BEA Systems、ウィル・プゥ氏

　「Workshopはシンプルなオブジェクトモデルを目指している。メタデータされたものを作り、J2EEサポートを行っている」と米BEA Systems、ウィル・プゥ氏。

メタデータの扱い

　メタデータは、プログラムモデルをシンプル化へと導くものであり、BEAがSOAを広げるためには欠かせないものだ。BEA Workshopの現バージョン8.1では、このためにJavadocタグを利用しており、コンパイル時にはクラスファイルへと挿入される仕組みを持つ。

　メタデータの扱いは、すでにJ2EE 1.5、EJB 3.0サポートの「JSR 175」としてJCPで標準化されており、サービス構成とデプロイモデルを拡張するJWSが基の「JSR 181」へと通じる。これらのアノテーションモデルが枯れてこそ、相互運用性が確立できる。

　プゥ氏は、メタデータを扱う仕組みの例を挙げた。コンパイラがクラスファイルにメタデータを入れる点から触れる。

　ページフローの際は、struts-configによりプログラム情報をひとつのファイルに保持することが可能だ。一方、クラスを読み込んだランタイムは、メタデータを取り上げてディスクストラクチャーを作る必要があるが、クラス挿入情報を扱いポイントディスクリプタを作り上げなければならないという。また、独自仕様のコントロールを作る際は、アノテーションがキー/バリューペアとしてstruts-configへと入ることになる。

　次なるステップとしては、メタデータがクラスロードされている状態で新たなビヘイビアとしてインプリメントする必要がある点だ。ディプロイメントディスクリプタが生成されることで、フレームワークからも扱える。

メインとなる4つの抽象化。DispatcherはリクエストをEJBに届くよう配慮される。RequestはDispDataのコントロール、Responseはコントロールへの指示、Containerはこれらすべてを保持する役目

JWS、またはWebサービスを利用している基本的な流れ。リクエストがWeb Tierに入り、SyncDispacherBeanがバッファ選択した場合はキューへ、そしてAsyncDispacherBeanに。異なる場合は直接ContainerAdapterへと

コントロールの扱い

　プログラムモデル（フレームワーク）の強みは、メタデータを利用し、struts-configなどが集約されることだ。これにより、デプロイが楽になるという背景を挙げた。さらに、オーサリングモデルのシンプル化が大きなところでもあるという。

　コントロール実行のためのコンテキストは、常にContainer EJBの中にある点にも触れ、しかし実行コンテキストは場合によってはEJBコンテキストでJWS、JPDのために作られたもののため、ランタイムによるコンテキスト共有で必然的でもなくなるという。

受注管理コントロールの例。DispacherがJWS、またはいちばん上のコントロールに対してコールし、DynamicProxyが次のEJBでコントロール作成されたものへと続く

　次期Workshopの目指すところはSOAに則した複雑性の簡素化であり、EJBの扱いにもJSRによる標準サポートが大きく関わる。厳密にはBEAが独自プロトコルを標準化提案し、再搭載したというのが正しいかもしれない。