サービス指向ソリューションは、サービスとして設計されたクレジット残高レポート アプリケーションを提供します。 さらに、このアプリケーションでは、サービス自体として公開されている 3 つのバックエンド アプリケーションを使用して、クレジット残高に必要な情報を取得します。
サービス指向アーキテクチャ (SOA) は、分散システムの構築と部分的に重複するアプローチです。 サービス指向のアプローチには、いくつかの特性があります。
疎結合。 アプリケーションのビジネス ロジックは、サービスを処理するロジックとは別です。
発見可能な。 アプリケーションがサービスを見つけるためのメカニズムが必要です。
契約。 サービスへのインターフェイスは、ユーザーとサービスの間のコントラクトを実装します。
この文献では、多くの場合、サービス指向のアプローチを Web サービスと同義として扱いますが、必ずしもシノニムであるとは限りません。 Web サービスは、サービス指向ソリューションを実装する魅力的な方法を提供しますが、.NET リモート処理などの他のテクノロジを使用してサービスを作成できます。
閲覧者のガイダンス
このソリューションのドキュメントでは、BizTalk Server と Microsoft Visual Studio について理解していることを前提としています。 また、エンタープライズ アプリケーション統合と Web サービスに関する基本的な概念を理解していることを前提としています。
さらに、開発者向けドキュメントを読んでフォローするには、Visual Studio を使用してアプリケーションをビルドする方法と、プロジェクトの作成、参照の設定、BizTalk ソリューションのデバッグとテストを行う方法について理解している必要があります。
Woodgrove Bank でのクレジット カード レポート
サービス指向アーキテクチャ ソリューションは、Woodgrove Bank のクレジット カード残高レポート サービスです。 銀行は架空のものですが、シナリオは実際のデプロイされた顧客アプリケーションに基づいています。
このシナリオでは、クレジット カード残高の要求は次の 2 つのソースから取得されます。
対話型音声応答 (IVR) アプリケーション。
Web ページやカスタム クライアント アプリケーションなどの対話型クライアント。
このソリューションは、MQSeries を介して IVR アプリケーションから要求を受け取ります。 HTTP と SOAP を使用して、Web サービスを介して対話型クライアントからの要求を処理します。
新しいサービス指向アーキテクチャ アプリケーションは、多くの場合、古いテクノロジを使用するレガシ アプリケーションと、Web サービスを使用する Web サイトなどの最新のアプリケーションで機能する必要があります。 このシナリオでは、この実際の要件をモデル化します。IVR アプリケーションはレガシ アプリケーションを表し、カスタマー サービス クライアント アプリケーションは最新のアプリケーションです。
Woodgrove Bank アプリケーションは、3 つのバックエンドのレガシ システムからのデータを使用して、要求に応答します。
与信限度額全体を提供するアプリケーション。 これは、メインフレーム コンピューター上の SAP システムです。
アカウントに対する保留中のトランザクションの合計金額を管理・表示するシステム。 このシステムはメインフレームまたは AS/400 システムです。 このソリューションでは、Web サービスと Microsoft Host Integration Server (HIS) を使用してメインフレームまたは AS/400 システムと通信します。
システムに対して行われた最後の支払いを提供する支払い追跡システム。 支払追跡システムには MQSeries を使用してアクセスできます。
レガシ システムから情報を収集してコンパイルした後、ソリューションは応答を元のアプリケーションに送り返し、したがって顧客に送信します。
ビジネス要件
クレジット レポート アプリケーションは顧客の要求にリアルタイムで応答するため、要求を迅速に処理するには待機時間が短い必要があります。 さらに、多数の同時要求を処理できる必要もあります。 このソリューションでは、セキュリティが大きな懸念事項になるように、機密情報とパブリック インターフェイスが使用されます。 最後に、サービスは信頼性が高い必要があります。
ソリューションがこれらの要件を満たす方法については、「 サービス指向ソリューションの開発」を参照してください。
パフォーマンス特性
ビジネス要件を満たすために、シナリオには次のパフォーマンス特性があります。
1 秒あたり 40 回の受信要求の持続的スループット。
1 秒あたり 100 件の受信要求のピーク スループット。
BizTalk Server の入出力要求の 90% は、1000 ミリ秒未満で処理されることを目標としています。
BizTalk Server 内外で2000ミリ秒以内に処理される要求の95%。
BizTalk Server への入出力要求の 100% が5000ミリ秒未満で処理されるようにします。
注
これらの時間には、バックエンド システムの待機時間は含まれません。
ソリューションの 3 つのバージョン
ソリューションには、次の 3 つのバージョンがあります。
スタブ バージョンでは、すべてのバックエンド システムがソフトウェア スタブに置き換えられます。 スタブはバックエンド システムをシミュレートします。 このバージョンでは、ソリューションを 1 台のコンピューターに展開して実行する簡単な方法が提供されます。
アダプターのバージョンでは、BizTalk アダプターを使用してバックエンド システムに接続します。 このバージョンは、ソリューションを実装するために最初に考える方法です。 ただし、アダプターを使用してバックエンド システムにメッセージを送信すると、応答を返すのに大幅な待機時間が発生します。 アダプター自体では待機時間が非常に短くなる可能性があります。BizTalk Server の分散アーキテクチャでは、アダプターがメッセージ ボックスを使用してオーケストレーション ホスト インスタンスと通信する必要があります。 これにより、データベースへのラウンド トリップが発生し、待機時間に影響します。
インライン バージョンは、アダプターを、バックエンド システムと直接通信するインライン コードに置き換えます。 ソリューションのインライン バージョンでは、待機時間が最も短く、スループットが最も高くなります。
デプロイ ガイドでは、3 つのバージョンのソリューションをすべてビルドしてデプロイする方法と、HIS を介して保留中のトランザクション システムへの接続をシミュレートする方法を各バージョンで提供する方法について説明します。 ソリューションのビルドとデプロイの詳細については、「 サービス指向ソリューションのデプロイ」を参照してください。