50 以上のサード パーティ Web サービスからさまざまなスケジュールでデータを取得する必要があるバックエンド アプリケーションを構築していますが、その数は増え続けるでしょう。これらのサービスからのデータは現在 3 つのタイプにグループ化できるため、各応答を 3 つの既知のスキーマのうちの 1 つにマッピングする必要があります。
カスタム C# を記述して各 Web サービスにアクセスすることは、管理上の悪夢のように思えます。すべてのデータ マッピングがコード内にあることを気にする必要はありません。
現在の考えでは、これを BizTalk 2009 の上に構築します。まだ多くのメンテナンスが必要ですが、少なくともマッピング/変換機能を備えた明確に定義されたプラットフォームです。
以前にこれを行ったことがあるかもしれない人からのアドバイスを探しています。これは本当に私たちに何かをもたらしますか? BTS にポーリング機能がないことは承知していますが、このソリューションを快適に使用するには十分な回避策があります。
ありがとう！
C# を介した BizTalk を検討している人がいると聞いて新鮮です!
ESB ツールキット 2.0 と UDDI サービス v3 (BizTalk Server 2009 に含まれる) の機能を利用する BizTalk アプローチをお勧めします。その理由はいくつかあります。
マッピングに関しては、3 つの一般的なメッセージ タイプと Web サービスの応答ごとにスキーマを定義する必要があります。次に、応答メッセージを適切な共通スキーマにマップするためにマップを作成する必要があります。
このシナリオで ESB 機能を使用する利点は、ソリューションのどの側面も密結合にならないことです。Web サービスの応答が受信されると、応答メッセージのプロパティから正しいマップが (実行時に) 解決されます。メッセージが共通のスキーマ形式にマップされると、それに応じてルーティングできます。
以前にこのようなソリューションを実装したことがありますが、ツールセットを決定する際の大きな要因は、呼び出す必要がある Web サービスの複雑さです。BizTalk では、サード パーティの Web サービスごとに変換を開発します。ほとんどの場合、これは単純なタスクですが、マッピングが重要になる状況に遭遇する可能性があります。このような場合、マッピングを実装するのに必要な時間が、C# で直接マッピングをコーディングするのに必要な時間を急速に超えます。
複数の呼び出しが必要な Web サービスはありますか? たとえば、ポーリングする前に認証トークンを取得しますか? このようなサービスを BizTalk 経由で呼び出すには、より複雑なオーケストレーションが必要になります。
一般的に言えば、BizTalk のようなエンタープライズ システムを利用するよりも、問題に的を絞った C# ソリューションを開発して維持する方が簡単であることがわかると思います。BizTalk ソリューションを実装した私の経験では、必要なメンテナンスの量と問題のトラブルシューティングの難しさは、プラットフォームが提供するメリットをはるかに上回りました。ただし、私の経験では、BizTalk 2006 R2 - 2009 で発生した問題が解決された可能性があります。