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.
- 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.
- The resolver makes a call to the ServiceRepository.svc looking for the right binding and endpoint.
- The ServiceRepository service makes a network call to the SQL Server where the configuration is stored.
- 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.
- 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.