NServiceBusが、企業の.NETシステム構築を容易に

NServiceBus(サイト・英語)とは、オープンソース通信フレームワークであり、企業の.NETシステム構築を試みる開発者が、多くの典型的な落とし穴に陥ることがないようにガイドするのに役立つ。NServiceBusは、パブリッシュ/サブスクライブのサポート、長期の統合ワークフロー、および大幅な拡張性など、スケーラビリティが決定的に影響する機能を提供する。NServiceBusの作者によると、これは分散アプリケーションを構築するのに理想的な基礎を作るのだ。

NServiceBusは、2006年1月に最初にリリースされ、2006年3月に大規模分散システムとして展開された。InfoQは、NServiceBusの作者であるUdi Dahan氏に話を伺う機会に恵まれた。

NServiceBusを作った理由を述べた。

NServiceBusの記述の原動力は、主に2つあります。1つ目は、（Webサービスに関係なく）非同期メッセージングを使用するときの Service Layerクラスの記述方法を形式化したかったということ、2つ目は、トランスポート間を自由に行き来できるように、本質的な可否には関わらず、パブリッ シュ/サブスクライブ意味論をサポートする通信APIを形式化したかったということです。私にとって、集中型ブローカを使用しないということも重要でした。そうしないと、必要となる高レベルのスケーラビリティをサポートすることは不可能であったでしょう。最後に、長期ワークフローおよび編成を非同期メッセージングに結び付ける方法を形式化するというステップを行いました。

NServiceBusでは、スケーラビリティを損なうような方法で作業することはかえって困難です。非同期メッセージングパターンが前面に押し出されるため、開発者はデフォルトにて、大部分のWebサービス実装において非常に広く行き渡った一時的な結合を避けます。他の手法は、多くのその他のオプションの使用を簡単にするため、開発者はスケーラビリティや可用性を損なう失敗を犯し、稼動中にこれらの失敗の事実に気づくばかりということになる可能性があり ます。

NServiceBusが他と異なるまた別の点は、すべてのワークフローコードをすべての技術から完全に切り離すということです。これによって、 ワークフロークラスの単体テストが容易になり、主要なビジネスプロセスの開発において繰り返し行うことが可能になります。これらの移植性のある.NET POJOは、開発者が所望するあらゆるランタイムにおいてもワークフローをホストするための柔軟性を開発者に与えます。

NServiceBusのコアはMSMQに依存していません。NServiceBusの拡張性という点で、ユーザーは自身の通信トランスポート、サブ スクリプションストレージ、およびワークフローPersisterに接続できます。私は、すでにMSMQを通してトランスポートを実装し、またWCFの NetTCPバインディングを通して別のものを実装済みです。開発者は、これらをそのまま使用するか、自分で記述するかできます。現在登場しているSOA 製品の多くは、より強くHTTPに結びついているため、これは一般的な方法から一線を画すものです。

私がMSMQの使用を選択したのは、これが、パーティの未接続での通信を可能にする、Microsoftの2つの主要な通信技術のうちの1つであったためです（もう1つはSQL Server Service Broker）。MSMQは.NET Frameworkの一部として直接利用できますが、Service Brokerは現在利用できないという点で、MSMQはより多くのアクセス可能なAPIを持ちます。サービス自律主義では私達が通信したいサービスが現在 利用可能であるということが前提にはならないため、私は、未接続のコミュニケーションがあらゆるSOAインフラストラクチャにとって非常に重要な部分であ ると考えています。

NServiceBusは、Creative Commons Attribution 3.0ライセンス(サイト・英語) に基づいてライセンス供与されるオープンソース製品である。これは、ライセンスを持つあらゆるアプリケーションまたはクライアントにおい て、ホスティング可能な一連の.NETアセンブリとしてパッケージングされている。

インタビューが短いものであったため、Udi氏に、サービス指向アーキテクチャ（SOA）にあまり詳しくない、またはSOAの実装についてより詳しく知りたい読者に何か伝えたいことはないか伺った。

みなさんがサービス型アプリケーションの開発に関与しており、SOAに詳しくない場合は、これが今まで行ってきたことと大幅に異なることを理解する必要が あります。いつも記述しているものと同種のコードにいくつかの属性を加えるだけ、というわけにはいきません。使用している特定の技術で行き詰まる前に、時 間をかけて、より高レベルのメッセージングパターンサービスの展開を理解すると、深刻な書き直しを免れることができます。