Services are Loosely Coupled
Coupling refers to a connection between two things. Within automation solutions, the extent of coupling is a measure of dependency in relation to the connection between units of automation logic. A tightly coupled relationship indicates a high degree of dependency, whereas a decoupled relationship indicates no dependency (and no connection).

A fundamental principle of service-orientation is that units of logic that are classified as services retain a minimal level of coupling. The underlying logic of a service and its requestor are therefore not tightly coupled nor are they decoupled. They ideally retain a level of coupling that is classified as "loose" by limiting dependencies between a service and its clients on an agreed-upon service contract.

See Figure 3

Services Share a Formal Contract
Units of automation logic that are classified as services must provide a contract in which the terms of engagement are defined. As a whole, service contracts can be composed of legal and technical information. This principle is primarily concerned with service description documents that comprise the technical service contract and provide published details about the service, such as its programmatic interface, communication requirements, constraints, properties, usage policies, and even preferences.

Software programs that request consumption of the service must adhere to the conditions of this contract. By restricting awareness of the service (as well as the scope of allowable communication) to what is documented in the service contract, a loosely coupled relationship is formed. The result is the consistent abstraction of a service's underlying logic.

Services Abstract Underlying Logic
Aside from what is published and described in the service contract, information regarding a service is hidden. This limits dependency (and coupling) to the service contract and essentially treats the service as a black box.

One of the primary benefits of service abstraction is that it allows for the mechanics of the service (development technology, deployment environments, etc.) to change with minimal impact to client programs that have become (loosely) dependent on it. The golden rule, of course, is that the service contract should remain immutable, so as to preserve established service-client relationships.

The Core Trio
In a nutshell, the targeted use of service contracts abstracts underlying service logic, thus limiting the extent of coupling. Applying the principles that implement these characteristics results in a predictable and consistent relationship between a service and its requestor, thereby establishing a fundamental dynamic of primitive service-oriented architecture.

There are, however, additional characteristics that distinguish both service-orientation and SOA. These build upon the foundation laid by the core principles and are what mould services into standardized units of automation logic capable of realizing specific benefits associated with SOA.

See Figure 4

Service Are Composable
Service abstraction imposes no limit on what a service can encapsulate. This includes encapsulation of other services. A service composition represents a set of aggregated services that are united to collectively perform a particular task. The principle of composability applies to individual services, and strongly encourages that services be designed in support of aggregated assembly as composition controllers, members, or both.

By ensuring that services are capable of participating in multiple compositions, an inventory of adaptive services can be accumulated. The introduction of new or augmented business requirements can then, to a larger extent, be addressed by the reorganization (or remodeling) of services into new composition configurations. Essentially, the modeling of these compositions can be viewed as a form of service reuse.

See Figure 5

Services Are Reusable
Regardless of the design approach taken, a well-established benefit to separating concerns is that individual concerns may not be specific to a particular activity or business task. The solution logic decomposed to address these crosscutting concerns can therefore become reusable. The reuse potential in SOA broadens because the scope of SOA itself can be extended beyond solution or even enterprise environments.

Attaining an effective level of reuse often requires that a service be stripped of solution and/or business process logic in order for it to become adequately generic. As a result, service reuse is a principle that is almost always realized through standardized design. Key service characteristics that support and help to foster reuse are autonomy, statelessness, and discoverability - each of which is addressed by a corresponding principle.

See Figure 6

Services Are Autonomous
It is preferred that services exist as independently as possible - both from each other as well as from other parts of the technical environment that may want to share the resources encapsulated by the service. Autonomy represents the governance a service has at the time of execution over the underlying application logic required to carry out the functions exposed by the service contract. The extent to which a service can control its underlying logic dictates the level of its autonomy.

Purely autonomous services have absolute ownership of their resources, which allows them to be better tuned for efficiency, reliability, and availability. However, attaining this level of autonomy can be challenging. For example, integration architectures where services encapsulate legacy system logic frequently require that resources be shared with existing legacy clients. Also, the autonomy of a service that is spearheading a composition will be dependent on the collective autonomy of all services involved.

Either way, services with a high level of autonomy are considered the best candidates for reuse, especially in environments in which usage patterns from multiple clients cannot easily be predicted. Note that although frequently discussed in tandem with reuse, autonomy in no way guarantees statelessness.

See Figure 7

Services Are Stateless
State information is data specific to a current activity or task. Its lifespan is generally associated with this task and therefore the manipulation and retention of state-related data typically must occur at runtime.

State management can consume considerable resources. Maintaining a condition of statelessness therefore benefits a service by increasing its scalability and availability. Furthermore, the processing of state information typically requires automation logic that is specific to the business task being executed. For services to maximize reuse potential, their context and underlying logic must be as generic (task-neutral) as possible. Emphasizing stateless design supports the reallocation of task-specific logic outside of the service or to dedicated, stateful services.

• What Is Service Orientation?