Transcript Service-Oriented Architecture

Rachel Sims
Terminology
Service-oriented architecture
(SOA)
Service
Service wrapper
Service orchestration
2
What is SOA?
Packaging software assets in a way
that lets you use it, reuse it, and
keep on reusing it.
“A collection of services, which
communication with each other,
involving either simple data
passing or involving two or more
services coordinating some
activity”
Web Services and Service-Oriented Architecture (19)
3
SOA
Application
frontend
Service
Service
repository
Contract
Implementation
Interface
Business logic
Service bus
Data
4
What is a service?
A package, usually consisting of
information and a set of
operations for managing this
information
* The purpose is to have a single
implementation with a single set of
interfaces
5
What is service orchestration?
Deciding when and how each service
is employed
Succeeding With SOA (41)
6
What defines a good service?
—“Allows the service
implementation and the service
consumer to evolve independently,
each without affecting the other”
—“avoids additional
development work when you need a
new access to the service”
Succeeding With SOA (41)
7
Achieving Stability and Accessibility
1. Functional stability
2. Event support
3. Universal Accessibility
4. Flexibility in implementation
technology
5. Location transparency
6. Independent access control
7. Standardized message content and
structure
8
1. Functional Stability
Functionality must be relatively
stable
Modification of existing
functionality should be avoided
Eventual disruptive changed should
be planned for
9
2. Event Support
Your service infrastructure should
be able to support interaction
styles
 Synchronous request-reply
 Asynchronous request-reply
10
3. Universal Accessibility
Services should be provided using an
access technology that is available
in all environments
 A universally accessible
communications transport
 A platform-independent content
representation technology
* Minimize the technologies in use
11
4. Flexibility in Implementation Technology
When interfaces are written using
technologies that are not
universally accessible:
 The application must be modified to
use the service access
technologies, or
 A service wrapper must be
introduced as an intermediary
component
12
5. Location Transparency
In order to direct a service
request, the service consumer must
know the physical location of the
service provider
Because of this instability, it is
common for communications to be
directed indirectly to an abstract
destination
13
6. Independent Access Control
Access to service information and
operations must be controlled
 Authentication validates that the
credentials are legitimate
 Authorization will only allow
access to those with proper
credentials
 Sensitive information is generally
encrypted upon sending
14
7. Standardized Message Content and Structure
The separation of directly related
information and auxiliary
information should be
standardized using the W3C SOAP
Envelope


—operation-specific
information
—auxiliary information
15
Paralysis
Ability to Deliver
Transitioning to SOA
Pre-SOA
Green field
Transition
Agony
SOA
Renovation
Agony V. Agility
Enterprise SOA (89)
16
SOA’s Evolutionary Approach
any change
—take great care in
—take adjustments
into consideration
—convince
decision makers to support your
endeavors
—more functionality means
more cross-dependencies
17
HTTP
HyperText Transfer Protocol
“the address”
The standard for addressing web
pages
Identifies a web service
18
XML
eXtensible Markup Language
“for decoding messages”
An agreed-upon standard used by many
different industries
The IT industry invented it to make it
possible for programs to talk to
programs
Was designed to be extensible to
support new additional tags
19
XML
Example
<Hint>
<To> You, dear reader </To>
<From> The authors </From>
<Heading>USEFUL HINT</Heading>
<Hint_Text> It helps to remember that XML has no
fixed tags. But you can invent all the ones you
need. That’s why people say it is extensible. And
they are correct.
</Hint_Text>
</Hint>
Service Oriented Architecture for Dummies, 2nd Edition (119)
20
SOAP
Simple Object Access Protocol
“for writing messages”
A message has up to 4 components:
 The envelope
 The header
 The body
 The fault
21
SOAP
High-Level View of Structure
SOAP envelope
Header
Body
WSDL
XML or other format
HTTP or other protocol
Web Services and Service-Oriented Architectures (206)
22
WSDL
Web Services Description Language
“for describing interfaces”
Creates XML documents that describe a Web Service
and how to access it
Divided into 4 parts:
 Definition of ports
 Definition of messages
 Definition of types
 Definition of binding
23
WSDL
Web Services Description Language
Four types of operations:

—messages sent without a
reply required

—the sender sends a
message and the receiver sends a reply

response
—A request for a

—messages sent to
multiple receivers
24
UDDI
Universal Description, Discovery, and Integration
“for finding services”
Describes, discovers, and integrates
services via the Internet
Consists of three directories
 UDDI white pages
 UDDI yellow pages
 UDDI green pages
25
REST
REpresentational State Transfer
“to transfer data over the web”
Transfers data over HTTP without
having to use a messaging layer
like SOAP or use HTTP cookies
Makes interactions from a browser
to a website stateless to restore
a connection to the same state it
was in when it broke
26
Benefits of SOA
Reuse
Feedback at
different
levels
Risk
mitigation
Evolutionary
approach
SOA
Agility
Cost savings
Enterprise SOA (240)
More efficient
development
process
Adequate
business
infrastructure
27
Benefits of SOA
Liberates business from the
constraints of technology
Eliminates redundancy, giving the
benefits of scalability,
consistency, and maintainability
Makes a business more flexible and
reuses the best of its software
assets
28
Motivation and Benefits
for Software Developers
Benefits
Challenges
More Attractive Jobs
An SOA allows the developer to
focus on more interesting tasks.
Respect Service Interfaces
Developers have to adopt a serviceoriented approach. Service
interfaces must be respected. This
in turn requires a clear specification
before coding.
Reduction of Dependency
An SOA reduces dependencies.
Within a single service, developers
can change implementations
without affecting external
functionality.
Rapid Prototyping
Once a substantial number of
services are available, developers
can easily test approaches.
Better Defined Requirements
The interface driven SOA-based
development process provides the
developers with better-defined
requirements.
Simplified Testing
Decoupling and service interfaces
simplify distributed testing.
Processes
Developers have to accept rigid
processes.
Shared Responsibility
In particular for well-established
developers it might be a major
change in responsibility for an
application because it must be
shared between different
development teams.
Learning New Skills
Developers have to learn new skills
regarding the specifics of SOAs.
This includes, for example, the
handling of distributed transactions
or the assignment of the ownership
of data.
Enterprise SOA (254)
29
References
 Barry, D. K. (2003). Web Services and Service-
Oriented Architectures: The Savvy Manager's
Guide. San Francisco: Morgan Kaufmann
Publishers.
 Brown, P. C. (2007). Succeeding With SOA:
Realizing Business Value Through Total
Architecture. Upper Saddle River, NJ:
Addison-Wesley.
 Hurwitz, J., Bloor, R., Kaufman, M., & Halper, F.
(2009). Service Oriented Architecture for
Dummies. Indianapolis: Wiley Publishing, Inc.
 Krafzig, D., Banke, K., & Slama, D. (2005).
Enterprise SOA: Service-Oriented
Architecture Best Practices. Indianapolis:
Prentice Hall Professional Technical
Reference.
30