SOA in Practice

Applying SOA means extracting some practical design rules from the SOA tenets and measuring them in the context of a real system. Applying SOA principles to a service layer means having coarse-grained services that act as a remote façade facing the business logic.

As a result, you have the following practical rules:

·      Services in the service layer do not implement any business logic.

·      Services in the service layer script and consume the business logic whatever that logic might entail, including workflows, domain objects, and application services.

·      Application services—that is, services that implement pieces of the business—might or might not be SOAs themselves.

·      Data exchange happens through DTOs (via data contracts) and not by using classes in the domain model.

·      Services do not distribute and share objects, and service methods do not work on objects. Services are limited to getting and returning a collection of values formalized in a schema.

·      Services in the service layer should aim at a UI-oriented interface.

·      Application services should aim at a business-oriented interface.

·      Any services with an entity-based interface tend to expose plain CRUD operations. These services are referred to as CRUDy and, for what it matters, are not SOAs.

·      Services should be deployed and versioned independently of the system in which they are deployed and consumed.

·      To the extent that it is possible, do not modify service and data contracts. When you absolutely need to do that, apply versioning.

From “Microsoft .NET: Architecting Applications for the Enterprise” by  Dino Esposito and Andrea Saltarello