1

レガシ .Net Remoting サービスを WCF に移行中です。この件についてしばらく読んだ後、このメタデータの話と、クライアント上で動的にプロキシを構築することに出くわしました。有望に思えました。

私が達成したかったのは、可能であれば、最小限の構成で (つまり、構成<services>ファイルに明示的なノードがない) 1 つの Web アプリケーションでサービスを公開し、最小限の構成で (インターフェイスを共有することによって) クライアントでプロキシを構築することです。 .

デフォルトですべてのサービスのメタデータを公開できることは知っていますが、これが機能しているように見える方法は、サービスごとに異なる URL を生成し、クライアントでハードコーディングされた数十の文字列を維持する必要があるため、役に立たないようです。

これは私の現在の設定ファイルです：

<system.serviceModel>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />

  <behaviors>
    <serviceBehaviors>
      <behavior>
        <serviceMetadata httpGetEnabled="true" />
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

'http://localhost/VirtualDirサーバー上に 1 つの URL (おそらくベース アドレス自体) を設定し、このエンドポイントを使用して、クライアントからのサービス インターフェイスを自動的に解決したいと考えていました。このやや古い投稿に出くわしました。これは多かれ少なかれ私が達成したいことです。当時、それを優雅に行う方法はないように思われました。

おそらく、サーバー上で単一の MEX エンドポイントを公開し、その上のコントラクト インターフェイスを解決する方法はありませんか? このようにして、次のことができるようになります。

  1. クライアントに単一の URL を保存する
  2. MetadataResolver特定のインターフェイスのクラスを使用してエンドポイントを取得する
  3. ChannelFactory<T>解決されたエンドポイントを使用してプロキシを作成します

これをある種のファクトリ クラス内で実行し、Unity IoC コンテナーで使用したいと考えました。

既知の形式を使用して多くの実際のエンドポイント アドレスを構築する何らかの規則を使用して、これを機能させることができると思います。それでも問題が発生する可能性があるため、それは避けたいと思います。

4

1 に答える 1

1

これにどのようにアプローチできるかについては、次の 2 つの方法が考えられます。

  1. WCF ルーティング サービスを使用し、フィルタを使用して、SOAP アクションまたはその他のコンテンツに基づいてルーティングします。
  2. リクエストでMessageインスタンスを処理するエンドポイントを作成し、内部で変換します。

WCF ルーティングの欠点は、これ自体が別の WCF サービスであることです。また、オプション 2 が、あなたが希望する方法とまったく同じように可能であるかどうかもわかりません。

このMSDN マガジンの記事を確認してください。

また、MetadataResolver は主にクライアントで使用して、サービスのエンドポイントを呼び出す前に動的に解決します。あなたが説明したように、サービス側でこれが実装されているのを見たことがありません。

さらに、マイナーな点として、WCF は、2 つのアプリケーションが通信する際の明示的な境界を定義するために使用されるように設計されています。この分離は明示的であり、抽象的で冗長な外部契約の相互受け入れとして表現されます。私の意見では、この種の明示的な契約を回避しようとすると、そもそもなぜ境界が必要なのかという疑問が生じます。可能であれば、インプロセスで実行されているサービスを呼び出すことをお勧めします。

于 2013-09-26T07:57:44.550 に答える