Gateway Service in Service-Oriented Architecture

I开发者_运维百科'm enamoured with the idea of implementing my own single-entry-point "gateway" that does two things.

First, it records how many requests have been handled by SOA servers and cycles the next request to the most available server. Full control over load balancing logic is attractive.

Second, this "gateway" would be the single liaison to all my services, including security. If the client sends up a username-password combo, it passes them to the security service which grants a token on successful authentication. If the client sends up a token, the gateway runs this token by the security service and, if it's kosher, passes the request to one of the business services. Hiding or encapsulating all services besides the gateway seems desirable.

My questions are: Is there any reason why this would not be "the right way to do things"? Am I reinventing the wheel when there's already a framework that does what I've described above? My stack is .NET and WCF.

---

Good question, but I have to agree with sweetfa's comment, in 99% of cases an off-the-shelf load balancer will be the best option. A more exhaustive list of options:

1. hardware load balancer/gateway (e.g. IBM XML Gateway) - very scalable and expensive
2. a service bus software (e.g. Oracle Service Bus) will do the security and load balancing as well - very configurable and expensive. Less scalable than hardware solution
3. an open source load balancer software (e.g. Apache HTTPD Proxy module) will have large number of users who will help you setting it up via forums. Many of the solutions are pretty scalable and robust, but will have a more complex way of configuration than options 1 and 2
4. load balancing based on service registry (UDDI v3), when the service consumer looks up the provider URI at every invocation. The registry will load balance the requests by returning different URIs. This solution won't act as a security gateway and the consumers may ignore it alltogether
5. build your own, if you need some advanced adaptive load balancing algorithm or if you want a non-standard security layer. Let's forget about non-standard security, it is rarely a good idea, but adaptive load balancing can be desirable. Options 1-3 will do round-robin or weighted round robin or adaptive round robin based on response times and they will detect unresponsive instances. Options 1 and 3 provides another difficult to implement feature, the HTTP session stickyness as well, but it is not necessary for SOAP or REST services