Java、.NET、でもなぜ一緒に?

作者 Ted Neward , 翻訳者 白石 俊平 投稿日 2007年10月1日 午後9時34分

コミュニティ

.NET,

Java

トピック

Java+.NET,

REST,

Webサービス,

インターロップ

タグ

SOAP,

Microsoft Office

12年前、Sun Microsystemsはちょっとしたファンファーレと共に、よりダイナミックな"生きた"Webページを作成するのに使える、新しいプログラミング言語と環境を発表しました。現在ではもちろんJavaプログラミング言語はユビキタスなツールです。Webページをよりダイナミックな環境にするというだけではなく、それらのページを生成し排出し(サーブレットとJSP)、ビジネスロジックのトランザクショナルなプラットフォームを提供し (Enterprise Java Beans:EJB)、メッセージングシステムにアクセスし、(Java Message Service:JMS)、リレーショナルデータベースにアクセスし(JDBC)、メインフレームにすらアクセスします(Java Connector API)。そしてこのストーリーはまだ終わっていません。Javaをとりまくコミュニティは、オープンソースの成果とプロジェクトを通して日々成長し、かつ、"公式の"JavaプラットフォームもJava Community Processを通じて成長、拡大を続けています。

6年前、Microsoftは盛大なファンファーレと共に、プログラミングが必要な全てのシチュエーションにおいて使える新しいプログラミング言語のセットと環境を発表しました。.NETは二度のリリースのあと行われた一度のメジャーリリースにより、クライアント層とサーバ層に多くの新機能を加えるのみならず、実行環境と最も人気のある三つの言語(C#、C++、Visual Basic)に対して大きな変更を行いました。トランザクションのサポート(System.Transactions)、ジェネリクス(C#、Visual Basic共に)、ディレクトリサービス、マネジメント(WMI)等々です。そしてこのストーリーはまだ終わっていません。Microsoftは次のリリース(Vistaに搭載される.NET Framework 3.0)で複数の新しいテクノロジーの搭載を計画していますし、コミュニティも急速に成長しており、.NET環境はオープンソース、商用問わず、新しいプロジェクトやアイデアとともに拡大していきます。

数年の間、これらの環境それぞれについて多くの議論がありました。その多くはどちらか一方にとって非常に怒りを掻き立てられるようなものであり、そしてそのほとんどは無益なものでした。結局のところ、"こちらの言語はあなたの言語より優れている"とか、"こちらのプラットフォームはあなたのプラットフォームより速く動作する"とか、"お前ら最低だ"などのやりとりは、カクテルパーティやカンファレンスのパネルディスカッションなどで話し合われる分には楽しいのかもしれませんが、それらはソフトウェア開発を意義あるものにするための生産的な議論ではありません。政争、駆け引き、傷付け合いが一通り済んだ後、Javaと.NETが協調する事について意義のある議論をしようとすると、たいてい議論の方向性は"Webサービス"、"エンタープライズサービスバス（ESB）"、"サービス指向アーキテクチャ（SOA）"といった、ほとんどは具体的なものが見えない、非常に上流のバズワードの議論に終始することになります。その後上流の議論が一通り済んで、実装レベルに踏み込んだなら、SOAP、WSDL、WS-プロトコルだとか、メッセージを介してデータを交換するだとか、CLR内でJVMをホスティングするだとか、その逆だとか、そういう会話になるのが典型的です。

一般的なフレーズに言い換えれば、"あなたは、どうやるか、について論じ、進めてきた。なぜそれをすべきか、について論じることも無く。"といったところです。

歴史的に、Java/.NET間の相互運用性についての議論は、.NETとJavaのシステムのどちらも持ち、対話させることが必要な特定の企業においてのみ発生する、"必要なときのみ"の相互運用性という見出しの元でしか行われてこず、アーキテクチャの話題の二の次とされていました。しかし、それらの議論から抜け落ちているものがあります。それは、開発者には「必要だから」という場合でなくともJavaと.NETをともに動作させたい場合があり、その動機についての議論です。

一見して、これは危険な話題です。あるプラットフォームが他方よりも何かしら"優れている"などの示唆に富む意見は、他方のプラットフォームで"○○が不可能だ"なんてうっかりほのめかして完全に怒らせるというよりはましなものの、えこひいきだとか、無知だとの非難を招く恐れがあります(これでは、そもそも"優れている"の意味するところを理解するという、基本的な問題さえ無視されてしまいます)。そうした意見を軽視したり敬遠しようとしたりするくらいなら、むしろ正面から向かい合って見ましょう。そうした非難、批判は、無視すべきものではなく、実際、そうした意見がどこから来るのか、と言ったより大きな議論の一部として、喜んで受け入れるべきなのです。とは言っても、開かれた議論を行うこと、アイデアを検証すること、読者が自身の(批判的な)意見を持つのを許すことは依然として重要です。

Java/.NETの相互運用性について語る記事シリーズ第一弾として、我々が本当にやろうとしていることはそういうことです。

* * *

Javaと.NET両方についてよく考えるとき、より検討に値するいくつかのシナリオが思いつきます。

Officeクライアント、J2EEサーバ

良くも悪くもMicrosoft Officeは、コンピュータの歴史上一番とまでは言いませんが、(より多くのコンピュータにインストールされているという意味で)人気のあるソフトウェアプラットフォームのうちの一つです。Officeは現在では登場してから10年を過ぎ、ユーザが多種多様なデータを入力し、操り、閲覧することのできる、パワフルなプラットフォームの代表格です。そうしたユーザにとって興味深い、膨大な量のデータが、現在J2EEで構築されたエンタープライズサーバ内に存在しています。それらのデータをOfficeプラットフォームに取り込んで簡単に操作し、分析できるとすれば、素晴らしいことです。さらに面白い方法としては、既にSpringやその他の軽量Javaコンテナで書かれているビジネスロジックを、プロセスのコミュニケーションツールを用いて、Officeプラットフォームから利用するというものがあります。

MSDNマガジン2006年10月号(http://msdn.microsoft.com/msdnmag/issues/06/08/default.aspx(英語)にてオンラインで見ることができます) には、Officeによる開発に関するいくつかの記事が掲載されており(こうした記事が掲載される理由としては、多くの人がOfficeのプログラマティックな可能性にほとんど親しみがないという背景があります)、"Officeを開発プラットフォームとして利用するためにあなたが知るべきこと (What You Need To Know About Using Office As A Development Platform)"という記事中の図で、Officeプラットフォームの持つ能力が全て一覧にされています。その完全な一覧をまたここで繰り返し載せるのではなく、Officeの拡張性のうちJavaプラットフォームとうまく協調する点をいくつか整理してみましょう。

• 外部オートメーション。COMオートメーションのパワー、そしてその後継となるVisual Studio Tools for Office (VSTO)のおかげで、Word、Excel、Outlookなどのコンポーネントのうち多くが外部公開用APIにより動作します。そのため、汎用的なプログラミング言語を用いてそれらのドキュメントを生成することができます。Excelのパワフルな図表作成機能や計算能力、もしくはWordの編集機能やスペルチェック機能は、これら2つがホストされている環境であればJavaアプリケーションからも利用できるというのは非常に魅力的です。それはサーバかもしれませんし(例えば、Velocityエンジンがテンプレートに値を入れてHTMLを表示しているのとほとんど同様の方法で、Webアプリケーションが顧客へのメール送信にWordを使用したり、J2EEサーバからデータを取ってきて印刷済みのレポートを作成するなど)、クライアントであれば、既にEclipse Rich Client PlatformはCOMオートメーションコンポーネントのホスティングが可能です(もちろん実は、EclipseはOfficeがインストールされた Windowsマシン上であれば単体でもWordのドキュメントを作成することができます。)。これは、ユーザがWordドキュメントを書くのではなく、見るほうが主な用途であるという場合には非常にパワフルです。MicrosoftはフリーのWordビューアを利用可能にしていますので、Javaの WebアプリケーションはWordドキュメントを作成し、HTMLよりもリッチなフォーマットを用いて、HTTPを介してWebにそれを公開できます。
  
  
• アドイン。Officeは"アドイン"をホスティングすることもできます。アドインとは、"プラグイン"してOffice内部で実行されるソフトウェアコンポーネントのことで、通常はメニューバーやコンテキストメニューから利用されます。.NETコンポーネントは自身をExcelスプレッドシートのアドインとして登録でき、様々な形式でJavaと接続し(Webサービス、プロプライエタリなリモーティング・ツールキット、もしくはin-proc hostingなど)、バリデーションやデータの検索、保存などのため、Javaのビジネスコンポーネントと関わります。例えば、多くの企業がExcel を請求書の作成や経理に利用していますが、Javaコンポーネントを利用することで、企業の内外にあるJavaベースの、より大きく、エンタープライズサーバ上で動作している会計処理パッケージに対して、EJB Session Bean内のJavaコネクタを介してアクセスするのが非常に簡単でした。
  
  
• Excelのユーザ定義関数。Excelは長らく、自身の計算エンジン内でユーザ定義関数を"呼び出す"という機能を持っています。それらは歴史上の理由から、アンマネージドな(生のC++)コードで記述する必要があり、アプリケーションを非常に不安定にしてしまいます。Excelのユーザ定義関数を、アプリケーションサーバ内に定義された既存のビジネスロジックに対する薄いラッパーとして -注文書を生成するために、Excelスプレッドシートのテンプレート内で動作する、商品一覧チェックのような- 作成するなら、Excelは、多くのユーザを幸せにするような"オンライン"体験を兼ね備えることになるでしょう。
  
  
• スマートタグ。これは、Microsoftによって名づけられた、ユーザがドキュメント内で次に行いそうな事柄をドロップダウン形式の小さなボックスによって表示する機能のことです。スマートタグは、オフィスドキュメント内の細かい要素をカスタマイズしたり、設定したりする場合に頻繁に利用されます; 例えば、Wordがミスタイプと判断してオートコレクトしてくれましたが、それが本当はミスではない場合に、訂正された単語の上にマウスを重ねるとスマートタグが出現します。そしてユーザはドロップリストの中から動作を選択することにより、行われた訂正を"アンドゥ"することができます。スマートタグはアドインによる入力形式であり、クライアントとエンタープライズサーバの間のギャップを橋渡しするための視覚的な補助として、ユーザを助けるために利用できます。

Officeはまた、こうしたプログラマティックな要素により書かれ/配布されたコンポーネントやドキュメントに対して、配布を楽にするいくつかのサポートも提供しています。多くのケースにおいて、こういったコンポーネントの機能をアップデートし配布する場合も、共有のダウンロードサーバに何かを置いてリリースするのと同じくらい簡単です。明らかに、こうした利用法はOfficeのライセンスコストが悩みの種になりそうですが、しかし幸運なことに、ほとんどのビジネス環境にはすでにOfficeがインストールされているので、全く、とは言わないまでもコストの大幅な削減にはなります。

Windows WorkfrowをSpringもしくはJ2EEコンテナの内部で使用する

Windows Workfrowは、.NET Framework 3.0の一部としてリリースされた新しいフレームワークで、Windows Vistaに搭載されています。ワークフローとは、核となるビジネスプロセスの機能 - 小さなスケールではWebサイトのインタラクションだとか、大きなスケールでは保険金請求の届出を行うための処理のステップだとか - を、開発者以外の人間が作成したり、見たり、追跡したり、編集したりする手段を提供することを目的としています。ワークフローはプロセスの論理的なステップを表す複数のアクティビティからなり、ワークフローの開発者(従来は.NET開発者、もしくはドメインエキスパート)はそのデザインを行うためにフローチャートに似た環境を用います。この環境は普通はVisual Studio内で利用できるのですが、カスタムアプリケーション内で利用することもできるため、企業はこれらの環境を従来の"プログラマのための"ツールセットから切り離して、ワークフローデザイナーを置く事ができます。ワークフローデザインの結果生成された、XMLフォーマットもしくはプログラムコードによる成果物は、ワークフローコンパイラによって通常の.NETクラスにコンパイルされます。そしてそれはワークフローランタイムにより処理され、 ASP.NET、コンソールアプリケーション、もしくはGUIアプリケーションを含む様々な環境の上で動作します。ワークフローはシーケンシャルに、もしくは外部のステートが変化したときに、時には長い時間をかけて動作します。

ワークフローランタイムが、その実行環境やコンテキストに関しては高い柔軟性を持つよう設計されていることを踏まえると、ワークフローとSpring(もしくは他のJ2EEコンテナ)を様々な形で結合して使用するというアイデアがすぐに思いつきます - ワークフローランタイム内でSpringコンテナを実行し、SpringのBeanを呼び出すカスタムのアクティビティを作成してビジネスに作用させたり、もしくはSpringのBean内でワークフローランタイムを実行し、ワークフローの結果をSpringで受け取ったり - となると、答えはリモートコールとなります。特に後者の場合は、エンドユーザは直感的に利用できる環境を使用してビジネスプロセスのデザインを行え、しかも従来からあるエンタープライズサーバの世界でそれを動作させることができます。同様に、ワークフローの愛好家は既に、ASP.NETアプリケーション内でWEBページのナビゲーションを構成するためのワークフローの使用方法(Strutsのアクションマッピングファイルとは全く異なる)について述べています。ワークフローをサーブレットコンテナ内で動作させるには同様のアプローチが必要になるでしょう。そして、サーブレット/JSPページの間のフローを視覚化しますが、現在のところはXMLのシンタックスによる判りにくいものになるでしょう。

Windows Presentation FoundationクライアントとJavaサービス

最後に、本当に大事なことを言い忘れていましたが、.NETとJavaをともに利用するケースとして最も有望なのは、新しいWindows Presentation FoundationテクノロジーをリッチでパワフルなUIとして、豊富かつパワフルなJavaサービス(Spring、EJB、ほかいろいろな組み合わせ)が提供するデータモデルの上で使用するという方法です。XAMLをベースとした、WPFの宣言的プログラミングモデルは、つい最近まで行われてきたコードベースのUIプログラミングモデルとは全く対照的で、多くの場合、現在のSwingやSWTよりも複雑なユーザインターフェースの作成をするのが簡単です。そして、XAMLはテキストベースのフォーマットがゆえに、現在HTMLで行われているような、XAMLを動的に生成し、ダウンロードしてクライアント層で実行することが簡単に実現可能です。

正統派のシナリオとしては、WPFのフロントエンドがJavaのバックエンドと対話をする際、Windows Communication Foundation(WCF) -Microsoftの新しいコミュニケーションパイプラインで、あらゆる分散プログラミングを一つのフレームワーク - を使用するというものです。加えて、最新のWS-*仕様の多くをサポートするために、WCFは様々な方法でコミュニケーションを行うためのリッチで拡張可能なモデルを提供しています。その中にはREST-fulフォーマット(時にPlain Old XMLやPOXと呼ばれる)や、UDPのようなほかのトランスポートメディアを利用できる可能性も備えています。Sunは、Tangoプロジェクトにおいて、このアプローチをより実用性の高いものにしようとしています。同プロジェクトは、設計のゴールとして、WCFとのシームレスな統合を明確に掲げています。

* * *

これでJavaと.NETの相互運用のシナリオを全て挙げきった、とはとても言えたものではありません。実際は、この連載がほどよい期間で収まるようにするため、我々はいくつかある他の可能性にはあえて触れませんでした。

• Eclipseリッチクライアントプラットフォームをクライアントとして使用し、その上で動作するカスタムのRCPビューが、DCOM上で.NET/COM+サービスと対話する、もしくはWCFサービスと対話する。
• SwingクライアントとJavaWebStartを利用してポータブル、ダウンロード可能、デプロイ不要なクライアントアプリケーションを作成し、Windows Server 2003マシンにホストされたExcelコンピューティングエンジンの問題を解決する。
• SWTアプリケーションの内部でDirectXを使用し、ネイティブな3D効果(音声含む)を提供する。
• Microsoft Speech Serverを用いて、SwingやJ2EEアプリケーションに対する音声自動認識の"フロントエンド"を提供する。

などなど・・・

取ってつけたような、そしてやたらとセンセーショナルに聞こえることでしょう。こういったシナリオはマーケティングのことなど頭から抜けていて時間がかかりすぎる上、あまり意味がありません。なぜJavaが数式のエンジンを持っているときにExcelで頭を悩ますのでしょうか?JAX-WSがあるのに、なぜ WCFで頭を悩ますのでしょう?なぜ、Java3Dがあるのに、WPFで頭を悩ますのでしょう?えこひいきだとか、見え透いたマーキテクチャ (MarketingとArchitectureを組み合わせた造語で、大したことではなくても、宣伝のために先進技術らしく見せかけること)だとか非難されないように、我々は全てにおいて率直で、明快でいるようにします。.NETならこれができる、Javaならこれができる、逆もまた然り。ただしかし、一つの事実にだけは特に誠実でいるようにします:どちらのプラットフォームにも得意分野があります。開発者の皆さんが心を開いた議論を支持してくれるならば、どんな政治的教義に身を寄せていようと気にはしませんが、お互いの長所を尊重することでとても素晴らしい利益を得ることもあるでしょう。もしくは、カール・マルクスの言葉を引用しましょう、"From each platform, according to its abilities, to each project, according to its needs."

原文はこちらです：http://www.infoq.com/articles/java-dotnet-integration-intro

（このArticleは2006年10月5日にリリースされました）

• 次へ >