Need some critique on .NET/WCF SOA architecture plan

Question

I am working on a refactoring of some services and would appreciate some critique on my general approach. I am working with three back-end data systems and need to expose an authenticated front-end API over http binding, JSON, and REST for internal apps as well as 3rd party integration. I've got a rough idea below that's a hybrid of what I have and where I intend to wind up.

I intend to build guidance extensions to support this architecture so that devs can build this out quickly.

Here's the current idea for our structure:

1. Front-end WCF routing service (spread across multiple IIS servers via hardware load balancer)
   • Load balancing of services behind routing is handled within routing service, probably round-robin
   • One of the services will be a token
   • Multiple bindings per-service exposed to address JSON, REST, and whatever else comes up later
   • All in/out is handled via POCO DTOs
   • Use unity to scan for what services are available and expose them
2. The front-end services behind the routing service do nothing more than expose the API and do conversion of DTO<->Entity
   • Unity inject service implementation to allow mocking
   • automapper for DTO/Entity conversion
   • Invoke WF services where response required immediately
   • Queue to ESB for async WF -- ESB will invoke WF later
3. Business logic WF layer
   • Expose same api as front-end services
   • Implement business logic
   • Wrap transaction context where needed
   • Call out to composite/atomic services
4. Composite/Atomic Services
   • Exposed as WCF
   • One service per back-end system
   • Standard atomic CRUD operations plus composite operations
   • Supports transaction context

The questions I have are:

• Are the separation of concerns outlined above beneficial? Current thought is each layer below is its own project, except the backend stuff, where each system gets one project. The project has a servicehost and all the services are under a services folder. Interfaces live in a separate project at each layer. DTO and Entities are in two separate projects under a shared folder.
• I am currently planning to build dedicated services for shared functionality such as logging and overload things like tracelistener to call those services. Is this a valid approach?
• Any other suggestions/comments?

Answer 1

It sounds quite a bit complicated, conversion of DTOs to Entities (entity framework objects, I trust) which also sounds like quite a bottleneck and 4 distinct layers...

I mean you have n services directly exposed to the client via a load balancer, but these then call a service that performs DTO conversion, that then calls a WF (windows workflow?) service - is this latter duplicated across each server you're load balancing, or is it a single service that is called? This then calls out to the back-end wrapper services.

Now, it's good you have the back-end wrappers to encapsulate the 3 data services, and good you have the JSON/REST client API. I think the problem comes in the middle - why not combine these 2 layers together, ignore the EF conversion and stick to directly manipulating the DTOs. It'll be faster (especially as you're probably going to have to convert back to DTOs to send to the 3 data services anyway), and easier to understand. Sure, you don;t get to use the 'cool EF tech', but tech for tech's sake is never a good idea.

Personally, I'd even try to merge the WCF wrappers with the middle tier too, unless there's an absolute need to make all 3 services look alike, you might as well call them using their native systems, perhaps using a local, in-proc library to wrap them.

Remember, ultimately, keeping it simple will pay dividends in the future. Your current system will be difficult to refactor with new back-end systems as a small amount of dev will have to touch a lot of different layers and technologies.