Page History

...

<service role="WEATHER">

• The role/implementation/version triad is used through Knox for integration plugins.
• Think of the role as an interface in Java.
• This attribute declares what role this service “implements”.
• This will need to match the topology file’s <topology><service><role> for this service.
  
  

<service name="weather">

• In the role/implementation/version triad this is the implementation.
• Think of this as a Java implementation class name relative to an interface.
• As a matter of convention this should match the directory beneath <GATEWAY_HOME>/data/services
• The topology file can optionally contain <topology><service><name> but usually doesn’t. This would be used to select a specific implementation of a role if there were multiple.
  
  

<service version="0.0.1">

• As a matter of convention this should match the directory beneath the service implementation name.
• The topology file can optionally contain <topology><service><version> but usually doesn’t. This would be used to select a specific version of an implementation there were multiple. This can be important if the protocols for a service evolve over time.

...

<service><routes><route path="/weather/**"></routes></service>

• This tells the gateway that all requests starting starting with /weather/ are handled by this service.
• Due to a limitation this will not include requests to /weather (i.e. no trailing /)
• The ** means zero or more paths similar to Ant.
• The scheme, host, port, gateway and topology components are not included (e.g. https://localhost:8443/gateway/sandbox)
• Routes can, but typically don’t, take query parameters into account.
• In this simple form there is no direct relationship between the route path and the rewrite rules!

...

<rules><rule pattern="*://*:*/**/weather/{path=**}?{**}"/></rules>

• Defines the URL pattern for which this rule will apply.
• The * matches exactly one segment of the URL.
• The ** matches zero or more segments of the URL.
• The {path=**} matches zero or more path segments and provides access them as a parameter named 'path’.
• The {**} matches zero or more query parameters and provides access to them by name.
• The values from matched {…} segments are “consumed” by the rewrite template below.
  
  

<rules><rule><rewrite template="{$serviceUrl[WEATHER]}/{path=**}?{**}"/></rules>

• Defines how the URL matched by the rule will be rewritten.
• The $serviceUrl[WEATHER]} looks up the <service><url> for the <service><role>WEATHER. This is a implemented as rewrite function and is another custom extension point.
• The {path=**} extracts zero or more values for the 'path’ parameter from the matched URL.
• The {**} extracts any “unused” parameters and uses them as query parameters.

...

Rewrite rules can be applied to inbound (requests going to the Gateway - from browser, curl etc.) or outbound (response going from the Gateway towards browser) requests/responses. The direction is indicated by the "dir" attribute

<rule dir="IN">

The possible values are IN and OUT for inbound and outbound requests.

...