The acronym SOA is for Service Oriented Architecture. To define a service is simple terms , a service is a program that can be interacted with via well-defined message exchanges. Services must be designed for both availability and stability.

Agility is often promoted as one of the biggest benefits of SOA. An organization with business processes implemented on a loosely-coupled infrastructure is much more open to change than an organization constrained underlying monolithic applications that require weeks to implement the smallest change.

Loosely-coupled systems result in loosely-coupled business processes, since the business processes are no longer constrained by the limitations of the underlying infrastructure. Services and their associated interfaces must remain stable, enabling them to be re-configured or re-aggregated to meet the ever-changing needs of business. SOAP and XML schemas for message definition. Services designed to perform simple, granular functions with limited knowledge of how messages are passed to or retrieved from it are much more likely to be reused within a larger SOA infrastructure.

Following are a set of principles and best practices for building service-oriented applications which are referred to as the tenets of service-oriented architecture:

"Service boundaries are explicit"

Any service is always confined behind boundaries such as technology and location. The service should not make the nature of these boundaries known to its clients by exposing contracts and data types that betray its technology or location. Adhering to this tenet will make aspects such as location and technology irrelevant. To minimize the potential for coupling, the service has to explicitly expose functionality, and only operations (or data contracts) that are explicitly exposed will be shared with the client. Everything else is encapsulated.

There are several principles to keep in mind regarding this tenet:

Know your boundaries. Services provide a contract to define the public interfaces it provides. All interaction with the service occurs through the public interface. The interface consists of public processes and public data representations. The public process is the entry point into the service while the public data representation represents the messages used by the process.

Services should be easy to consume. When designing a service, developers should make it easy for other developers to consume it. The service‘s interface (contract) should also be designed to enable evolving the service without breaking contracts with existing consumers.

Keep service surface area small. The more public interfaces that a service exposes the more difficult it becomes to consume and maintain it. Provide few well-defined public interfaces to your service. Once these interfaces have been designed they should remain static.

Internal (private) implementation details should not be leaked outside of a service boundary. Leaking implementation details into the service boundary will most likely result in a tighter coupling between the service and the service‘s consumers

 "Services are autonomous"

A service should need nothing from its clients or other services. The service should be operated and versioned independently from the clients. This will enable the service to evolve separately from the client. The service is also secured independently and it protects itself and the messages sent to it regardless of the degree to which the client uses security.

Services are dynamically addressable via URIs, enabling their underlying locations and deployment topologies to change or evolve over time with little impact upon the service itself

Service providers also cannot trust consumers to ?do the right thing?. For example, consumers may attempt to communicate using malformed/malicious messages or attempt to violate other policies necessary for successful service interaction. Service internals must attempt to compensate for such inappropriate usage, regardless of user intent

 "Services share schema and contract, not class"

What the service does decide to expose across its boundary should be technology-neutral. The service must be able to convert its native data types to and from some neutral representation, and does not share indigenous, technology-specific things such as its assembly version number or its type. In addition, the service should not let its client know about local implementation details such as its instance management mode or its concurrency management mode. The service should only expose logical operations. How the service goes about implementing these operations and how it behaves should not be disclosed to the client.

 "Services are compatible based on policy"

The service should publish a policy indicating what it can do and how clients can interact with it. Any access constraints expressed in the policy (such as reliable communication) should be separate from the service implementation details. Not all clients can interact with all services. It is perfectly valid to have an incompatibility that prevents a particular client from consuming the service. The published policy should be the only way that clients decide if they can interact with the service, and there should not be any out-of-band mechanism by which the clients make such a decision. Put differently, the service must be able to express, in a standard representation of policy, what it does and how clients should communicate with it. Being unable to express such a policy indicates a poor design of the service. Not that the service may not actually publish any such policy due to privacy (if it is not a public service). The tenet implies that the service should be able to publish a policy if it needs to.