Infoqが以前に報告したように(参考記事)、近ごろMicrosoftはAzureサービスプラットフォーム(リンク)の新たなCTPをリリースした。
Microsoftのホストによる、非常にスケーラブルなデベロッパ指向のサービスであり、多くのクラウドベースおよびクラウドを意識したアプリケーショ ンによって必要とされる、主要なビルディングブロックを提供する。.NET Frameworkが、デベロッパをより生産的にする、よりハイレベルなクラスライブラリを提供しているのと同様に、.NET Servicesはデベロッパが独自のクラウドベースのインフラストラクチャーサービスの構築やデプロイよりもむしろアプリケーションロジックにフォーカ スできるようにするものである。
Azura .Net Servicesの目玉的存在は、Services Bus(リンク)であり、それは
ネットワーク、セキュリティおよび組織の境界をまたいで、インターネット規模でこのパターンを実装する場合に生じる難しい問題を解決するのを支援しながら、おなじみのEnterprise Service Busアプリケーションパターンを提供する。
Clemens Vasters氏によると、2009年3月のCTPにおけるもっとも顕著な変化(リンク)は、サービスバスルーターおよびキューの追加である。
あるマシンのどこかにあり、Service Busに接続されるすべてのアクティブリスナーから完全に独立して動作し存在する、長寿でシステムに固有のメッセージングプリミティブを開始した。そ れは、プッシュプル翻訳の媒介として、またはすでに「Webにある」場所間でのメッセージングを最適化したり、促進したりするためのパブリッシュ/サブス クライブメッセージ配信機能として、Service Busを利用することができることを意味する。また、メッセージのあて先が既存のWeb Servicesであるメッセージ配信シナリオを設定することができるので、受信側はService Busのリレー機能が連絡可能である必要がある。
Service Busルーターおよびキューの実装は、Service Bus名前空間(リンク)の変更を通して促される。
その中心として、Service Bus名前空間は連合されており、その構造は「プロジェクト」によって指示され、所有されている。Service Bus名前空間とDNSやUDDIもしくはLDAPのような「昔ながらの」サービスレジストリシステムの違いは、サービスまたはメッセージングプリミティ ブが(通常)、レジストリによって参照されるだけでなく、レジストリに直接投影される。そのため、類似した、またはまったく同じプログラミングインター フェイスを使用して、統合名前空間の範囲で、レジストリやそうしたサービス、またはレジストリに投影されたメッセージングプリミティブと対話することが可 能である。名前空間を「連合」させているのは、サービスもしくはメッセージングプリミティブが、「どこから」でも共用名前空間に投影することができる。概 して、URIのパスの部分は比較的緊密に収集された一連のリソースを表す。それはWebファーム全体またはターゲットクラスタを(直接もしくは間接に) データベースクラスタを特定する権限があるデータベースクラスタに存在している。
Clemens Vasters氏は、以下のように説明している(リンク)。
あらゆるメッセージングプリミティブとService Bus名前空間の関係は、プロジェクトのService Busの階層の名前を選択し、その名前にロールをアサインすることで成立する。理論上は存在可能なService Bus名前空間のすべての名前は、すでに存在し、それらのロールは「ない」。そこで、名前にロールをアサインするとき、名前自体は作成しない。すでに名前 はそこにあり、ちょうど隠れている。すべての名前が、システムでサポートされているあらゆるロールをおこなう。現在「メタデータ」のロールがあり、レジス トリの名前のURIやWS-Addressエンドポイントリファレンスを貼り付ける。Service Busをリッスンするために名前を引き継ぐ際、WCFリスナーにより確立される「接続ポイント」ロールがある。また、これらの2つの新たなロール 「キュー」および「ルーター」がある。
ルーターおよびキューを以下のように定義している。
ルーターは、パブリッシュ/サブスクライブメッセージ配信プリミティブであり、ルーターに流れてくるメッセージをサブスクライブし、取得するように、サブ スクライバーを「後押し」可能にする。キューは、メッセージを受け取り、コンシューマーがメッセージを取得し、キューからメッセージ「プル」するまで、保 持する。明確に、ルーターがルーターをサブスクライブし、キューがルーターをサブスクライブできるようにしている。結果として生じる合成物は、一般にプリ ミティブだけよりも、多少力強い。そこで、これらの機能を「プリミティブ」と呼ぶ。なぜならば、明確に合成物を考慮に入れるからである。
キューの機能は、キューポリシーによって定義される。それは典型的なJMSキューのポリシー(リンク)と類似しており、WS*およびRest API(リンク)の両方を使用してアクセスおよび管理可能である。
Microsoftは.NET Service BusをESBパターンの実装としてとらえている。複数サービスのつながりを簡略化するので、数年をかけて人気が出てきた。これを実行する1つの方法は、 パブリッシュ/サブスクライブアーキテクチャを使用可能にすることで、エンタープライズで、より疎結合を提供することである。Service Bus Routers And Queues in .Net Services March 2009 CTPを通じたキューサポートの紹介により、この概念が一歩現実に近付いた。