Windows Server AppFabricの紹介。 BizTalkおよびService Busを使用したホスティングサービス

これは、Windows Server AppFabric Servicesに関する3番目の最終記事です。 次のリンクで他の2つの記事を見つけることができます。

• Windows Server AppFabricの紹介。 キャッシングサービス
• Windows Server AppFabricの紹介。 ホスティングサービス、ホスティングおよびスケーリングサービス

シナリオ：BizTalk Serverを使用してワークフローベースのサービスを既存のアプリケーションに接続する

多くのアプリケーション、おそらく大部分は、他のアプリケーションと通信する必要があります。 たとえば、店舗のサイト用に作成されたサービスをもう一度想像してください。 サービスが処理のために完了した注文をERPアプリケーションに送信する必要がある場合、またはクレジットカード検証のために別のアプリケーションから情報を受信する必要がある場合を考えます。 何らかの方法で、サービスはしばしば相互に通信する必要性を感じます。

Microsoftの世界では、このタイプの統合は通常、BizTalk Serverによって処理されます。 図1は、ワークフローベースのサービス、AppFabricホスティングサービス、およびBizTalk Serverが相互に連携する方法を示しています。


図1 BizTalkサービスとサーバーの統合

図に示すように、サービス内のアクティビティは、BizTalkサーバーへの要求を作成できます。 これは、Webサービスを使用するか、何らかの方法で行うことができます。この目的のために、BizTalkはさまざまなタイプの通信用のアダプターメカニズムを提供します。 要求の開始後、BizTalkサーバーで実行されているビジネスロジックによって処理できます。 このロジックはコンダクターとして実装され、このプロセスの次のステップをサポートする方法を知っています。 ここでは、たとえば、コンダクターは別のBizTalkアダプターを使用して、ERPアプリケーションと直接対話します。 すべての応答は、同じコンポーネントを介して送り返すことができます。

純粋に技術的な観点から見ると、AppFabric Hosting Servicesで実行されるワークフローベースのサービスは、BizTalkサーバーで実行されるコンダクターとまったく同じように見える場合があります。 どちらもワークフローであり、どちらもグラフィックエディターで作成できます。Microsoftは、サービスとコンダクターの両方で使用できるWCFアダプターも提供しています。 ただし、だまされてはいけません。これらの2つの技術は異なる問題を解決します。

AppFabric Hosting Servicesで開始されたワークフローベースのサービスは、ビジネスロジックを実装するように設計されています-これはアプリケーションです。 対照的に、BizTalkで立ち上げられたコンダクターは、統合のみに焦点を当てています。 統合は特別なツールと技術を必要とする特定の問題であり、BizTalkはまさにそのようなツールです。 ほとんどの場合、2つのテクノロジーの選択は簡単です。AppFabricホスティングサービスを使用してアプリケーションを構築し、BizTalkを使用して統合の問題を解決します。

AppFabricホスティングサービスとWFを使用してBizTalk機能を実装することは技術的には可能ですが、経済的な理由からこれは意味がありません。 独自の統合サーバーの構築と保守の総コストは、BizTalk Serverライセンスのコストを超える可能性があります。 実際には、競合他社よりもAppFabricホスティングサービスとBizTalkパートナーを検討する方が良いでしょう。 各メカニズムは、アプリケーションの作成と接続に役割を果たします。

シナリオ：サービスバスを使用してリモートサービスに接続する

サービスを使用するときに発生する可能性のある別の問題は、インターネットからサービスへのアクセスの提供です。 組織内で開始されたWCFサービスを、インターネットチャネル経由で組織外の顧客に提供する必要があると想像してください。 WFを使用するかどうかに関係なく、この場合にはいくつかの障害があります。 たとえば、クライアントはファイアウォールを介してどのようにサービスとやり取りできますか？ そして、ほとんどの組織が動的アドレスとNATを使用していることを知っているので、クライアントに固定IPを提供する方法は？

Windows Azureプラットフォームの一部であるService Busは、この問題を解決するために作成されました。 図2に操作スキームを示します。


図2。 作業サービスバス

まず、WCFサービスはエンドポイントをService Busに登録し、これに一意の名前を付けます（ステップ1）。 その後、Service Bus自体がこのエンドポイントに同じインターフェイスを提供します（ステップ2）。 一意の名前を使用して、クライアントはService Busエンドポイントにアクセスできます（手順3）。 クライアントはインターフェイスに精通しているため、サービスバスのエンドポイントで操作できます（ステップ4）。 クライアントが呼び出す各操作に対して、Service Busはエンタープライズインフラストラクチャの側でサービス内の対応する操作を呼び出します（ステップ5）。

これが機能する理由を理解するには、ステップ1でサービスがエンドポイントをサービスバスに登録すると、クラウドブローカーとのTCP接続が確立されることを理解することが重要です。 その後、接続は開いたままになり、Service Busはエンタープライズファイアウォールによってブロックされることなくサービス操作を呼び出すことができます。 ファイアウォールは、このようなトラフィックを企業外部のクライアントからの接続の応答として処理するため、そのようなパケットを通過させます。 接続を開いたままにすると、WCFサービスはNATに依存しない固定IPアドレスを持つことができ、サービスバスがサービス操作を柔軟に呼び出すことができます。 さて、Service Busには常に特定のIPアドレスがあるため、顧客は簡単に見つけることができます。

シナリオ：ワークフローに基づいたサービスを備えた複合アプリケーションの作成

サービスを介して機能を提供するアプリケーションの成長に伴い、開発者はこれらのサービスが消費するさまざまなアプリケーションを構築する機会がますます増えています。 このタイプの複合アプリケーションは、さまざまな状況で非常に役立ちます。 たとえば、既存のERPアプリケーションを直接変更する代わりに、ERPサービスとサードパーティアプリケーションの他のサービスを使用して新しい機能を作成する複合アプリケーションを作成する方が簡単で安価です。 図3は、AppFabricホスティングサービスを使用して起動されたワークフローベースのサービスが、このタイプのアプリケーションを作成する方法を提供する方法を示しています。


図3 複合アプリケーション図

この例では、ワークフローベースのサービスは、いくつかのアプローチを使用して他のアプリケーションと対話します。

• Service Busを使用して、インターネット上にあるパートナーアプリケーションで操作を呼び出す
• SOAPサービスを使用してCRMアプリケーションへの直接リクエストを作成する
• BizTalkを使用してERPアプリケーションと対話する

成長を続けるサービス指向の世界では、これらのサービスを操作するためのロジックを簡単に作成できることが大きな役割を果たしています。 AppFabric Hosting Servicesは、アプリケーションを実行するためのサービスアーキテクチャを提供することにより、この動きをサポートしています。

パーツを全体に結合する

Windows Server AppFabricの2つの部分-AppFabric Caching ServicesとAppFabric Hosting Servicesは、互いに別々に使用できます。 しかし、多くの場合、それらを一緒に使用するのが理にかなっています。 たとえば、組織がユーザーからの非常に多くの同時リクエストを処理できるアプリケーションを作成するとします。 図4は、Windows Server AppFabricの2つのコンポーネントを組み合わせてこれを実現する方法を示しています。


図4 AppFabricサービスを一緒に使用する

いつものように、ユーザーからのリクエストは、ビジネスロジックのコピー（ASP.NETページの形式）をそれぞれに持つ複数のWebサーバー間の分散のために、ロードバランサーによって処理できます。 このロジックが同じ情報（組織が販売するものを正確に記述するデータのカタログなど）を頻繁に使用する場合、そのような情報はAppFabric Caching Servicesを使用して実装されたキャッシュクラスターからアクセスできます。 また、アプリケーションのトレーディングバスケットはAppFabricホスティングサービスで起動されるワークフローベースのサービスを使用して実装されているため、Webサーバーからのリクエストは複数の中間サーバー間で分散できます。 ところで、これは図には示されていませんが、ワーカースレッドはキャッシュデータにアクセスして必要な情報を取得することもできます。 このようなシナリオでは、Windows Server AppFabricの両方の部分を組み合わせることは非常に有用であり、高度にスケーラブルなシステムを構築する必要がある開発者の作業を容易にします。

おわりに

遅いアプリケーションは良いとは言えません。 本当に優れたアプリケーションも管理可能でなければなりません。 Windows Server AppFabricサービスは、Windowsアプリケーションのパフォーマンス、スケーラビリティ、および管理性を向上させるインフラストラクチャを提供し、開発者がアプリケーションを改善するのに役立ちます。

すべてのソフトウェアインフラストラクチャと同様に、これらのテクノロジーはツールです。 しかし、ツールは快適な生活の基盤です。 同様に、Windows Server AppFabricの目標は、より効率的なWindowsアプリケーションを構築するためのフレームワークを提供することです。 開発者がビジネスロジックにより多くの時間を費やし、インフラストラクチャの構築に費やす時間が少ない方が良いでしょう。