Service compatibility is determined based on policy

[WorldMaker]

Commenting as issue again because Markdown is a bit easier for a quick chat than markup in a PR. Aside: Have you considered Giscus?

I think that tenet is the most nebulous because best practices shifted a lot. What I recall of what early WCF called "policy" was a lot of the "administrivia" and boilerplate of early WCF bindings and was often reflected in the weird complexities of WSDL (and SOAP's WS-Policy in the wilderlands of WS-*).

At first everything was open to negotiation, runtime configuration, and trade winds: transport protocol, transport port, transport security, message security, RPC format (despite being described in SOAP you could switch to non-SOAP), and more. My view of "policies" in this case was that it was an overly broad abstraction of all of transport meta-considerations, security considerations, message format meta-considerations (spoken inside an existing message format), authorization, authentication, and a bunch of other things that were useful to think about but not always useful to think about together as a group, especially in a way that micro-managing such policies always made strict sense either.

In theory, the same service could provide any number of combinations of these things and as long as the client understood at a high level the individual "policies" of these transport/connection/security/authc/authz could decide how best to connect or could connect in different ways at different times.

In practice, it was almost impossible to get a service working that could serve say both TCP socket and UDP sockets at the same time. The underlying transports are too different and make very different guarantees. In theory a client agreeing to the UDP "policy" is opting into the lossy nature of the transport protocol and accepts the loss. In practice it lead to a lot of "why does this client work only some of the time?" hard to debug questions and learning the difference was a subtly different binding XML document anywhere on the service or client or hard-coded in either or a bug in the binding negotiation steps inside WCF in either.

In practice, while negotiation and micro-management over security specifics is "future proofing", the failure case almost always seems to be "insecure", especially if developers aren't specialized in security and don't know what they are doing. We've learned from too many collective mistakes that security suites should be opinionated, impossible to micromanage, and as much as possible left to Operating Systems and specialists.

In practice, we find authentication and authorization are much more application level concerns than RPC protocols thought they were and negotiating anything about it at in service level configs was sometimes putting the cart before the horse.

And so forth. There were too many things in that one abstraction bucket, and most of them turned out to be mistakes in practice, though they sounded nice in theory.

That played out in WCF Bindings. I still remember pulling out multiple different UI tools for all sorts of complicated Binding debugging in early WCF. (Though I also made things worse for myself by trying to use WCF's ambitious but not really ready for prime time peer to peer bindings.) As WCF aged the bindings all got more opinionated and less configurable and less negotiated.

There's probably still something salvageable in the tenet itself, but the WCF era idea of "policy" from my understanding was a flawed abstraction that was elegant in theory and didn't survive contact with practice.

[ploeh]

Thank you for writing

Commenting as issue again because Markdown is a bit easier for a quick chat than markup in a PR. Aside: Have you considered Giscus?

I haven't considered that system in particular, but I've considered and rejected that entire category of comment systems.

Given that you've just suggested yet another one of those, I consider this only validation that that's the correct strategy.

I think that tenet is the most nebulous because best practices shifted a lot. What I recall of what early WCF called "policy" was a lot of the "administrivia" and boilerplate of early WCF bindings and was often reflected in the weird complexities of WSDL (and SOAP's WS-Policy in the wilderlands of WS-*).

That's a good point. It didn't cross my mind from reading the article that policy actually turned out to be configuration. That's not how I read the description of the tenet, but you may be right.

I've definitely been around that block a few times myself, as witnessed by a few archived articles:

• Authorizing Services
• Troubleshooting WCF In Production Environments
• Declarative Use of Custom SecurityTokenParameters
• Custom Tokens Over Non-HTTP Transports