1

私は現在、Windows Server 2008 の IIS7 で実行される Web サービス アプリケーション プロジェクトに取り組んでいます。Web サービスは、サーバーの外部からだけでなく、同じサーバー内の他のコンポーネントからも、さまざまなクライアントから呼び出されます。(その他の Web サービスおよび Windows サービス)

私の見解では、Web サービスの目的は機能を公開して、外部クライアントがそれを呼び出すことができるようにすることです。同じサーバー上の別の Web サービスを呼び出す Web サービスや、同じサーバー上の Web サービスを呼び出す Windows サービスにはあまり意味がありません。私が間違っている場合は修正してください。

WCF の調査を開始しましたが、かなり混乱しています。

次のようにした方が適切でしょうか？

  • Web サービス プロジェクトの代わりに、WCF サービスを実装します。
  • 2 つのエンドポイント
    を公開します。1) 1 つは、外部クライアントから呼び出される従来の Web サービス バインディングを使用して公開されます。
    2）内部サービス（他のWebサービスまたはWindowsサービス）がそれらを呼び出すことができる別のエンドポイント。これらはサーバー上ですでに実行されているアプリケーションであるため、おそらくより効果的にセキュリティレイヤーを超えます。

私のアプローチは正しいでしょうか、それとも物事を過度に複雑にしていますか?

私を正しい方向に向ける可能性のある提案やリンクは高く評価されています。

ありがとう

4

2 に答える 2

1

BasicHttpBinding は、外部クライアントとの相互運用性を最大限に高めます。名前付きパイプは、両方のサービスが同じマシンでホストされている場合に最も効率的です。

BasicHttpBinding は、古い asmx & XML Web サービスのようなものです。

両方のエンドポイントを公開するのは AOK!

あるサービスが別のサービスを呼び出すことは珍しいことではありません。

同じマシンで複数のサービスをホストすることは一般的です。企業では、SQL-Server の複数のインスタンスを実行することは一般的です。もちろん、ハードウェア、サービス、および応答時間によって異なります。

于 2013-02-28T13:41:55.320 に答える
1

別の Web サービスを呼び出す Web サービス?

役割が違うなら分けたほうがいいと思います。懸念事項の分離が改善され (他のプロジェクトやコード ベースとの共有が容易になります)、保守が容易になり、独立した展開が可能になります。

私は WCF を使用し、異なるコンシューマーに対して 2 つの異なるエンドポイントを用意します。たとえば、同じサーバー (クライアントがサポートしている場合) での通信には net.pipe を使用し、外部クライアントには http を使用します。

WCF は、古い xml Web サービスよりも優れた機能と柔軟性を提供すると思います。また、構成部分は非常に優れています。

于 2013-02-27T09:44:38.010 に答える