SOA with WCF responsibilities and dependencies

Question

I am moving onto a new team that has implemented a solution using SOA with WCF. The services are all very vertical, for example: a CustomerService, an AddressService, an AccountService, etc. To return the fully populated objects the services may call another service over a wcf endpoint.

There are a few very high level vertical areas, but underneath they can reuse a lot of the core service logic.

How valid is the following new architecture:

The webservices are thin layers that handle remote calls; they are strictly for communication. The real functionality would be implemented in something lets call, "business or domain services".

Domain Service responsibilities:

• Reference data access / repository interfaces for working with the infrastructure
• Call multiple repository methods to create fully populated objects
• Process data against the complex business rules
• Call other domain services (not having to call WCF)

This would give us domain services that can be tested outside of specific WCF and SQL Server implementations.

The web services reusing the different business services seems to be the biggest gain and yet the biggest potential pitfall.

• On one hand the logic can be reused for multiple services, eliminating web service calling web service calling web service.
• On the other hand, if someone changes one of the assemblies multiple services need to be updated, potentially breaking multiple applications.

Have people tried this and had success? Are there better approaches?

Answer 1

That can be a valid approach. The pitfall about updating multiple services depends on how closely related the services are. Do you have a use case where if Customer Service is updated and Address Service is not the clients can still work or is it more common that all services are used by the same client and hence should be updated together. Remember the service only changes if the WSDL changes and not implementation. If you manage not to change the DataContracts and OperationContracts of the front end services there is no worries.
One approach you may investigate is using in-proc WCF services for your domain services. Alternately the front end webservices can use domain managers/engines in separate;y layered assemblies which in turn uses repositories. You can have a coarse grain of webservice class implementations and fine grained managers for domain entities that are mocakble and unit testable.

Answer 2

At first blush, it sounds like the design you've walked into might be an SOA antipattern identified in this article: a group of 'chatty services,' a term the authors use to describe a situation in which ...

developers realize a service by implementing a number of Web services where each communicates a tiny piece of data. Another flavor of the same antipattern is when the implementation of a service ends up in a chatty dialog communicating tiny pieces of information rather than composing the data in a comprehensive document-like form.

The authors continue:

Degradation in performance and costly development are the major consequences of this antipattern. Additionally, consumers have to expend extra effort to aggregate these too finely grained services to realize any benefit as well as have the knowledge of how to use these services together.