重複の可能性:
WCF API デプロイメントのバージョン管理
私はWCF Restサービスに取り組んでいます。私はいくつかのサービスを持っています。ここで、クライアントがサービスにアクセスする前に、チェックを追加したいと思います。バージョン番号。バージョン番号が 2.0 よりも小さい場合、クライアント アプリケーションは「アプリケーションが古くなっています」というエラーを受け取り、サービスにヒットしません。
私の主な目的は、このチェックを各 Web サービスに適用したくないということです。最初にバージョンをチェックしてから、クライアントが目的のサービスにアクセスできるようにする汎用サービスが必要です。
これはどのように行うことができますか。また、これが .NET の従来の Web サービスで可能かどうか。
これはかなり悪い考えだと思います。すべてのサービス エンドポイントのすべてのバージョンの詳細をどうにかして知っている集中型サービスを作成し、サービスを利用するために消費者に追加の呼び出しを要求する必要があります。
これにより、「バージョン チェッカー」サービスが利用できない場合、「有効な」コンシューマー (正しいクライアント バージョンを持つコンシューマー) が引き続きサービスを呼び出すことができないという点で、単一障害点が作成されます。
また、この中央の場所で各サービスの最新バージョンを維持する必要があり、サポートのオーバーヘッドが発生します。
サービスのバージョンを管理する最善の方法は、古いバージョンのクライアントをサポートできるように、破壊的でない変更を加えることです。あなたは多くの方法でこれを行います。これについては、以前にこことここに投稿しました。
重大な変更を加える必要がある場合は、コンシューマーを中断させる (したがって、アップグレードを強制する) か、異なるエンドポイントで異なるバージョンのサービスを共同ホストする必要があります。
注: UDDIと呼ばれる、あなたが考えているもののために設計されたものがあります。UDDI サーバーの背後にある考え方は、エンドポイント アドレス、トランスポート、さらには公開された型など、サービスに関するすべての情報を格納できるため、コンシューマーは実行時に UDDI を照会し、オンザフライでクライアントを組み立てることができます。
これにより、コンシューマはサービスのバージョンをまったく知らなくてもよく、実行時に UDDI からこの情報を取得することになります。
ただし、UDDI が使用されることはめったにありません (おそらく、単一障害点が発生するのと同じ理由で)。私はクライアントのために ESB を構築したときに、私のキャリアの中で一度だけ使用しました。
編集
あなたのコメントに応えて、私はあなたにとって最善の解決策は、サービス操作要求コントラクト タイプでバージョン メンバーを公開することだと思います。これにより、消費者は、呼び出す予定のサービスのバージョンを宣言する必要があります。
リクエストを受信したら、リクエストを調べてバージョンを確認できます。それらが一致しない場合は、 で定義した型の例外をスローできますFaultContract。(フォルト コントラクトの詳細はこちら)。
これにより、コンシューマーはサービス操作呼び出しを catch ブロックでラップし、返されたカスタム例外タイプを処理できるようになります。「無効なバージョン」エラーをカバーする組み込みの例外はないと思うので、独自に定義する必要があります。
これは、消費者が古いバージョン属性を使用してサービスを呼び出そうとした場合にのみ例外が返されることを意味し、余分なサービス呼び出しを行う必要がなくなります。また、この情報を一元化するのではなく分散します (これはより堅牢なアプローチです)。
編集2
あなたのコメントに応えて、Fault コントラクトは asmx ではサポートされていません。サービスで例外をスローし、クライアントで例外をSoapExceptionとしてキャッチする必要があります。クライアントでは、バージョン管理が原因であるかどうかを判断するために、SoapException メッセージ (良くない) を調べる必要があります。