オンプレミス/クラウドをつなぎ目なく連携、既存アプリケーションとWebサービスとの連携基盤を提供するAppFabric。それぞれの確実な接続やメッセージ中継、アクセス制御といった課題を解決する。
プラットフォームに依存しないアプリケーション連携技術としてWebサービスが登場後、すでに10年以上が経過した。これまで業界を挙げて膨大なエネルギーが注ぎ込まれたが、それに見合うだけの見返りがないと実感しているのは、著者だけではないだろう。
なぜか？ 一言でいえば「つなぎたい/つなぐべきWebサービスがない」に尽きる。Webサービス自体は、利用者にとっては非常に敷居の低い技術だ。ところが、提供者にとってみれば解決すべき問題が常に付いてまわる。
非常にシンプルな“Hello World”的なものを含めれば、一度はWebサービスを作ったことがある読者がいるかもしれない。もし経験がなければ想像してほしいのだが、それらのWebサービスを実際にグローバルIPを割り当てて公開するとなるとどうなるか。単なる実験として、誰がアクセスしてくるか気にせず短期間だけ公開するならともかく、ビジネス目的で継続的に運用し続けるとなると、以下の2点だけは決着をつけておかねばならない。
- 安定した接続環境
- 安全なアクセス
こう書くと堅い表現に思えるかもしれないが、「誰」に「何」を「どうやって」提供するかというサービスの本質を、技術ソリューションの観点で置き換えたに過ぎない。「何」の部分が既にWeb サービスとして実装されているなら、次に「誰にサービスを提供するか」、すなわち「誰にサービスへのアクセスを許すか」と、「どうやってサービスを提供するか」すなわち「どうやってサービスのエンドポイントを公開するか」の2つがサービス提供者にとっての共通の課題となる。
それらの技術ソリューションをサービス本体から分離し共有サービスとして利用させることで、Webサービスの公開や、ホストされる場所がオンプレミス環境/クラウド環境に関わらずアプリケーション間の連携などの敷居を低くする。それがWindows Azure platform AppFabricの目的である（図5-1）。
クラウドコンピューティングに注目する企業は多いが、業務アプリケーションで扱うデータを外部のクラウドサービス（データセンター）に置くことへの心理的な不安や法規制の未整備などの声があることも事実である。これに対しAzureでは、個人情報やマスターデータなどはオンプレミスのアプリケーションで管理し、共有データやトランザクションデータはクラウド上に置くなど、柔軟なハイブリッド形式を選択できる。これもAppFabricが提供する特徴だ。
インターネット上にサービスバスを実装する
先の「どうやってサービスのエンドポイントを公開するか」という課題に対する技術ソリューションがAppFabric Service Busである。バスという概念は既にお馴染みと思われるが、簡潔に言えば「モジュール間で情報をやり取りするための通信路」のことである。
モジュールの単位をサービスという粒度でとらえれば、それはサービスバスと呼ばれる。ESB（エンタープライズサービスバス）の概念を実装したミドルウェアについて、何らかの説明を見聞きしたことのある人は多いだろう。マイクロソフトもオンプレミス環境を対象にBizTalk Serverという製品を提供済みだ。ESB Toolkitという無償のコンポーネントを導入することでWebサービスのエンドポイントを組織内に公開。複数のサービスをバスに対して「抜き差し」させることで、柔軟かつ安定した接続環境を提供する。
では、このESBのコンセプトをクラウドで展開、つまり「インターネットサービスバス」が提供されたらどんなメリットが生まれるか。インターネットにある仮想的なバスに対して、組織内/組織外を問わず自由にWebサービスを抜き差しできるので、どこにアプリケーションがあろうと、あるいはアプリケーションのホスト場所が変わっても（例えばオンプレミス環境からクラウド環境に移行、あるいはその逆であっても）利用者に意識させることなくサービスを提供できることになる。
ただし、現実はそれほど単純ではないことは容易に想像がつく。インターネットをまたがって（組織外からWebサービスを通じて）自社のアプリケーションに自由にアクセスができる環境を提供している企業など皆無に等しい。ほとんどの企業はファイアウォールを構築してアクセス可能なポートを厳密に絞っているし、社内のネットワークはNAT（Network Address Translation）を通じてグローバルIPをローカルIPに変換しているため、そもそもサービス提供者が外部に対して自由にエンドポイントを公開できない。
エンドポイントに確実につなぐ
ではAppFabric Service Busはどのような仕組みでこの課題を解決しているのか。Service Busはメッセージング基盤の中心としてリレーサービスという機能を備える。「リレー」という名前の通りクライアントからのリクエストメッセージを中継し、最終的にWebサービスに渡すのが目的である。
Service Busからメッセージを受け取るために、Webサービスは自分からService Busへ接続しにいく（アウトバウンド）。その接続は双方向のソケット（IPアドレスとポート番号の組）であるから、Service BusからWebサービスへの接続（インバウンド）のためにファイアウォールのポートを開けたり、外部IPアドレスを用意する必要がない。これがService BusとWebサービスの間にファイアウォールやNATが存在しても通信が可能となる基本的な解決策だ（図5-2）。
このソリューションと似た例としてはDMZが挙げられる。DMZはWebサービスの環境と独立し、外部からのネットワークトラフィックを監視し、望ましくないトラフィックはフィルタで除去する役割を担っている。これと同様の仕組みをクラウド上で実現しているのがService Busのリレーサービスだと言える。ちなみにService BusとWebサービスの間は規定ではTCPプロトコルが選択され決まったポート番号を使うが、もしTCPプロトコルが使えない環境であればHTTPプロトコルを設定することもできる。
最終的にWebサービスのエンドポイントにつなぐために、クライアントにどのような作業が必要となるのかを説明しよう。Webサービスの提供者は、前もってAppFabricの管理用Webポータルでプロジェクトを作成する。具体的にはService Busを経由して自サービスを呼び出してもらうためのユニークなURI（形式は[スキーム]://[サービスの名前空間].servicebus.windows.net/[サービス名]/）と、Service Busにつなぐための共有の秘密キー、およびキーの発行者（規定は”owner”）などを作成しておき、これらの情報をクライアントと共有する。現在のところこの情報を交換する仕組みはService Bus自体では用意されていないため、別のアプリケーションか電子メール経由など従来からの手段を使うことになる。
これらの情報でクライアントはService Busに対してログインし、メッセージを送信すると、前もって起動されServiceBusと接続しているWebサービスへ中継されメッセージが届く。
このようにService BusはWebサービスを外部から隠ぺいしつつ、アクセスを許可するクライアントだけに確実にメッセージを届ける機能を提供しているのである。
会員登録（無料）が必要です
- 1
- 2
- 次へ ＞
