2. Disclaimer
The content of this presentation is not my own. The
presentation is an aggregation of content available on
the internet. Unfortunately I do not have the links to
provide references or pointers to the original authors.
3. Agenda
Why do we need another architecture?
Why are present day architectures inadequate?
What is Service Oriented Architecture (SOA)?
What constitutes a service?
So what is a service?
What are the elements of a SOA?
How do the SOA elements interact?
What are the different categories of a service?
Where do the services fit in our enterprise architecture?
Which business situations make good candidates for SOA
implementation?
What technologies do I use to implement SOA?
What does the SOA stack comprise of?
5. Pressures on the business…
Continuous business
transformation
EvolvingBusinessObjectives
ChangingMarkets
New Demands
Growth, profit,
and value
Leadership
Customer
satisfaction
Innovation
Technology
Regulation/
Deregulation
Mergers &
acquisitions
Economy
Competition
Satisfying Unpredictable Needs
CustomerSupplier Partner
Business agility
7. Application Architecture – Monolithic Applications
User Interface
Logic
Business Rules
Application Logic
Data Access
Logic
Data
Application
No Partitioning
Mainframe
Server
or
Deployment
Monolithic applications
• Applications where code implementing
business rules, data access, and user
interface are put together as part of a single,
large computer program
• Typically deployed on a single platform,
often a mainframe or midrange computer*
Limitations of monolithic applications:
• Applications are tightly coupled
• Software applications are difficult to understand and maintain
• Limited scope for code reuse
• Applications are inflexible for handling changing business requirements
8. Application Architecture – Client Server Applications
Client Server applications
• 2 tier applications with one tier containing
the graphical user interface (GUI) and
implementing the business rules. The
application’s data storage resides in the
second tier. The first tier executes on PCs
or workstations and requests data from the
second tier.
• Although the application has two tiers, most
of the code is contained in the tier executing
on the workstations, hence the name “fat
client”.
Limitations of Client Server applications:
• Lacks scalability
• As logic is located in the fat client layer, code reuse is difficult
9. Application Architecture – 3 Tier Applications
3 Tier applications
• 3 tier applications are partitioned into three
executable tiers of code: the user interface,
the business rules, and the data access
software.
• The 3 tiers need not reside on different
platforms. Often the business tier is
deployed on the same platform as the data
access tier or the user interface.
Limitations of 3 tier applications:
• 3 tier applications are developed using a silo based approach
10. Application Architecture – Distributed Components
Distributed Component based applications
• Distributed component oriented architecture
emphasizes on decomposition of
applications into functional or logical
components.
Limitations of distributed component oriented applications:
• Interoperability is difficult; heterogeneous components, firewall unfriendly
• Software applications are difficult to understand and maintain
• Components need to know platform, language specific implementation details for
integration
12. Existing IT architectures cannot support changing needs
Limited scaling capability
Agility
IT assets cannot be
easily repositioned in
response to changing
requirements
No solution for
efficient intra- and
inter-organization
information sharing
Decision cycles are
unnecessarily
lengthened by data
stovepipes
Process Heterogeneity
Systems,
organizations units
and network of
partners duplicate the
same work
Information stovepipes
require point-to-point
integrations that limit
flexibility and create
maintenance
overhead
More efforts spent
connecting systems
together than adding
mission critical
capabilities
Data Heterogeneity
Difficult to determine
“what data means”
fosters duplicate
applications and data
Inability of applications
to interoperate due to
platform
incompatibility. Data
used across an
organization is often
inconsistent and
potentially inaccurate
Costs
Duplicate data entry
and manual data
reunion require extra
man power
Point-to-point
integration shifts IT
professionals towards
repetitive employees
to time consuming
tasks
Integrating data
stovepipes is
expensive and
wasteful
Operations and
maintenance costs are
a rising percentage of
the budget
Limited agility, redundant processes , lack of system interactions, and high cost factor
14. What does your enterprise needs?
• Software that reflects the business need
• Promotes reusability
• Promotes integration
• Software which is agile to enterprise’s
changing business needs
“Software needs to be built to change and not built to last.”
16. What is SOA
• Service Oriented Architecture is an architectural style/pattern for creating and using business
processes as “services”.
• An approach for building distributed computing systems based on encapsulating business
functions as services that can be easily accessed in a loosely coupled fashion.
• Application’s business logic or individual functions are modularized and presented as services to
client/consumer applications
In essence…….
• A shift in focus away from “applications” towards business processes
• An architecture in which processes are constructed either in whole or in part by assembling
reusable services.
17. A Solution – Service Oriented Architecture
SOA is an approach
to organizing and
using IT to match
and combine needs
with capabilities in
support of the
overall mission of an
enterprise
Capabilities performed by one for
another to achieve a desired
outcome
Functionally aligning architecture
to enable a collection of
independent services to be linked
together to
solve a business problem
The fundamental organization of a
system embodied in its capabilities,
their interactions, and the
environment
Architecture
Oriented
Service
SOA - A
paradigm that
encourages
organizations to
re-think how their
IT capabilities
are organized
18. SOA: What it is not
“It is an approach for building agile and flexible business
applications.”
It’s not:
• Product
• A specific technology
• An application
• A specific standard
• A specific set of rules
20. Service and Service Scenario
Definition
A service is a self-sufficient unit of work representing a specific business function, accessible
through well defined interfaces, governed by a defined contract.
Service Scenario
To understand what a service means, let’s consider an example. A patient walks into a hospital
with an illness. The patient encounters the following actors: receptionist, doctor, technician,
nurse
Each of these actors is associated with some specific services.
The receptionist manages the patient’s files.
The doctor inspects the patient, recommends medical tests or formulates a
treatment plan.
The technician carries out medical tests e.g. pathology test or radiology test or
lab test.
The nurse takes care of the patient and ensures their adherence to the specified
drug treatment.
Each of these actors typically use independent/coordinated IT applications to
record patient related information.
22. The previous slide takes a simplistic view of the hospital functioning. The
actual functioning may involve number of different departments such:
Insurance Company – claim
Accounts – patient billing
Medical Exam Agencies – lab, pathology etc
Other hospitals – specialized care
It is critical that data flows between these agencies smoothly and in a real
time fashion to ensure best possible patient care.
Service - continued
24. Here’s how the patient care example translates into services. The green globes
represent business functions exposed as “services”.
Service – Drill Down
HIS Lab
Information
Systems
Patient visits the hospital
Receptionist creates/updates the patient file, fixes an appointment with doctor
Create/Update
Patient File
Fix Doctor
Appointment
The doctor examines the patient, prepares an inspection report, or suggests lab
examination
Physical
Examination
Report
Request
Lab Exam
Patient visits the doctor
Patient visits the laboratory
The lab technician takes sample, conducts tests and prepares reports
Prepare
Lab Report
The doctor examines the lab reports, makes a diagnosis and suggests treatment
Prepare
Diagnosis
Prepare
Treatment
Accounting
The Hospital reconciles with insurance company and conveys billing information to
accounting which creates billing notice
Billing
Info Update
25. Service - Continued
So how have we benefited?
• Closely related business functionality continues to remain as a part of single business application i.e. for
e.g. Hospital Information System, Lab Information System, Billing
• Enterprise data is shared across various silos like hospital, lab, accounting etc.
• Key participants like the doctor is presented with a unified view of patient data, in turn providing best
possible patient care.
Limitations of implementing the hospital IT as a monolithic system:
• Extremely rigid application with all business functions in single application
• Limited scope for code reuse
• Implementation of business change would be effort intensive
Limitations of implementing the hospital IT as a client server system:
• No scope for integrating with external systems
Limitations of implementing the hospital IT as a n tier system:
• External systems can be integrated using point-to-point connectivity
• Code reuse limited to the application
• Separate application silos for hospital admin, lab admin and accounting would be created.
27. What is a Service?
• Loosely coupled, autonomous, reusable, and have well-defined, platform-
independent interfaces
• Provides access to data, business processes and infrastructure, ideally in an
asynchronous manner
• Receives requests from any source making no assumptions as to the functional
correctness of an incoming request
• Each request encompasses a complete and independent unit of work
• Each request leaves the system in a long-term steady state
• Can be written today without knowing how it will be used in the future
• May stand on its own or be part of a larger set of functions that constitute a larger
service
• Provides for a network discoverable and accessible interface
• Keeps units of work together that change together (high coupling)
• Builds separation between independent units (low coupling)
28. A Service….
• It has an interface and contract
• It can have one or more operations (methods to do something)
• Each business capability is invoked by messaging
• The messages into the service request business operations
• The semantics of the operations are around business functions
Service
Service
Logic Data
29. Service Contract
A service contract defines everything needed to interact with the service
and nothing more
Service
Consumer
Service
Provide
r
Contract
31. Service Interface
Service interface specifies operations, messages, transports, and location.
The interface definition can be in:
WSDL (Web Service Description Language)
XML Schemas
Proxies generated from Service Implementation
A formal hardcopy specification
e.g. A credit card service may define the following service
interface:
Operation name: processTransaction
Input Message: CreditCard data structure
debitAmount
Output Message: TransactionResponse
data structure containing transactionID, errorCode etc
URL: http://visa.com/creditcard/inputTx
Interface:
• Cust_Name
• CC#
• Expiration_Date
• PIN#
32. Service Description
Service description
sequencing requirements
exception handling
formal documentation and implied semantics
e.g. Sequencing requirements -
A third party service provider provides three separate interfaces, one for getting
requestid, second for sending the request and the last one for receiving the
response.
Exception handling -
In case of credit card service, failures will be communicated in
the form of error codes. For example
10502 – Credit Card used has expired
10545 – Credit Card declined because of possible fraudulent activity
10610 – Amount limit exceeded
The consumer will find documentation regarding the error codes in the
service description.
33. Service Level Agreement
A service-level agreement (SLA) is a formal contract between a service provider and a
consumer guaranteeing quantifiable performance at defined levels.
Service providers use SLAs to:
• Distinguish themselves from their competitors
• Guarantee the services it provides will be available for a certain percentage of time (for
example, 99.9%)
• Impose limits on maximum, average response times, service downtime within a
timeframe
• Provide an exit clause for the consumer in case of unsatisfactory services.
34. Service Level Agreement Categories
Functionality • Values/functions provided – e.g. “regular fund price”
• Service Interface – WSDL, non-WSDL SOAP, IDL, JMS etc
• Version compatibility – interface/function compatibility, version control policy
and procedures
Operational
aspects
• Service availability – “24/7/365” or “on schedule” with downtime
• Service cost – if any for consumer or license model etc
• Service Change Control protocol – how a new version of the service is made
available with and without backward compatibility
Quality Of
Services
• Conditional performance expectations
• Scalability – horizontal / vertical
• Failover, execution exception handling protocol and alerts
• Business Process Exceptions – Legitimate technical results that are
considered abnormal/exceptional
• Expected response time
• Throughput
Quality of Data • Returned data – a list of data items
• Metadata round returned data – format definition for all scenarios, validity of data
Service
Constraints
• Security policies – for users and other services
• Country/industry policies – regulation of information encryption algorithms
• Pre-known conditions – like delivery schedule, pick hours
• Service priority – may be different for different customer status
36. SOA Model Elements
Service Provider - provides a service interface for a software asset that
manages a specific set of tasks
Service Requester/Consumer - discovers and invokes other software
services to provide a business solution
Service Directory/Broker - acts as a repository, yellow pages or clearing
house for software interfaces that are published by service providers
Loosely coupled components communicating via well defined interfaces
Bind /
Invoke
Service
Consumer
Service
Provide
r
Service
Director
y
Find /
Details Publish
Contract
Contract
SOA
Infrastructure
37. Service Requester/Consumer
The service consumer is an application, service or any other type of
software module that requires a service.
It is the entity that initiates the locating of the service in the registry,
binding the service over transport and executing the service function.
Bind /
Invoke
Service
Consumer
Service
Provide
r
Service
Director
y
Find /
Details Publish
Contract
Contract
SOA
Infrastructure
38. Service Provider
Service provider is the service, network-addressable entity that
accepts and executes from consumers.
Independent software vendors are prime examples of potential
service providers.
e.g. – MIB, Amazon.com
Processes that are proven and generalized for a diverse set of
applications would be good candidates for service providers.
e.g. individual risk assessment in insurance industry
Bind /
Invoke
Service
Consumer
Service
Provide
r
Service
Director
y
Find /
Details Publish
Contract
Contract
SOA
Infrastructure
39. Service Broker / Directory
Service broker is an entity that collects and catalogs data about other
entity and further on providing data to others
Essentially is a repository of service contracts
Provides a facility for discovering services
May contain additional information such as:
o Contact Information
o Usage fees
May be formal or informal
o UDDI
o Centralized Web site
o A proprietary database of XML
schemas
o Printed documents
Scoped to application, department, enterprise, extended enterprise
May be formally managed by a corporate architecture group
Bind /
Invoke
Service
Consumer
Service
Provide
r
Service
Directory
Find /
Details Publish
Contract
Contract
SOA
Infrastructure
41. Service Elements
Presentation layer or
another service
Locates service provider
through agreed upon
service directory
Binds/invokes service
based service interface
Only the service
interfaces are exposed
Service implementation
is hidden from the
service consumer
Data store
encapsulated by
service
Service Interface
Fn()
Service Implementation
Service
Consumer
Service
Provider
Fn()
Data
Service
Logic
42. What are the different categories
of a service?
SOA?
Whoa!
43. SOA Service Types
SOA based services can be broadly classified under three categories
Basic Services
Intermediary Services
Business Process Services
44. Basic Services
A stateless service oriented software function
Strictly, acts as a service provider
Encapsulates all access to a particular data source
46. Intermediary Services
A stateless service which is both a provider and a consumer
Includes business and infrastructure types
Technology gateways
Bridge gap between two technologies
Transformation
Convert message format from/to what service consumer and provider expect
e.g. www.pricegrabber.com
Facades
Aggregated, simplified view of multiple services e.g. the underlying
implementation of orderProduct service does inventory check and handles
product shipping
Functionality-adding services
Add functionality to a service without changing the service itself
48. Business Process Services
Encapsulates an enterprise’s business process
Acts as both a service provider and a service consumer
Tends to be application specific
53. Multi level SOA
Online Ordering
Application
Order
Management
Customer
Management
Inventory
Management
Basic
Service
Layer
Application
Client
Layer
Order and Ship
Intermediate
Service
Layer
56. Services fitment in an enterprise application
The services become a part of the business layer of the enterprise application
Presentation Layer/s Integration Layer/s
Data Access Layers
Managed Unmanaged
Users
Enterprise
Services
Service Interface
Business
Workflows
Business
Tasks
Business
Entities
Service Adapter
Business
Process
Service
Basic and
Intermediary
Service
58. Shift towards SOA
• Function oriented
• Build to last
• Long development cycles
• Process oriented
• Build to change
• Incrementally built
and deployed
• Application silos
• Tightly coupled
• Object oriented
• Known implementation
• Orchestrated solutions
• Loosely coupled
• Message oriented
• Abstraction
Service5 Service6 Service9
Service1 Service2 Service3
Bus
59. SOA – A word of caution
• Tools and technologies will not automatically give you SOA
• SOA without good data is doomed to failure
• SOA without governance will NOT realize full value
• Do not rush to deploy technology solutions
• Do not ignore master data, data quality and
security issues
• Do not underestimate the cultural issues
surrounding change
60. SOA Candidate Business Scenarios
Which business situations
make good candidates for
SOA implementation?
?
?
?
61. SOA Candidate Business Scenarios
Business Collaboration - Efficiency of working with business partners
Integration
Merger & Acquisitions
Agility to handle market change
Reuse business functionality beyond business application
62. SOA Candidate Business Scenarios – Business Collaboration
Order Mgmt Service
Approve
FulfillOrder
Valid Order
Supplier Service
Check Credit
Hold Stock
Valid Order?
Online Ordering
Service
Req. Order
Notify Buyer
OrderEntry
Inventory Mgmt
Service
Hold
Ship
Lookup
Credit Services
Approve
Notify
Chk Credit
SOA - A sea of services
63. And what happens
when the
organization
makes a strategic
acquisition in
Germany?
SOA Enables System Integration
Oracle
HR
Online
Recruiting
Success
Factors
Performance
Assessment
Equity
Edge
Stock Plan
Admin
Online
Benefits
SOA
Germany
HR
?
?
?
?
SOA Enabled IT Systems:
• Agile – Rapidly meet business needs
• Reusable – Leverage existing solutions
• Standardized – Meets cross-functional
challenges
Why not skip the middle-man?
You could…
but significant IT systems are rarely that simple…
The plot thickens…
Direct point to point
becomes a complex web of connections
each requiring custom maintenance…
The SOA Solution
ADP
Payroll
Why SOA? – Why not Point-to-Point?SOA Is Inevitable
64. Business Agility
Division
Let’s take an example of company and its Order-to-Cash process. The
Order-to-Cash process within itself has multiple business functions like
marketing and catalog management, order entry, inventory management,
fulfillment and delivery logistics, accounting and receivables,
reconciliations etc
Initially all these business functions had been taken care of internally.
This has changed.
65. Business Agility
With the emergence of internet, customers can now access the company’s web site to
submit orders.
So a part of the business process has moved to the customer, it may be thru a web
interface or in case of B2B type interactions via a web service.
Change 1: Customer Order Entry
Division
Customer
66. Business Agility
Many companies are finding out that different parts of their business do the same thing.
Thus, the company loses on providing a consolidated customer experience and also to
high maintenance costs for maintaining different business applications doing the same
thing.
It pays to consolidate these commonalities as shared services within the company.
Examples of shared services are:
Marketing – Email generation with consistent branding
Billing – Common billing, often consolidated billing
Receivables – common credit status, collection processes etc
Change 2: Shared Service – Marketing, Billing, Receivables
Division
Customer
Shared
Service
67. Business Agility
Today organizations are looking for ways to minimize or eliminate inventory. Some
companies allow their supplier to take care of inventory management, a cost effective
solution vis-à-vis building and maintaining internal inventory management applications.
Change 3: Supplier handles inventory
Division
Customer
Shared
Service
Supplier
68. Business Agility
Organizations today utilize efficient shipping services of vendors specialized in shipping
and logistics. The organization’s business connects and uses the shipping services of
the shipping company.
Change 4: Order shipping by DHL, FedEx or UPS
Supplier
Division
Customer
Shared
Service
Supplier
Outsourced
69. Business Agility
For functions which are not strategic differentiators and which others do better,
organizations outsource those business functions. For example, an organization can
outsource its overdue payments handling to an external collections agency.
Change 5: Outsourcing
Outsourced
Division
Customer
Shared
Service
Supplier
70. Business Agility
Through analytics, bottlenecks or deficiencies in in-house processes can be identified
and ironed out. Areas of high costs, improvement or automation can be focused on and
removed. For example, for a high value customer with a collection issue, the
organization may decide to handle the situation on its own instead of using a collection
agency.
Change 6: Process Optimization
Outsourced
Division
Customer
Shared
Service
Supplier
72. SOA Infrastructure
Service Service Service
Service Service
AppServer (JEE / .NET)
CORBA
JMS
FTP
Web Services
SOA Infrastructure can be implemented using plethora of technologies.
Web Services just happens to be a popular option.
74. SOA enabling technologies – Web Services
XML
XML is a markup language for documents
containing structured information.
SOAP
SOAP is a XML based lightweight protocol for
exchange of information
WSDL
The Web Services Description Language is an
XML vocabulary that provides a standard way
of describing services
UDDI
The Universal Description, Discovery and
Integration specification provides a common
set of SOAP APIs that enable implementation
of a service broker
Web Services technology stack comprises the following:
75. Our Architecture in the EAI days
CRM ERP
PARTNER
SYSTEMS
FINANCE
ORDER
ENTRY
Let’s expose the application interfaces as Web Services.
76. Web Services
This has provided the following
benefits:
• Well defined service interface
promotes reuse
• XML-based data easily exchanged
• Designed for remote access, across
heterogeneous platforms
OpenEdge
Application
WEB
SERVICE
Implementation of the application interfaces as Web services, standardizes the interfaces.
TCP/IP
WEB SERVICES
INTERFACE
.NET™
APPLICATION
PACKAGED
APPLICATION
& LEGACY
SYSTEMS
J2EE™
APPLICATION
XML
XML
77. Web Services
• Is it more agile?
• Is it reliable, scalable and secure?
• Can it be managed and monitored?
J2EE™
APPLICATION
PACKAGED
APPLICATION
& LEGACY
SYSTEMS
.NET™
APPLICATION
OpenEdge
Application
WEB
SERVICE
WEB SERVICES
INTERFACE
But Have We Solved The Whole Problem?
Web services are interoperable
communications stacks but don’t offer
key capabilities like routing, service
deployment, management, format
transformation, and guaranteed
delivery.
TCP/IP
78. Web Services
The solution retains certain
drawbacks:
• Tight coupling
• Little flexibility / agility
• No service level monitoring capability
J2EE™
APPLICATION
PACKAGED
APPLICATION
& LEGACY
SYSTEMS
.NET™
APPLICATION
OpenEdge
Application
WEB
SERVICE
WEB SERVICES
INTERFACE
Web services has just addressed part of the problem. It has achieved
interoperability by standardizing the application interfaces.
TCP/IP
Clearly, implementing only web services
is not enough.
80. SOA Infrastructure Stack
The SOA infrastructure stack is sub-divided into the following distinct layers:
• Service enablement layer
Business functionality within applications are modularized and exposed as
standard interfaces
• Service orchestration layer
The orchestration layer provides transformation, availability, routing of
services exposed at the service-enablement layer and orchestrating
individual services into business services. The registry/repository is an
essential component of this layer.
• Process orchestration layer
Business process management and business activity monitoring is part of
process orchestration layer. This layer provides support for business
processes built on the business services integrated in the service
Orchestration layer.
81. SOA Infrastructure Stack
The likely candidates for the SOA infrastructure stack implementation are
mentioned below:
• Service enablement layer
Web Services
EJB
JMS
• Service orchestration layer
Enterprise Service Bus (ESB) products like Cape Clear ESB, IBM ESB,
TIBCO Business Works etc
• Process orchestration layer
BPM products like IBM Process server, Pegasystems, Savvion, Global 360
Service Enablement
Service Orchestration
Process Orchestration
Web Services, EJB, JMS
ESB
BPM
Infrastructure Layer Implementation product/Std
82. Enterprise Service Bus
ENTERPRISE SERVICE
BUS
J2EE™
SERVICE
LEGACY
SYSTEMS
.NET™
SERVICE
OPENEDGE
SERVICE
WEB
SERVICE
Integrated Set of SOA Services Based on a Common SOA Infrastructure Backbone
ESB Features:
• Data transformation
• Protocol transformation
• Content-based routing
• Service Registry
• Logging
• Persistence
• Specialized Adapters
• Orchestration Server
• Asynchronous and synchronous
messaging
• Security
• Transaction Management
• Performance, scalability & fault
tolerance
83. Business Process Management
BPM is a set of integrated management and analytic processes, supported by
technology, that addresses business and operational activities.
BPM is an enabler for businesses in defining strategic goals, and then measuring and
managing performance against these goals.
Core BPM processes include financial and operational planning, consolidation and
reporting, modeling, analysis, and monitoring of key performance indicators (KPIs)
linked to organizational strategy
BPM Features:
• Business Process Modeling
• Business Process Execution
• Process Monitoring
• Process Optimization
• Content Management
• Human Tasks
84. SOA Benefits
Loose coupling among interacting software agents
A mechanism for integrating software components on dissimilar
platforms
Supports non-intrusive reuse of software components in ways not
specifically predicted during development
Can enable easier in-house/outsourced development by breaking
systems down into smaller into smaller chunks
Interoperability
Separation of developer concerns - Clean separation of business
logic from presentation and resource connectivity, allows for maximum
developer productivity
Increase Code Reuse – Since services do not contain presentation or
data access code, the same service can be easily reused in another
application that needs the same business logic
Maximize flexibility – With SOA, the different core components of the
application are very loosely coupled.
85. Service Oriented Architecture Benefits Summary
Agility
Focus more on core
competencies
Creates a network of
service requesters
(consumers) and service
providers (producers)
Enable enterprises to be
more agile and respond
quickly to changing
requirements
Increase business
flexibility through plug-
and-play architecture and
re-use of existing services
Process Heterogeneity
Allow interoperation
with other systems
without time consuming
customization and
point-to-point
integration
Ensure system change is
not a constraint on
business or mission
change
Facilitate integration
with multiple solutions
via open IT standards
Data Heterogeneity
Improve semantics of
data exchanged during
business process
execution
Maintain consistency of
data across different
systems
Remain platform,
language, and vendor
independent to remove
IT barriers for using
best-of-breed software
packages
Costs
Leverage existing IT
infrastructure
Reduce costs of
development of new
functionalities by
acquiring pre-built
components/services
Lower maintenance
costs
SOA allows to align IT with mission of the organization
Better agility, no redundancy, system interactions, and reduces overall costs of system maintenance
86. SOA – The road ahead
SOA is a continuing
journey and not a
destination.
88. SOA Standards
Web Services protocols and specifications have grown in number and
complexity over the last decade.
Here we intend to provide an high level overview of some of the
important specifications.
90. The WS Alphabet Soup
XML
Messaging Metadata
TransactionsSecurity Reliability
Business Process Orchestration
Transport
The Fundamentals
- XML - SOAP
- XSD - WSDL
- JMS - WS-Addressing
- HTTP - WS-Policy
92. Fundamentals – Transport
HTTP is the most widely used protocol for internet
communications.
Intra-enterprise is a mix of protocols beyond HTTP like
Message Oriented Middleware (MOM) provider
specific protocol
SMTP
FTP
93. Fundamentals XML – The Data Format
XML
Provides a neutral representation of data
Supported across all platforms and programming environments
XML Schema
Syntax and structural rules
Object oriented language with rich extensibility
94. Fundamentals – Messaging - SOAP
SOAP
Enveloping structure to identify header and body contents
A SOAP message is an ordinary XML document containing the following elements:
- A required Envelope element that identifies the XML document as a SOAP message
- An optional Header element which contains header information
- A required Body element that contains call and response information
- An optional Fault element that provides information about errors that during message
processing.
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header> ... ...
</soap:Header>
<soap:Body> ... ...
<soap:Fault> ... ...
</soap:Fault>
</soap:Body>
</soap:Envelope>
95. Fundamentals – Messaging – WS-Addressing
Existing IT technologies provide addressing capabilities as a part of their solutions, typically
as a part of the transport layer.
For example, if HTTP is used as the transport layer, the HTTP header holds the address
information in the HTTP method and host fields.
This makes addressing transport layer specific.
Web Services are meant to be transport layer agnostic and can be implemented using any
execution environment. Therefore there is a need for an independent addressing mechanism.
WS-Addressing specification is a specification of transport-neutral mechanisms that allow
web services to communicate addressing information.
It essentially consists of two parts: a structure for communicating a reference to a Web
service endpoint, and a set of Message Addressing Properties which associate addressing
information with a particular message.
Instead of relying on network-level transport to convey routing information, a message
utilizing WS-Addressing may contain its own dispatch metadata in a standardized SOAP
header.
The network-level transport is only responsible for delivering that message to a dispatcher
capable of reading the WS-Addressing metadata. Once that message arrives at the
dispatcher specified in the URI, the job of the network-level transport is done.
WS-Addressing aims to make Web Services support:
- A wide range of transport protocols
- Asynchronous communication
- Dynamic end point addressing
96. Fundamentals – Messaging – WS-Addressing - Contd
Classical SOAP example to execute Stock Price Web Service :
The type of the
message being
conveyed is SOAP
Host URI
SOAP Action
!!! SOAP Message is dependent on the transport protocol !!!
97. Fundamentals – Messaging – WS-Addressing - Contd
To make SOAP transport protocol neutral use <To> and <Action>
tags…
WS-Addressing also adds ability to make Web Services asynchronous…
98. Fundamentals – Messaging – WS-Addressing - contd
current message has id “uuid:someid”
and it is related with another message
that has id “uuid:someotherid” and the
type of the relationship is “Reply”
The address of the sender of the
message, the addresses for return
reply or fault messages are given
99. Fundamentals – Messaging – Attachments & MTOM
SOAP With Attachments
- method used by Web Services to send and receive files using a combination of SOAP and
MIME, primarily over HTTP
MTOM (Message Transmission Optimization Mechanism)
- a method of efficiently sending binary data to and from web services. It uses XOP (XML-
binary Optimized Packaging) to transmit data and will replace MIME and DIME attachments.
- MTOM allows for more efficient sending of binary data in a SOAP request or response.
100. The fundamentals – Metadata - WSDL
Web Service Description Language
Define the logical interface of a service in
terms of messages and operations
Message style and encoding formats:
doc/literal or rpc/encoded
Specifies endpoint addresses
Port
Service
Binding
Data Type
Part
Message
Operation
PortType
WSDL
Logical
Contract
Physical
Contract
101. Components
Types
XML representations of the types (typically XML Schema language)
e.g. searchRetrieveRequestType
Messages
XML messages built from types passed from client to server and server to
client
e.g. searchRetrieveRequest, searchRetrieveResponse
portTypes
Which messages are sent in which direction, and what the response is
e.g. searchRetrieveRequest is sent client to server, and a
searchRetrieveResponse sent back
Bindings
How to encode (e.g. SOAP document/literal)
How to transport (e.g. HTTP, SMTP)
Services
Endpoint
e.g. http://voyager.loc.gov:7090/
WSDL Components
102. The Main Structure of WSDL
<definition namespace = “http/… “>
<type> xschema types </type>
<message> … </message>
<port> a set of operations </port>
<binding> communication protocols </binding>
<service> a list of binding and ports </service>
<definition>
103. Types
• <types> define types used in message declaration
• XML Schema, DTD, and etc.
• XML Schema must be supported by any vendor of
WSDL conformant products.
105. WSDL Messages
• The <message> element defines the data elements of an operation.
• Each messages can consist of one or more parts. The parts can be
compared to the parameters of a function call in a traditional programming
language.
107. WSDL Ports
• The <portType> element is the most important WSDL element.
• It defines a web service, the operations that can be performed, and the
messages that are involved.
• The <port> defines the connection point to a web service, an instance of
<portType>.
• It can be compared to a function library (or a module, or a class) in a
traditional programming language. Each operation can be compared to a
function in a traditional programming language.
109. Operation Types
• The request-response type is the most common operation
type, but WSDL defines four types:
• One-way: The operation can receive a message but will not
return a response
• Request-response:The operation can receive a request and
will return a response
• Solicit-response:The operation can send a request and will
wait for a response
• Notification:The operation can send a message but will not
wait for a response
• -- v 1.2 addition
request – multiple response …
110. One way and Notification Example<portType name=“RegisterPort">
<operation name=“register">
<input name=“customerInfo" message=“RegInfo"/>
</operation>
<operation name = “register Response”>
<output name = “response” message=“ResponseInfo”/>
</operation>
</portType >
114. The fundamentals – Metadata - UDDI
Universal Description Discovery & Integration
A catalog of services – think LDAP for Web Services
Browsing and querying interfaces
Synchronization between registries
Subscriptions to change notifications
Marketplace
Search Portal
Marketplace
Marketplace
Search Portal
Search Portal
UDDI Registries & Protocol
Technical Users
Business
Users
Advanced Discovery via Portals & Marketplaces
115. The fundamentals – Metadata – WS-Policy
To use a web service a client needs more information than what is provided in
WSDL. For example,
- Does the web service support WS-Security? If so,
- What is the encryption algorithm the web service expects or prefers?
- Must messages be signed?
- What character encoding is used?
- What version of SOAP is supported?
WS-Policy is a specification that allows web services to advertise their policies (on
security, Quality Of Service, etc).
WS-Policy provides a flexible and extensible grammar for expressing the
capabilities, requirements and general characteristics of web services.
116. WS Alphabet Soup - continued
XML
Messaging Metadata
TransactionsSecurity Reliability
Business Process Orchestration
Transport
The Qualities of Service
- WS-Security - WS-Coordination
- WS-ReliableMessaging - WS-SecureConversation
- WS-AtomicTransaction - WS-Trust
- WS-BusinessActivity - WS-Federation
118. WS-Security
WS-Security specification defines a set of mechanisms to assist in securing SOAP
message exchanges.
The specification provides for Quality Of Protection for the SOAP message in the
following aspects:
- Message integrity => message is not tampered in transit
- Message Confidentiality => message is unreadable for everyone except the recipient
- Single Message Authentication => You are who you said you are
- Provide end to end message security
120. WS-Security-contd
The business needs to prove its identity to the credit report company and the bank
(authentication)
The credit report company needs to know that their paying customer won’t back out
maliciously after sending the request (non repudiation)
The credit report company needs to prove it supplied the credit score itself
(authentication)
All the message content needs to reach its various destinations unchanged (integrity)
and be safe from competitors’ eyes (confidentiality)
The bank needs to record the receipt of the application (auditing)
121. WS-Security-contd
Security Requirements WS-Security Implementation
techniques / technologies
Authentication SecurityToken – UserName,
Binary, XML
Non-repudiation, integrity XML Digital Signature
Confidentiality XML Encryption
Auditing WS-Security defines a
<Timestamp> element
124. WS-Trust
Motivation- A SOAP Message protected using WS-Security presents the following
possible issues with regards security token
- Security token incompatibility
- Security token trust
- Namespace differences
WS-Trust defines standard interfaces for
- Security token creation, management and exchange
- Dissemination of credentials within different trust domains
Specific purpose of WS-Trust is to provide:
- Methods for issuing and exchanging security tokens
- Ways to establish and access the presence of trust relationships
125. WS-Trust-Use Case 1 contd
In complex Web service architectures, it can be cumbersome and error-prone to require
that all services directly trust all possible clients.
Web services can be more flexible and manageable by designating a separate
authentication service. The separate authentication service can exchange or issue
tokens to consumers of a service or validate tokens for the service itself.
126. WS-Trust-Use Case 2 contd
Client understands X.509 certificates
only
Service understands SAML only
No established trust between client
and service
127. WS-Trust-Use Case 2 contd
SOAP Client sends initial request to SOAP serviceSOAP gateway recognizes that it must map to SAML, so it contacts the Security
Token Service (STS)
STS sends back the token in requested formatThe gateway formats and sends the message to the service
128. Federation
Federation is a collection of realms/domains that have established trusts.
Federation is the technology and business arrangements necessary to
interconnect users, applications, and systems.
Federated systems can interoperate across organizational and technical
boundaries (i.e. various operating systems or security platforms)
129. Federation - Example
Account Number
and PIN
Home Bank Network
Visiting Bank Network
Funds Network of Trust
Federated ATM Network
130. WS-Federation
The primary goal : “Single Sign On” access across trust domains using
identities from the different domains.
WS-Federation defines a model for this by building on the WS-* security
specifications:
Brokering trust
Sign out messages
Attribute service
Pseudonym service
Authorities
Security Token Service (STS) – Web service that issues security tokens;
makes assertions based on evidence that it trusts to whoever trusts it
Identity Provider (IP) – Entity that acts as an authentication service to end
requestors (an extension of a basic STS)
131. Trust Topologies
Federation approach must address different trust topologies:
Model existing business practices
Leverage existing infrastructure
Sample topologies
- Direct trust
- Exchange
- Validation
- Indirect trust
- Delegation
132. Direct Trust – Token Exchange
Trust
Get identity
token
Get access
token1
3
2
IP/STS IP/STS
Requestor
Resource
133. Direct Trust – Token Validation
Trust
Get identity
token
Get access
verification
1
2
3
IP/STS IP/STS
Requestor Resource
134. Indirect Trust
C trusts B which vouches for A who vouches for client
1
3
C
B
A
IP/STS
IP/STS
IP/STS
Requestor Resource
2
136. Attribute Service
Scenario: You ask a weather service for the current weather (or visit a
weather site); it provides a personalized response because it knows your zip
code
Why it worked:
- Policy indicated an attribute service
- Identity information was used to find zip code
- Weather service was authorized to access zip code
Specification defines the concept of an attribute service but not a specific
interface
137. Attribute Service - Example
Trust
1
3
2
4
Trust
Zip: 12309
FN: Fred
…
IP/STS IP/STS
Requestor Resource
Attribute
Service
138. Pseudonym Service
This service provides a mechanism for associating alternate identities
Pseudonym represents alternate identities
- Depends on scope of request
- Subject to authorization control
- Can be integrated with IP/STS
139. Pseudonym Service – Example 1
Trust
“Fred”
“A123@B456.com” “A123@B456.com”
“Freddo@F123.com”1
2
3
“A123@B456.com”
B456.com
IP
Requestor
Resource
B456.com
Pseudonym
Service
140. Pseudonym Service – Example 2
Trust
“Fred”
“B456@B456.com”
“B456@B456.com”
“Freddo@F123.com”
1
2
3
“B456@B456.com”
Requestor
Resource
4
B456.com
IP
B456.com
Pseudonym
Service
141. WS-Federation Features Summary
Cross-domain trust federation
Generic token acquisition
- Enables different trust topologies
Single Sign-on / Sign-off
Identity protection and privacy
- Attributes and pseudonyms
End-to-end security
- no HTTPs required
Integrates with existing infrastructures
- Business model, token format, attribute stores, directory services
Together with WS-* specifications, provides a rich fabric for building secure,
reliable, transacted systems across federation boundaries
142. WS-SecureConversation
Generally a single message is exchanged between the sender and receiver
in a web services interaction.
It is possible that the sender and receiver need to exchange multiple
messages.
WS-Security provides for only single message security.
WS-SecureConversation defines mechanisms to allow nodes
(sender/receiver) to exchange more than one message.
143. WS-SecureConversation
Participants establish a shared context (SecurityContextToken)
- Context contains keys and other information
- Has an identifier – used in subsequent messages
- Optionally has creation/expiry timestamps
Context can be established in a variety of ways
- Using WS-Trust
- Having one party create the context
- Through negotiation
145. WS-ReliableMessaging
Ws-ReliableMessaging specification defines a messaging protocol to identify,
track, and manage the reliable delivery of messages between two parties, a
source and a destination.
It is extensible and allows additional functionality such as security to be tightly
integrated. It can integrate with and complements the WS-Security, WS-
Policy and other Web Service specifications.
The WS-RM protocol defines and supports a number of delivery assurances:
- AtLeastOnce: Each message will be delivered at least once. Messages can
be delivered more than one. If message is not delivered, an
error is raised.
- AtMostOnce: Each message will be delivered at the most once. Messages
may not be delivered to destination, but destination will not
get duplicate messages.
- ExactlyOnce: Each message will be delivered to destination exactly once.
Destination will not get duplicate messages. If message is not
received, an error will be raised.
- InOrder: Messages will be delivered to the destination retaining the
order in which they were set by the sender.
149. WS-Coordination
WS-Coordination specification defines mechanisms for transactional interoperability
between web services domains and provides a means to compose transactional
quality of services into web services applications.
The framework defined in this specification enables an application service to create
a context needed to propagate an activity to other services. The specification
describes the definition of the structure of the context and the requirements for
propagating context between cooperating services.
A business process may encompass more than one web services. Interaction with
these services can be synchronous/asynchronous, short-lived/long-lived. The
transactional semantics in terms of ACID properties compliance would change
depending upon the type and duration of interaction with a web service.
Web Services standards have defined two different specifications based on the
coordination types (i.e. period of interaction between the participants):
- WS-AtomicTransaction (WS-AT): short duration, ACID transactions
- WS-BusinessActivity (WS-BA): longer running business transactions
150. WS-Coordination - contd
The coordination framework is supposed to provide the following services:
- Activation Service:
-- Activation Service creates the CoordinationContext that is used in the
subsequent stages
- Registration Service: used by the participants to register with the coordinator for a
given coordination protocol
- Coordination Protocol Service: Defines the coordination protocol used depending
upon the coordination type.
Each message sent by a participant contains CoordinationContext. It has a unique
identifier, pointer to participant’s registration service and coordination type.
151. WS-AtomicTransaction
WS-AtomicTransaction (WS-AT) specification defines the guidelines which allow multiple
web services to participate in an atomic transaction.
Web Services participating in WS-AT are
- Short duration interactions; executed within limited trust domains
- Satisfy ACID properties
WS-AT coordination protocols are:
- Completion: The completion protocol initiates the commit/abort processing.
- Two-Phase Commit (2PC): The 2PC protocol coordinates registered participants to
reach a commit or abort decision. The 2PC protocol has two variants
-- Volatile 2PC: Participants managing volatile resources such as cache etc
-- Durable 2PC: Participants managing durable resources such as database etc
Note a participant MAY register for more than one of these protocols
152. WS-AT Coordination Protocol – Completion Protocol
The Completion protocol is used by an application to tell the coordinator to either try to
commit or abort an Atomic Transaction. After the transaction has completed, a status is
returned to the application.
A Completion protocol coordinator MUST be the root coordinator of an Atomic Transaction.
The Registration service for a subordinate coordinator MUST respond to an attempt to
register for this coordination protocol with the WS-Coordination fault Cannot Register
Participant.
A coordination service that supports an Activation service MUST support the Completion
protocol.
153. WS-AT Coordination Protocol – 2PC Protocol
The Completion protocol is used by an application to tell the coordinator to either try to
commit or abort an Atomic Transaction. After the transaction has completed, a status is
returned to the application.
A Completion protocol coordinator MUST be the root coordinator of an Atomic Transaction.
The Registration service for a subordinate coordinator MUST respond to an attempt to
register for this coordination protocol with the WS-Coordination fault Cannot Register
Participant.
A coordination service that supports an Activation service MUST support the Completion
protocol.
154. WS-AT Example
STEP 1: On completion of work, the
Completion participant initiates the
commit process by sending a Commit
message to the coordinator.
STEP 2: The coordinator initiates the
prepare phase on the Volatile2PC
participants by sending a Prepare
message. Each participant signals the
successful completion of the prepare
phase by responding with a Prepared
Message.
STEP 3: When all Prepared messages are received from Volatile2PC participants,
the coordinator initiates the prepare phase on the Durable2PC participants by
sending a Prepare message.
STEP 4: When all Prepared messages are received from Durable2PC participants,
the coordinator decides to commit, sends the Committed message to the Completion
participant, and sends the Commit message to both Volatile2PC and Durable2PC
participants. There is no ordering constraints among steps 4a, 4b, 4c.
155. WS-BusinessActivity
WS-BusinessActivity (WS-BA) specification defines the guidelines which allow multiple
web services to participate in a long running transaction.
Long running transactions/business activities show the following characteristics
- A business activity may consume many resources over a long duration.
- There may be a significant number of atomic transactions involved.
- Individual tasks within a business activity can be seen prior to completion of the
business activity, their results may have an impact outside the system boundary.
- Responding to a request may take a long time. Human approval, assembly,
manufacturing, or delivery may have to take place before a response can be sent.
- In a case where a business exception requires an activity to be logically undone, abort
is not sufficient. Exception handling mechanisms may require business logic, in the
form of a compensating transaction, to reverse the effects of a previous task.
156. WS-BusinessActivity - contd
WS-BA coordination types:
- AtomicOutcome: A coordinator MUST direct all participants to either close or
compensate.
- MixedOutcome: A coordinator MUST direct all participants to an outcome but MAY
direct individual participant to close or compensate.
All Business Activity coordinators must implement AtomicOutcome coordination type.
Implementation of MixedOutcome coordination type is optional.
WS-BA coordination protocols:
- BusinessAgreementWithParticipantCompletion:
Under the BusinessAgreementWithParticipantCompletion protocol, a child activity is
initially created in the Active state; if it finishes the work it was created to do and no more
participation is required within the scope of the BA (such as when the activity operates on
immutable data), then the child can unilaterally send an exited message to the parent.
However, if the child task finishes and wishes to continue in the BA then it must be able
to compensate for the work it has performed. In this case it sends a completed message
to the parent and waits to receive the final outcome of the BA from the parent. This
outcome will either be a close message, meaning the BA has completed successfully or
a compensate message indicating that the parent activity requires that the child task
reverse its work.
157. WS-BusinessActivity - contd
WS-BA coordination protocols contd:
- BusinessAgreementWithCoordinatorCompletion:
The BusinessAgreementWithCoordinatorCompletion protocol is identical to the
BusinessAgreementWithParticipantCompletion protocol with the exception that the child
cannot autonomously decide to end its participation in the business activity, even if it can
be compensated. Rather the child task relies upon the parent to inform it when the child
has received all requests for it to perform work which the parent does by sending the
complete message to the child. The child then acts as it does in the
BusinessAgreementWithParticipantCompletion protocol.
158. How Business Activities differ from Atomic Transactions?
Exception Handling
In a business activity, the coordinator needs to handle an exception by retrying or
selecting an alternative strategy or by aborting the activity (this may require explicit
compensating transactions to be invoked) in order to achieve a defined business goal. In
an atomic transaction, exception are handled via retries or aborts. Atomic transactions do
not require special programmatic handling.
Duration
A business activity occurs over many minutes, days, weeks. An atomic transaction
typically is instantaneous.
Isolation
Unlike an atomic transaction, a business activity does not hold locks and therefore has
weaker isolation characteristics. In business activities, intermediate steps become visible
outside the system boundary even if the activity is partially complete.
Durability
Business activities span long time spans, hence post intermediate step completions, their
state is persisted, unlike atomic transactions where intermediate steps are not persisted.
Diverse operational characteristics
Unlike atomic transactions, business activities do not expect their participants to be
available simultaneously.