Different web services engines route incoming requests to particular web services implementations differently.
You said "web services", but didn't specify the use of SOAP. I'm going to assume SOAP.
The SOAP 1.1 specification says ...
The SOAPAction HTTP request header field can be used to indicate the intent of the SOAP HTTP request. The value is a URI identifying the intent. SOAP places no restrictions on the format or specificity of the URI or that it is resolvable. An HTTP client MUST use this header field when issuing a SOAP HTTP Request.
Most web services engines comply with the spec, and therefore use the SOAPAction:
header. This obviously works only with SOAP-over-HTTP transmissions.
When HTTP is not used (say, TCP, or some other), the web services engine needs to fall back on something. Many use the message payload, specifically the name of the top-level element in the XML fragment within the soap:envelope. For example, the engine might look at this incoming message:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<soap:Body>
<m:GetAccountStatus xmlns:m="Some-URI">
<acctnum>178263</acctnum>
</m:GetAccountStatus>
</soap:Body>
</soap:Envelope>
...find the GetAccountStatus
element, and then route the request based on that.