Service Oriented
Architecture
Paolo Falcarin
2
From Components to (Web) Services
Requires a client library Client / Server Extendable Stateless Fast Small to medium granularity
Loose coupling via Message exchanges Policies Peer-to-peer Composable Context independent Some overhead Medium to coarse granularity
3
Towards a Service-Oriented Architecture
Function oriented Build to last Prolonged development cycles
From
From
To
To
Coordination oriented Build to change Incrementally built and deployed Application silos Tightly coupled Object oriented Known implementation Enterprise solutions Loosely coupled Message oriented Abstraction
SOA (Service Oriented Architecture)
SOA IS
AN ARCHITECTURAL STYLE
WHOSE GOAL IS TO ACHIEVE
LOOSE COUPLING
AMONG INTERACTING
SOFTWARE AGENTS
5
Large Firms Implementing SOA
Implemented/(ing) SOA No plans
58% of 612 organizations polled by CIO Magazine implemented or plan to implement SOA
CIO Magazine March 2006
6
SOA Growth
Forrester: 70% of global enterprises
have adopted or will adopt SOA
Hayward, S “Position 2005: Service Oriented Architecture Adds Flexibility to Business Processes”
Gartner, Inc. Feb 2005
“SOA will provide the basis for 80% of
new development projects by 2008”
Dr. Chris Harding, “Modeling SOA Implementation”
7
Service Oriented Architecture
“The SOA models the business as a collection of self-contained services that are available across the enterprise that can be invoked through standard protocols both internally and externally.” (Hohpe)
•Services are
course grained
collections of
functionality rather than small
components.
•Services are
factored out
of their
applications to eliminate duplicated
functionality.
•Services are
run-time
shareable functions.
SOA
=
Web Services
• Service-Oriented Architecture (SOA): An IT architectural style based on the concept of a collection of services that communicate and coordinate with each other in an enterprise-level, distributed computing environment.
• Service: A self-contained, reusable function that is invoked through well-defined interfaces and is independent of the context, state or location of other services or applications.
• Reuse: Services encapsulate business functions that are located and reused at run-time.
Key SOA Concepts
/
9
• Coarse-Grained: Granularity is the level of detail at which an item is viewed or described. Services tend to be Coarse-Grained where as an API is fine-grained. • Loose Coupling: Service provider and consumer need
no knowledge of how the other is implemented resulting in minimal dependencies. Generally implies
asynchronous messaging.
• SOA Governance: The organization and processes to ensure optimal reuse of services and enforcement of policies (eg. Business design, technical design, application security).
Key SOA Concepts
SOA = Concepts and Principles
not Technology
10
• Web Services: A specific implementation of SOA that uses standard Web protocols to connect services together via XML messages. Most commonly used scenario is synchronous request/response pattern.
• Message Oriented Middleware (MOM): A category of inter-application communication software that relies on asynchronous message passing as opposed to a
request/response metaphor. (e.g. MQ-Series)
• Enterprise Service Bus: Message Oriented Middleware that provides a robust asynchronous transport service for XML messages and standard Web services protocols.
Key SOA Technologies
SOA is not a new concept – but new technologies, like Web services, have made it more practical
Migrating Information
Systems to SOA
Two Approaches to SOA
Top Down – Business-centric
Start with high-level picture of Business Processes
Decompose processes – look for redundancy, Service candidates
Best approach to demonstrate business value
Bottom Up – Technology-centric
Start by looking at existing IT capabilities Look for redundant coarse-grained functions
to expose as Services
Prioritize with 80/20 rule – Expose the 20% functionality that is used 80% of the time
13 User Interface Security Reporting Workflow Business Rules Processing Correspondence Entity Mgmt Core Business Logic
From a survey on
Industrial Insurance
Apps
Only about 30%
Unique Business Logic
Bottom-Up:
Identify Redundant Functions
14 User Interface Security Reporting Workflow Business Rules Processing Correspondence Entity Mgmt Core Business Logic
70% Redundant
Functions Common
to Most Business
Applications
15 User Interface Security Reporting Workflow Business Rules Processing Correspondence Entity Mgmt Core Business Logic User Interface Security Reporting Workflow Business Rules Processing Correspondence Entity Mgmt Core Business Logic User Interface Security Reporting Workflow Business Rules Processing Correspondence Entity Mgmt Core Business Logic
Multiplied times many apps…
Lots of redundant functionality
to build and maintain
Bottom-Up: Identify Redundant Functions
WHAT CAN WE DO?
User Interface User Interface User Interface Reporting Business Rules Processing Core Business Logic Security Correspondence Core Business Logic Workflow Entity Mgmt Core Business Logic Web
Facing DeliveryInfo BusinessRules Corresp. Workflow Security EntityMgmt Security Workflow Correspondence Entity Mgmt Reporting Workflow Business Rules Processing Entity Mgmt Security Reporting Business Rules Processing Correspondence SHARED SERVICES
INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE
Tight Coupling?
X
17
Message Bus
(asynchronous)Core Business Logic
Core Business
Logic Core Business Logic Web
Facing DeliveryInfo BusinessRules Corresp. Workflow Security EntityMgmt
SHARED SERVICES
INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE
INTERFACE INTERFACE
INTERFACE
Build Functions as Services
18 Core Business
Logic
Core Business
Logic Core Business Logic Web
Facing DeliveryInfo BusinessRules Corresp. Workflow Security EntityMgmt
Message Bus
(asynchronous) SHARED SERVICESXML
INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE
INTERFACE INTERFACE
INTERFACE
Build Functions as Services
LOOSE COUPLING
XML XML XML XML XML XML19
BUSINESS APPLICATION SERVICES
•Not shared across multiple processes •Very specific business logic
•Uses services from lower levels
INFRASTRUCTURE FRAMEWORK SERVICES
•Generalized, shareable technology •Programmable, no native business logic •Some relevance to developers
BUSINESS FRAMEWORK SERVICES
•Shared across multiple business processes •Broad business logic
•Highly relevant to developers
INFRASTRUCTURE FOUNDATION SERVICES
•Highly standardized technology •Broadly shareable, no business logic •Not very relevant to developers
Example: Accounts Receivable Example: Business Process Mgmt Example: Security Example: Enterprise Service BUS
Service Classifications
High LowRelevance to Developers
BUSINESS APPLICATION SERVICES (Common Apps)
INFRASTRUCTURE FRAMEWORK SERVICES BUSINESS FRAMEWORK SERVICES
INFRASTRUCTURE FOUNDATION SERVICES •Accts. Receivable
•Accts. Payable •Inspections •Permits & Licensing
•Claims Mgmt •Pension Mgmt •Provider Bill Processing •Customer Relationships
•Finance & Budget •Purchasing & Assets •Safety Mgmt •HR
•In-Correspondence •Out-Correspondence •Info Delivery
•Work Flow/BPM (app) •Business Rules (app) •Entity Mgmt (app)
•Personalization (portal) •Content Mgmt (portal) •Payment Processing
•Web Facing (portal) •Portal Servers •App Servers (.NET)
•Work Flow/BPM (engine) •Business Rules (engine) •Shared Security •Entity Mgmt (engine) •Active Metadata •Message Routing •Service Bus •XML Cache •Data Exchange •Directory services •Networks •Load balancing •Storage •Computing Platforms •Databases
Services Examples
21
Increasing levels of encapsulation
Code reuse Language Objects Platforms Components Frameworks Applications Abstraction Time 22
SOA fosters Agility
Agility is the ease with which an
organisation can change
Highly agile organisations react quickly to
changes in the market, thus getting
ahead of the competition
Software evolution
If the system cannot evolve, the business
cannot react to changes
Software evolution entails
costs and risks
Evol.23
Agility
Unprecedented levels of change
often unanticipated
Virtual organizations
Interacting applications belong to multiple
administrative domains
Internal applications increasingly exchange
functions with the external of the enterprise
Many potential providers can be found for
each required function
Web based interactions become pervasive
Yet another middleware?
Execution is distributed . . .
. . . but also costs and risks are distributed
Organization ability to evolve business
depends on the marketplace ability anticipate trends and needs and provide the right services at the right time
does not depend on ability of a software vendor to change a piece of software
Services are realized by software
need for development / maintenance this is a vendor concern
25
Striving for agility
Agility Decentralization of components Dynamicity of bindings Monolithic Distributed Cross domain Modular 26
Striving for agility
Agility Decentralization of components Dynamicity of bindings Monolithic Distributed Cross domain Compile time Deploy time Run time On demand Modular
27
What SOA brings in
Open infrastructures where “pieces of
functionality” are published as services
come with a contract for clients specifying QoS
Services appear dynamically
they must be discovered
They run in their own domains
New services built by composing services,
which may live in external domains
late binding
execution time discovery
What SOA brings in
Not just web services
Not all Web services fit into an SOA
e.g., fine-grained RPC-type services
Not all SOAs use Web services technology
e.g., message-oriented middleware technology
Services may must be
Derived from
business requirements
Typically expressed as business processes
Sufficiently
coarse-grained
to
29
Many new challenges for software
engineering
Service engineering
e.g. contract based specification
Publishing, searching and negotiation
e.g. syntactic vs.semantic discovery, policy-driven resource allocation
Composition
e.g. balancing dynamicity and safety
Validation
e.g. limitations of traditional testing
Trust
e.g. the role of run-time self checking
31
SOA as “On Demand” Computing
Use software
as you need
Much
lower setup time
, forget about
Installation Implementation Training
Maintenance
Scalable and effective usage
of resources
Provision
Billed on true usage
Parallelism (CPU, Storage, Bandwidth…)
New Paradigms in SOA
An application
is NOT a single system
running on a single device and bounded by a
single organization
Object <=> XML Document
Messages
and
Services
As opposed « distributed objects »
Exchanges becomes peer-to-peer
Asynchronous
communications
Concurrency
becomes the norm
33
SOA
34
Message Based Interaction
All interaction between
components is through
messages
35
“Bus”
Conceptual artifact
To get you away from the point to point mentality A strategy for integrating
applications together at runtime using MOM.
(like the bus/ backplane in a PC)
Broker
A dispatcher of messages
Many varieties and variations
37
Queues
Queues are key to
making this work
38
SOA vs. Web services
What is it?
Interface standard
Architectural Style
Web service
SOA
39
SOA vs. Web services
Early use
New development
Composite Apps
Legacy Wrapping
EAI
Web services
SOA
SOA vs. Web services
Predominant/ default interaction
Request/Reply
Synchronous
Publish/Subscribe
Asynchronous
Web service
SOA
41
SOA and Web service co-existing
Service Registry Service Provider Service Consumer WSDL SOAP WSDL SOAP 42
Loose Coupling: Intermediaries
Decoupling is achieved by introducing an ‘intermediate form’
Full application decoupling requires intermediate forms for Technology, Destination, Syntax,
43
What Makes a Good Intermediary ?
It doesn’t change as rapidly as its
clients.
It is non proprietary.
It is evolvable.
It is simple to use.
Examples of Intermediaries
Integration Brokers
Message Queues
Enterprise Service Bus (ESB)
45
WS-Notification
Brings enterprise quality publish and
subscribe messaging to Web services
Loosely coupled, asynchronous messaging in a Web services context
WS Notification exploits WS Resource
framework and other Web services
technologies
Direct and Brokered notification
Topics and Topic Spaces
More on subscribe
Use of WS-Notification in WS-RF
46
WS-Notification Family of Documents
WS-Notification is a family of documents:
Publish-Subscribe for Web services
– Whitepaper describing roles, concepts, terms, etc.
Base Notification
– Basic interfaces: Producer, Consumer, Subscription
Topics
– Topics and TopicSpaces model in XML – Topic Expression Dialects
Brokered Notification
47
Consumer
Producer
Subscriber
WS-Notification: Base Notification
subscribesubscribe
S
notify
EPR
Defines the Basis for the family
Direct notification: Three primary
roles
Subscriber deals directly with the
producer of the Notifications
indicates interest in a particular “Topic” by issuing a “subscribe” request
An EPR to the subscription is
returned
Producer is responsible for
detecting situation and
creating the notification
Subscriptions that match
receive the notification
Similar roles as in direct, adding ‘Broker’Role
Broker (intermediary) permits decoupling Publisher and Subscriber
Subscriber indicates interest in a particular “Topic” by issuing a “subscribe” request “Subscriptions” are WS-Resources
Various subscriptions are possible
New role: Publisher
need NOT be a Web Service
Publisher detects situation:
Publishes the Notification to a broker
Broker responsible for disseminating notifications
examines current subscriptions for match
Brokers may provide “value add”
“Transform” or “interpret” topics
Broker Subscriber
WS-Notification: Brokered Notification
Publisher subscribe subscribe S S S notify notify notify notify
49
4. Introduction to the WS - * specifications
Web Service Addressing Web Service Policy
Web Service Transactions WS – Coordination
WS – AtomicTransaction WS - BusinessActivity
Web Service Reliable Messaging WS – ReliableMessaging WS – ReliableMessaging Policy Web Service Security
50
4. Introduction to the WS - * specifications
Web Service Addressing
provides transport-neutral mechanisms to address Web Services and messages.
Web Service Policy Framework
defines a base set of constructs that can be used and extended by other Web Services specifications to describe a broad range of service requirements and capabilities.
WS – Coordination
Describes an extensible framework for providing protocols that coordinate the actions of distributed applications
51
4. Introduction to the WS - * specifications
Web Service Reliable Messaging
Describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system or network failures. The protocol is described in a transport-independent manner. Web Service Security
Provides comprehensive solutions to secure Web Service communication. In general these issues are addressed:
– Authentication – Authorization – Secure Messaging – Secure data access – Denial of service
53
SOA and BPM
SOA is about constructing software
components that can be reused in
context unknown at design time
Composition versus Extension (OO)
BPM is about being able to precisely
model and possibly change the
context in which enterprise
components are used
But how the two meet?
54
BPM in SOA
Two approaches
Event Oriented
–BPML, BPEL
–Pi-Calculus (Also Event Calculus)
Activity Oriented
–WfMC
–Petri nets
55
Web service/BPEL Orchestration
You can get a
similar effect
with Web
services
orchestration.
A very simple example
A buyer orders some goods from a
supplier
The supplier performs a series of
steps to fulfill the order
Approve the order
Update the order entry system
Update the billing system
…
57
Orchestration languages
They allow us to implement complex
services which involve:
Long running (from a few hours to a few
months),
And event driven business logic
They are not about modeling Business
Processes by themselves
Different orchestration (i.e. different
services) can run within the same business
process
And
vice versa
58
A Business Process can be Viewed as a
Multi-Party Choreography of Peer Services
User Activity
Buyer Supplier SFA Sales
person Start ERP Mapping Routing Quote RFQ RFQ RFQ Order Order Order Invoice Accounts Account SalesTax.com CreditCheck.com Orders Billing Invoice Sales Order Events Activity Information Entity
59
Services in a SOA are orchestrated (BPEL)
Quote Service Orchestration Definition RFQ Nack Quote Sales Tax <<send>> quote updateDB Transition Message flow RFQ Quote Ok? No sendNack Order <<invoke>> calculateSalesTax <<invoke>> GetQuote Ok? No Entity State Entity <<receive>> RFQ
A Choreography Provides a Model of
the Event Flow Between Activities
Buyer Supplier (Self) Order Entry PO AckPO BTA1 OpA1 PO AckPO Manager OpA2 Sales order Start Wit1 PO PO Billing Failure Success [BusinessFailure] [Success]
61
Orchestration vs Choreography
Orchestration
« … is an emerging [concept] that would give programmers a way to formally describe
processes underlying business applications so that they can be exposed and linked to
processes in other applications
»
Choreography
Is a concept that specifies how these processes are linked together across the enterprise
Choreography can be « active » when mapping and routing are necessary
They are both a form of Coordination
62
Putting BPM and SOA together
The foundation is becoming sound with
strong theoretical support
Lot of work to be done on Stateful Services
Semantic Web standards add:
Shared ontologies in OWL-S Semantic Interfaces (WSDL-S)
Formal unambiguous semantic for intefaces and data
Fundamental for reaching automatic service composition and adaptation
63
SOA is a New Computing Paradigm
Not as a new name for
API
Component
A genuine set of concepts with which we can
construct new kinds of software
This is as significant if not more than Object Orientation
In particular SOA forces us to think about
enabling the same piece of code to be
leveraged
by large numbers of consumers in unforeseen context
References
Existing BPEL Runtimes:
ActiveBPEL [http://www.activebpel.org] Eclipse BPEL [http://www.eclipse.org/bpel] Orchestra – ObjectWeb- JONAS J2EE app server Workflow Runtime:
Windows Workflow Foundation
[http://msdn.microsoft.com/workflow] WS - * Frameworks: WS Apache [http://ws.apache.org] WS Apache Pubscribe Microsoft WSE [http://msdn.microsoft.com/webservices/webservices/buil ding/wse/default.aspx
