SO-Aware - Life cycle of a service call

13.10.2010 12:17Comments
In my previous post about centralizing WCF configuration with SO-Aware, I was asked about the life-cycle of a hypothetical CRUD application request. So in this post we will go through the different steps in a simple user request to this application. Roughly, the steps for a simple request are depicted in the following diagram. In our example, the box "MyService" represents the WCF Service for our CRUD application. However it can be any type of WCF Service (REST, SOAP or OData) with any type of operations. Here is the description step by step.
  1. First we have a user that fires a request to the CRUD website. This website acts as the client for our WCF service. So, as we discussed in our previous post, we can use the resolver shipped with SO-Aware SDK in order to look for the binding and the endpoint of our WCF service. Notice that even though this requires a webservice call, the resolver will cache the bindings and endpoints in memory, so it might be a good idea to keep your instance of the resolver statically.
  2. The resolver makes a call to the ServiceRepository.svc looking for the right binding and endpoint.
  3. The ServiceRepository service makes a network call to the SQL Server where the configuration is stored.
  4. With the binding and endpoint at hand, we can now create an instance of the service proxy. The proxy will let us invoke a service operation.
  5. If the service was not actively running yet, and the host was not instanciated, then the Service Host Factory provided by the SO-Aware toolkit will fetch the necessary configuration from the Service Repository in order to instanciate the Service Host. This config is only fetched once for as long as the service lives. With the service up and running we can now establish the connection with the client and serve the requests.
The interesting part of this cycle is that the WCF configuration was taken out of a centralized repository. This means that in the config files of the website and the web service, we don’t really need to have the serviceModel section any more. Apart from the configuration, we could also take advantage of SO-Aware and monitor our service and even set up some tests to run periodically to make sure that our services are correctly integrated.

comments powered by Disqus