1. Service Boundaries are Explicit: Services are expressed at their boundary and there is only ONE way to access the information and/or functionality held within a service - through capabilities exposed at the Service Boundary. Also, assume that calling methods on a Service may take time and may be unreliable.
  2. Services are Autonomous: A service should not have hard-dependencies on other services. You should design your Services to be isolated, independent and interchangeable otherwise you'll end up with a closely coupled system that is fragile and overly complex. Services should maintain all the information needed to operate in isolation so that should one or more supporting services become unavailable, your service will not fail.
  3. Services expose Schema and Contract, not Class and Type: Services should expose their interfaces and shared information interchange structures through well understood schema, rather than a particular language or platform's representation of class or type. By adopting standards based schema can we hope to build truly interoperable systems.
  4. Services negotiate using Policy: This is quite possibly the most valuable, most differentiating tenet. Services must comply with one another's policy requirements in order to interoperate. If you offer a secure, reliable, transacted service, a caller must also support the necessary protocols etc. This protocol negotiation should be performed dynamically which will help ensure that systems do not take hard-dependencies upon one another, and will allow Service designers to largely abstract away the actual “hook-up“ mechanisms between systems focussing instead on the functional semantics of their service.