Unit IV: Principles of Service-Orientation: Service-orientation and the enterprise – Anatomy

of a service-oriented architecture –Common principles of Service-orientation- Service-

Orientation and object-orientation.

Principles of Service-Orientation
Service-orientation and the enterprise
The collective logic that defines and drives an enterprise is an ever-evolving entity
constantly changing in response to external and internal influences. From an IT
perspective, this enterprise logic can be divided into two important halves: business logic
and application logic (Figure 8.1).

Figure 8.1. The business and application logic domains.

Each exists in a world of its own, and each represents a necessary part of contemporary
organization structure. Business logic is a documented implementation of the business
requirements that originate from an enterprise's business areas. Business logic is
generally structured into processes that express these requirements, along with any
associated constraints, dependencies, and outside influences.

Application logic is an automated implementation of business logic organized into

various technology solutions. Application logic expresses business process workflows
through purchased or custom-developed systems within the confines of an
organization's IT infrastructure, security constraints, technical capabilities, and vendor
dependencies.

Service-orientation applies to enterprise logic. It introduces new concepts that augment

the manner in which this logic is represented, viewed, modeled, and shared. While the
principles behind service-orientation exist in a vacuous realm of abstraction and theory,
they are a necessary counterpart to the real world environments that require their
guidance and structure.
The concepts introduced by service-orientation are realized through the introduction of
services. Let's have a look at where services are located within the overall structure of
an automated organization. As Figure 8.2 illustrates, services establish a high form of
abstraction wedged between traditional business and application layers. When
positioned here, services can encapsulate physical application logic as well as business
process logic.

Figure 8.2. The service interface layer positioned between enterprise layers that promote
application and business logic.

Services modularize the enterprise, forming standalone units of logic that exist within a
common connectivity layer. Services can be layered so that parent services can
encapsulate child services. This allows for the service layer to consist of multiple layers
of abstraction (as explained later in Chapter 9).

In Figure 8.2 we display a fragmented application layer, where individual applications

are confined to the boundaries that represent their respective proprietary platform
environments. Though we show services as existing in a single, continuous layer, this
only illustrates the open connectivity that exists among service interfaces. Freed from
proprietary ties, services can communicate via open protocols.

On a physical level, services are developed and deployed in proprietary environments,

wherein they are individually responsible for the encapsulation of specific application
logic. Figure 8.3 shows how individual services, represented as service interfaces within
the service interface layer, represent application logic originating from different
platforms.
Figure 8.3. The service interface layer abstracts connectivity from service deployment
environments.

Anatomy of a service-oriented architecture

To best understand what constitutes a true SOA, we need to abstract the key
components of the Web services framework and study their relationships more closely.
To accomplish this, we begin by revisiting these familiar components and altering our
perspective of them. First, we re-label them to reflect terminology more associated with
service-orientation. Then we position them into a logical view wherein we subsequently
re-examine our components within the context of SOA.

8.2.1. Logical components of the Web services framework

The communications framework established by Web services brings us the foundation

technology for what we've classified as contemporary SOA. Because we covered this
framework in Chapter 5, we will use it as a reference point for our discussion of service-
orientation.

Let's first recap some Web services fundamentals within a logical modeling context. As
shown in Figure 8.4, each Web service contains one or more operations. Note that this
diagram introduces a new symbol to represent operations separately from the service.
Figure 8.4. A Web service sporting two operations.

Each operation governs the processing of a specific function the Web service is capable
of performing. The processing consists of sending and receiving SOAP messages, as
shown in Figure 8.5.

Figure 8.5. An operation processing outgoing and incoming SOAP messages.

By composing these parts, Web services form an activity through which they can
collectively automate a task (Figure 8.6).

Figure 8.6. A basic communications scenario between Web services.

8.2.2. Logical components of automation logic

The Web services framework provides us not only with a technology base for enabling
connectivity, it also establishes a modularized perspective of how automation logic, as a
whole, can be comprised of independent units. To illustrate the inherent modularity of
Web services, let's abstract the following fundamental parts of the framework:

o SOAP messages
o Web service operations
o Web services
o activities

The latter three items represent units of logic that perform work and communicate using
SOAP messages. To better illustrate this in a service-oriented perspective, let's replace
these terms with new ones, as follows:

o messages
o operations
o services
o processes (and process instances)

You'll notice that these are quite similar to the terms we used before. The one exception
is the use of "process" instead of "activity." In later chapters we actually use the word
"activity" in different contexts when modeling service-oriented business processes.

For now, the one discrepancy to be aware of is that while a Web service activity is
typically used to represent the temporary interaction of a group of Web services, a
process is a static definition of interaction logic. An activity is best compared to an
instance of a process wherein a group of services follow a particular path through the
process logic to complete a task.

Regardless, for the purposes of our discussion of service-orientation, we'll continue with
our look at how automation logic is comprised of the four identified parts. We can further
qualify these parts by relating each to different sized units of logic, as follows:

o messages = units of communication

o operations = units of work
o services = units of processing logic (collections of units of work)
o processes = units of automation logic (coordinated aggregation of units of work)

Figure 8.7 provides us with a primitive view of how operations and services represent
units of logic that can be assembled to comprise a unit of automation logic.

Figure 8.7. A primitive view of how SOA modularizes automation logic into units.
Next, in Figure 8.8, we establish that messages are a suitable means by which all units
of processing logic (services) communicate. This illustrates that regardless of the scope
of logic a service represents, no actual processing of that logic can be performed without
issuing units of communication (in this case, messages).

Figure 8.8. A primitive view of how units of communication enable interaction between
units of logic.

The purpose of these views is simply to express that processes, services, and
operations, on the most fundamental level, provide a flexible means of partitioning and
modularizing logic. Regardless of the technology platform used, this remains the most
basic concept that underlies service-orientation. In being able to derive this view from
the Web services framework, we also have demonstrated the suitability of the Web
services platform as a means of implementation for SOA.

8.2.3. Components of an SOA

We'll continue to work with our components of automation logic, but we now broaden our
discussion to how the characteristics and behaviors of these components are formed
within service-oriented architecture.

Each of the previously defined components establishes a level of enterprise logic

abstraction, as follows:

o A message represents the data required to complete some or all parts of a unit of
work.
 o An operation represents the logic required to process messages in order to
complete a unit of work (Figure 8.9).

Figure 8.9. The scope of an operation within a process.

o A service represents a logically grouped set of operations capable of performing

related units of work.
o A process contains the business rules that determine which service operations
are used to complete a unit of automation. In other words, a process represents a
large piece of work that requires the completion of smaller units of work (Figure
8.10).

Figure 8.10. Operations belonging to different services representing various parts

of process logic.

8.2.4. How components in an SOA inter-relate

Having established the core characteristics of our SOA components, let's now look at
how these components are required to relate to each other:

o An operation sends and receives messages to perform work.

o An operation is therefore mostly defined by the messages it processes.
o A service groups a collection of related operations.
o A service is therefore mostly defined by the operations that comprise it.
o A process instance can compose services.
o A process instance is not necessarily defined by its services because it may only
require a subset of the functionality offered by the services.
o A process instance invokes a unique series of operations to complete its
automation.
 o Every process instance is therefore partially defined by the service operations it
uses.

Figures 8.11 and 8.12 further illustrate these relationships.

Figure 8.11. How the components of a service-oriented architecture relate.

Figure 8.12. How the components of a service-oriented architecture define each other.

A service-oriented architecture is an environment standardized according to the

principles of service-orientation in which a process that uses services (a service-oriented
process) can execute. Next, we'll take a closer look at what exactly the principles of
service-orientation consist of.
Common principles of service-orientation

Service-orientation is said to have its roots in a software engineering theory known as

"separation of concerns." This theory is based on the notion that it is beneficial to break
down a large problem into a series of individual concerns. This allows the logic required
to solve the problem to be decomposed into a collection of smaller, related pieces. Each
piece of logic addresses a specific concern.

This theory has been implemented in different ways with different development
platforms. Object-oriented programming and component-based programming
approaches, for example, achieve a separation of concerns through the use of objects,
classes, and components.

Service-orientation can be viewed as a distinct manner in which to realize a separation

of concerns. The principles of service-orientation provide a means of supporting this
theory while achieving a foundation paradigm upon which many contemporary SOA
characteristics can be built. In fact, if you study these characteristics again, you will
notice that several are (directly or indirectly) linked to the separation of concerns theory.

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.

o Services are reusable Regardless of whether immediate reuse opportunities

exist, services are designed to support potential reuse.
o 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.
o Services are loosely coupled Services must be designed to interact without the
need for tight, cross-service dependencies.
o 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.
o 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.
o 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.
o 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.
 o 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. As
explained in the How service-orientation principles inter-relate section later in this
chapter, these four principles directly support the realization of other principles (as well
as each other).

There are other qualities commonly associated with services and service-orientation.
Examples include self-descriptive and coarse-grained interface design characteristics.
We classify these more as service design guidelines, and they are therefore discussed
as part of the design guidelines provided in Chapter 15.

Note

You may have noticed that the reusability and autonomy principles also were mentioned
as part of the contemporary SOA characteristics described in Chapter 3. This overlap is
intentional, as we simply are identifying qualities commonly associated with SOA as a
whole as well as services designed for use in SOA. We further clarify the relationship
between contemporary SOA characteristics and service-orientation principles in Chapter
9.

To fully understand how service-orientation principles shape service-oriented

architecture, we need to explore the implications their application will have on all of the
primary parts that comprise SOA. Let's take a closer look at each of the principles.

8.3.1. Services are reusable

Service-orientation encourages reuse in all services, regardless if immediate

requirements for reuse exist. By applying design standards that make each service
potentially reusable, the chances of being able to accommodate future requirements
with less development effort are increased. Inherently reusable services also reduce the
need for creating wrapper services that expose a generic interface over top of less
reusable services.

This principle facilitates all forms of reuse, including inter-application interoperability,

composition, and the creation of cross-cutting or utility services. 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.

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.

8.3.2. Services share a formal contract

Service contracts provide a formal definition of:

o the service endpoint

o each service operation
o every input and output message supported by each operation
o rules and characteristics of the service and its operations

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.

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.

8.3.3. Services are loosely coupled

No one can predict how an IT environment will evolve. How automation solutions grow,
integrate, or are replaced over time can never be accurately planned out because the
requirements that drive these changes are almost always external to the IT environment.
Being able to ultimately respond to unforeseen changes in an efficient manner is a key
goal of applying service-orientation. 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.
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.

8.3.4. 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.

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).

Figure 8.17. Service operations abstract the underlying details of the functionality they
expose.
Operation granularity is therefore a primary design consideration that is directly related
to the range and nature of functionality being exposed by the service. Again, it is the
individual operations that collectively abstract the underlying logic. Services simply act
as containers for these operations.

Service interface-level abstraction is one of the inherent qualities provided by Web

services. The loosely coupled communications structure requires that the only piece of
knowledge services need to interact is each others' service descriptions.

8.3.5. Services are composable

A service can represent any range of logic from any types of sources, including other
services. The main reason to implement this principle is to ensure that services are
designed so that they can participate as effective members of other service
compositions if ever required. This requirement is irrespective of whether the service
itself composes others to accomplish its work (Figure 8.19).

Figure 8.19. The UpdateEverything operation encapsulating a service composition.

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.

In Plain English
Given that the services provided by the Business License Office are distinct and reusable, it can be ask
other government offices to participate in the completion of other services. For example, the Business R
Office manages all administrative paperwork for businesses that need to be moved when their location i
for demolition.

As part of its many tasks, this office takes care of revising the business license information for the affect
does so by enlisting the Business License Office and requesting that they issue a new business license
organization.

By reusing the services offered by the Business License Office, the Business Relocation Office has effe
composed services, much like a controller service reuses and composes other service providers.

8.3.6. Services are autonomous

Autonomy requires that the range of logic exposed by a service exist within an explicit
boundary. This allows the service to execute self-governance of all its processing. It also
eliminates dependencies on other services, which frees a service from ties that could
inhibit its deployment and evolution (Figure 8.22). 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.

Figure 8.22. Autonomous services have control over underlying resources.

Deferring the location of business rules is one way to strengthen autonomy and keep
services more generic. Processes generally assume this role by owning the business
rules that determine how the process is structured and, subsequently, how services are
composed to automate the process logic. This is another aspect of orchestration
explored in the Orchestration service layer section in Chapter 9.

Note that 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.

o 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.
 o 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.

8.3.7. Services are stateless

Services should minimize the amount of state information they manage and the duration
for which they hold it. State information is data-specific to a current activity. While a
service is processing a message, for example, it is temporarily stateful (Figure 8.24). If a
service is responsible for retaining state for longer periods of time, its ability to remain
available to other requestors will be impeded.

Figure 8.24. Stateless and stateful stages a service passes through while processing a
message.
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. Chapters 6 and 7 explore various WS-* extensions that rely on the
use of SOAP headers to carry different types of state data.

8.3.8. Services are discoverable

Discovery helps avoid the accidental creation of redundant services or services that
implement redundant logic. Because each operation provides a potentially reusable
piece of processing logic, metadata attached to a service needs to sufficiently describe
not only the service's overall purpose, but also the functionality offered by its operations.

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.

Service-orientation and object-orientation

Indeed, service-orientation owes much of its existence to object-
oriented concepts and theory. Table 8.1 provides a look at which
common object-orientation principles are related to the service-
orientation principles we've been discussing.

Table 8.1. An overview of how service-orientation principles relate

to object-orientation principles.
Service-
Orientation Related Object-Orientation Principles
Principle
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.
service contract The requirement for a service contract is very
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.
 Table 8.1. An overview of how service-orientation principles relate
to object-orientation principles.
Service-
Orientation Related Object-Orientation Principles
Principle
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.
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,
where any logic within the class outside of what is
exposed via the interface is not accessible to the
external world.

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.
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.
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
 Table 8.1. An overview of how service-orientation principles relate
to object-orientation principles.
Service-
Orientation Related Object-Orientation Principles
Principle
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.
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.

Although it is possible to create stateful services

and stateless objects, the principle of
statelessness is generally more emphasized with
service-orientation.
service Designing class interfaces to be consistent and
discoverability self-descriptive is another object-orientation best
practice that improves a means of identifying and
distinguishing units of processing logic. These
qualities also support reuse by allowing classes to
be more easily discovered.

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.