SOA Service Oriented Architecture

Service Oriented
Architecture
August, 2008

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.

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?

Why do we need another
architecture?

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

Why are present day
architectures inadequate?

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

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

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

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

Present day architectures
limitations are

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

IT Reality
Requirements
Time
Business
IT Systems
IT Systems Can’t Keep Up

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.”

What is Service Oriented
Architecture (SOA)?
SOA?
Whoa!

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.

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

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

What constitutes a service?
SOA?
Whoa!

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.

Service
-Inspection
-Treatment
-Patient-care
-Drugs
-Manage files
Doctor Nurse Receptionist Technician
-X-ray films
Patient
Hospital
External
Clinic
Cure
Process
Business
Objective
HIS ECP Clinical
Systems
RIS
PIS

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

Service
Department
Radiology LaboratoryPathology
External
Hospital
Accounting
Drug
Company
Insurance
Hospital
Administration
Radiology Order
[RIS]
Pathology Order
[Pathology Info System]
Laboratory Order
[LIS]
Billing
[ERP]
Payment Claim
Processing
[ECP]
Drug Info
[Drug DB]
External EHR
[EHR System]
Patient Demographics
[Hospital Info System]

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

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.

So what is a service?
SOA?
Whoa!

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)

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

Service Contract
A service contract defines everything needed to interact with the service
and nothing more
Service
Consumer
Service
Provide
r
Contract

Service Contract
Service contract defines the following:
 Service interface
 Service description
 Service level agreements

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#

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.

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.

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

What are the elements
of a SOA ?
SOA?
Whoa!

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

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

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

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

How do the SOA elements
interact?
SOA?
Whoa!

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

What are the different categories
of a service?
SOA?
Whoa!

SOA Service Types
SOA based services can be broadly classified under three categories
 Basic Services
 Intermediary Services
 Business Process Services

Basic Services
 A stateless service oriented software function
 Strictly, acts as a service provider
 Encapsulates all access to a particular data source

Basic Services
Online Ordering
Application
Order
Management
Customer
Management
Inventory
Management
Basic
Service
Layer
Application
Client
Layer
Warehouse
Application

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

Intermediate Services
Online Ordering
Application
Order
Management
Customer
Management
Inventory
Management
Basic
Service
Layer
Application
Client
Layer
Order and Ship
Intermediate
Service
Layer

Business Process Services
 Encapsulates an enterprise’s business process
 Acts as both a service provider and a service consumer
 Tends to be application specific

Business Process Services
Online
Ordering
Application
Order
Management
Customer
Management
Inventory
Management
Basic
Service
Layer
Application
Client
Layer
Order and Ship
Intermediate
Service
Layer
Catalog
Service
Business
Process
Service
Layer
Order
Cancellation
Service

SOA Service Types
Business
Process
Services
Intermediary
Services
Basic
Services
Application
Client Layer
The service types can be diagrammatically represented as below

SOA: Growth Stages
Agility
and
Flexibility
Complexity
Process-Driven
SOA
Multi-Level
SOA
Simple
SOA
Maturity
of
SOA
SOA evolves thru incremental and iterative development process

Simple SOA
Online Ordering
Application
Order
Management
Customer
Management
Inventory
Management
Basic
Service
Layer
Application
Client
Layer
Warehouse
Application

Multi level SOA
Online Ordering
Application
Order
Management
Customer
Management
Inventory
Management
Basic
Service
Layer
Application
Client
Layer
Order and Ship
Intermediate
Service
Layer

Process driven SOA
Online
Ordering
Application
Order
Management
Customer
Management
Inventory
Management
Basic
Service
Layer
Application
Client
Layer
Order and Ship
Intermediate
Service
Layer
Catalog
Service
Business
Process
Service
Layer
Order
Cancellation
Service

Services
Where do these services fit in
our enterprise architecture?
SOA?
Whoa!

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

SOA
Remember, SOA is a
paradigm shift in software
development

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

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

SOA Candidate Business Scenarios
Which business situations
make good candidates for
SOA implementation?
?
?
?

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

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

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

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.

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

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

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

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

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

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

SOA
What technologies do I use to
implement SOA?

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.

SOA
Let’s focus on Web Services.

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:

Our Architecture in the EAI days
CRM ERP
PARTNER
SYSTEMS
FINANCE
ORDER
ENTRY
Let’s expose the application interfaces as Web Services.

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

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

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.

SOA
What does the SOA stack
comprise of?

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.

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

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

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

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.

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

SOA – The road ahead
SOA is a continuing
journey and not a
destination.

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.

SOA Standards Overview
Courtesy: www.innoq.com URL

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

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

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

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>

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

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 !!!

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…

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

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.

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

 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

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>

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.

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.

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.

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 …

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 >

Binding
• Binding defines how message are transmitted, and the
location of the service.

<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>

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

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.

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

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

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)

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

WS-Security-Samples SOAP Header
<S:Envelope>
<S:Header>
<wsse:Security>
<! - - Security Token - - >
<wsse:UsernameToken>
……………..
</wsse:UsernameToken >
<! - - XML Signature - - >
<ds:Signature>
………
<ds:Reference URI=“#body”>
…….
</ds:Signature>
<! - - XML Encryption Reference List - - >
<xenc:RefereneList>
<xenc:DataReference URI=“#body”/>
</xenc:RefereneList>
</wsse:Security>
</S:Header>
<S:Body>
<! - - XML Encryption Reference List - - >
<xenc:EncryptedData Id=“body” type=“content”>
……………….
</xenc:EncryptedData>
</S:Body>
</S:Envelope>

WS-Security-Samples SOAP Header with Timestamp
<S:Header>
<wsu:Timestamp>
<wsu:Created> 20-02-06 13:45</wsu:Created>
<wsu:Expires> 21-02-06 13:44</wsu:Expires>
<wsu:Recevied Actor=http://me.com
Delay=“60000”> 20-02-06 13:49
</wsu:Created>
</wsu:Timestamp>
</S:Header>

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

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.

 Client understands X.509 certificates
only
 Service understands SAML only
 No established trust between client
and service

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

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)

Federation - Example
Account Number
and PIN
Home Bank Network
Visiting Bank Network
Funds Network of Trust
Federated ATM Network

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)

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

Direct Trust – Token Exchange
Trust
Get identity
token
Get access
token1
3
2
IP/STS IP/STS
Requestor
Resource

Direct Trust – Token Validation
Trust
Get identity
token
Get access
verification
1
2
3
IP/STS IP/STS
Requestor Resource

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

Delegation
Trust
1
3
2
Trust
5
4
IP/STS IP/STS IP/STS
Requestor
ResourceResource

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

Attribute Service - Example
Trust
1
3
2
4
Trust
Zip: 12309
FN: Fred
…
IP/STS IP/STS
Requestor Resource
Attribute
Service

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

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

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

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

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.

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

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.

Example Message Exchange
Sender
Destination
Establish Protocol Preconditions (Policy exchange, endpoint resolution, establishing trust)
Create Sequence
Create Sequence Response (Identifier=http://fabrikam.com)
Message 1
Message 2
Message 3, LastMessage
Sequence Acknowledgement (Acknowledgement Range=1,3)
Message 2, AckRequested
Sequence Acknowledgement (Acknowledgement Range=1..3)
Terminate Sequence

Transaction Management
Transactions

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

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.

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

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.

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.

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.

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.

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.

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.

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.

SOA Service Oriented Architecture

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à SOA Service Oriented Architecture

Similaire à SOA Service Oriented Architecture (20)

Dernier

Dernier (20)

SOA Service Oriented Architecture