Typemock: その過去・現在・未来
Eli Lopian氏率いるTypemock社の過去・現在・未来について、インタビュー形式にて記します。
作者 Hartmut Wilms, 翻訳者 岡田 英久 投稿日 2008年5月30日 午前4時1分
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 の主な新機能は以下のとおり。
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 を使う利点はいくつかある。
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(サイト・英語)も提供している。
原文はこちらです:
この論文では、仮想化やクラウドサービスの複雑なメリットと実世界における応用を検討します。さらに重要なこととして、Contegixが複雑な問題の解決に仮想化を実装している方法や、仮想化を使うべきではないケースについて詳細を提供します。
Fiberはユーザに試練を課すことなくこの考えを実装する有益な並行性ツールとして、ライブラリが2つあります。まさにこのためのソリューションとしてあるのがNeverBlockライブラリです。私たちはNeverBlockプロジェクトのMohammad A. Ali氏とRevactorライブラリのTony Arcier氏に話を聞きました。
システムの保守容易性や拡張性を確保するためのベスト・プラクティスに関する記事は数多くありますが、この記事では避けた方がいい、いくつかの悪習慣(ワースト・プラクティス)を強調します。
この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。
Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。
マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。
No comments
返信