Gateway Service Resolution Process

When the gateway receives a request, the service resolution process determines the target web service and the policy that is enforced by the Gateway.
gateway92
When the
CA API Gateway
receives a request, the service resolution process determines the target web service and the policy that is enforced by the Gateway.
The resolution process does not ensure that the messages are valid or meaningful. It is recommended that your policy includes a  Validate XML Schema Assertion to ensure compliance.
By default, web services are accessed through the URI
/ssg/soap
. However, you should assign a custom resolution URI instead of using this default value. There are benefits to using a custom URI--for example, to allow the same WSDL to be published more than once. To define a resolution URI, see  Published Service Properties.
To determine the correct web service, the resolution process uses the following steps to narrow down the possible targets. When the list of possible targets is reduced to a single web service, the resolution succeeds and the request is routed. If no service is found, the resolution fails and an error is returned to the requestor.
Any resolution logic can be disabled through the Policy Manager, if it is appropriate to do so. For more information, see  Manage Service Resolution.
Step 1: Determine service based on service entity ID
Initially, the resolution process attempts to match the unique identifier of a service from the URI. The URIs is displayed in this format:
http://gatewayhost:8080/service/123456
where
"123456"
is the entity ID of the service
These are the possible outcomes:
  • The URI contains a service entity ID and it matches a service:
    The request succeeds and the appropriate policy is executed (pending "SOAP Verification", if necessary).
  • The URI contains a service entity ID that does not match any service:
    The resolution process fails and an error is returned to the requestor.
  • The URI does not contain a service entity ID:
    The resolution process moves to Step 2.
Step 2: Determine service based on URI
When the incoming URI does not contain a unique service identifier, the resolution process examines the URI for a custom routing URI, for example:
http://gatewayhost:8080/customURI
.
These are the possible outcomes:
  • A custom routing URI matches a single service assigned to this URI:
    The request succeeds and the appropriate policy is executed (pending "SOAP Verification", if necessary).
  • A custom routing URI matches more than one service with this URI:
    The resolution process moves to Step 3.
  • A custom routing URI does not match any service:
    The resolution process fails and an error is returned to the requestor.
  • A custom routing URI does not exist
    (that is, the default "/ssg/soap" is used): The resolution process moves to Step 3.
Step 3: Determine service based on SOAPAction
In this step, the resolution process searches for a SOAPAction accompanying the incoming message. SOAPActions are associated with a service during publication time using a service description document provided by the administrator.
These are the possible outcomes:
  • The SOAPAction matches a published service:
    The request succeeds and the appropriate policy is executed (pending "SOAP Verification", if necessary).
  • The SOAPAction does not match any service:
    The resolution process fails and an error is returned to the requestor.
  • No SOAPAction exists:
    The resolution process moves to Step 4.
Step 4: Determine service based on SOAP payload namespace
In this step, the resolution process examines the namespace of the first element in the message body. It then tries to match the namespace against known namespaces from the list of published services.
For the purposes of service resolution, only the namespace URIs of the SOAP payload element(s) are considered, not the local names or namespace prefixes. For example, the following elements can be treated as identical by the resolution process:
<a:doStuff xmlns:a="http://ns.example.com/services"/>
<b:doSomeOtherStuff xmlns:b="http://ns.example.com/services"/>
These are the possible outcomes:
  • The namespace matches a published service:
    The request succeeds and the appropriate policy is executed.
  • The namespace does not match any service:
    The resolution process fails and an error is returned to the requestor.
Partial Matches
The resolution process routes requests to target services as quickly and efficiently as possible. It is designed to stop once it finds a single web service within Steps 1 to 4 that matches the contents of the request. This may result in only a partial match because there is no guarantee that the request has passed any subsequent checks. For example, a request is successfully routed based on its URI (Step 2), but that does not means its SOAPAction (Step 3) or SOAP payload namespace URI (Step 4) matches the target web service.
SOAP Verification
If the request is resolved to a SOAP service (that is, one published with a WSDL), the following additional verification is performed. The Gateway verifies that:
  • The request is SOAP, and
  • The payload elements in the request correspond to an operation defined in the WSDL.
If both of these checks are satisfied, the request is routed to appropriate service.
The SOAP Verification process may be overridden on a service-by-service basis. For more information, see the "WSDL" tab under  Published Service Properties.