Chapter 1.

Web Service and SOA fundamentals

Introduction to SOA

SOA is an architecture approach for defining, linking, and integrating reusable business services that have
clear boundaries and are self-contained with their own functionalities. Within this type of architecture, you
can orchestrate the business services in business processes. Adopting the concept of services—a higher-
level abstraction that's independent of application or infrastructure IT platform and of context or other
services—SOA takes IT to another level, one that's more suited for interoperability and heterogeneous
environments.

Because an SOA is built on standards acknowledged and supported by the major IT providers, such as
web services, you can quickly build and interconnect its services. You can interconnect between
enterprises regardless of their supported infrastructure, which opens doors to delegation, sharing, reuse,
and maximizing the benefits of your existing assets.

With an SOA established, you bring your internal IT infrastructure to a higher, more visible, and
manageable level. With reusable services and high-level processes, change is easier than ever and is
more like disassembling and reassembling parts (services) into new, business-aligned processes. This not
only promotes efficiency and reuse, it provides a strong ability to change and align IT with business.

The value of SOA

So why is everyone so excited SOA? What does it provide, and how can it help? Should it be used in all
cases? Let's answer these questions one at a time.

What's the best fit for SOA?

You might be wondering in which business functions and situations SOA fits best and which best shows its
potential? There are some situations and business functions that should conjure SOA immediately,
because SOA can boost competitiveness and productivity, and clearly display its benefits. Such situations
mainly include:

 Centralized business functions used by multiple entities: SOA helps to identify such functions
and package them into reusable, self-contained services that aren't affected by process changes around
them.
 Integration with partners: SOA promotes using standards, which is critical in any integration
because standards create a common baseline for all parties to work on. Also, the agility provided by SOA
enhances the integration experience with the flexibility to plug in, change, or update services almost
seamlessly to your clients with SOA's decoupling capabilities.

 The existence of old technologies that are still working: Some organizations aren't willing to
give up their tried-and-true technologies. Security concerns make some customers, especially in sensitive
industries such as banking, suspicious of new software systems and their unknown vulnerabilities. In these
cases, SOA can help by wrapping legacy technologies in standardized ways, enabling their exposure in a
standards-based environment suited for integration and reuse.

What factors contribute to SOA's most popular capability: business agility

enablement?
 Because change is inevitable, the only guarantee of the continuity of a business is its ability to anticipate
and adapt to changes, also known as business agility. Crucial to the future of any business, SOA makes
business agility possible with the following factors.

Loose coupling

 Enables real-time business capabilities because it removes the hard connections that impede the ability to change
 Changes the way IT costs are distributed, with less expenses in implementation and more investments in reuse

 Increases the feasibility of real-time remote access to original sources of information, thus reducing the delay and
dependencies

 Integration projects are driven by business needs, with the visibility of capabilities provided (that is, business is the
main driver)

 Lets companies extract more data measuring business performance in real time by exposing and sharing
information

 Decreases time to market because connections to customers and partners can be made faster

 Makes it easier for partners to do business with your company

 Promotes and publicizes your services, making it easier for customers to find you and your services

 Makes it easier to find new partners and services by helping you search for the most suitable service for your need

Reuse

 Makes processes more consistent because they depend on the same reused components
 Promotes increased quality through competition between the services providers

 Gives consumers a wide choice of suppliers

 Covers essentially all classes of IT assets: hardware, software, data, and process assets

 Decreases the impact of change because it's done in a central location and reflects on all concerned parties

 Lets you focus on business processes rather than technical implementation

 Helps decrease the cost of integration because the component has already been integrated

 Lets you make system changes without constraining business change

 Promotes flexibility, which gives you more space to innovate

 Lets you publish once but consume many times

Extensibility

 Makes SOA solutions available to all sizes of organizations

 Changes software-deployment activities from a big-bang model into a more dynamic, less-time-consuming model,
which is more appropriate to the business

 Makes it easier to add or change partners

 Accelerates mergers and acquisitions

 Facilitates exposed services, which represent potential new revenue sources

So what will a company lose if it doesn't adopt SOA?

Given that SOA is a plausible solution for a company, the cost of not implementing it can result in three
major setbacks:
 Inability to move to higher-value markets that provide more business growth and exposure. Because a company is
bound to its existing tailored systems, it becomes stuck in its original place in the market and struggles to address the
higher-value markets. However, with SOA, an organization can change business tactics and enable new ones, giving it an
edge.
 Inability to address more technologically advanced competition.

 Competition from lower-cost sources.

Is SOA always a better solution?

SOA provides benefits in almost all cases of business organizations. However, in very special cases, it
might prove to be a liability more than a drive towards better business. These cases include:

 A homogeneous IT environment: If an organization depends on a set of coherent products—belonging to a same

vendor, for example—, has a limited scope of work, and has no need to add or change any of these products, an SOA might
be a liability more than a useful strategy.
 When true real-time performance is critical: To provide loose coupling between different consumers and
producers, an SOA depends on interoperable protocols, which are slow by nature. It can also induce mediation logic and
asynchronous protocols, which aren't suitable for real-time performance.

 When things don't change: If the customer sees no change happening to the business logic, presentation, data
flow, process, or any other aspect of the application, converting old systems to SOA might not return sufficient value to make
the effort worthwhile.

 When tight coupling is not an inconvenience: Loose coupling is of best use when it's used with a component
that's not under your control and, this, you can't control its change. On the other hand, when the component is yours and
under your control, loose coupling can be a burden, especially if the component isn't really reusable.

SOA concepts
Definition of a service in SOA

There are a lot of different definitions of services, but I think these do the best job of explaining what a
service really is.

"A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services."

"...a service is defined as a unit of work to be performed on behalf of some computing entity, such as a human user or
another program."

The concept of loose coupling in SOA

To understand the concept of loose coupling in SOA, you should first examine the concept of loose
coupling in general. The following items demonstrate what loose coupling is and why it's valuable:

 An entity is coupled if changes to the entity by one party in the interaction require corresponding changes by the
other parties (for example, business data models).
 An entity is declared if its behavior is specified in the interface to the service, and service requesters and providers
can only interact if they have matching declared behavior. Declared aspects include security, transactional behavior, and
quality of service (such as response time and delivery).

 An entity is transformed if it's declared by both service requesters and service providers, but the infrastructure
provides some transformation capability to enable interactions between service requesters and providers that declare
mismatched behavior.

 An entity is negotiated if both requester and provider declare a spectrum of behaviors they are able to support, and
the intermediary infrastructure is capable of negotiating an agreed-upon behavior between them for each interaction.

 An entity is decoupled if changes to the aspect by one party in the interaction don't require corresponding changes
by the other parties.
 Loose coupling manifests itself in the SOA paradigm as follows:

 It helps to have an abstraction layer between the service producers and service consumers.
 Loose coupling promotes flexibility in changing the service implementation without impacting the service
consumers.

 In the SOA approach, functionality is organized as a set of modular, reusable shared services. These services have
well-defined interfaces that encapsulate the key rules for accessing the services. They're also built without making any
assumptions of who will use or consume these services. Thus, they are loosely coupled to the consumer of these services.

How does XML contribute in an SOA?

Based on open standards and promoting platform-independent business integration, SOA needs a
common platform to base its infrastructure on. This infrastructure needs to be supported by all involved
parties to form a common base of understanding. XML is at the core of this infrastructure for the following
reasons:

 XML is the foundation for virtually all web services standards, such as XML schema, SOAP, Web Services
Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). These standards leverage the
core concept of XML-based representations, a worldwide supported format that carries out information interchange between
service providers and requesters in an SOA.
 Using XML resolves the challenge of working with different data formats in different applications across multiple
platforms.

 XML has the benefit of ease of representation, being text-based, flexible, and extensible by nature.

Examples of standards built on XML that SOA leverages include:

 SOAP: This simple XML-based protocol lets applications exchange information over transportation protocols like
HTTP. Using XML in SOAP guarantees that the SOAP protocol is:
o Platform independent.

o Internet usable.

o Humanly readable, structured, and text based.

With the benefits above, SOAP is the recommended and most widely used communication protocol for web services.
Knowing that web services are the cornerstone for SOA, it's therefore also the basic communication protocol for SOA
solutions.

 WSDL: WSDL is a document written in XML to describe a web service. It specifies the location of the service and
the operations (or methods) the service exposes to let individuals access those services. A WSDL file describes four main
things:
o Services available by the web service interface, such as listing names of methods and attribute messages

o Data types of messages

o Binding information for the transport protocol, such as HTTP and JMS

o Service address to be used when calling it

 Electronic Business using eXtensible Markup Language (ebXML): ebXML is a standard way to define the
business transactions that can be performed between different businesses. ebXML defines standard methods for business
messages exchange, establishing trading communications and registering business processes between companies

Service registries
 A service registry is a directory of services available in an SOA system. It contains the physical location of
services, versions and validity periods of services, service documentation, and policies. A service registry is
one of the main building blocks of an SOA architecture. Its role is described below:

 The service registry realizes the SOA promise of loose coupling. By holding the service endpoint locations, it
removes the high coupling resulting from hard-wiring the consumer to the provider. It also eases the potential difficulties in
replacing one service implementation with another if needed.
 A service registry is highly scalable; it evolves seamlessly should the system it serves grow.

 It enables systems analysts to survey an enterprise's business services portfolio. They can then determine which
services are available to automate processes to address pressing business needs and which aren't, letting you know what
needs to be implemented and added to the portfolio, providing a catalog of the available services.

 A service registry can step into the role of governing services by enforcing compliance for subscribing services. This
helps ensure the integrity of service governance and policies. You'll learn more about governance and its importance in SOA
later in this tutorial.

 Visibility of the available services and their interfaces allows speedier development, greater application reuse,
improved governance, and better business planning and management. The lack of a service registry leads to redundancy
and inefficiency.

 Service registries help reduce time wasted in locating service information.

 Without a registry to track services and their relationships, an SOA environment not only lacks coherence and
control, it invites chaos.

What's a business process?

Business process is a term you hear used frequently in this environment. Here are two definitions of a
business process:

From "Business processes and workflow in the web services world" (developerWorks, Jan 2003):

"A business process can be defined as a set of interrelated tasks linked to an activity that spans functional boundaries.
Business processes have starting points and ending points, and they are repeatable."

Another definition is: A business process can be seen as a set of activities performed by a business entity
in response to an event. This set of activities is harmonized, described and integrated within the business
process.

Issuing an identification card for a person is an example of a business process. You present your certificate
of birth, your educational and professional papers, and a photograph to initiate the process. Then an
internal file is created, a security investigation is conducted on you, and finally, after all the processing is
done, you get an ID card.

In the SOA paradigm, the business process controls the flow of services. The business process drives the
flow of events, calls and coordinates services, and creates a context for them to intercommunicate.
Business processes represent the business abstraction; decoupled from the implementation of services, a
process cares about the flow of business. This separation of concerns not only allows more focus on
process creation, it makes it easier to edit processes according to need without having to edit the
underlying service implementations.

Elements of a business process

 It might be better to define a business process in terms of its composing elements; this provides some
technical insight into a business process.

 Input: The information needed by the activities of the process to produce a result. In the example of the ID card, the
inputs would be your credentials, birth certificate, and photograph.
 Output: All the data and information generated by the process. The output represents business goals and
measurements needed for the business. In the ID card example, this would be an internal file for you and a physical ID card
as well as measurements on how the process proceeded.

 Events: Notifications of some occurrence of importance. An indication, for example. They can occur before, during,
and after the execution of a process. In the ID example, this might be the input of a new document that wasn't present at first
and that needs to be included.

 Subprocess: Smaller process, or process steps, inside a process. A subprocess is used when it's not possible to
represent the scope of work with only a set of activities. It has the same elements as the process. In the ID example, this
might be the subprocess of investigating your criminal record and getting the results.

 Activity: The lowest level of work in a process. In the ID example, this can be the creation of a new internal file for
you, the person getting the ID card.

 Performance metrics: Attributes that represent the effectiveness of a process to determine if it meets the required
performance. These metrics help determine the performance and compare it to the required figures. They also point out
potential areas of improvement in the process, ultimately, and ideally, realizing the cycle of improvement that the SOA
promises. In the ID example, measurements would calculate which part of the process consumed most of the time or had
the highest processing hit. This helps later on in improving the process.

How does SOA address transaction control?

Because a process spans multiple activities, business transactions occurring within an SOA environment
can be very complex. This is due to the nature of the services in long-running processes within the SOA
context, which are often asynchronous, stateless, distributed, and opaque.

Web services are a perfect representation of services in an SOA environment. Being self-contained as
needed by SOA, they are limited when it comes to the need of a cross-service transaction. As long as a
service is at the root of a transaction and the scope of the transaction is limited to activities that are
performed by the service's underlying solution logic, there's no need for cross-service transaction
functionality, and the transaction can be managed by whichever proprietary technology (component-based,
legacy, or otherwise) it encapsulates. But as the number of services in an environment grows, the need to
span transactions across those services increases.

Some web services specifications were developed to address the problem of transactions. These include:

 WS-Coordination: Enables registered processes to participate in an activity to create a shared context that's
responsible for holding the stateful data and information propagated between them as well as the transaction state. The
framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary
protocols and to operate in a heterogeneous environment. This protocol provides the infrastructure for other protocols, such
as WS-AtomicTransaction or WS-BusinessActivity, which make use of its framework.
 WS-AtomicTransaction: Is used with short-lived distributed activities. It provides three types of protocols that can
be used with the WS-Coordination framework for two phase commit ACID-type transactions (transactions supporting
atomicity, consistency, isolation, and durability) to choose from:

o Completion

o Volatile two-phase commit

o Durable two-phase commit

 WS-BusinessActivity: This protocol is used with long-running transactions with compensation processes. As with
the WS-AtomicTransaction protocol, it uses the WS-Coordination framework to provide two protocols for business activity
coordination:
o BusinessAgreementWithParticipantCompletion

o BusinessAgreementWithCoordinatorCompletion

What's the role of standards in SOA?

In general, SOA projects are highly reliant upon standards, and leverage them because of these critical
benefits:

 Standards ensure interoperability across system and partners.

 Using standards speeds up development and delivery through processes and tools.

 Standards enable better management and visibility of IT assets.

 Standards ensure quality of service (QoS).

 Standards help with flexibility by reducing dependencies on a specific implementation.

Next, explore a few examples of standards leveraged by SOA and see how they help realize its promises.

WS-Security

The WS-Security protocol is based on adding SOAP extensions to the message header to store security
metadata that's intended to provide protection through message integrity, confidentiality, and
authentication. Those extensions provide a general-purpose mechanism to associate security tokens to the
message rather than a fixed security mechanism. The generic platform supports different security
mechanisms. The protocol is designed to be extensible.

BPEL4WS

Business Process Execution Language for Web Services (BPEL4WS) is defined in the OASIS online
community for BPEL:

"This protocol defines a model and a grammar for describing the behavior of a business process based on interactions
between the process and its partners. It also defines how multiple service interactions with partners are coordinated to
achieve a business goal, as well as the state and the logic necessary for this coordination."

As they are clearly needed, BPEL4WS introduces methods to deal with business exceptions and faults, as
well as ways to compensate other committed processes that may need to be reversed in case of errors.
Because BPEL needs to be supported universally, it's based on the universally acknowledged WSDL
protocol, which, itself, is layered on XML.

WS-I

As declared on the WS-I Web site (see Resources for a link):

"The Web Services Interoperability Organization (WS-I) is an open industry organization chartered to establish Best
Practices for web services interoperability, for selected groups of web services standards, across platforms, operating
systems and programming languages."

This group is concerned with the development of web services standards among different implementations,
platforms, and their actual interoperability. Its main goal is to guide and advise organizations on how to
ensure interoperability while interconnecting systems using web services.
 WS-I has four main deliverables:

 Profiles that are versioned specifications describing implementation guidelines and best practices for web services
that are interoperable and work together as a set
 Use cases and usage scenarios to demonstrate the guidelines in the profiles

 Sample applications

 Testing tools for profile conformance

Basic SOA architecture

Now let's take a look at some more complex, technical subjects, such as the role of the enterprise service
bus (ESB), business processes, their choreography, and the role of web services.

What constitutes a basic SOA architecture?

A basic SOA architecture is composed of a service provider, service, and an optional service directory.
Application-to-application messaging is used in the information exchange.

The similarity between this model and that of straight web services is very visible, with WSDL being the
invocation contract stored in a service directory where it can be queried and fetched via UDDI. Web
services are actually a realization of SOA at its most basic level.

In this model, the basic scenario is as follows: First the service provider creates a service and decides to
expose it and publish it. Publishing is done by posting the service information on the service directory. On
the other side, a service requester, in need of a certain service, searches the service directory for one that
meets the necessary criteria. Upon finding one and using the information available on the service directory,
the service requester is able to directly contact the service provider in the correct way to fulfill the business
need.

Figure 1. Basic SOA architecture

Here are some definitions of terms used in this section:

 Service provider: Provider of services whose invocation contract and location are published
 Service consumer: Consumer of services matching his or her business need found in a service directory

 Service directory: Directory for publishing and listing available services for consumers

What's the role played by an ESB in an SOA?

 An ESB plays an important role in an SOA. At the base of its roles, it represents the backbone and
infrastructure capable of connecting service providers and service consumers.

Below are the detailed roles of the ESB:

 Provides an integration infrastructure consistent with the principles of SOA:

o Enforces the use of explicit implementation-independent interfaces to define services with loose coupling

o Uses communication protocols that stress location transparency and interoperability

o Promotes the definition of services that encapsulate reusable business functionalities

 Provides the means to manage the service infrastructure

 Operates in the distributed, heterogeneous environment because it:

o Supports synchronous and asynchronous communication

o Uses standard interfaces and standard protocols

 Centralizes control and distributes processing

 Supports mediation to formulate the request/response as needed between different parties without the need of
change in any

 Applies security and QoS to the SOA project

What's the role of web services in SOA?

Although web services came before SOA, they represent the answer and realization of the SOA question
seeking the need for interoperability between systems and platforms. This helped get SOA up and running
quickly because it already had a supporting technology to satisfy its needs. It's clear now that web services
represent the cornerstone of the SOA and its recommended technology for interoperability.

Web services are the cornerstone of SOA because they:

 Enforce standards and, thus, promote compatibility and portability.

 Are cross-platform and cross-language.

 Are widely supported, making SOA relatively easy to adopt.

 Are message-oriented.

 Provide faster tooling support, which speeds the implementation of SOA.

What is choreography? How does it fit in the SOA big picture?

Business service choreography is concerned with the development and execution of business flow logic,
independent from underlying services and business logic. This means that the process choreography cares
about the sequence of events and how the events are related, but it doesn't care about the events
themselves. This separation of concerns between process and services provides flexibility to easily change
the processes without changing the core services. This follows the loose-coupling aim of SOA.

To describe business processes, an emerging standard, BPEL4WS, was created. BPEL4WS is layered
over web services standards. The compatibility of such standards enables processes to call underlying
services and partner services in an open standards-based infrastructure.
 A process that's defined in the BPEL4WS is composed of:

 The activities, which are the individual business steps within the process. The activities can be basic or formed of
other activities (structured).
 Partner links, which specify external entities that interact with the process, or vice versa, using WSDL interfaces.

 Variables that store messages passed between activities, thus, representing state.

 Correlation sets, used to correlate multiple service requests or response messages with the same business process
instance.

 Fault handlers to deal with exceptional situations that can occur when a business process runs.

 Event handlers, which receive and process messages in parallel to the normal execution process.

 Compensation handlers, which specify the compensation logic to undo an activity or more when an exception
happens.

Human tasks

Business choreography also provides support for human tasks, which are components involving human
intervention either with a service or with another person. An example is managerial approval on travel
requests or handling a customer request by an individual.

The types of human tasks are:

 Participating tasks: These are initiated by the system (process), which requires a human response to continue
execution. The system initiates the task and an individual from the candidate executers claims the task and executes it.
Then she provides the output back to the system, notifying it of its completion. An example for this is a travel reimbursement
process awaiting manager approval.

Figure 2. Participating task members and interactions

 Originating tasks: As their name signifies, these are initiated by a person through a user interface. They target a
system; a person creates an originating task and starts it; and a request is sent to the system to run the services that are
needed. As soon as the system finishes executing, a notification is sent to the initiator. An example of such a task is the
initiation of a travel reimbursement process by an employee.

Figure 3. Originating task members and interactions

 Purely human tasks: These are, like originating human tasks, created and started by a person. And, like
participating human tasks, they target another person who then claims and completes the task. Purely human tasks don't
interact with business processes or other web services. They're not automated tasks, yet they pass through the same cycle
of assignment and notifications.

Figure 4. Purely human task members and interactions

 It's logical that human tasks can take much more time than automated tasks, which raises another
question: Can processes afford the interruption and wait time caused by human tasks? The answer is yes.
And to get into more detail, let's tackle the subject of business process types.

Business process types

Business processes can be either long-running or micro-flow:

 Long running processes are interruptible and can also run in several transactions. They can wait for external
stimuli, like those resulting from the use of human tasks. A rule of thumb is that if a process contains a human task, then the
process must be long running. Long-running processes can also contain both synchronous and asynchronous services.
Long-running processes store each intermediate process state to be forward-recoverable.
 Micro-flows run in a single thread without interruption. They are also called noninterruptible business processes.
Micro-flows run in only one transaction, are short in duration, and consist of synchronous services only.

The SOA life cycle and its different stages

SOA is characterized by a dynamic life cycle. Inherent in it is the possibility of continuous improvement of
the processes, which, associated with the loose coupling enforced with the SOA, allows processes to
improve as easily as disassembling and reassembling the building blocks (services in this case) without
rework. This improves time to market and alignment of business and IT.

A famous diagram of the SOA life cycle includes the four interconnected hexagonal figures representing the
four stages of SOA. As visible in the diagram in Figure 5, the four stages form a closed loop, representing
the continuous cycle of monitoring and improvement.

Figure 5. The four stages of the SOA life cycle

Let's break these down:

Model stage

The model phase includes business analysis and requirements gathering, which are then followed by
modeling and optimizing the business process. The model helps lay a common understanding of the
process, its objectives, and outcomes. It also makes sure that the design meets the business requirement
and provides a baseline to measure the performance later on.
 Assemble stage

During this phase, existing assets—such as enterprise resource planning (ERP), financial systems, IBM
CICS® applications, and so on)—that are needed in the modeled processes are wrapped as services,
while nonexisting needed functionalities are implemented and tested. After all services are available, they
can be orchestrated to implement the business process.

Deploy stage

During the deployment phase, the runtime environment can be configured to meet the required quality-of-
service levels and security requirements. The environment can be scaled and optimized to be capable of
reliably running the mission-critical processes, and at the same time providing flexibility to make updates
dynamically in case of change.

Manage stage

During this phase, several aspects are managed and monitored, such as the services assets, services
availability and response times, and version control over services. An important role in this phase is
monitoring the key performance indicators (KPIs) of the processes. This helps to prevent or isolate and
diagnose emerging problems in real time as well as provide feedback on the business process
performance and bottlenecks to help improve it. This feedback is sent to the model phase, the first step,
helping improve the process.

SOA management

As covered in the first section, an SOA needs a robust active management framework or else it gets out of
hand. SOA management is realized through the governance concept, which controls the different aspects
of SOA. Security is another aspect that has to be enforced in an SOA-enabled environment because of its
open nature. Details of SOA management are discussed in this section.

SOA governance

Without a controlling entity, an SOA is not only challenging to manage, but it invites chaos because of its
open and distributed nature. Because of this, it needs a management and controlling entity: governance.

Definition of governance

SOA governance is a framework for decision and role identification to encourage IT actions that are
synchronized with the enterprise strategy and prevent those that aren't. This framework is managed by a
group or committee responsible for creating policies to enforce governance and role identification,
empowerment, and accountability of individuals who are given the capability of decision making and policy
enforcement. In brief, the committee needs to address three main questions:

 What decisions need to be made to ensure effective management of IT assets?

 Who should be responsible for making these decisions?

 How can such decisions be enforced and monitored?

 As part of the governance realization, service level agreements (SLAs) are identified and monitored for
verification. Performance metrics are also collected to represent the effectiveness of the governance.

What role does governance play in an SOA environment?

The role of governance in SOA is crucial; it needs to be enabled on all phases of the SOA life cycle, as
shown in Figure 6.

Figure 6. Governance location with respect to the SOA life cycle stages

The need of SOA governance is obvious because:

 Governance involves applying the principles of an enterprise strategy to direct and control IT.
 Governance aims to encourage behaviors consistent with the organization's mission, strategy, and values toward
achieving the enterprise's business goals, adding value while balancing risk and return.

 Governance assures keeping services at a defined level in terms of integrity, performance, reliability, and currency.

 Governance makes sure that business application needs are being correctly assessed and prioritized to drive
creation and consumption of services, thus ensuring the best usage in alignment with business goals.

 Governance ensures that IT investments are being used in a profitable manner.

 Governance ensures that an enterprise-wide SOA-enabling architecture is the main guide for design of any service.

 Governance, as a controlling entity, leverages the best practice of IT principles.

 To protect the business assets, governance also enforces security of enterprise data and privacy of information
shared across boundaries.

 Governance, managing the IT of the enterprise, enforces integrity and reliability of data and processes to leverage
reuse and maximize profit.

 Governance ensures a certain level of performance and quality of service on all components in the consumer-
provider chain of services.

 Standards are at the base of SOA, so governance helps to enforce high levels of interoperability, which leverages
the enterprise with all the benefits of open standards.

 Governance uses metrics to audit and monitor the progress of the development of the IT infrastructure and its
conformance with established policies.

Quality of service compliance in SOA governance.

In a framework with SOA governance, QoS policies are defined and enforced on the organization. This is
essential in an open environment where integration and services exchange is not limited to the internal
functions of an enterprise, but to other enterprises of different sizes, different scopes, and different IT sizes
to maintain and guarantee a steady level of the overall processes. For example, if you consider response
 time to be a QoS, if QoS is not enforced on services to respond in a given time, the slowest service can
create a bottleneck and waste the QoS provided by other faster services. The same goes for security: One
noncompliant service may jeopardize the whole system. In some systems, the infrastructure is made to
detect QoS levels and reject noncomplying services.

Why are security systems in SOA environments complex and distributed?

Such complex security systems are needed because:

 Distributed systems require distributed security.

 There's a need to manage user registries and access control across multiple applications, platforms, business
partners, and entities, which can't be managed at a single point.

 You have to consistently enforce security policies across the environment.

 The security system needs to be able to evolve as the enterprise and its applications evolve.

In the SOA life cycle, what's the impact of change in services?

With the decoupling principle applied, changes in services in the SOA environment are handled simply,
because service consumers are decoupled from service contributors by the ESB, which sits in the middle
and can mediate the messages. Changes on the provider side can be consumed by the ESB so that the
consumer remains the same and stays seamless to the change.

On the other hand, I have to point out the importance of unmanaged change in an SOA environment. With
the principle of reuse, each service may be an enterprise-level service, not just a local one within its
department or unit. Any unmanaged change in such a service can lead to unpredictable enterprise-wide
failures and halting processes. This shows the importance of governance in ensuring that a policy is
managing the change. This policy should measure the impact, allow the change, and ensure a system of
notification for the parties impacted (ESB or direct consumers). Changes in distributed systems require
stern rules to manage them.

What's the role of the ESB in SOA governance?

The ESB plays an important role in enforcing governance. Security and QoS policies can be applied to the
ESB to control their levels and allow only conforming requests. In general, an ESB plays the role of a
unifying platform on which required policies are mandated. The nature of an ESB as a central place where
all communication occurs makes it a perfect place to activate such rules. And rest assured that everyone
either complies or is isolated.

Prepare to implement an SOA

The process of introducing SOA in an organization requires special skills, including:

 The ability to measure the readiness of the organization to such adoption.

 Identifying boundaries and entry points.

 Enlightening people with the benefits that SOA can bring to the business and IT.

 Measuring the challenges and drivers to SOA induction on both the business side and the technical side.
 What benefits does SOA provide to business and IT strategy?

SOA's benefits to the business include:

 Increasing the responsiveness of the business to market changes and improving agility in the organization.
 Bypassing organizational boundaries and synergizing with the existing assets.

 Helping reduce development time.

 Exposing inefficiencies in business processes.

 Ensuring the alignment of IT resources to business strategy and goals.

 Decreasing the cost of compliance and security with standards enforcement.

 Making it easier for partners and customers to find you and making it easier for you to find them.

 Granting more consistent processes.

 Providing a different choice of suppliers because of the standards enforcement.

 Enabling asset reuse.

 Reducing the cost of integration.

 Easing upgrades and mergers.

SOA's benefits to the IT strategy include:

 Architecting systems to effectively use standards and services to gain the benefits they promise the business.
 Allowing various communication mechanisms to be used.

 Allowing flexible and reliable security systems to be incorporated to ensure security.

 Providing a service bus where the flow of messages and messages themselves can be managed providing another
dimension to flexibility and adaptability of the system.

 Easing integration with modular, componentized services and a connecting services bus.

 Being built on standards and protocols that are widely supported to enable interoperability, a goal of SOA since its
start.

 Promoting reuse with a services repository and mediation modules.

 Boosting connectivity using the ESB, which takes connectivity to its highest peak. The ESB is responsible for
mediation of protocols, data, and formats to ensure compatibility.

What business issues and drivers can organizations expect when preparing for
SOA adoption?

The business domain cares about the form and impact that this new paradigm will have on the
organization, so there will likely be some business issues that need to be identified and confronted.

Business issues

Business issues can include:

 Management doubting or questioning SOA because it's a new idea that's more IT-driven than business-driven.
 Defining the strategy and level of adoption, taking into account the current situation of the organization and how
ready it is to adopt SOA.

 Mapping process to services.

 Lack of knowledge about SOA and what it can provide.

 The misconception that SOA is an IT architecture method only, which can lead to neglecting the critical role of
governance.

 Underestimating IT business value.

Most of these issues can be resolved, or at least highlighted, by conducting educational sessions to show
the benefits and real value of SOA.

Business drivers

The main business driver is SOA's potential to:

 Drive a business' return on investment (ROI), with reduced implementation costs through adopting standards,
reuse, exposing services, and integrating with partners.
 Decrease time to market by reusing assets and incorporating partner-provided services.

 Increase the visibility of IT assets and their alignment to the business goals.

 Improve flexibility both internally in communication and externally in dealing with partners.

 Provide more efficient processes by reusing IT assets and leveraging standards.

 Promote business agility and the ability to adapt easily and quickly to business and market changes.

 Reduce costs throughout the organization.

What IT issues and drivers can organizations expect when preparing for SOA
adoption?

Don't forget the IT department. Some of the issues and drivers that are important to them are listed next.

IT issues

IT issues can include:

 Changing the existing tailored systems into standards-based services.

 Management, governance, and control of services.

 Security challenges of distributed systems.

 Reliability of new systems versus the existing, dependable systems.

 Optimizing and unifying the existing asset to remove redundancy.

IT drivers

IT drivers might be:

 Adopting standards. The drive for standards is also considered an issue, but despite the effort needed to adopt
standards, the benefit is clear to every IT specialist.
 Ensuring high QoS.

 Reuse of existing IT assets.

 Loose coupling of services.

 Independence from a certain provider or partner.

What factors affect the adoption of SOA in an organization?

 While preparing for SOA adoption, you will have to identify factors that might affect SOA adoption and
measure their impact to identify the organization's readiness. The factors revolve around people and
technology, for example:

 The organization's experience with SOA.

 The level of awareness of SOA and its benefits.

 The existing methodology of identifying services and reusable components.

 Readiness of the existing business to be exposed as services.

 The current ability to access heterogeneous systems.

 The reusability level of legacy systems.

 The existence of a governance model in the organizational structure.

 The availability of shareable service layer.

 The existing architecture's ability to support advanced interactions between applications.

 The infrastructure's ability to support SOA with security, connectivity, and so on.

 The existence of a methodology to measure business processes and their efficiency levels.

Identify barriers to SOA adoption

Organizations need to identify and tackle any barriers blocking the advancement towards SOA. Such
barriers can include:

 Old-fashioned IT practitioners insisting on old-fashioned waterfall development cycles.

 The notion that complex systems are better, and fear of the unknown.

 Overlooking the importance of architects and considering them theorists that cost more than the solution needs. It's
important to note that architects are instrumental in SOA, and their absence will surely result in undesirable results.

 Organizational resistance to adopt an SOA model. SOA requires cooperation from all groups in the organization,
not just the mere implementation of the IT framework.

What are the entry points for SOA in an organization?

To start adopting SOA in an organization, five entry points have been identified:

 People
 Process

 Information

 Connectivity

 Reuse

The organization should choose the entry point that's most ready to adopt SOA and focus on it, while not
ignoring the other entry points.

Figure 7. Entry points to SOA

 Here are more details about the entry points.

People

Empowering people through SOA solutions can help boost efficiency and innovation, and provide a
foundation for greater productivity and collaboration. Because people drive the interaction with the SOA
services that execute business results, focusing on people is critical to the success of SOA
implementations. The people entry strategy to SOA can help:

 Accelerate productivity.
 Reduce costs of access to multiple applications and information sources.

 Reduce time to deployment for new services.

 Increase access to process flexibility and orchestration.

 Enable collaboration inside and outside the enterprise.

Process

By entering SOA from a process entry point—a business-centric starting point for SOA—an organization
can streamline processes across the enterprise, including improving the efficiency, flexibility, and control of
key business processes. This helps align business and IT goals, and reduces the complexity of building
process. Focusing on the processes entry points helps:

 Improve employee productivity.

 Increase collaboration.

 Accelerate time to market.

 Respond quickly to business challenges.

 Implement new processes in less time.

 Maximize ROI.

Information

By entering SOA from an information entry point, an organization can improve the availability and
consistency of information, while removing barriers to information sharing, thus offering information access
to heterogeneous data sources inside and outside the organization's boundaries. It can also help people
better understand the organization's operational, transactional, analytical, and unstructured information,
and make it available in new ways through SOA. This entry point can help:
 Collect and clean date, and make data widely accessible, enabling transparency and business insight.
 Reduce the cost of migration and rationalization of data by decoupling information from applications.

 Increase an organization's agility by providing reusable information services spanning the whole organization that
can be used by applications and processes, and at the same time reduce costs associated with accessing and transforming
data.

Connectivity

This IT-centric entry point to SOA is designed to simplify the IT environment with a more secure, reliable,
and scalable way to connect within and beyond a business, linking people, processes, and information in
the business. Empowering connectivity through SOA helps:

 Ensure seamless flow of information with different protocols inside and outside the organization.
 Execute enterprise-level business processes that span the organization and business partners efficiently.

 Build trusted relationships with partners.

 Scale the business to grow smoothly.

 Deliver a consistent user experience regardless of channel or device.

Reuse

Reuse is another IT-centric entry point to SOA. It focuses on deriving continued value from existing assets
and identifying services to be outsourced instead of implemented. By entering SOA from this entry point,
the organization can reuse, extend, enhance, or create new processes. This enables it to increase
business flexibility and responsiveness through reduced development time and elimination of duplicate
processes. Using this entry point can help:

 Reduce the amount of new code that must be created for business initiatives.
 Improve efficiency.

 Reduce risk by reusing dependable resources.

 Lower maintenance costs by eliminating redundant systems.

 Wrap services performed by legacy applications into standards-based services that can participate in the broader
image while delivering the same dependable output.

________________________________________________________________________________________________-

Introduction to SOA

The SOA Elephant

SOA has become a well-known and somewhat divisive acronym. If one asks two people to define SOA one
is likely to receive two very different, possibly conflicting, answers. Some describe SOA as an IT
infrastructure for business enablement while others look to SOA for increasing the efficiency of IT. In many
ways SOA is a bit like John Godfrey Saxe’s poem about the blind men and the elephant. Six blind men
from Indostan encounter an elephant – each of the men then describes the elephant a bit differently
because they are influenced by their individual experiences:

 The man touching the trunk believes it to be a snake

 The man touching the tusk believes it to be a spear
  The man touching the ear believes it to be a fan

 The man touching the elephant’s side believes it to be a

wall

 The man touching the tail believes it to be a rope

 The man touching the legs believes they are trees.

Figure 1. Saxe's Elephant

The blind men then engage in a series of debates about what they believe are facing them:

“…And so these men of Indostan

Disputed loud and long,

Each in his own opinion

Exceeding stiff and strong,

Though each was partly in the right,

And all were in the wrong!”

In many ways Mr. Saxe’s poem has become a prophecy for SOA. Industry analysts, pundits, bloggers and
reporters engage each other in an ongoing, never-ending debate about what is or isn’t SOA. Like Mr.
Saxe’s blind men, people have correctly identified many of the capabilities of SOA but largely fail to
communicate the concept as a whole. The challenge of defining SOA has become so important that various
vendor consortia and standards organizations have launched initiatives to try and answer the question
“What is SOA?”

A simple definition for SOA

For the purposes of this book, we will define SOA as:

 A loosely-coupled architecture designed to meet the

business needs of the organization.

At first glance this definition seems far too simplistic – where is SOAP, web services, WSDL, WS-* and
other related standards? A SOA does not necessarily require the use of Web Services – Web Services are,
for most organizations, the simplest approach for implementing a loosely coupled architecture. In the past,
loosely coupled architectures have relied upon other technologies like CORBA and DCOM or document-
based approaches like EDI for B2B integration. Many of these technologies are still in widespread use and
are being augmented, replaced or extended with Web Services. Our definition works for us not because the
focus here is not on the technology of SOA but upon meeting the needs of the organization. In simpler
terms, one organization’s SOA may look like nothing more than a bunch of Web Services (or other
technologies) to another. There may be some common infrastructure capabilities such as logging and
authentication, but for the most part a SOA for one organization will be quite different from the SOA used
by another.

Many analysts and industry pundits have confused the concept of Service Oriented Architecture with
Service Oriented Implementations. This has only added to the confusion associated with SOA and its
related concepts. This can lead to disastrous results.

The Winchester Mystery House is an intriguing tourist attraction in the USA near San Jose, CA. The
Winchester Mystery House was the home to the heiress of the Winchester fortune (amassed from the sales
of Winchester rifles). According to the legend, the heiress went to see a fortune teller and learned she was
cursed to be haunted by the spirits of everyone ever killed by a Winchester rifle. The only way to avoid the
curse was to build a mansion – as long as she kept building the spirits would leave her alone. She promptly
hired 147 builders (and 0 architects), all of whom began working on the mansion simultaneously. The
builders worked on the mansion until the heiress passed away, 38 years later. The result of their efforts is a
classic example of implementation without architecture:

 The mansion contains 160 rooms, 40 bedrooms, 6

kitchens, 2 basements and 950 doors
 Of there 950 doors, 65 of them open to blank walls, 13
staircases were built and abandoned and 24 skylights
were installed into various floors.

 No architectural blueprint for the mansion was ever

created.

Figure 2. The Winchester Mystery House

Confusing architecture with implementation generates chaotic and unpredictable results – much like the
Winchester Mystery House. Articles that try to explain SOA and jump into a tutorial for building Web
Services are providing guidance for coding, not architecture. This is one of the many reasons that SOA is
so misunderstood today – the rush to promote loosely coupled architectures focuses on the trees instead of
the forest.

The architectural concepts associated with SOA are not new – many have evolved from ideas originally
introduced by CORBA, DCOM, DCE and others. Unlike these previous initiatives, the key promise of SOA
is to enable agile business processes via open, standards-based interoperability. While these standards
are important we must remember that standards are not architecture and architectures are not
implementations. At the end of the day it is the implementation of a well-designed architecture that will
generate business benefits, not the architecture itself.

SOA is an architectural approach to creating systems built from autonomous services. With SOA,
integration becomes forethought rather than afterthought - the end solution is likely to be composed of
services developed in different programming languages, hosted on disparate platforms with a variety of
security models and business processes. While this concept sounds incredibly complex it is not new –
some may argue that SOA evolved out of the experiences associated with designing and developing
distributed systems based on previously available technologies. Many of the concepts associated with SOA
such as services, discovery and late binding were associated with CORBA and DCOM. Similarly, many
service design principles have much in common with earlier OOA/OOD techniques based upon
encapsulation, abstraction and clearly defined interfaces.

Does the buzz around SOA and services mean that IT wasn’t service-oriented in the past? No - IT
(outsourced or not) exists solely to enable the business. Without IT businesses will have tremendous
difficulty in both execution and competition. However, if IT cannot respond to business needs and
opportunities fast enough then IT is perceived as a constrainer to the business instead of an enabler. (This
also enables people like Nicholas Carr to start throwing bombastic claims around about IT in general but
that’s another story).

SOA promises to help IT respond to market conditions in a much timelier manner. SOA, however, is an
architectural philosophy and is not necessarily an implementable concept. Many analysts and trade
magazines have confused architecture with implementation – this leads one to believe that an
implementation is, in fact, an architecture which can lead to disastrous results.

Organizations have different requirements and expectations for SOA because of vastly different business
needs and objectives. This simple fact is one of the reasons that describing SOA can be such a challenge.
SOA, like any initiative, must provide some level of value to the organization – otherwise there would be no
use in ever considering it. The best way to ensure that SOA investments will provide a return to the
organization is to align SOA with the organization’s business drivers. Despite this obvious fact there is still a
lot of confusion about SOA.

SOA Myths and Facts

There are several myths associated with SOA which are very important to understand before digging deeper into it.
The table below describes some of the top myths surrounding SOA and the facts to help debunk them.

Myth Fact
SOA is a design philosophy independent of any vendor, product, technology or
industry trend. No vendor will ever offer a “complete” SOA “stack” because
SOA is a technology
SOA needs vary from one organization to another. Purchasing your SOA
infrastructure from a single vendor defeats the purpose of investing in SOA.
SOAs may be realized via Web services but Web services are not necessarily
SOAs require Web Services
required to implement SOA
SOA is new and
EDI, CORBA and DCOM were conceptual examples of SO
revolutionary
SOA ensures the alignment
SOA is not a methodology
of IT and business
A SOA Reference
SOAs are like snowflakes – no two are the same. A SOA Reference
Architecture reduces
Architecture may not necessarily provide the best solution for your organization
implementation risk
SOA requires a complete SOA should be incremental and built upon your current investments
technology and business
processes overhaul
We need to build a SOA SOA is a means, not an end

Focus on delivering a solution, not an SOA. SOA is a means to delivering your solution and should not be
your end goal.

The Evolution of SOA

Service Orientation (SO) is the natural evolution of current development models. The, 80s saw object-
oriented models; then came the component-based development model in the 90s; and now we have
service orientation (SO). Service orientation retains the benefits of component-based development (self-
description, encapsulation, dynamic discovery and loading), but there is a shift in paradigm from remotely
invoking methods on objects, to one of passing messages between services. Schemas describe not only
the structure of messages, but also behavioral contracts to define acceptable message exchange patterns
and policies to define service semantics. This promotes interoperability, and thus provides adaptability
benefits, as messages can be sent from one service to another without consideration of how the service
handling those messages has been implemented.

Figure 3. Simple SOAP-based communications between Web Services

Service orientation provides an evolutionary approach to building distributed software that facilitates loosely
coupled integration and resilience to change. With the advent of the WS-* Web Services, architecture has
made service-oriented software development feasible by virtue of mainstream development tools support
and broad industry interoperability. Although most frequently implemented using industry standard Web
services, service orientation is independent of technology and its architectural patterns and can be used to
connect with legacy systems as well.

Unfortunately, the benefits offered by service orientation and SOA have been obscured by the hype and
confusion that increasingly surround the terms. As awareness and excitement around SOA have swelled,
the clear lines that once defined service orientation have been blurred. However SO does offer some
specific benefits when utilized for the right purpose. There are three important observations about SO:

1. It’s evolutionary: The principles of service-oriented

development build on decades of experience in building
real world distributed applications. SO incorporates
concepts such as self-describing applications, explicit
encapsulation, and dynamic loading of functionality at
runtime – principles first introduced in the 1980s and
1990s through object-oriented and component-based
development. What changes with SO is the metaphor
with which developers achieve these benefits. Instead of
 using method invocation on an object reference, service
orientation shifts the conversation to that of message
passing – a proven metaphor for scalable distributed
software integration.
2. It’s not a product or technology: It is a set of architectural
principles expressed independently of any product. Just
as development concepts such as polymorphism and
encapsulation are independent of technology, so is
service orientation. And while Web services have in
recent years facilitated the development of service-
oriented applications, they are not required to do so.

3. It’s incremental: Finally, service orientation can and

should be an incremental process – one that can often
be done in-house. Customers should not be required to
dramatically re-engineer their businesses to attain the
benefits of service orientation. Rather, they should be
able to leverage existing IT assets in doing so. Service-
oriented development can often be achieved using the
skills and technologies customers already have today.

The fundamental building block of service-oriented architecture is a service. A service is a program that can
be interacted with through well-defined message exchanges. Services must be designed for both
availability and stability. Services are built to last while service configurations and aggregations are built for
change. 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 by 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. Services remain stable by relying upon standards-based interfaces and
well-defined messages—for example using 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.

Service Orientation does not necessarily require rewriting functionality from the ground up. Following the
four tenets (see below) enables reuse of existing IT assets by wrapping them into modular services that
can be plugged into any business process that you design. The goals for doing this should be:

 Connect into what is already there - Layer business

process management, collaborative workflows, and
reporting on top of existing IT assets.
 Extract more value from what is already there - Enable
existing applications to be re-used in new ways.

 Extend and evolve what we already have - Create IT

support for new cross-functional business processes that
extend beyond the boundaries of what the existing
applications were designed to do.

One of the key benefits of service orientation is loose coupling. No discussion of Web services seems
complete without some reference to the advantages of looser coupling of endpoints (applications) facilitated
by the use of Web service protocols. The principle is that of using a resource only through its published
service and not by directly addressing the implementation behind it. This way, changes to the
implementation by the service provider should not affect the service consumer. By maintaining a consistent
interface, the service consumer could choose an alternative instance of the same service type (for example
change service provider) without modifying their requesting application, apart from the address of the new
instance. The service consumer and provider do not have to have the same technologies for the
implementation, interface, or integration when Web services are used (though both are bound to use the
same Web service protocols).

Why should I care about SOA?

Service Orientated Architecture is important to several stakeholders:

 To developers and solution architects, service

orientation is a means for creating dynamic,
collaborative applications. By supporting run-time
selection of capability providers, service orientation
allows applications to be sensitive to the content and
context of a specific business process, and to gracefully
incorporate new capability providers over time.
 To the IT manager, service orientation is a means for
effectively integrating the diverse systems typical of
modern enterprise data centers. By providing a model
for aggregating the information and business logic of
multiple systems into a single interface, service
orientation allows diverse and redundant systems to be
addressed through a common, coherent set of
interfaces.

 To the CIO, service orientation is a means for protecting

existing IT investments without inhibiting the deployment
of new capabilities. By encapsulating a business
application behind capability-based interfaces, the
service model allows controlled access to mission-critical
applications, and creates the opportunity for continuous
improvement of the implementation behind that
interface. Service orientation protects investments from
the swirl of change.

 To the business analyst, service orientation is a means

of bringing information technology investments more in
line with business strategy. By mapping employees,
external capability providers and automation systems
into a single model, the analyst can better understand
the cost tradeoffs associated with investments in people,
systems and sourcing.

 To Microsoft, service orientation is a crucial prerequisite

to creating applications that leverage the network to link
the actors and systems that drive business processes.
This application model transcends any single device,
crossing boundaries respectfully, and rejecting the
restrictions of synchronicity. SOA-enabled solutions pull
together a constellation of services and devices to more
 effectively meet your business challenges than the
disconnected applications of the past.

The architectural concepts associated with SOA enable loose coupling. Loose coupling is the fundamental
principle behind SOA, enabling us to summarize up the benefit of SOA in a single word: agility.

As traditional application architectures evolved from the mainframe application through client server to
multi-tier web applications, the applications have remained to a large extent tightly coupled. In other words,
each of the subsystems that comprise the greater application is not only semantically aware of its
surrounding subsystems, but is physically bound to those subsystems at compile time and run time. The
ability to replace key pieces of functionality in reaction to a change in a business model, or of distributing an
application as individual business capabilities, is simply not possible.

With a Service Oriented Architecture the application’s functionality is exposed through a collection of
services. These services are independent and encapsulate both the business logic and its associated data.
The services are interconnected via messages with a schema defining their format; a contract defining their
interchanges and a policy defining how they should be exchanged.

Figure 4. Anatomy of a Web Service

An application’s services are designed to last with the expectation that we cannot control where and who
consumes them. This is one of the key differences between SOA and traditional application architectures.
Traditionally applications are designed to interact with humans, and the application vendor would provide
the user-interface, the underlying business components and data stores. While good engineering
disciplines separated the business components from the user interface, the only consumers of this
business logic were the user interfaces delivered as part of the application. These UI and business
components were traditionally deployed and versioned as a single entity. With service orientation, the
business functionality exposed through the service can be used by any consumer outside of the control of
the application. These consumers can be other services (incorporating the encapsulated business process)
or alternatives to the user interfaces provided by the application itself. Therefore, contracts for these
services, once published, must remain constant as we have no idea who is consuming them, nor when. In
addition to offering services and exploiting its own services, an application itself should have the flexibility to
adapt to new services offered after deployment. The availability and stability of these services therefore
becomes a critical factor.

Understanding Services

The first step in any SOA undertaking is to clearly identify the critical business problems or challenges. The
more precisely these can be defined the easier it will be to determine the scope and direction of each SOA
project. By setting clear vision and direction from the top, it will be easier to obtain buy in on projects that
are cross-functional in nature. Once the business drivers of the organization are defined, the service
analysis process can begin. Service analysis is one of several steps that comprise a Service Lifecycle
(Chapter 2 provides more information about the Service Lifecycle). The Service Lifecycle explains the
necessary steps an organization must go through to define, develop, deploy and operate a service.

Services are commonly used to expose IT investments such as legacy platforms and Line of Business
applications. Services can be assembled (or “composed”) into business processes, and be made available
for consumption by users, systems or other services. The process is an iterative one of creating
(“exposing”) new services, aggregating (“composing”) these services into larger composite applications,
and making the outputs available for consumption by the business user.

Figure 5. An incremental, business-driven approach to SOA

Fundamental to the service model is the separation between the interface and the implementation. The
invoker of a service need only (and should only) understand the interface; the implementation can evolve
over time without disturbing the clients of the service. Several key benefits of service orientation derive from
this abstraction of the capability from how the capability is delivered. This means that, the same interface
can be offered by many implementations, or conversely, that implementations can change without affecting
the aggregate application. At its most abstract, service orientation views everything — from the mainframe
application to the printer to the shipping dock clerk to the overnight delivery company — as a service
provider. The service model is “fractal:” the newly formed process is a service itself, exposing a new,
aggregated capability.

What is a service? In this book we will avoid using the term Web Services simply because all services are
not necessarily Web Services. A service might also be manifested as an OS-specific process like a Unix
daemon or a Windows Service. A service might also be an application that uses a well-defined contract that
may or may not be based upon Web Services. Regardless of how the actual services are developed, they
must be capable of participating within a loosely coupled architecture. There are four distinct principles
(sometimes referred to as “Tenets”) that can help ensure a loosely-coupled architecture. These Tenets of
Service Design are defined below:

The Tenets of Service Design

The acronym SOA prompts an obvious question – what, exactly, is a service? Simply put, a service is a
program that can be interacted with via well-defined message exchanges. Services must be designed for
both availability and stability. Services are built to last while service configurations and aggregations are
built for change. 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. Services remain stable by relying upon standards-based interfaces and
well-defined messages – in other words, 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. As stated earlier,
recalling basic OO design principles regarding encapsulation and interface design will serve us well as we
design and build reusable Web Services. We can extend these OO principles into the world of Web
Services by further understanding the frequently cited “four tenets” of Service Orientation:

Tenet 1: Boundaries are Explicit

Services interact through explicit message-passing over well-defined boundaries. Crossing service
boundaries may be costly, depending upon geographic, trust or execution factors. A boundary represents
the border between a service’s public interface and its internal, private implementation. A service’s
boundary is published via WSDL and may include assertions dictating the expectations of a given service.
Crossing boundaries is assumed to be an expensive task for several reasons, some of which are listed
below:

 The physical location of the targeted service may be an

unknown factor.
 Security and trust models are likely to change with each
boundary crossing.

 Marshalling and casting of data between a service’s

public and private representations may require reliance
upon additional resources – some of which may be
external to the service itself.

 While services are built to last, service configurations are

built to change. This fact implies that a reliable service
may suddenly experience performance degradations
due to network reconfigurations or migration to another
physical location.

 Service consumers are generally unaware of how

private, internal processes have been implemented. The
consumer of a given service has limited control over the
performance of the service being consumed.

The Service Oriented Integration Pattern tells us that “service invocations are subject to network latency,
network failure, and distributed system failures, but a local implementation is not. A significant amount of
error detection and correction logic must be written to anticipate the impacts of using remote object
interfaces.” While we should assume that crossing boundaries is an expensive process, we must also
exercise caution in the deployment of local methods designed to minimize such boundary crossings. A
system that implements monolithic local methods and objects may gain performance but duplicate
functionality of a previously defined service (this technique was referred to as “cut and paste” in OOP and
shares the same risks regarding versioning of the service).

There are several principles to keep in mind regarding the first Tenet of SO:

 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. If we use
WSDL to represent a simple contract, the <message>
 represents the public data while the <portType>
represents the public process(es).
 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. (This topic will be addressed in greater
detail in future papers in this Series.)

 Avoid RPC interfaces. Explicit message passing should

be favored over an RPC-like model. This approach
insulates the consumer from the internals of the service
implementation, freeing service developers to evolve
their services while minimizing the impact on service
consumers (encapsulation via public messages instead
of publicly available methods).

 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. These
interfaces should be relatively simple, designed to
accept a well-defined input message and respond with
an equally well-defined output message. Once these
interfaces have been designed they should remain
static. These interfaces provide the “constant” design
requirement that services must support, serving as the
public face to the service’s private, internal
implementation.

 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. Service consumers
should not be privy to the internals of a service’s
implementation because it constrains options for
versioning or upgrading the service.

Tenet 2: Services Are Autonomous

Services are entities that are independently deployed, versioned, and managed. Developers should avoid
making assumptions regarding the space between service boundaries since this space is much more likely
to change than the boundaries themselves. For example, service boundaries should be static to minimize
the impact of versioning to the consumer. While boundaries of a service are fairly stable, the service’s
deployment options regarding policy, physical location or network topology is likely to change.

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 (this is also true of a
service’s communication channels). While these changes may have little impact upon the service, they can
have a devastating impact upon applications consuming the service. What if a service you were using
today moved to a network in New Zealand tomorrow? The change in response time may have unplanned
or unexpected impacts upon the service’s consumers. Service designers should adopt a pessimistic view of
how their services will be consumed – services will fail and their associated behaviors (service levels) are
subject to change. Appropriate levels of exception handling and compensation logic must be associated
with any service invocation. Additionally, service consumers may need to modify their policies to declare
minimum response times from services to be consumed. For example, consumers of a service may require
varying levels of service regarding security, performance, transactions, and many other factors. A
configurable policy enables a single service to support multiple SLAs regarding service invocation
(additional policies may focus on versioning, localization and other issues). Communicating performance
expectations at the service level preserves autonomy since services need not be familiar with the internal
implementations of one another.

Service consumers are not the only ones who should adopt pessimistic views of performance – service
providers should be just as pessimistic when anticipating how their services are to be consumed. Service
consumers should be expected to fail, sometimes without notifying 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.

While services are designed to be autonomous, no service is an island. A SOA-based solution is fractal,
consisting of a number of services configured for a specific solution. Thinking autonomously, one soon
realizes there is no presiding authority within a service-oriented environment - the concept of an
orchestration “conductor” is a faulty one (further implying that the concept of “roll-backs” across services is
faulty– but this is a topic best left for another paper). The keys to realizing autonomous services are
isolation and decoupling. Services are designed and deployed independently of one another and may only
communicate using contract-driven messages and policies.

As with other service design principles, we can learn from our past experiences with OO design. Peter
Herzum and Oliver Sims’ work on Business Component Factories provides some interesting insights on the
nature of autonomous components. While most of their work is best suited for large-grained, component-
based solutions, the basic design principles are still applicable for service design,

Given these considerations, here are some simple design principles to help ensure compliance with the
second principle of SO:

 Services should be deployed and versioned independent

of the system in which they are deployed and consumed
 Contracts should be designed with the assumption that
once published, they cannot be modified. This approach
forces developers to build flexibility into their schema
designs.

 Isolate services from failure by adopting a pessimistic

outlook. From a consumer perspective, plan for
unreliable levels of service availability and performance.
From a provider perspective, expect misuse of your
service (deliberate or otherwise), expect your service
consumers to fail – perhaps without notifying your
service.

Tenet 3: Services share schema and contract, not class

As stated earlier, service interaction should be based solely upon a service’s policies, schema, and
contract-based behaviors. A service's contract is generally defined using WSDL, while contracts for
aggregations of services can be defined using BPEL (which, in turn, uses WSDL for each service
aggregated).

Most developers define classes to represent the various entities within a given problem space (e.g.
Customer, Order and Product). Classes combine behavior and data (messages) into a single programming-
language or platform-specific construct. Services break this model apart to maximize flexibility and
interoperability. Services communicating using XML schema-based messages are agnostic to both
programming languages and platforms, ensuring broader levels of interoperability. Schema defines the
structure and content of the messages, while the service’s contract defines the behavior of the service
itself.

In summary, a service’s contract consists of the following elements:

 Message interchange formats defined using XML

Schema.
 Message Exchange Patterns (MEPs) defined using
WSDL.

 Capabilities and requirements defined using WS-Policy.

 BPEL may be used as a business-process level contract

for aggregating multiple services.

Service consumers will rely upon a service’s contract to invoke and interact with a service. Given this
reliance, a service’s contract must remain stable over time. Contracts should be designed as explicitly as
possible while taking advantage of the extensible nature of XML schema (xsd:any) and the SOAP
processing model (optional headers).

The biggest challenge of the Third Tenet is its permanence. Once a service contract has been published it
becomes extremely difficult to modify it while minimizing the impact upon existing service consumers. The
line between internal and external data representations is critical to the successful deployment and reuse of
a given service. Public data (data passed between services) should be based upon organizational or
vertical standards, ensuring broad acceptance across disparate services. Private data (data within a
service) is encapsulated within a service. In some ways services are like smaller representations of an
organization conducting e-business transactions. Just as an organization must map an external Purchase
Order to its internal PO format, a service must also map a contractually agreed-upon data representation
into its internal format. Once again our experiences with OO data encapsulation can be reused to illustrate
a similar concept – a service’s internal data representation can only be manipulated through the service’s
contract.

Given these considerations, here are some simple design principles to help ensure compliance with the
third principle of SO:

 Ensure a service’s contract remains stable to minimize

impact upon service consumers. The contract in this
sense refers to the public data representation (data),
message exchange pattern (WSDL) and configurable
capabilities and service levels (policy).
 Contracts should be designed to be as explicit as
possible to minimize misinterpretation. Additionally,
contracts should be designed to accommodate future
versioning of the service via the extensibility of both the
XML syntax and the SOAP processing model.
  Avoid blurring the line between public and private data
representations. A service’s internal data format should
be hidden from consumers while its public data schema
should be immutable (preferably based upon an
organizational, defacto or industry standard).

 Version services when changes to the service’s contract

are unavoidable. This approach minimizes breakage of
existing consumer implementations.

Tenet 4: Service compatibility Is based upon policy

While this is often considered the least understood design tenet, it is perhaps one of the most powerful in
terms of implementing flexible web services. It is not possible to communicate some requirements for
service interaction in WSDL alone. Policy expressions can be used to separate structural compatibility
(what is communicated) from semantic compatibility (how or to whom a message is communicated).

Operational requirements for service providers can be manifested in the form of machine-readable policy
expressions. Policy expressions provide a configurable set of interoperable semantics governing the
behavior and expectations of a given service. The WS-Policy specification defines a machine-readable
policy framework capable of expressing service-level policies, enabling them to be discovered or enforced
at execution time. For example, a government security service may require a policy enforcing a specific
service level (e.g. Passport photos meeting established criteria must be cross-checked against a terrorist
identification system). The policy information associated with this service could be used with a number of
other scenarios or services related to conducting a background check. WS-Policy can be used to enforce
these requirements without requiring a single line of additional code. This scenario illustrates how a policy
framework provides additional information about a service’s requirements while also providing a declarative
programming model for service definition and execution.

A policy assertion identifies a behavior that is a requirement (or capability) of a policy subject. (In the
scenario above the assertion is the background check against the terrorist identification system.) Assertions
provide domain-specific semantics and will eventually be defined within separate, domain-specific
specifications for a variety of vertical industries (establishing the WS-Policy “framework” concept).

While policy-driven services are still evolving, developers should ensure their policy assertions are as
explicit as possible regarding service expectations and service semantic compatibilities.

The four tenets are primarily designed to assist you in designing and developing your services.

An Abstract SOA Reference Model

While a well planned and executed SOA undertaking can help organizations realize greater responsiveness
in a changing marketplace, not all service-oriented efforts have been successful. SOA projects may
experience limited success when they are driven from the bottom up by developers unfamiliar with the
strategic needs of the organization. Building SOA for the sake of SOA without reference to the business
context is a project without organizing principles and guidance. The result is a chaotic implementation that
has no business relevance. On the other hand, taking a top-down mega-approach to SOA requires such
enormous time investments that by the time the project is complete, the solution no longer maps to
business needs. (This of course is one of the problems SOA is supposed to solve!)

By contrast, Microsoft advocates a “middle out” approach which combines both top-down and bottom-up
methodologies. In this approach, SOA efforts are driven by strategic vision and business need, and are met
through incremental, iterative SOA projects that are designed to deliver on business goals one business
need at a time. Microsoft has been using this technique to assist customers with their SOA initiatives since
the .NET framework was first released in 1999.

The concept of SOA can be viewed from several possible perspectives. While no single perspective or set
of perspectives represents a definitive view of a SOA, from a holistic view these perspectives assist in
understanding the underlying architectural requirements. Microsoft believes that there are three abstract
capability layers exposed within a SOA.

An illustration of these categories and their relationships to one another appears below:

Figure 6. An Abstract Reference Model for SOA

Expose

Expose focuses on how existing IT investments are exposed as a set of broad, standards-based services,
enabling these investments to be available to a broader set of consumers. Existing investments are likely to
be based upon a set of heterogeneous platforms and vendors. If these applications are unable to natively
support Web services a set of application or protocol-specific set of adapters may be required. Service
creation can be fine grained (a single service that maps on to a single business process), or coarse grained
(multiple services come together to perform a related set of business functions). Expose is also concerned
with how the services are implemented. The functionality of underlying IT resources can be made available
natively if they already speak Web services, or can be made available as Web services though use of an
adapter. A Service Implementation Architecture describes how services are developed, deployed and
managed.

Compose

Once services are created, they can be combined into more complex services, applications or cross-
functional business processes. Because services are exist independently of one another they can be
combined (or “composed”) and reused with maximum flexibility. As business processes evolve, business
rules and practices can be adjusted without constraint from the limitations of the underlying applications.
Services compositions enable new cross-functional processes to emerge, allowing the enterprise to adopt
new business processes, tune processes for greater efficiency, or improve service levels for customers and
partners. A Service Integration Architecture describes a set of capabilities for composing services and other
components into larger constructs such as business processes. Composing services requires some sort of
workflow or orchestration mechanism. Microsoft provides these capabilities via BizTalk Server 2006 (BTS)
or Windows Workflow Foundation (WF). While BTS and WF may appear to serve similar needs, they are
actually quite different. WF and BTS are complementary technologies designed to serve two very different
needs:

· BTS is a licensed product designed to implement workflow (“orchestrations”) across disparate

applications and platforms.

· WF is a developer framework designed to expose workflow capabilities within your application.

There are no fees or licensing restrictions associated with using or deploying WF.

We will examine workflow, orchestration and the use of BizTalk/WF in Chapter 3 (Workflow and Business
Processes).

Consume

When a new application or business process has been created that functionality must be made available
for access (consumption) by IT systems, other services or by end-users. Consumption focuses on
delivering new applications that enable increased productivity and enhanced insight into business
performance. Users may consume “composed” services through a broad number of outlets including web
portals, rich clients, Office business applications (OBA), and mobile devices. “Composed” services can be
used to rapidly roll out applications that result in new business capabilities or improved productivity. These
application roll-outs can be used to measure the return on investment (ROI) in an SOA. A Service Oriented
Application Architecture describes how “composed services” are made available for consumption through
as business processes, new services or new end-user applications. This concept is sometimes referred to
as Composite Applications since it implies service consumption by end-user applications. Microsoft’s Office
Business Applications (OBAs) support the Composite Application notion of transactional systems while
expanding the scope of user interaction via the familiar Office environment.

We will examine consumption in greater detail in Chapter 5 (User Experiences).

While the architectures described within Expose / Compose / Consume may be interdependent, they are
designed to be loosely coupled. This enables services to be managed, versioned and configured
independently of how they are exposed,

Recurring Architectural Capabilities

As we saw earlier, the SOA architectural model is fractal. This means that a service can be used to Expose
IT assets (such as a Line of Business system), be Composed into workflows or Business Processes (each
of which may also be exposed as a service) and be Consumed by end users, systems or other services.
SOA is a fractal, not layered model. While the Abstract SOA Reference Model provides a holistic view of
several important SOA concepts, the Expose / Compose / Consume portions of the model should not be
interpreted as layers (despite their apparent appearance in the model). Designing a SOA as a set of well-
defined tiers (or layers) will constrain the value and flexibility of your services, resulting in dependencies
across unrelated components. This is why the Expose / Compose / Consume portions of the model can be
thought of as independent architectural initiatives referred to as a Service Implementation Architecture
(Expose), a Service Integration Architecture (Compose) and an Application Architecture (Consume). While
each of these architectures are designed to be independent of one another, they share a set of five
common capabilities.
Figure 7. Recurring Architectural Capabilities

Messaging and Services

Messaging and Services focuses on how messaging is accomplished between senders and receivers.
There are a broad array of options and patterns available – from pub/sub and asynchronous to message
and service interaction patterns. Services provide an evolutionary approach to building distributed software
that facilitates loosely coupled integration and resilience to change. The advent of the WS-* Web Services
architecture has made service-oriented software development feasible by virtue of mainstream
development tools support and broad industry interoperability. While most frequently implemented using
industry standard Web services, service orientation is independent of technology and architectural patterns
and can be used to connect with legacy systems as well. Messaging and Services are not a new approach
to software design – many of the notions behind these concepts have been around for years. A service is
generally implemented as a coarse-grained, discoverable software entity that exists as a single instance
and interacts with applications and other services through a loosely coupled (often asynchronous),
message-based communication model. Messages tend to be based upon an agreed-upon set of semantics
(such as an industry-standard Purchase Order) and serialized using an interoperable, extensible syntax
(usually XML, although alternate approaches like JSON, RNC and ASN1 are sometimes used).

Workflow and Process

Workflow and Process are pervasive across multiple layers of an integration architecture – from formal
orchestration of processes to flexible ad hoc systems and collaborative workflow across teams. Since
business processes are dynamic and evolve with the organization, the workflow that models these
processes must be equally adaptable. In addition, effective workflow involves not only process modeling,
but also monitoring and analytics in order to respond to exceptions and optimize the workflow system over
time.

Data

The lynchpin to success in many integration architectures is the ability to provide Data management. The
need to deliver a shared view across disparate, often duplicate sources of data is more important than ever,
as businesses strive to achieve a 360-degree view of organizational information. Entity aggregation, master
data management, and the ability to make data useful via analytics and mining are crucial elements of
integration architecture.

User Experience

Successful integration architectures depend upon both service delivery and the ability to consume services
in a rich and meaningful way. Service consumption needs to be contextual, mapping to the natural workflow
of employees, customers, and partners. To that end, an integrated User Experience spanning smart
clients, rich clients, lightweight Web applications, and mobile devices enables service consumption by the
broadest possible audience.
Identity and Access

To support integrated user experiences, customers require the ability to manage the identity lifecycle –
providing integrated Single Sign-On (SSO), access management, directory services, and federated trust
across heterogeneous systems. Today, many solutions are built using fragmented technologies for
authentication and authorization. In the new application model, access decisions and entitlements need to
be made at multiple layers and tiers, in which a federated Identity and Access across trust boundaries
becomes a key requirement.

Management

During the lifetime of a service, the service most probably changes in different perspectives as listed below.
As a result, one service will probably have to be available in several versions.

· Difference in interface (e.g. extended interface, but same business object)

· Difference in semantics with same interface (business objects changed)

· Difference in QoS, e.g. slower but cheaper or high-available but more expensive

Service management encompasses many capabilities, some of which are listed below:

· A comprehensive solution for change and configuration management, enabling organizations to

provide relevant software and service updates to users quickly and cost-effectively.

· Reducing the complexity associated with managing the IT infrastructure environment with a focus on
lowering the cost of operations.

· Centralized backup services capturing changed files to disk. Centralized backup should enable rapid,
reliable recovery from disk while providing end-user recovery without IT intervention.

· Pre-deployment capacity planning coupled with best-practice guidance and hardware-specific

knowledge to help information technology professional make low-risk architectural decisions.

· Data warehouse and reporting to help IT better support corporate decision making, improve the
quality of service provided, and better administer resources through improved reporting capabilities and
management data integration from a broad variety of resources.

Supporting the Common Architectural Capabilities

The five architectural capabilities discussed above are supported by the Microsoft SOA Platform. The
remainder of this book discusses the common architectural capabilities in greater detail, starting with
Messaging and Services in Chapter 2.
Figure 8. SOA Capabilities on the Microsoft Platform

Common Architectural Capabilities and the Abstract SOA Model

We can also think of these five common architectural capabilities as set of perspectives for viewing and
understanding the Abstract SOA Model. The five architectural capabilities serves as a set of lenses to help
us view and better understand the challenges associated with Exposing existing IT investments as
services, Composing the services into business processes and Consuming these processes across the
organization.

Expose

Service Enablement

Expose focuses on how we design and expose our services. We will most likely start out by enabling our IT
investments to be exposed as web services.

As our organization matures we will start adding new services, most likely as proxies for other resources
within the organization.

One of the hardest parts of service implementation is deciding where to begin. The are a variety of choices
here and there is no single recommendation that will work for everyone. Motion is a methodology that
provides some guidance for identifying business capabilities that could be exposes as services.

What are some best practices that one should follow when exposing IT investments as services?

 Think big– but start small



o Show value at every step along the way – not

build it and they will come

 Middle-out – not Top-down or bottom-up

o Be pragmatic

 Vertical-slice – not build it and they will come

 

o Risk-mitigation

 Demonstrate value in rapid iterations – not waterfall

o New approaches to development

 Successful customers ‘snowball’

The recurring architectural capabilities provide us with a set of considerations when exposing IT
investments as services. Let’s take a quick look at some of the considerations associated with each
capability for service exposure (this is by no means a complete list):

Messaging and Services

 Determining what to expose and how - Avoid falling into

the granularity trap - focus on meeting your business
requirements
 Service Operation Contracts

 Message and Data Contracts

 Configuration, behaviors and control

 SLAs

 Governance

 Versioning

Workflow and Process

 Coordinator services for distributed, long-running

processes
 Tracking services capable of logging specific events
within a workflow

 Compensation services

Data

 Entity services
 Entity Aggregation services: acts as a single point to
access information that may exist in multiple systems.
An Entity Aggregation service has the following
responsibilities:

o Acts as a unified source of entities

o Provides a holistic view of an entity

 o Provides a holistic view of the entity model—
entities and their relationships with other entities

o Provides location transparency—consumers of

the Entity Aggregation layer do not need to know
who owns the information

o Enforces business rules that determine the

segments of entities retrieved in a given context

o Determines the system of record for each data

element constituting an entity

o Enriches the combined data model across

systems—the whole being better than the sum of
its parts

o Entity factoring

 MDM focuses on exposing data across corporate or

departmental boundaries. We’ll discuss MDM in greater
detail in Chapter 4. (The Canonical schemas imply that
all the services share the same schema, which need not
be the case.)

User Experience

 Specialized services for supporting user interfaces

(caching resources, communications between UI and
services, etc). Service wrappers provide coarse-grained
interfaces for user app consumption, lightweight mash-
ups, etc.

Identity and Access

 Identity Management
 Impersonation and Delegation services

 Trusted Subsystem - A trusted subsystem model implies

that services are trusted to perform specific tasks, such
as processing customer orders.

 Authentication (Kerberos, SSL)

 Role-based access control (RBAC)

 Create/revoke trust relationships

 Services need to make authorization decisions, such as

approving an order submission before performing the
business transaction.

 The service must know the identity of the end user

submitting the order.

 Need to flow the identity of the end user is an inherent

property of the delegation model, it is not so for the
 trusted subsystem model and special efforts must be
made to include this feature.

 To support the notion of trust as defined by the model,

the services must at least be able to:

1. Authenticate / verify identity of upstream /

downstream services

2. Decide if the service is a trusted subsystem for

specific functions (including propagating identity
claims)

3. Protect the integrity of the data being

communicated between trusted subsystem and
services.

 Besides application data, application plumbing data,

such as the identity claims of the original user, must also
be protected so that no man-in-the-middle can modify
the identity information that is in transit.

Compose

Service Composition

Compose focuses on how we can combine or aggregate granular services into more complex processes.
We will most likely start by using services that expose our existing IT investments.

Service composition results in a new service instance that the rest of the organization can make use of.
The composition provides capabilities such as correlated asynchronous service invocation, long running
processes and other capabilities for orchestrating autonomous services.

The recurring architectural capabilities provide us with a set of considerations when composing granular
services into complex processes. Let’s take a quick look at some of the considerations associated with
each capability for service composition (this is by no means a complete list):

Messaging and Services

 Service interaction patterns

 Exposing orchestrations as services

 Asynchronous service invocation patterns

Workflow and Process

 Transactions
 High frequency of change

 Business Rules

 Service Orchestration
  Service Interaction Patterns (SIPs)

 Process Externalization

 Long Running Processes

 Auditing and analytics

Data

 Tracking the state of a given workflow instance

 Data transformation (ETL)

 Reliable message processing and storage

 Replication

 Synchronization

 Metadata repository and Management

 Instance reconciliation

 Schema reconciliation

 Document Replication

 Syndication/Aggregation

User Experience

 Composite applications (OBAs)

 Human workflows (MOSS)

 Orchestrations initiate human workflows via SharePoint

adapter

 Pageflows

Identity and Access

 Impersonation and Delegation

 Provisioning

 Identity Repository synchronization

 Approval workflows

Consume

User Experience

Consume focuses on how services and orchestrated processes (which may be exposed as services) are
consumed by other services, applications and end-users. Any resource capable of interacting with services
can be referred to as a “consumer”. Consumers may appear across the organization in several possible
forms:

 Lightweight, browser-based applications

  Rich internet applications (RIA) are browser-based
applications that can address and cache local and
remote resources

 Configurable, portal-based user experiences

 Applications that are installed on the local machine (such

as a custom Windows application)

 Corporate business applications with solution-specific

extensions (such as Microsoft Office with context-aware
activity panes)

 Applications designed for mobile devices

 Services may act as consumers of other services

Recall that the SOA model is fractal – services may be consumed by other services and service
compositions may be exposed as new services. In the last couple of years a “new breed” of consumers has
emerged, enabling consumers to be aggregated and consumed by additional consumers. This “new breed”
of consumers is usually referred to as a “mashup”. A mashup is a set of services, websites or applications
that combine content from multiple resources into a new integrated user experience. Content used by
mashups is typically sourced from a third party (such as a service or website) via a public interface or API.
Alternative methods of sourcing content for mashups include newsfeeds and JavaScript constructs (JSON).

The recurring architectural capabilities provide us with a set of considerations for User Experience. Let’s
take a quick look at some of the considerations associated with each capability for User Experience (this is
by no means a complete list):

Messaging and Services

 Forms-based service consumption

 Web parts

 Service Registry – check in / check out / search

 AJAX, REST

Workflow and Process

 Human workflows (MOSS)

 Event brokering (CAB)

 Page flows

Data

 Entities (OBA Business Data Catalog)

 Single view of the customer problem

 JSON

User Experience

 Composite applications (OBAs)

 Personalization, user profiles
  Portals

 Business Intelligence

 Reporting

 Content aggregation

 Declarative UX

Identity and Access

 Single Sign-On (password synchronization)

 User identification

 Role-based access (RBAC)

 Directory Services

 Password management

 Privacy (firewalls, encryption)

 Compliance

Summary

In this chapter we provided some useful analogies for understanding the fractal nature of SOA. Services
are the fundamental building blocks of SOA, although services do not necessarily need to be web services.
Ideally these services should follow the four service design tenets which describe a set of best practices for
service scopes, dependencies, communications and policy-based configuration. While these tenets focus
upon service design, it is important to realize that services alone are not necessarily solution architecture –
Microsoft uses an abstract reference model to describe the various aspects of SOA. The abstract SOA
reference model provides three fundamental concepts to help most organizations understand the role that
services can play within their solution architectures:

 Expose focuses on how existing IT investments are

exposed as a set of broad, standards-based services,
enabling these investments to be available to a broader
set of consumers. A Service Implementation Architecture
describes how services are developed, deployed and
managed.
 Compose focuses on combining services into
applications or cross-functional business processes. A
Service Integration Architecture describes a set of
capabilities for composing services and other
components into larger constructs such as business
processes.

 Consume focuses on delivering new applications that

enable increased productivity and enhanced insight into
business performance. A Service Oriented Application
Architecture describes how “composed services” are
made available for consumption through as business
processes, new services or new end-user applications.
Each aspect of the Expose / Compose / Consume abstract reference model encompasses a set of five
recurring architectural capabilities: Messaging and Services, Workflow and Processes, Data, User
Experience and Identity and Access. The five architectural capabilities serves as a set of views to better
understand the challenges associated with Exposing existing IT investments as services, Composing the
services into business processes and Consuming these processes across the organization.