“SOAs are like snowflakes – no two are alike.”
- David Linthicum
Consultant
Contents
Reader ROI
Acknowledgements
Introduction to SOA
Understanding Services
An Abstract SOA Reference Model
Recurring Architectural Capabilities
Management
Supporting the Common Architectural
Capabilities
Common Architectural Capabilities
and the Abstract SOA Model
Summary
References
Reader
ROI
Readers of this chapter will learn about
some of the general concepts generally associated with Service Oriented
Architectures (SOA). The chapter provides several analogies for understanding
service oriented concepts and some high level recommendations for designing
services. This chapter provides an abstract model for describing SOA and introduces
a set of architectural capabilities that will be explored in subsequent
chapters of this book.
Acknowledgements
The vast majority of this book consists of
content from a wide variety of people. Some of this content is new while other
content may have appeared in other formats. Each chapter in this book will begin
with an “Acknowledgements” section to thank the authors of the content that
comprises each chapter.
Many of the concepts in Chapter One are
based upon earlier published efforts. We wish to thank the following
individuals for their work in this area: Don Box (Four Tenets), John deVadoss
(Recurring Architectural Capabilities), and Kris Horrocks
(Expose/Compose/Consume).
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.
.gif)
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.
.jpg)
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 technology
|
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 needs vary from one organization to
another. Purchasing your SOA infrastructure from a single vendor defeats the
purpose of investing in SOA.
|
|
SOAs require Web Services
|
SOAs may be realized via Web services
but Web services are not necessarily required to implement SOA
|
|
SOA is new and revolutionary
|
EDI, CORBA and DCOM were conceptual
examples of SO
|
|
SOA ensures the alignment of IT and
business
|
SOA is not a methodology
|
|
A SOA Reference Architecture reduces
implementation risk
|
SOAs are like snowflakes – no two are
the same. A SOA Reference Architecture may not necessarily provide the best
solution for your organization
|
|
SOA requires a complete technology and
business processes overhaul
|
SOA should be incremental and built upon
your current investments
|
|
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.
.jpg)
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:
- 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.
- 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.
- 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.
.jpg)
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.
.jpg)
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:
.jpg)
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.
.jpg)
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.
.jpg)
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
- Show value at every step along the way –
not build it and they will come
- Middle-out – not Top-down or bottom-up
- Vertical-slice – not build it and they
will come
- Demonstrate value in rapid iterations –
not waterfall
- 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:
- Acts as a unified source of entities
- Provides a holistic view of an entity
- Provides a holistic view of the entity
model—entities and their relationships with other entities
- Provides location transparency—consumers
of the Entity Aggregation layer do not need to know who owns the
information
- Enforces business rules that determine
the segments of entities retrieved in a given context
- Determines the system of record for each
data element constituting an entity
- Enriches the combined data model across
systems—the whole being better than the sum of its parts
- 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:
- Authenticate / verify identity of upstream
/ downstream services
- Decide if the service is a trusted
subsystem for specific functions (including propagating identity claims)
- 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.
In the Chapter 2 we will enter into a more
detailed analysis of both Service Orientation and the Messaging and Services
architectural capability.
References