2

WS-Security、WS-Encryptionなどを使用して認証/承認を追加するためだけに、一連の内部Web サービス上に外部Web サービスを構築した、この非常に奇妙なコードベースを継承しました。この契約を開始してから 1 か月も経たないうちに、厳密な WSDL を介して揮発性コンポーネントを結合することの苦痛をすでに感じています。特に、WCF を使用するものもあれば、最初に WSDL を使用することを選択するものもあると考えています。生成されたプロキシとラッパーのさまざまなバージョンをさまざまなレベルで管理するのは悪夢です!

設計が複雑すぎることは認めますが、もっと良くできたはずですが、基本的に私の質問は次のとおりです。

  • 一連のサービスに対して分野横断的な懸念を提供するためだけに Web サービスを構築することはありますか?
  • これは、Web サービス ハンドラとして実装したほうがよいでしょうか?

そして最後に...

  • これを Web サービス ゲートウェイ パターンに分類しますか?
4

2 に答える 2

3

私はまさにそれが1年前に建てられているのを見ました。チームが 4 つの Web サービスを構築するのに数か月を要したとき、私は泣きそうになりました。そのうちの 2 つは、WCF といくつかの本格的な暗号化を使用して、他の内部サービスをラップするだけでした。彼らが内部のものをラップした唯一の理由は、返される潜在的なエラー番号を変更することでした.

それで、私は意図的にそれをするでしょうか？いいえ。

他のほとんどのものとして実装したほうがよいでしょうか？はい。

それを WTF パターンに分類しますか? 絶対。

アップデート：

私が思い出したのは、「エンタープライズ サービス バス」と呼ばれるアーキテクチャがあることです。その目的は、他の SOA システムに共通のインターフェイスを提供することです。このように、さまざまなアプリケーションがエンド ポイント メカニズム (WCF、WSE 1/2/3、RESTful など) に何を使用しているかは問題ではありません。

BizTalk は ESB の一例であり、使用できる既製のプログラムは他にも多数あります。基本的に、アプリはメッセージを ESB に渡し、そのメッセージを信頼できる方法で他のシステムに送信し、応答をマーシャリングします。

これは、エンドポイントに対するさまざまな種類の変更から他のアプリケーションを隔離できることも意味します。もちろん、新しいエンドポイントに追加情報が必要な場合は、呼び出し元を変更する必要があります。ただし、変更がメカニズムだけである場合、優れた ESB はアプリに影響を与えることなくこれらの変更を処理できます。

于 2008-10-03T05:10:14.433 に答える
0

サービスを外部に公開している場合や、セキュリティを強化する必要がある場合は、同様の実装を見てきました..このMSDN コラムを確認してください..

于 2008-10-03T05:04:15.010 に答える