Service resolution works on 10 pieces for web services -
1 - ip
2 - port
3 - uri
4 - content-type
5 - xml parsing
6 - ws-security parsing
7 - soap
8 - wsdl
9 - namespace
10 - potentially policy driven if you have something like Require TLS/SSL with Client Authentication
It is roughly those in order.
1- 3 are pretty obvious for SOAP Web Services.
4 needs to be text/xml if no attachment or multipart-related with text/xml or application/xop+xml for attachments.
5 content needs to be XML parable if it is not you get an Error of content-type text/html with an html response of Bad Request this is not overrideable in policy.
6 if either WS-Signature or WS-Encryption is in inbound then those get checked prior to policy execution meaning CipherData is decrypted if possible and Signature blocks are check. If signatures are invalid you get a soap fault with Bad Request in details. If encryption key is not found cipher data is not decrypted. These are only overrideable if you chose the properties of the Service and uncheck WS-Security checks on the main tab
7 must be the version of soap that was in the WSDL and that you are enforcing on the WSDL tab of the Service Properties
8 must be a method within the wsdl and optionally the HTTP Header SoapAction is checked against the method as well
9 namespace of inbound must match - this is how you version a service from v1 to v2 to ... vN with namespaces changes
10 your policy does not have to start with Require TLS/SSL with Client Auth - you can actually have other assertions that do just Require TLS/SSL and Require HTTP Basic and if HTTP Basic is not present then require Client Auth on the TLS/SSL. This is more policy, but since it happens on the protocol setup I put it in here
Service resolution works on 3 pieces for web apis -
1 - ip
2 - port
3 - uri
1 and 2 are obvious
3 is where all the action happens. in web apis you will have different web apis with similar uris with wild cards like
a - /app*
b - /app/customer*
c - /app/customer/region/*
c - /app/portfolio*
d - /*
So the rule of thumb here is the most closely matched is the policy that prevails. So If I send in /app/customer/1 matches "b" where /app/customer/region/west would match "c" and /app would match "a" and /application would match "d"