Recently, while developing a Web Application with a large development team, we initially encountered problems with keeping the many WCF interfaces consistent between the Client and Server applications. Because of parallel development, both Client and Server applications developed a sort of race condition. Client Application’s were typically built against older generations of the WCF interface. It was difficult to ensure that each locally developed Client Interface matched the current, deployed Service Interface.
Traditionally, once a WCF Service interface is developed, the responsibility for integrating the Service into the Client application belongs to the Client development team. What we found, was the necessary disconnect was creating havoc in critical test environments.
So we have since introduced a policy whereby, Service developers are now themselves responsible for creating and maintaining the necessary Client integration code, as a project/assembly. Hence any Client Application can just include the client project into its solution and hence expect to be up-to-date with the latest generation of Service Interface when built.
Otherwise the problems with consuming a large number of different WCF Services would quickly consume your development team’s patience.
When this approach is combined with a basic IDisposable Service Proxy pattern, using the WCF services becomes pretty trivial for Client Application developers.
0 Responses to “Problems with Consuming many WCF Services in One Application”