title: Gateway Service in Service-Oriented Architecture
body: <p>I'm enamoured with the idea of implementing my own single-entry-point "gateway" that does two things.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>