WCFエンドポイント、baseAddressPrefixFilters、ホストヘッダー
質問
同じマシンに2つのWebサイトがあります。最初の(クライアント)は、2番目のサイト(サーバー)のWCFサービスを参照します。
サービス参照のアドレスを設定するにはどうすればよいですか?ローカルマシンでの開発からグループ開発サーバーに移行する場合、サービスのURLを変更するにはどうすればよいですか?サイトは、次のようなホストヘッダーによって区別されます。 http://dev.admin/ ... そして http://dev.public/ ...
これは複数のエンドポイントを使用して処理できると思いますが、私はWCFが初めてであり、実際にここで何をしているのか分かりません。
解決
多くのフラストレーションの後、両方のweb.configファイル(この場合は両方ともWebアプリです)で、次のセクションを変更する必要があると判断しました:
クライアント:
<client>
<endpoint
address="http://mysite.com:port/services/someservice.svc"
binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISomeService"
contract="MyServices.ISomeService"
name="BasicHttpBinding_ISomeService" />
</client>
</system.serviceModel>
サーバー
<system.serviceModel>
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="http://mysite.com:port/services"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
<behaviors>
<serviceBehaviors>
<behavior name="MyServices.SomeServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="MyServices.SomeServiceBehavior"
name="MyServices.SomeService">
<endpoint address="http://mysite.com:port/services/someservice.svc"
name="endpoint.SomeService"
binding="basicHttpBinding"
bindingConfiguration=""
contract="MyServices.ISomeService"/>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
</system.serviceModel>
ここで注意すべきことは、関連する3つのセクションすべて(クライアントエンドポイントアドレス、サーバーbaseAddressPrefixFilter値、およびサーバーエンドポイントアドレス)のホストアドレスが一致する必要があることです。
一致している限り、これらを変更することでサーバーを切り替えることができます。サーバーが実行されているマシンに基づいてこれを設定する方法を引き続き希望しますが、これは現時点では機能します。
WCFインプレッション 最新情報:永続オブジェクト。クライアントプロキシオブジェクト(サービス参照を追加するときに作成される)は、サーバー上のサービスへの永続的な接続を維持します。クライアントプロキシによって参照されるサービスインスタンスは、呼び出し間で状態を維持します。これにより、メソッドシグネチャが簡素化され、クライアントプロキシオブジェクトとサービス全体が特定のアプリケーションで非常に役立ちます。パラメータオブジェクトタイプは、共通ライブラリで宣言されている場合、クライアントとサーバー間で共有できます。つまり、2つの非常に類似したクラスやラッパークラスを作成して、非プリミティブデータ構造をやり取りする必要はありません。
ないこと:構成は王室の苦痛であり、文書化が不十分であり、非常に複雑です。サービスがその場所を認識する必要があるtest / dev / staging / production環境構成でこれを機能させるのはイライラします。ドメインURL(たとえば、実行しているものへの相対パスではなく)をサービスに認識させることには大きな利点があるとは思いませんが、セキュリティ上の懸念はさておきます。
とはいえ、これまでの利点が頭痛の種をはるかに上回っているので、WCFの道を歩み続けています。
他のヒント
最も簡単な方法:さまざまなポートでWCFパーツを実行します。