In terms of performance, we should also look at the how the 'gateway' is integrated into the environment.
There will be cases where the services being represented need to be invoked remotely, and therefore we can't get away from the fact that the requests/responses are going to be marshalled again in this extra step.
However we should ensure that where appropriate the 'gateway' can directly invoke service implementations (i.e. with remoting) in a co-located environment - so in this configuration the gateway is essentially replacing the transport layer for the service. This should be possible with switchyard.
Another configuration we may want to support is providing the gateway functionality as an embedded capability within interceptors/handlers - so in this case the 'gateway' may not be dealing with routing, but may apply authentication and other policies (e.g. throttling, service suspension, etc).
Good points - we need integration points on both ends of the Gateway (manifested endpoints and proxies to backend services) so that those layers can be customized. I'm definitely envisioning a connector layer between the Gateway's Policy Chain and the backend service. I hadn't thought as much about the options for endpoint manifestation. In situations where the endpoints are manifested by some other technology, then the Policy Chain simply needs to be injected into the appropriate place(s) in that technology. This is excellent to consider when designing/implementing the policy layer.
Another aspect of performance to consider is how metrics are recorded. Data collection should be configurable, but when it is enabled we need to be mindful of its impact on performance. I suspect we will want to do any recording of metrics asynchronously. One question is how transactional that recording needs to be - it may be more performant to simply asyncronously log the data, but with the understanding that the occasional entry will be lost under extreme situations (e.g. server crash). Perhaps both must be supported.