アダプターの初期展開後、および有効期間中に数回発生する可能性がある場合は、アダプター (および公開するエンドポイント) をさまざまな理由で変更する必要があります。 これらの理由には、ビジネス ニーズの変化、情報テクノロジの要件、基幹業務システムまたはアダプター自体に関する問題が含まれます。 このトピックでは、Microsoft Windows Communication Foundation (WCF) 基幹業務 (LOB) アダプター SDK を使用して記述されたアダプターのバージョン管理を処理するためのさまざまな方法について説明します。
バージョン管理と Windows Communication Foundation
WCF LOB アダプター SDK は、Windows Communication Foundation (WCF) に基づいて構築されており、システム間でメッセージを交換するためのインフラストラクチャに依存しています。 WCF が公開するメカニズムを使用して、サービスとデータ コントラクトの両方をバージョン管理できます。 サービスのバージョン管理のベスト プラクティスなど、詳細については、WCF オンライン リファレンスの 「サービスのバージョン管理 」を参照してください。 データ コントラクトのバージョン管理のベスト プラクティスなど、詳細については、WCF オンライン リファレンスの 「データ コントラクトのバージョン管理 」を参照してください。
バージョン管理のシナリオ
主なバージョン管理シナリオは 2 つあります。
1 つのアダプター バージョンでは、ターゲット システムの複数のバージョンがサポートされています。
2 つ以上のアダプター バージョンでは、同じシステムまたは 2 つ以上の異なるシステムがサポートされています。
また、WCF LOB アダプター SDK の更新プログラムが既存の機能に影響する場合は、アダプターの新しいバージョンをリリースする必要があります。
これらの各シナリオには、異なるバージョン管理戦略が必要です。
Note
WCF LOB アダプター SDK では、特定のバージョン管理シナリオは適用されません。 アダプターのバージョン管理の要件を決定するには、開発者に任されています。
1 つのアダプターで複数のバージョンのターゲット システムがサポートされる
アダプターがターゲット システムの複数のバージョンをサポートしている場合は、目的のバージョンを識別するために使用できる 1 つ以上のバインド プロパティを公開する必要があります。 たとえば、アダプターは、ターゲット システムのベンダーによって提供される複数の通信ライブラリをサポートする場合があります。 "LibraryVersion" という名前のカスタム バインド プロパティを使用すると、アダプター コンシューマーは、展開環境またはその他の要件に基づいて使用するライブラリを選択できます。
1 つのバージョンのターゲット システムをサポートする 2 つ以上のアダプター
この場合、各アダプターでは、一意のスキーム (ContosoV1:// と ContosoV2://) と一意のバインド名 (ContosoV1Binding と ContosoV2Binding) を使用する必要があります。 ベンダーは、スキームとバインド名 (Microsoft.ContosoV1:// や Microsoft.ContosoV1Binding など) にも名前を使用することを検討する必要があります。
WCF LOB アダプター SDK の新しいバージョン
WCF LOB アダプター SDK の新しいバージョンがリリースされると、WCF LOB アダプター SDK リリースは下位互換性があるため、アダプターを再コンパイルしなくても新しいバージョンをインストールできます。 ただし、新しいリリースを評価して、アダプターが依存する機能に変更があるかどうか、またはアダプターが実装することでメリットを得られる新しい機能があるかどうかを判断する必要があります。