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:
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
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
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
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?
