[特別企画] J2EEと.NETの連携を考える（1)

J2EEと.NET連携の意義を考える

宮下知起
2003/12/18

INDEX

リッチクライアント回帰の流れでの.NET連携 Webサービス時代を迎えるための.NET連携 J2EEと.NETをORBでつなぐ

　Microsoft .NET（以下.NET）が登場した頃は「.NETかJavaか？」といった議論が起こった。しかし、現実には両者はどちらかで完全に置き換えられるようなプラットフォームではない。J2EEも.NETもアプリケーションやサービスを実装するためのプラットフォームといえるが、その周辺に存在するツールやミドルウェアなどを含めて考えれば、現状、同様のソリューションを提供しているとはいえない。よって、ユーザーのニーズによって自由に選択されるべきものであるし、必要に応じては共存して利用することもあるだろう。

　本稿では、後者のJ2EEと.NETが共存・連携して利用されるケースを扱い、その意義に簡単に触れたあと、実際の連携例をコードレベルで解説する。

リッチクライアント回帰の流れでの.NET連携

　J2EEと.NETの連携として最近最もポピュラーなケースは、.NETベースのWindowsアプリケーションをクライアントに配置し、サーバ側のJ2EEと連携を図るというものだ。その目的は「リッチなクライアントを実現することにある」と説明するのはオージス総研 eソリューション事業部ビジネスプロセスソリューション部 山口健氏だ。オージス総研は、大手金融系企業の基幹システムにJ2EEと.NETの連携を採用した。すべて.NETで構築しなかったのは、「基幹系業務に求められる信頼性と、既存システムとの連携を考えると、サーバ側には実績のあるJ2EEを選んだ」（山口氏）からだという。

　この案件で求められたリッチなユーザーインターフェイスとは、データエントリ業務を効率よくこなすためのものだ。Webブラウザをクライアントに用いた場合、誤って［戻る］ボタンをクリックしてしまう問題があったり、［Enter］キーやファンクションキーを効率よく使った入力ができないなど、データエントリを行うオペレータの生産性を落とすことが問題視された。この点で、ホストやクライアント／サーバ時代と比べてダウングレードしてしまったといっても過言ではないだろう。.NETでWindowsアプリケーションを作成し、クライアント／サーバ時代と同様のユーザーインターフェイスを構築することで、オペレータの作業効率を落とさないところに連携の狙いがある。

　ところで、この事例ではJ2EEと.NETをつなぐインターフェイスとしてSOAPを採用している（下図参照）。J2EEと.NETの両者が業界標準のプロトコルであるSOAPに対応しているため、プラットフォームの違いを意識することなくデータ連携を行うことが可能だ。さらにSOAPはファイアウォールも越えることが可能で、セキュリティの実装も可能だ。イントラネット、インターネットという環境を選ぶことがない、汎用性の高いインターフェイスである。

SOAPによってクライアント側の.NETとサーバ側のJ2EEをつなぐモデル

　ただ、現状では.NETとJ2EE間のSOAP連携に問題がないわけではない。標準仕様に従ってSOAPエンジンの実装が行われていたとしても、仕様の実装はそれぞれに行うため、「ゆらぎ」ともいうべき違いが生じている。このことによって、素直につながらないのが現状である。そのため「いまはまだ違いを意識した実装が必要」（山口氏）だが、J2EE陣営に限っていえば、すべてのJ2EEサーバの上でポータビリティを実現するためのWeb Service for J2EE（JSR-109）の策定が進んでいる。同様の流れで、J2EEと.NET間でもポータビリティの保証を求める声が高まれば、この課題は解消されていく方向にあるだろう。

■リッチクライアント実現にほかの手段はないのか

　リッチクライアントを実現するための手段は、必ずしも.NETに限らない。JavaアプリケーションやJava Web Startを使ったJavaアプリケーションのクライアントへの配布、アクシスソフトのBiz/Browserに代表されるEnterキーやファンクションキーを使用できる特殊なブラウザ技術、Flashなどがあるだろう。このように多くの選択肢がある中で.NETが選ばれるケースでは、.NETの開発生産性の高さやVBプログラマの多さが理由とされることが多いようだ。実際、オージス総研の事例でも（1）協力会社にVBプログラマが多いこと、（2）エンドユーザーの情報システム部門がVBユーザーであること、（3）.NETはツールの完成度が高く生産性が非常に高いこと、を採用の理由としている。

　Java Web Startを使えば、クライアントJavaアプリケーションを中央のサーバで管理して使用することができ、クライアント側の管理の問題は解消できる。しかし、JavaアプリケーションでGUIを実現するにはSwingやSWTといったGUIアプリケーション作成のスキルが必要になる。サーブレット／JSPを書けるプログラマは増えたが、クライアントJavaをこなせるプログラマは非常に少ない。生産性の点で、従来のVisual Studioのスキルが生かせるVisual Studio .NETを使った開発に軍配が上がるだろう。

　しかし、この先J2EEにはJavaServer Faces（JSF）の登場が控えている（＠IT Java Solution「JavaServer Facesを理解する」を参照）。JSFに対応した開発ツールがまもなくサン・マイクロシステムズやIBMから登場する予定だが、これによって、Visual Studio.NET同様に、フォームに部品を貼り付け、部品に対してイベントハンドラを記述するスタイルのプログラミングが可能になる。さらには、これらのツールにはリッチなGUIを実現するためのコンポーネントが提供される予定だ。すなわち、VBライクな開発スタイルを使い、J2EEだけでリッチなインターフェイスを持ったアプリケーションを構築できるようになる。リッチクライアントを構築するためのツールとして.NETの強力なライバルになる可能性が高いが、これらのツールが登場してすぐにVisual Studio .NET並みの操作性と完成度の高いコンポーネントを提供できるとは考えにくく、しばらくはツールの成熟を様子見するということになるかもしれない。

Webサービス時代を迎えるための.NET連携

　ここまでリッチクライアント実現のための.NET連携を見てきたが、今度は視点を変えてみよう。Webサービス時代のシステム構築モデルとしてのJ2EEと.NETの連携である。ここで1つ事例を取り上げよう。J2EEにおけるコンポーネントベースの開発と、コンポーネント部品の流通活性化を目指すコンポーネントスクエアは、2003年10月、コンポーネントスクエアと日立ソフトウェアエンジニアリング（以下日立ソフト）、住商エレクトロニクス、NTTコムウェア間で、ソフトウェア部品の情報を共有・管理するためのパッケージ製品「CSQ Component Manager（以下CCM）」を一斉に導入したと発表した。これは、コンポーネントスクエアが用意するマーケットプレイスへの情報の検索・参照・提供をCCMによって行えるようにし、各社間でのソフトウェア部品の流通を促進しようというものだ。マーケットプレイスの情報は、SunOne Application Server 7をプラットフォームとするWebサービスで提供される。CCMはJavaで開発されているが、このサービスではWSDLが公開されているため、Java、.NETどちらのプラットフォームでも接続が可能だ。

　ここで注視すべきは、Webサービスの提供／利用においては、プラットフォームにJ2EEと.NETのどちらを選ぶかということは本質ではないということだ。

　「J2EEと.NETのマイグレーションはWebサービスだ」と語るのは、日立ソフトウェアエンジニアリング ソリューション企画本部 本部長 中村輝雄氏である。中村氏によれば、今後のシステム開発において、Webサービスを使ったシステム間連携は非常に増えてくるという。なぜなら「例えばMQを使うところのような、密な連携が必要とされないケースは非常に多い。しかもWebサービスはファイアウォールを越えられるので、従来は連携が難しかったシステム間での連携も容易になる」（中村氏）からだ。そして中村氏は「Webサービスは今後、EAIベンダのソリューションと真っ向からバッティングする」とまで断言する。

　ところで、本格的なシステム間連携では非同期での連携が必要になる。しかし、Webサービスは同期での通信を実現するしくみだ。この点が、システム間連携にWebサービスを採用するネックとなる。しかし、この課題を超えるヒントが「IBMとマイクロソフトが策定を進めるワークフロー記述言語である『BPEL4WS（Business Process Execution Language for Web Services Version 1.1）』にある」と中村氏は説明する。

　BPEL4WSは、システム間のアーキテクチャの違いを意識することなく、ビジネスフローによって連携を図ることを狙いとした言語だ。BPEL4WSは、BPEL4WSを実行するためのワークフローエンジンによって解釈され、ワークフロー処理を実現する。「重要なのはビジネスプロセスであり、テクノロジベースの制御ではない。アプリケーションレベルでビジネスフローを制御する」（中村氏）というのが、BPEL4WSの考え方だ。

WebServices.orgのBPEL4WSを紹介するページ

　従来、例えば企業内の経理システムと営業管理システムを連携する場合、インプリメンテーションレベルで統合を行っていた。これをBPEL4WSで統合しておけば、次回のシステム更新の際に、連携する相手がだれであろうと（あるいはJ2EE、.NETのどちらのプラットフォームでも）容易な連携が可能になる。もっとも、社内システム全体を最初からBPEL4WSで構築しておけば、社内のワークフローのフレキシブルな変更も可能になる。

　「今後のエンタープライズではJ2EEと.NETのどちらが優位かという議論はあり得ない。適材適所で混在することになり、重要なのはワークフローでうまくつなぐということ」と中村氏は説明する。さらに中村氏は「ワークフローを記述する標準言語が登場することによって、開発者が注目すべき焦点も、言語や要素技術から、ビジネスワークフローへと移行するだろう」とまで語る。

　BPEL4WSは策定が始まったばかりであり、今後の動向はまだ明確ではない。しかし、システム間連携という世界での、J2EEと.NETの連携は当たり前となる時代が到来しそうだ。

J2EEと.NETをORBでつなぐ

　ところで、BPEL4WSでは、つなぐためのアーキテクチャは特に規定していない。J2EEと.NET間の連携は、Webサービスでも、CORBAによるORB接続でもいいのだ。その意味で、今後、ORBによるJ2EEと.NETの連携も注目される可能性は大きい。

　ボーランドは、.NETとJ2EEおよびCORBAのランタイム環境との、完全でシームレスな相互運用を可能にするミドルウェアとして「Borland Janeva」を提供している。この製品のターゲットは、企業内のJ2EEベースの資産と.NETの密な連携である。Webサービスによる疎結合は、例えばトランザクション管理を必要とする連携には向かない。CORBAによる密結合であれば、高パフォーマンスを実現できる。さらに「ファイアウォールを越える必要のない企業内の連携では必ずしもWebサービスである必要はない」（ボーランド株式会社 マーケティング部 部長 藤井等氏）。

◆

　第1回は、取材を通して得た情報を中心にJ2EEと.NETの連携の意義について考えてきた。第2回以降は、具体的な連携の解説に入っていく。第2回はWebサービスによる疎な連携を、第3回はORBによる密な連携例として、だれもが簡単に手に入れることができるHORBによる連携を解説する。

INDEX
特別企画：J2EEと.NETの連携を考える
	第1回　J2EEと.NET連携の意義を考える
	第2回　Webサービスによる.NET連携
	第3回　ORBによる.NET連携

Java Solution全記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）