前編では、｢基幹系」の概念が変わりつつあり、新たなアーキテクチャを導入するニーズが高まっていることを説明した。すなわち、コンポーネント化した業務処理（＝サービス）群を疎結合していく、というアーキテクチャである。

　ここまできて、前編で紹介した「EJB（Enterprise JavaBeans）にもう一度焦点を」という発言の真意が見えてくる。堅牢な業務コンポーネントを作る技術となると、EJB以外の候補は考えにくいからだ。そして、コンポーネント群を疎結合する技術としてはWebサービスがある。

　EJB技術を利用する場合には、ビジネス・ロジックを記述したEJBコンポーネントを、アプリケーション・サーバーが提供する「EJBコンテナ」と呼ぶ枠組みの中で動作させる。このEJBコンテナは、トランザクション管理、セキュリティ、コンポーネントのライフサイクルを管理する仕組みを提供する。こうした仕組みを、アプリケーションを開発するたびに独自開発していたのでは生産性は上がらない。

　とはいうものの、EJBに対して「遅い」、「難しい」といったイメージを抱く人も多い。製品技術や利用技術が未熟な段階でEJBを使い、それいらい敬遠しているという開発者もいるかもしれない。だが、今のアプリケーション・サーバー製品では、EJBの性能上の問題はまったく感じられない、と清水氏は言う。

　むしろ、基幹系と呼べるような規模のシステムにおいては、「EJBはこれからのシステム・アーキテクチャを考えるうえで、一番下側のインフラ技術と考えた方がいい」と清水氏は語る。EJBが基本であり、その上に新たなシステムを構築していくのだ－－と。

　ここで要注目の技術として清水氏が強調しているのは、EJBとWebサービスを結ぶ標準技術が登場したことだ。それが「JSR-109 Implementing Enterprise Web Services」である。EJBを使い堅牢なサービスを構築し、それをJAX-RPCによってWebサービスとして扱う枠組みが整った。

次世代の金融サービス・インフラをJ2EEで

　こうした新アーキテクチャを具体化したシステムは、すでに現実のものとなりつつある。その実例の一つが、IBMが日本市場に投入しようとしている次世代金融システム「NeFIS」である。そのシステム基盤には最新のシステム技術が使われており、コアとなるビジネス・ロジックの構築ではEJBを活用している。

　さらに、このNeFISでは、WebSphere Application Server V5の機能である「プロセス・コレオグラフィー」によるワークフロー機能も取り入れている。このワークフロー機能は現時点ではIBM独自の技術。だが、将来的には標準技術であるBPEL4WS（Business Process Execution Language for Web Services）に移行する予定だ。

ワークフローを「ポータブル」に

　ワークフローの分野では、現在10を越える製品が並立しており、それぞれ互換性がない。だがBPEL4WSがワークフロー標準が確定すれば、「ポータブル（移植可能）なワークフローを記述することが可能となる」（清水氏）。BPEL4WSのインパクトはここにある。

　今後は、「基幹系」であっても、人間が関与する処理を扱う必要性は高まる一方だ。こうした次世代システムのための技術として、ワークフローの標準化は大きな意味を持つ。EJBで作った業務コンポーネントをWebサービスとして扱えるようにし、それらを集めてワークフローを形成する－－こうした新たな枠組みに基づくシステム資産が構築されようとしているのだ。

J2EEの次世代機能を先行して実装、標準化団体に提案

　清水氏は、その講演の中で、さらにJ2EEを補完する新技術について言及した。興味深いのは、「Async Bean」である。これは、WebSphere Application Server V5で取り入れた新機能で「J2EEコンテクストを継承しつつ、常に動き続けるデーモン・プログラムを作れるようになる」（清水氏）。

　このほか、IBMは、データ・モデルに関するAPIであるWDO（WebSphere Data Object）を開発、すでに開発ツール製品WebSphere Studio V5.1.1に搭載している。

　これらの技術は、さきほど標準化団体JCP（Java Communityu Process）に「JSR-235 Service Data Objects」、「JSR-236 Timer for Application Servers」、「JSR-237 Work Manager for Application Servers」として提案された。すでに製品に搭載済みの機能を、標準化プロセスを経て標準的なJava技術に位置づけようというのだ。

　興味深いのは、このJSR-235、JSR-236、JSR-237の提案元が、IBMだけでなく、競合ベンダーである米BEA Systemsであることだ。この2社はJ2EEアプリケーション・サーバーの分野で影響力が強く、2社の提案という形としたことで、これらの技術が普及する可能性が高まったといえる。

　製品化と標準化を並行して進めるというやり方は議論を呼んでいるが、現時点のシステム構築ニーズを満たしつつ、将来的なユーザー資産の保護（標準化）を図るという戦略と見ることもできる。いずれにせよ、J2EEの進化はまだまだ続きそうだ。