Common Principles of Service-Orientation

• Services are reusable

– Regardless of whether immediate reuse opportunities
exist, services are designed to support potential reuse.
• Services share a formal contract
– For services to interact, they need not share anything
but a formal contract that describes each service and
defines the terms of information exchange.
• Services are loosely coupled
– Services must be designed to interact without the
need for tight, cross-service dependencies.

As previously mentioned, there is no official set of service-orientation principles.

There are, however, a common set of principles most associated with service-
orientation. These are listed below and described further in this section.

1
 Common Principles of Service-Orientation

• Services abstract underlying logic

– The only part of a service that is visible to the outside
world is what is exposed via the service contract.
– Underlying logic, beyond what is expressed in the
descriptions that comprise the contract, is invisible
and irrelevant to service requestors.
• Services are composable
– Services may compose other services.
– This allows logic to be represented at different levels
of granularity and promotes reusability and the
creation of abstraction layers.

2
Common Principles of Service-Orientation
• Services are autonomous
– The logic governed by a service resides within an explicit
boundary.
– The service has control within this boundary and is not
dependent on other services for it to execute its
governance.
• Services are stateless
– Services should not be required to manage state
information, as that can impede their ability to remain
loosely coupled.
– Services should be designed to maximize statelessness
even if that means deferring state management
elsewhere.

3
Common Principles of Service-Orientation

• Services are discoverable

– Services should allow their descriptions to be
discovered and understood by humans and
service requestors that may be able to make use
of their logic.

• Of these eight, autonomy, loose coupling, abstraction

and the need for a formal contract can be considered
the core principles that form the baseline foundation
for SOA.

4
 Services are Reusable
• Service-orientation encourages reuse in all services,
regardless if immediate requirements for reuse exist.
• Application of design standards is required so that
future requirements can be easily accommodated
• No need to create wrapper services if the services
are reusable
• This principle facilitates all forms of reuse, including
inter-application interoperability, composition and
the creation of utility services.

5
 Services are Reusable

…
As we established earlier in this chapter, a service is simply a collection of related
operations. It is therefore the logic encapsulated by the individual operations that
must be deemed reusable to warrant representation as a reusable service (Figure
8.13).
Figure 8.13. A reusable service exposes reusable operations.

6
 Services are Reusable
• “Messaging indirectly supports service reusability
through the use of SOAP headers.“
– The processing-specific logic embedded in a message
alleviates the need for a service to contain this logic.
– More importantly, it imposes a requirement that
service operations become less activity-specific.

• “The more generic a service's operations are, the

more reusable the service.”

Messaging also indirectly supports service reusability through the use of SOAP
headers. These allow for messages to become increasingly self-reliant by grouping
metadata details with message content into a single package (the SOAP envelope).
Messages can be equipped with processing instructions and business rules that allow
them to dictate to recipient services how they should be processed.
The processing-specific logic embedded in a message alleviates the need for a service
to contain this logic. More importantly, it imposes a requirement that service
operations become less activity-specificin other words, more generic. The more
generic a service's operations are, the more reusable the service.

7
 Services share a Formal Contract
• Service contracts provide a formal definition of:
– The service endpoint
– Each service operation
– Every input and output message supported by
each operation
– Rules and characteristics of the service and its
operations

• Hence it covers all primary components of SOA

8
 Services share a Formal Contract

Service contracts therefore define almost all of the primary parts of an SOA (Figure
8.15). Good service contracts also may provide semantic information that explains
how a service may go about accomplishing a particular task. Either way, this
information establishes the agreement made by a service provider and its service
requestors.
Figure 8.15. Service contracts formally define the service, operation, and message
components of a service-oriented architecture.

9
 Services share a Formal Contract
• “Contract design is extremely important.”

• “Contracts need to be carefully maintained and

versioned after their initial release.”

• WSDL definition, XSD schemas, and policies, can be

viewed collectively as a communications contract
that expresses exactly how a service can be
programmatically accessed.

Because this contract is shared among services, its design is extremely important.
Service requestors that agree to this contract can become dependent on its
definition. Therefore, contracts need to be carefully maintained and versioned after
their initial release.
As explained in Chapter 5, service description documents, such as the WSDL
definition, XSD schemas, and policies, can be viewed collectively as a
communications contract that expresses exactly how a service can be
programmatically accessed.

10
 Services are Loosely Coupled
• “No one can predict how an IT environment will
evolve.”

• Being able to ultimately respond to unforeseen

changes in an efficient manner is a key goal of
applying service-orientation.

• Loose Coupling:
– “Having knowledge of other services still remain
independent”

11
Realizing this form of agility is directly supported by establishing a loosely coupled
relationship between services (Figure 8.16).
Figure 8.16. Services limit dependencies to the service contract, allowing underlying
provider and requestor logic to remain loosely coupled.

12
 Services are Loosely Coupled
• Loose coupling is achieved through the use of service
contracts that allow services to interact within
predefined parameters.

• “It is interesting to note that within a loosely coupled

architecture, service contracts actually tightly couple
operations to services.“
– When a service describes its operations, other
services become dependent on that.

Loose coupling is a condition wherein a service acquires knowledge of another

service while still remaining independent of that service. Loose coupling is achieved
through the use of service contracts that allow services to interact within predefined
parameters.
It is interesting to note that within a loosely coupled architecture, service contracts
actually tightly couple operations to services. When a service is formally described as
being the location of an operation, other services will depend on that operation-to-
service association.

13
 Services Abstract underlying logic
• Also referred to as service interface-level abstraction,
it is this principle that allows services to act as black
boxes, hiding their details from the outside world.

• The scope of logic represented by a service

significantly influences the design of its operations
and its position within a process.

• Services can encapsulate varying amounts of logic

14
Figure 8.17. Service operations abstract the underlying details of the functionality
they expose.
There is no limit to the amount of logic a service can represent. A service may be
designed to perform a simple task, or it may be positioned as a gateway to an entire
automation solution. There is also no restriction as to the source of application logic a
service can draw upon. For example, a single service can, technically, expose
application logic from two different systems (Figure 8.17).

15
 Services Abstract underlying logic
• “Operation granularity is a primary design
consideration”
– It is the individual operations that collectively
abstract the underlying logic.
– Services simply act as containers for these
operations.
• The loosely coupled communications structure
requires that the only piece of knowledge services
need to interact is each others' service descriptions.

16
Because both RailCo and TLS employ Web services to communicate, each
environment successfully implements service interface-level abstraction. On RailCo's
end, this abstraction hides the legacy systems involved with generating electronic
invoice documents and processing incoming purchase orders. On the TLS side,
services hide service compositions wherein processing duties are delegated to
specialized services as part of single activities (Figure 8.18).
Figure 8.18. Neither of RailCo's or TLS's service requestors require any knowledge of
what lies behind the other's service providers.

17
 Services are Composable
• Services should be able to take part in compositions
as and when required

• A common SOA extension that underlines

composability is the concept of orchestration.
– Here, a service-oriented process is controlled by a
parent process service that composes process
participants.

18
Figure 8.19. The UpdateEverything operation encapsulating a service composition.

19
 Services are Composable
• “Composability is simply another form of reuse”
– Therefore operations need to be designed in a
standardized manner
– and with an appropriate level of granularity to
maximize composition opportunities.

A common SOA extension that underlines composability is the concept of

orchestration. Here, a service-oriented process (which essentially can be classified as
a service composition) is controlled by a parent process service that composes
process participants.
The requirement for any service to be composable also places an emphasis on the
design of service operations. Composability is simply another form of reuse, and
therefore operations need to be designed in a standardized manner and with an
appropriate level of granularity to maximize composition opportunities.

20
 Case Study

The TLS Accounts Payable Service already establishes a well-defined composition,

wherein it acts as a controller service that composes the Vendor Profile and Ledger
Services (Figure 8.21). Because they each expose a complete set of generic
operations, all three of these services are capable of participating in other
composition configurations.
Figure 8.21. The TLS Accounts Payable Service composition.

21
 Services are Autonomous
• Autonomy requires that the range of logic exposed by a
service exist within an explicit boundary.

• It also eliminates dependencies on other services, which

frees a service from ties that could inhibit its deployment
and evolution.

• “Service autonomy is a primary consideration when

deciding how application logic should be divided up into
services and which operations should be grouped
together within a service context.”

22
Figure 8.22. Autonomous services have control over underlying resources.

23
 Services are Autonomous
• “Deferring the location of business rules is one way to
strengthen autonomy and keep services more generic.”
– Orchestration helps to achieve this aspect

• “Autonomy does not necessarily grant a service exclusive

ownership of the logic it encapsulates.”
– It only guarantees that at the time of execution, the
service has control over whatever logic it represents.
– We therefore can make a distinction between two
types of autonomy.

24
 Services are Autonomous
1. Service-level Autonomy
– Service boundaries are distinct from each other,
but the service may share underlying resources.

2. Pure Autonomy
– The underlying logic is under complete control
and ownership of the service.
– Used when a new service is being built

Service-level autonomy Service boundaries are distinct from each other, but the
service may share underlying resources. For example, a wrapper service that
encapsulates a legacy environment that also is used independently from the service
has service-level autonomy. It governs the legacy system but also shares resources
with other legacy clients.
Pure autonomy The underlying logic is under complete control and ownership of the
service. This is typically the case when the underlying logic is built from the ground
up in support of the service.

25
 Services are Stateless
• Services should minimize the amount of state
information they manage and the duration for which
they hold it.

• “While a service is processing a message, for

example, it is temporarily stateful.”

• If a service is responsible for retaining state for

longer periods of time, its ability to remain available
to other requestors will be impeded.

26
Figure 8.24. Stateless and stateful stages a service passes through while processing a
message.

27
 Services are Stateless
• “Statelessness is a preferred condition for services and
one that promotes reusability and scalability”.

• For a service to retain as little state as possible, its

individual operations need to be designed with stateless
processing considerations.

• A primary quality of SOA that supports statelessness is

the use of document-style messages.
– The more intelligence added to a message, the more
independent and self-sufficient it remains.

28
 Services are Discoverable
• Discovery helps avoid the accidental creation of
redundant services or services that implement
redundant logic.

Note that this service-orientation principle is related to but distinct from the
contemporary SOA characteristic of discoverability. On an SOA level, discoverability
refers to the architecture's ability to provide a discovery mechanism, such as a service
registry or directory. This effectively becomes part of the IT infrastructure and can
support numerous implementations of SOA. On a service level, the principle of
discoverability refers to the design of an individual service so that it can be as
discoverable as possible.

29
 So far,
• Different organizations have published their own
versions of service-oriented principles. As a result,
many variations exist.
• The most common principles relate to loose
coupling, autonomy, discoverability, composability,
reuse, service contracts, abstraction, and
statelessness.

30
 ?
• What's the difference between reusability and
composability?
• What's the difference between autonomy and
statelessness?
• What's the difference between loose coupling and
the use of a service contract?

When reading through the previous descriptions, a number of questions might come
to mind, such as:
What's the difference between reusability and composability? (Aren't you reusing a
service when you compose it?)
What's the difference between autonomy and statelessness? (Aren't both a
representation of service independence?)
What's the difference between loose coupling and the use of a service contract?
(Doesn't a service contract automatically implement loose coupling?)
To answer these and other questions, this section revisits our service-orientation
principles to explore how each relates to, supports, or is affected by others. To
accomplish this, we abbreviate the original names we assigned each principle, as
follows:

31
 Service-Orientation Principles

• Services are reusable = service reusability

• Services share a formal contract = service contract
• Services are loosely coupled = service loose coupling
• Services abstract underlying logic = service abstraction
• Services are composable = service composability
• Services are autonomous = service autonomy
• Services are stateless = service statelessness
• Services are discoverable = service discoverability

We intentionally prefix each principle with the word "service" to emphasize that the
principle applies to the design of a service only, as opposed to our SOA
characteristics, which apply to the design of SOA as a whole.
Note
Each relationship is essentially described twice within these sections. This
repetitiveness is intentional, as this part of the chapter is provided more for reference
purposes.

32
Service reusability and its relationship with other service-orientation principles.

33
The diagram in Figure 8.27 illustrates how the principle of service contract usage
relates to others.
Figure 8.27. The service contract and its relationship with other service-orientation
principles

34
Figure 8.28 demonstrates these relationships.
Figure 8.28. Service loose coupling and its relationship with other service-orientation
principles.

35
These relationships are shown in Figure 8.29.
Figure 8.29. Service abstraction and its relationship with other service-orientation
principles.

36
Figure 8.30 further illustrates these relationships.
Figure 8.30. Service composability and its relationship with other service-orientation
principles.

37
The diagram in Figure 8.31 shows how service autonomy relates to these other
principles.
Figure 8.31. Service autonomy and its relationship with other service-orientation
principles.

38
Figure 8.32 illustrates how service statelessness relates to the other service-
orientation principles.
Figure 8.32. Service statelessness and its relationship with other service-orientation
principles.

39
The diagram in Figure 8.33 shows how service discoverability fits in with the other
service-orientation principles.
Figure 8.33. Service discoverability and its relationship with other service-orientation
principles.

40
 So far,
• Service-orientation principles are not realized in
isolation; principles relate to and support other
principles in different ways.
• Principles, such as service reusability and service
composability, benefit from the support of other
implemented principles.
• Principles, such as service loose coupling, service
contract, and service autonomy, provide significant
support for the realization of other principles.

41
 Service-orientation and Object-orientation

SO Principle Related Object-Orientation Principles

service Much of object-orientation is geared toward the
reusability creation of reusable classes.
The object-orientation principle of modularity
standardized decomposition as a means of
application design.
Related principles, such as abstraction and
encapsulation, further support reuse by requiring a
distinct separation of interface and implementation
logic.
Service reusability is therefore a continuation of
this goal.

Those of you familiar with object-oriented analysis and design probably will have
recognized a similarity between a number of the service-orientation principles
discussed and the more established principles of object-orientation.
Indeed, service-orientation owes much of its existence to object-oriented concepts
and theory.

42
 Service-orientation and Object-orientation

SO Principle Related Object-Orientation Principles

service The requirement for a service contract is very
contract comparable to the use of interfaces when building
object-oriented applications.
Much like WSDL definitions, interfaces provide a
means of abstracting the description of a class.
And, much like the "WSDL first" approach
encouraged within SOA, the "interface first"
approach also is considered an object-orientation
best practice.

43
 Service-orientation and Object-orientation

SO Principle Related Object-Orientation Principles

service loose Although the creation of interfaces somewhat
coupling decouples a class from its consumers, coupling in
general is one of the primary qualities of service-
orientation that deviates from object-orientation.

The use of inheritance and other object-orientation

principles encourages a much more tightly coupled
relationship between units of processing logic when
compared to the service-oriented design approach.

44
 Service-orientation and Object-orientation
SO Principle Related Object-Orientation Principles
service The object-orientation principle of abstraction
abstraction requires that a class provide an interface to the
external world and that it be accessible via this
interface.
Encapsulation supports this by establishing the
concept of information hiding.
Service abstraction accomplishes much of the same
as object abstraction and encapsulation. Its purpose
is to hide the underlying details of the service so
that only the service contract is available and of
concern to service requestors.

45
 Service-orientation and Object-orientation
SO Principle Related Object-Orientation Principles
service Object-orientation supports association concepts,
composability such as aggregation and composition.

These, within a loosely coupled context, also are

supported by service-orientation.

For example, the same way a hierarchy of objects

can be composed, a hierarchy of services can be
assembled through service composability.

46
 Service-orientation and Object-orientation
SO Principle Related Object-Orientation Principles
service The quality of autonomy is more emphasized in
autonomy service-oriented design than it has been with
object-oriented approaches.
Achieving a level of independence between units of
processing logic is possible through service-
orientation, by leveraging the loosely coupled
relationship between services.
Cross-object references and inheritance-related
dependencies within object-oriented designs
support a lower degree of object-level autonomy.

47
 Service-orientation and Object-orientation
SO Principle Related Object-Orientation Principles
service Objects consist of a combination of class and data
statelessness and are naturally stateful.

Promoting statelessness within services therefore

tends to deviate from typical object-oriented
design.

The principle of statelessness is generally more

emphasized with service-orientation.

48
 Service-orientation and Object-orientation
SO Principle Related Object-Orientation Principles
service Designing class interfaces to be consistent and
discoverability self-descriptive is another object-orientation
best practice.

Discoverability is another principle more

emphasized by the service-orientation
paradigm.

It is encouraged that service contracts be as

communicative as possible to support
discoverability at design time and runtime.

As it stands today, object-orientation and service-orientation are not necessarily

competitive paradigms. Service-orientation clearly has several roots in object-
orientation, and typical contemporary service-oriented solutions will consist of a
mixture of services (that adhere to service-orientation principles) and object-oriented
components. With a balanced design, each set of principles can be properly
positioned and leveraged to complement and support each other.

49
 So far,
• Several principles of service-orientation are related
to and derived from object-orientation principles.
• Some object-orientation principles, such as
inheritance, do not fit into the service-oriented
world.
• Some service-orientation principles, such as loose
coupling and autonomy, are not directly promoted by
object-orientation.

50