Components In its basic form, a component is an element of a composite type such as an application or a system. In its implemented form, a component is an element of reusable code that can be assembled with other components to build applications. A component can be isolated and replaced with a different component that provides similar functionality. The terms component and service are often used interchangeably, yet they differ in scope. Services A service is a collection of related operations accessible through a well-defined published interface. Ideally, a service is a self-contained, stateless business function which accepts one or more requests and returns one or more responses through a well-defined, standard interface. Services are typically accessed in a client-server pattern, where the service provider generally runs on a different machine from the service consumer or client. One of the major benefits of SOA is the ability to compose services by combining the functionality of one or more services to realize a new service. It is generally done across environments without regard to the details and differences of those environments. Services can range from simple atomic functions to complex business processes. More specifically: An Atomic service is a simple atomic action or function that does not depend on another service to complete a specific task. A Composite service relies on other services to perform the bulk of the work. The composite service is usually “built” or composed from atomic services or other composite services.   Policies A policy can be defined as a principle or rule designed to influence decisions and actions. In the context of SOA, policies define rules, guidelines and constraints that govern service offerings. There are three categories of policies: Lifecycle: Dictate transitions across lifecycle states. Design: Consistently designed & interoperable services. Operational: Ensures consistent operational behaviors. Policies should be externalized and centralized so they may be applied broadly. Defining, externalizing and centralizing policies will provide: Consistency, Predictability, Discoverability, Trust & Control Three major areas that policies will govern are: Reliability, Security & Transactional Integrity Service Contracts In the context of SOA, a service contract is a promise or set of promises made by a service provider to consumers. A contract is actually a combination of the service interface and the policies that influence this service. A service contract generally includes information such as: Operations. Input(s) and output(s). Pre and Post conditions. Error handling or faults. Policies (e.g. Quality of Service, Service-Level Agreements, security, etc). Service contracts mature and transition in predictable and consistent phases following the service life cycle closely. Service contracts can exist in two forms: A Unilateral Contract is a one-sided agreement whereby the service provider promise to perform some operations. The fulfillment of the promise is contingent on certain conditions – in this case, satisfying the conditions of the contract. A Binding Contract is a negotiated contract between a service provider and a consumer. The negotiation leading to a binding contract may start from an existing unilateral contract evolving it to include a new service configuration required by a specific consumer. A common approach for designing and building services is to design by contract. This approach consists in designing and defining the service contract before actually starting the construction of the service. Early contract definition enables parallel development of consumers and service providers and early application framing and testing. Please note that contract life cycle is beyond the scope of this document.