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?