Service Oriented Architecture
Alberto Polzonetti
1
.
.
.
.
.
Service-Oriented Architecture: Concepts,
.
Technology, and Design
.
By Thomas Erl.
.
.
Publisher: Prentice Hall PTR
.
Pub Date: August 04, 2005
.
.
ISBN: 0-13-185858-0 Pages: 792
.
.
.
.
.
.
Service-Oriented Architecture:
.
A Field Guide to Integrating XML and Web
.
Services
.
written by Thomas Erl
.
(560 pages, Paperback)
.
.
.
2
Additional information
• The XML & Web Services Integration Framework (XWIF)
– Some of the contents in this book originated from research I performed
for SOA Systems Inc. (formerly XMLTC Consulting Inc.), as part of the
XML & Web Services Integration Framework (XWIF) project. For more
information, visit www.soasystems.com or www.xwif.com.
• www.serviceoriented.ws
– Updates, source code, and various other supporting resources can be
found at www.serviceoriented.ws.
• Contact the Author
– www.thomaserl.com/technology.
• Sito del corso
3
Case Studies
• Due to the distinctive nature of modern-day
service-oriented architectures, using case
studies is an effective way of conveying the
topics covered by this book. Though purely
fictional, the examples derived from these case
studies raise common issues and problems
faced by typical IT departments
• RailCo Ltd.
• Transit Line Systems Inc.
4
Motivation
• WE LIVE IN HARD TIMES. THE SOCIAL
MARKET ECONOMY IS BEING REPLACED BY A
GLOBAL MARKET ECONOMY
• you have to be fast and flexible to survive.
• “It is not the strongest of the species that survive,
nor the most intelligent, but the ones most
responsive to change.”
• The key is flexibility.
• For all major companies and large distributed
systems, information technology (IT) flexibility is
paramount.
5
• processes and systems are also becoming
more and more complex.
• We have left the stage where automation
was primarily a matter of individual
systems, and are fast moving toward a
world where all those individual systems will
become one distributed system
• The challenge is
maintainability.
6
• Centralization, the precondition for
harmonization and control, does not scale,
and we have reached its limits.
• For this reason, we need a new approach
• an approach that accepts heterogeneity
and leads to decentralization.
7
• In addition, we have to solve the problem of the
business/IT gap.
• This gap is primarily one of semantics
• business people and IT people appear to speak
and think in entirely different languages.
• The new approach must bring business and IT
much closer than ever before
8
Service-oriented
architecture (SOA) is exactly
what's needed
It's an approach that helps systems remain
scalable and flexible while growing, and
that also helps bridge the business/IT gap
9
The approach consists of three
major elements:
•
•
•
Services, which on the one hand represent
self-contained business functionalities that can
be part of one or more processes, and on the
other hand, can be implemented by any
technology on any platform.
A specific infrastructure, called the enterprise
service bus (ESB), that allows us to combine
these services in an easy and flexible manner.
Policies and processes that deal with the fact
that large distributed systems are
heterogeneous, under maintenance, and have
different owners.
10
Part I – INTRODUCING SOA
11
Foundamental SOA
1.
2.
the term "service-oriented" has existed for some time,
it has been used in different contexts and for different
purposes
Approach
1.
2.
3.
the logic required to solve a large problem can be better
constructed, carried out, and managed if it is decomposed into
a collection of smaller, related pieces.
Each of these pieces addresses a concern or a specific part of
the problem.
This approach transcends technology and
automation solutions. It is an established and
generic theory that can be used to address a
variety of problems.
12
A service oriented analogy
Credit companies are service-oriented in that each provides a
distinct service that can be used by multiple consumers
13
Service Oriented and Composition
The definition of
software services aligns
with the business
services that a bank
offers to ensure smooth
business operations and
to help realize strategic
goals such as providing
ATM and Web access to
banking services in
addition to providing
them in the branch
office.
14
Architecture
• When coupled with "architecture," serviceorientation takes on a technical connotation.
• "Service-oriented architecture" is a term that
represents a model in which automation logic is
decomposed into smaller, distinct units of logic.
– Collectively, these units comprise a larger piece of
business automation logic.
– Individually, these units can be distributed.
15
Services oriented
• Business Community
– impose dependencies  inhibit the potential of individual businesses.
– empowering businesses to self-govern their individual services  allow
them to evolve and grow relatively independent from each other.
– Independence within our business outlets, and adhesion to certain
baseline conventions
– standardization key aspects of each business for the benefit of the
consumers without significantly imposing on the individual business's
ability to exercise self-governance.
• Service-oriented architecture (SOA)
– encourages individual units of logic to exist autonomously yet not
isolated from each other.
– Units of logic are still required to conform to a set of principles that
allow them to evolve independently, while still maintaining a
sufficient amount of commonality and standardization.
– Within SOA, these units of logic are known as
services.
16
How services encapsulate logic
• each service can
encapsulate
– a task performed by
an individual step
– a sub-process
comprised of a set
of steps.
• A service can even
encapsulate the
entire process
logic.
17
How services relate (I)
• The relationship between services is based on
an understanding that for services to interact,
they must be aware of each other.  service
descriptions.
• A service description establishes
– the name of the service
– the data expected and returned by the service.
18
How services relate (II)
• The manner in which services use service
descriptions results in a relationship classified as
loosely coupled.
– Loose coupling describes an approach where
integration interfaces are developed with minimal
assumptions between the sending/receiving parties,
thus reducing the risk that a change in one
application/module will force a change in another
application/module. ( wikipedia ottobre 2007 )
• A communications framework capable of
preserving their loosely coupled relationship is
therefore required. [ messaging ].
19
How services communicate
• After a service sends a message, it loses
control of what happens to the message
thereafter.
• The messages exist as "independent
units of communication."
20
Service orientation : three core
components
1. SERVICES
2. DESCRIPTIONS
3. MESSAGES
21
Architectural component design
22
How services are designed :key aspects
• Loose coupling  Services maintain a relationship that and only
requires that they retain an awareness of each other.
• Service contract  Services adhere to a communications
agreement
• Autonomy  Services have control over the logic they encapsulate.
• Abstraction  Services hide logic from the outside world.
• Reusability  Logic is divided into services with the intention of
promoting reuse.
• Composability  Collections of services can be coordinated and
assembled to form composite services.
• Discoverability  Services are designed to be outwardly
descriptive so that they can be found and assessed via available
discovery mechanisms.
23
How services are built
• the term "service-oriented" and various abstract
SOA models existed before the arrival of Web
services.
• However, no one technology advancement has
been so suitable and successful in manifesting
SOA than Web services.
• All major vendor platforms currently support the
creation of service-oriented solutions, and most
do so with the understanding that the SOA
support provided is based on the use of Web
services.
24
What Are Web Services?
• Web Services refers to a collection of
standards that cover interoperability.
• These standards define both the protocols
that are used to communicate and the
format of the interfaces that are used to
specify services and service contracts.
25
Fundamental Web Services Standards
• There are five fundamental Web Services
standards.
• Two of them are general standards that
existed beforehand and were used to
realize the Web Services approach:
– XML is used as the general format to describe
models, formats, and data types.
– HTTP (including HTTPS) is the low-level
protocol used by the Internet.
26
• The other three fundamental standards are
specific to Web Services and were the first
standards specified for them:
– WSDL is used to define service interfaces. In fact, it
can describe two different aspects of a service: its
signature (name and parameters) and its binding and
deployment details (protocol and location).
– SOAP is a standard that defines the Web Services
protocol. While HTTP is the low-level protocol, also
used by the Internet, SOAP is the specific format for
exchanging Web Services data over this protocol.
– UDDI is a standard for managing Web Services (i.e.,
registering and finding services).
27
Primitive SOA
represents a
baseline
technology
architecture that
is supported by
current major
vendor platforms
28
Summary
1.1
• SOA and service-orientation are implementation
paradigms that can be realized with any suitable
technology platform.
• Primitive SOA model represents a mainstream
variation of SOA based solely on Web services and
common service-orientation principles.
29
Contemporary SOA
• Major software vendors are continually
conceiving new Web services
specifications and building increasingly
powerful XML and Web services support
into current technology platforms.
• The result is an extended variation of
service-oriented architecture we refer to as
contemporary SOA.
30
Common Characteristics
31
SOA increases quality of service
• Ability for tasks to be carried out in a secure manner,
protecting the contents of a message, as well as access to
individual services.
• Reliability so that message delivery or notification of failed
delivery can be guaranteed.
• Overhead imposed by SOAP message and XML content
processing does not inhibit the execution of a task.
32
SOA is based on open standards
•
Standard open technologies are used within and
outside of solution boundaries.
33
SOA supports vendor diversity
34
SOA promotes discovery
35
SOA encourages intrinsic
interoperability
36
SOA promotes federation
37
SOA promotes architectural
composability
• Different solutions can be composed of different extensions
and can continue to interoperate as long as they support
the common extensions required.
38
SOA encourages intrinsic
reusability
39
SOA emphasizes extensibility
• Extensible services can expand functionality with
minimal impact.
40
SOA supports a service-oriented
business modeling paradigm
• Partitioning business logic into services that can then be
composed has significant implications as to how business
processes can be modeled
41
SOA implements layers of
abstraction
• Application logic created with proprietary technology
can be abstracted through a dedicated service layer.
42
SOA promotes loose coupling
throughout the enterprise
43
SOA promotes organizational
agility
44
SOA general definition
• SOA is a form of technology architecture
that adheres to the principles of serviceorientation.
• When realized through the Web services
technology platform, SOA establishes the
potential to support and promote these
principles throughout the business process
and automation domains of an enterprise.
45
SOA wikipedia definition feb 2006
• In computing, the term "Service-Oriented
Architecture" (SOA) expresses a software
architectural concept that defines the use of
services to support the requirements of software
users.
• In a SOA environment, nodes on a network
make resources available to other participants in
the network as independent services that the
participants access in a standardized way.
• Most definitions of SOA identify the use of Web
services in its implementation. However, one can
implement SOA using any service-based
technology.
46
SOA Is a Paradigm
• SOA is not a concrete architecture: it is
something that leads to a concrete architecture.
– You might call it a style, paradigm, concept,
perspective, philosophy, or representation.
– It is an approach, a way of thinking, a value system
that leads to certain concrete decisions when
designing a concrete software architecture.
• This aspect of SOA has a very important
consequence: you can't buy SOA.
47
SOA Aims to Improve Flexibility
• A critical factor for business success is keeping
time to market share.
• My job is to deliver on time, on budget, with the
"appropriate" quality metrics.
• To deliver a quality solution right on time, you
need flexibility. But flexibility has a lot to do with
clear organization, roles, processes, and so on.
Therefore,
• SOA has to deal with all these aspects.
48
Distributed Systems
• As businesses grow, they become more and
more complex, and more and more systems and
companies become involved.
• SOA is a paradigm for "organizing and utilizing
distributed capabilities."
• SOA allows entities that need certain distributed
capabilities to locate and make use of those
capabilities. In other words, it facilitates
interactions between service providers and
service consumers, enabling the realization of
business functionalities.
49
Different Owners and
Heterogeneity
• SOA includes practices and processes that are
based on the fact that networks of distributed
systems are not controlled by single owners.
• Different teams, different departments, or even
different companies may manage different
systems
• Thus, different platforms, schedules, priorities,
budgets, and so on must be taken into account.
• This concept is key to understanding SOA and
large distributed systems in general.
50
Distributed systems with different
owners
51
Distributed systems are
heterogeneous
52
Common misperceptions about
SOA
53
• An application that uses Web services is
service-oriented
– you need to standardize how Web services are
positioned and designed, according to serviceorientation principles.
• SOA is just a marketing term used to re-brand
Web services
– SOA is a legitimate and relatively established
technical term. It represents a distinct architecture
based on a set of distinct principles.
• If you understand Web services you won't have
a problem building SOA
• Once you go SOA, everything becomes
interoperable
54
Common tangible benefits of SOA
• Improved integration (and intrinsic
interoperability)
• Inherent reuse
• Simplified architectures and solutions
• Leveraging the legacy investment
• Establishing standardized XML data
representation
• Focused investment on communications
infrastructure
• Organizational agility
55
Common pitfalls of adopting SOA
• Building service-oriented architectures like
traditional distributed architectures
• Not standardizing SOA
• Not creating a transition plan
• Not starting with an XML foundation
architecture
• Not understanding SOA performance
requirements
• Not understanding Web services security
56
Summary
•
1.2
We recognize contemporary SOA with a number of common
characteristics that build upon and extend the original qualities and
principles established by primitive SOA.
•
Some of the more dangerous assumptions about SOA are that
service-oriented solutions are simple by nature, easy to build, and
automatically interoperable
•
When assessing the return on investment for an SOA there are several
concrete benefits that can be taken into account.
•
Many of the pitfalls relate to a limited understanding of what SOA is
and what is required to fully incorporate and standardize serviceorientation.
•
A transition plan is the best weapon against the obstacles that tend to
face organizations when migrating toward SOA.
57
Part II - The evolution of
SOA
58
XML: brief history
• Like HTML, the Extensible Markup Language (XML) was
a W3C creation derived from the popular Standard
Generalized Markup Language (SGML) that has existed
since the late 60s.
• This widely used meta language allowed organizations
to add intelligence to document data.
• The language itself was used as the basis for a series of
additional specifications.
– XML Schema Definition Language (XSD) and XSL
Transformation Language (XSLT) were both authored
using XML. (These specifications, in fact, have become key parts of
the core XML technology set)
59
Web Services:a brief history (I)
• In 2000, the W3C received a submission for the Simple
Object Access Protocol (SOAP) specification.
– This specification was originally designed to unify (and in some
cases replace) proprietary RPC communication. The idea was
for parameter data transmitted between components to be
serialized into XML, transported, and then deserialized back into
its native format.
60
Web Services:a brief history (II)
• This ultimately led to the idea of creating a pure, Webbased, distributed technology (one that could leverage
the concept of a standardized communications
framework to bridge the enormous disparity that existed
between and within organizations).
• This concept was called Web services.
• The most important part of a Web service is its public
interface.
– It is a central piece of information that assigns the service an
identity and enables its invocation
61
Web Services:a brief history (III)
• One of the first initiatives in support of Web services was
the Web Service Description Language (WSDL).
– The W3C received the first submission of the WSDL language in
2001 and has since continued revising this specification.
• IBM and Microsoft were each working on a way to
programmatically describe how to connect to a Web
Service. After some discussion, protocol proposals from
Microsoft and IBM merged. In late 2000, a merged
specification, Web Services Description Language
(WSDL), was announced.
62
Web Services:a brief history (IV)
• Completing the first generation of the Web services
standards family was the UDDI specification.
– Originally developed by UDDI.org, it was submitted to OASIS,
which continued its development in collaboration with UDDI.org.
• This specification allows for the creation of standardized
service description registries both within and outside of
organization boundaries.
• UDDI provides the potential for Web services to be
registered in a central location, from where they can be
discovered by service requestors.
• Unlike WSDL and SOAP, UDDI has not yet attained
industry-wide acceptance, and remains an
optional extension to SOA.
63
Early incarnation of SOA:
architecture modeled around three
basic components
64
Standard Organizations that
contribute to SOA
• W3C
– In the SOA arena, its role has been primarily as a standards
body responsible for specifications that provide core and generic
functionality.
• OASIS
– Its overall goal is to support the creation of standards targeted at
specific industries and to foster trade and commerce between
eBusiness-enabled enterprises.
• WS-I
– not produce technology standards.
– Instead, this organization provides profile documents that
establish a proven and tested collection of standards.
Compliance to these profiles guarantees organizations that their
environments support a level of industry-standard
interoperability.
65
Comparision of Standards
Organizations
66
Reading: compare SOA to past
architectures
• SOA vs. client-server architecture
• SOA vs. distributed Internet architecture
• SOA vs. hybrid Web service architecture
67
The Service-Oriented Enterprise
68
Extensible Markup Language
(XML)
• Standard data types and structures,
independent of any programming language,
development environment, or software system.
• Pervasive technology for defining business
documents and exchanging business
information, including standard vocabularies for
many industries.
• Ubiquitous software for handling operations on
XML, including parsers, queries, and
transformations.
69
Web services
• Pervasive, open standards for distributed
computing interface descriptions and document
exchange via messages.
• Independence from the underlying execution
technology and application platforms.
• Extensibility for enterprise qualities of service
such as security, reliability, and transactions.
• Support for composite applications such as
business process flows, multi-channel access,
and rapid integration.
70
Service-oriented architecture
(SOA)
• A strong architectural focus, including
governance, processes, modeling, and tools.
• An ideal level of abstraction for aligning
business needs and technical capabilities, and
creating reusable, coarse-grain business
functionality.
• A deployment infrastructure on which new
applications can quickly and easily be built.
• A reusable library of services for common
business and IT functions
71
Business process management
(BPM)
• Explicitly describe business processes so that
they are easier to understand, refine, and
optimize.
• Make it easier to quickly modify business
processes as business requirements change.
• Automate previously manual business
processes and enforce business rules.
• Provide real-time information and analysis on
business processes for decision makers.
72
73
Why Web Services ?
• The reason is that when exposing the
capabilities of software components, we
are essentially exposing software services.
• The goal is for these services to be widely
available over the World-Wide Web (more
strictly we really mean the Internet) —
hence the term ‘Web
74
RailCo
• RailCo Ltd. is an established
parts supplier for railways,
specializing in air brakes and
related installation tools.
• RailCo ships air brake parts
internationally, but 90% of its
sales are in North America.
• Though its primary line of
business is product resale,
RailCo also has a small group
of specialized technicians that
are hired out locally for
installations and repairs.
75
TLS
•
•
•
Transit Line Systems Inc. (TLS) is
a prominent corporation in the
private transit sector.
It employs over 1,800 people and
has offices in four cities.
Though its primary line of
business is providing private
transit, it has a number of
secondary business areas,
including the following:
– A maintenance and repair branch
that outsources TLS service
technicians to public transit
sectors.
– Parts manufacturing for other
industries.
– A tourism branch that partners
with airlines and hotels.
76
• Loose coupling is the concept typically employed to deal with
the requirements of scalability, flexibility, and fault tolerance.
• The aim of loose coupling is to minimize dependencies.
– When there are fewer dependencies, modifications to or faults in
one system will have fewer consequences on other systems.
• Loose coupling is a principle; it is neither a tool, nor a
checklist.
• Possible forms of loose coupling
– Physical connections Point-to-point Via mediator
– Communication style Synchronous Asynchronous
77
Descargar

soa