Java と .NET のインターオペラビリティツールを提供する JNBridge は同社の主力製品である JNBridgePro の新しいリリースを JavaOne 2008 で発表した(source)。
JNBridgePro は Java と .NET 間の汎用インターオペラビリティツールで、EJB、J2EE、AWT、Swing、SWT、.NET API、WinForms、ASP.NET、SharePoint Server などといったあらゆる領域において Java と .NET の橋渡しをしてくれる。この製品は .NET と Java のリモーティングスタックをベースとし、他方の側でコードを実行するためのプロキシを含むバイナリライブラリを生成する。
JNBridgePro 4.0 の主な新機能は以下のとおり。
- Java のクラスを .NET 側から、.NET のクラスを Java 側から、探索して明らかにする機能をもつ Visual Studio と Eclipse 用のプラグイン。
- 完全な 64 ビットサポート
- より優れた性能を実現するためのデータ圧縮
InfoQ は、新しいプラグインと JNBridge 全般について、JNBridge の CTO をつとめる Wayne Citrin 氏にインタビューする機会を得た。
Hartmut Wilms (HW): 開発者は新しいプラグインをどのように活用すればよいか?
Wayne Citrin (WC): GUI ベースのスタンドアロンのプロキシジェネレータと異なり、プラグインなら開発者が直接 .NET のクラスを Eclipse から、あるいは Java のクラスを Visual Studio から探索して明らかにする、ということが可能になる。
プラグインは、IDE のビルドサイクルにプロキシのビルドオペレーションを組み込むことによって、プロキシ生成のプロセスを単純化してくれる。Visual Studio と Eclipse のプラグインでは、プロキシはひとつのプロジェクトとして扱われ、他のプロジェクトから参照することが可能だ。開発者が IDE 上で開発中のシステムをビルドすると、IDE は .NET や Java のプロジェクトがプロキシ用プロジェクトに依存しているかどうかを判断してプロキシをビルドし、プロキシ用プロジェクトのアウトプット(プロキシの dll か jar ファイル)を、それに依存しているプロジェクトのビルドに利用する。
例として、Java の API へのアクセスを必要とする .NET アプリケーションを作っている開発者を考えてみよう。その開発者は Visual Studio を使って JNBridge プロジェクトを作成し、エディタを開いて、アクセスしたい Java クラスを指定する。そして次に .NET アプリケーション( C#、VB.NET、または他の .NET 言語で書かれる)用のプロジェクトを作成して、プロキシ用プロジェクトを参照し、それを利用してプログラミングをおこなう。開発者がプロジェクトをビルドする段になると、プロキシの dll が自動的に作成され、.NET アプリケーションプロジェクトのビルドに利用される。
HW: JNBridgePro がターゲットにしている Java と .NET のバージョンは?
WC: JNBridgePro は .NET Framework の 1.0、1.1、2.0、3.0、3.5 と JDK の 1.3.1 以上をターゲットにしており、
JNBridgePro のプラグインは .NET Framework 2.0 以上と JDK 1.4 以上をサポートしている。JNBridgePro のスタンドアロン GUI ツールはいまでも利用可能で、こちらは .NET Framework と JDK の古いバージョンをサポートしている。
HW: .NET Framework 4.0 は CLR の変更を盛り込む可能性があるし、Java も将来 JVM を変更するかもしれないが、このことで JNBridgePro にどのような影響があるか?
WC: 新しい CLR や JVM が後方互換性を保っているかぎり、現在の JNBridgePro を使っていても何の問題もないはずだ。もし新しいバイナリフォーマットが導入されたら、私たちはその新しいフォーマットやフレームワークに対応する新バージョンの JNBridgePro を発表するつもりだ。たとえば、同じことが .NET が 1.1 から 2.0 にバージョンアップした際に起こっている。.NET 2.0 のリリースに先立ち、私たちは .NET 2.0 のベータ版に対応する JNBridgePro 3.0 を開発し、.NET 2.0 が GA となったのと同じ月に JNBridgePro 3.0 をリリースした。
プラットフォーム( .NET や Java )が、人々が利用を望んでいる新しい API を導入したら、私たちはその新しい機能を利用可能な新バージョンを導入する。Java の話をすると、私たちは自分たちの Java 側コンポーネントが Java 5 と同様にそれ以前のバージョンの Java でも動作するようにしたいので、それらを Java 1.3 や 1.4 でコンパイルし、新しい API にはリフレクションを使ってアクセスする、といったことを実際に行っている。.NET 2.0 の新しいバイナリフォーマットでは、1.x と 2.0 両方に利用できる単一のバイナリセットという選択肢はなかったので、私たちはバージョンごとに .NET 用コンポーネントを開発した。
.NET Remoting については、Microsoft は向こう数年の間、サポートを継続することを公言している。私たちは Microsoft が発表した今後のリリース予定にしたがい、もし .NET Framework の次のバージョンで Remoting が削除されるようなら、確実に WCF へと移行することになるだろう。
HW: インターオペラビリティというと、IT 業界ではほとんどの人が Web サービスや SOA のことを思い浮かべるが、JNBridgePro をどのように位置付けているのか?
WC: Web サービスよりも JNBridgePro を使う利点はいくつかある。
- JNBridgePro の TCP/Binary と共有メモリのメカニズムは Web サービスとは桁違いに速い。
- JNBridgePro は、アクセスポイントのセットがずっと狭いことをさらけ出してしまった Web サービスのサービス指向アプローチとは対照的に、広範なオブジェクト指向 API へのアクセスにより適している。サービス指向アプローチは特定の目的には適しているが、それ以外のケースでは JNBridgePro のオブジェクト指向アプローチのほうが適している。
- 多くのアプリケーションやライブラリは Web サービスで利用することができず、また別のケースでは、Web サービスを使って同じマシンや同じプロセス上にある単純なライブラリにアクセスするというのはやりすぎのようにも思える。どんなアプリケーションでも JNBridgePro を使ってインターオペラビリティを簡単に実現することができるし、JNBridgePro の共有メモリメカニズムは Web サービスを使うほどでもない単一マシン間でのインターオペラビリティの実現に適している。
- Web サービスの実装は概して、組織のさまざまな部門に存在する多くのステークホルダの承認を必要とする戦略的な決定だ。そのような承認を得るには多大な時間が必要となるし、また上位レベルでの承認も必要になると思われる。一方 JNBridgePro は、開発者やアーキテクトレベルの承認だけで済むかもしれない二点間のインターオペラビリティを実現するための戦術的なソリューションとして利用することが可能だ。実装もかなり速く行うことができる。もちろん JNBridgePro を戦略的なコンテキストで利用することもできるし、その場合は上のほうで述べたような別のメリットがある。
HW: JNBridge 4.x に向けたロードマップにおいて次にすべきことは?
WC: 顧客たちがバージョン 4.0 をどのように受け取るかを一歩さがって確かめ、彼らのフィードバックを開発中の今後のバージョンに盛り込んでいく予定だ。私たちが現在注目しているのは、 TCP/Binary メカニズムでの SSL 通信をより広範にサポートすること、ref とか out パラメータのような Java には存在しないが .NET には存在する特性のサポート、などの機能だ。.NET と Java それぞれに特有の技術への対応も検討するかもしれない(単にこれらの特有の技術との相互運用を望んでいるだけで、Java や .NET プラットフォーム全体との相互運用を望んでいるわけではないユーザに対応するため)。そしてもちろん、.NET と Java プラットフォームの次期バージョンに導入される新機能に、私たちは注目している。
HW: ありがとうございました。
JNBridgePro(サイト・英語)に関する情報は JNBridge(サイト・英語)の Web サイトで見ることができる。JNBridgePro という主力製品以外に、JNBridge では JMS Adapter for .NET(サイト・英語)や JMS Adapter for BizTalk Server(サイト・英語)も提供している。
原文はこちらです: