1 service oriented architecture alberto polzonetti
Post on 22-Dec-2015
218 views
TRANSCRIPT
1
Service Oriented Architecture
Alberto Polzonetti
2
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: 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 Serviceswritten by Thomas Erl (560 pages, Paperback)
3
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
4
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.
5
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.
6
• 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.
7
• 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.
8
• 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
9
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
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
10
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.
11
Part I – INTRODUCING Part I – INTRODUCING SOASOA
Part I – INTRODUCING Part I – INTRODUCING SOASOA
12
Foundamental SOA
1. the term "service-oriented" has existed for some time, it has been used in different contexts and for different purposes
2. Approach1. 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.
2. Each of these pieces addresses a concern or a specific part of the problem.
3. This approach transcends technology and automation solutions. It is an established and generic theory that can be used to address a variety of problems.
13
A service oriented analogy
Credit companies are service-oriented in that each provides a
distinct service that can be used by multiple consumers
14
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.
15
Architecture
• When coupled with "architecture," service-
orientation 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.
16
Services oriented• Business CommunityBusiness 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)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.
17
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.
18
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 service descriptionsdescriptions.
• A service description establishes– the name of the service– the data expected and returned by the service.
19
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 ][ messaging ].
20
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."
21
Service orientation : three core components
1. SERVICES
2. DESCRIPTIONS
3. MESSAGES
1. SERVICES
2. DESCRIPTIONS
3. MESSAGES
22
Architectural component design
23
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.
24
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.
25
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.
26
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.
27
• 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).
28
Primitive SOA
represents a baseline technology architecture that is supported by current major vendor platforms
29
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.
• 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.
30
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.
31
Common Characteristics
32
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.
33
SOA is based on open standards
• Standard open technologies are used within and
outside of solution boundaries.
34
SOA supports vendor diversity
35
SOA promotes discovery
36
SOA encourages intrinsic interoperability
37
SOA promotes federation
38
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.
39
SOA encourages intrinsic reusability
40
SOA emphasizes extensibility
• Extensible services can expand functionality with
minimal impact.
41
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
42
SOA implements layers of abstraction
• Application logic created with proprietary technology
can be abstracted through a dedicated service layer.
43
SOA promotes loose coupling throughout the enterprise
44
SOA promotes organizational agility
45
SOA general definition
• SOA is a form of technology architecture that adheres to the principles of service-orientation.
• 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.
46
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.
47
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.
48
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.
49
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.
50
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.
51
Distributed systems with different owners
52
Distributed systems are heterogeneous
53
Common misperceptions about SOA
54
• An application that uses Web services is service-oriented – you need to standardize how Web services are
positioned and designed, according to service-orientation 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
55
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
56
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
57
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 service-
orientation.
• A transition plan is the best weapon against the obstacles that tend to
face organizations when migrating toward SOA.
• 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 service-
orientation.
• A transition plan is the best weapon against the obstacles that tend to
face organizations when migrating toward SOA.
58
Part II - The evolution Part II - The evolution of SOAof SOA
Part II - The evolution Part II - The evolution of SOAof SOA
59
XML: brief history• Like HTML, the Extensible Markup Language (XML)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 XML Schema Definition Language (XSD) and XSL Transformation Language (XSLT)Transformation Language (XSLT) were both authored using XML. (These specifications, in fact, have become key parts of the core XML technology set)
60
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.
61
• This ultimately led to the idea of creating a pure, Web-
based, 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
Web Services:a brief history (II)
62
• 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.
Web Services:a brief history (III)
63
• 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.
Web Services:a brief history (IV)
64
Early incarnation of SOA: architecture modeled around three
basic components
65
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.
66
Comparision of Standards Organizations
67
Reading: compare SOA to past architectures
• SOA vs. client-server architecture • SOA vs. distributed Internet architecture • SOA vs. hybrid Web service architecture
68
The Service-Oriented Enterprise
69
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.
70
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.
71
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
72
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.
73
74
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
75
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.
76
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.
77
• 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