Service Orientation
Main issues:
Whats special about services?
Essentials of service-oriented SE
Overview
Services, service description, service
communication
Service-Oriented Architecture (SOA)
Web services
SOSE: Service-Oriented Software Engineering
Italian restaurant analogy
Restaurant provides food: a service
After the order is taken, food is produced, served,
: service may consist of other services
The menu indicates the service provided: a
service description
The order is written down, or yelled at, the cook:
services communicate through messages
Main ingredients
Services
Service descriptions
Messages
Implementation: through web services
Other example
Citizen looking for a house:
Check personal data System X
Check tax history
System Y
Check credit history
System Z
Search rental agencies System A,B
Whats a service
Platform-independent computational entity that can be used
in a platform-independent way
Callable entities or application functionalities accessed via
exchange of messages
Component capable of performing a task
Often just used in connection with something else: SOA,
Web services,
Whats a service, cntd
Shift from producing software to using software
You need not host the software
Or keep track of versions, releases
Need not make sure it evolves
Etc
Software is somewhere, deployed on as-needed
basis
SaaS: Software as a Service
Key aspects
Services can be discovered
Services can be composed to form larger services
Services adhere to a service contract
Services are loosely coupled
Services are stateless
Services are autonomous
Services hide their logic
Services are reusable
Services use open standards
Services facilitate interoperability
Service discovery
Service
registry
lookup
Service
requestor
publish
bind
Service
provider
Service discovery
Rental agency 1
Rental agency 1
Rental agency 2
Apartment
(immediate, cheap)
Municipality
system
Agency 1
publish
Apartment?
Rental agency 1
2
Rental agreement
Service discovery
Discovery is dynamic, each invocation may select a different
one
Primary criterion in selection: contract
Selection may be based on workload, complexity of the
question, etc optimize compute resources
If answer fails, or takes too long select another service
more fault-tolerance
Is discovery really new?
Many design patterns loosen coupling between
classes
Factory pattern: creates object without specifying
the exact class of the object.
Services can be composed
Service can be a building block for larger services
Not different from CBSE and other approaches
Services adhere to a contract
Request to registry should contain everything needed, not
just functionality
For normal components, much is implicit:
Platform characteristics
Quality information
Tacit design decisions
Trust promises?
Quality of Services (QoC), levels thereof
Service Level Agreement (SLA)
Service discovery
Rental agency 1
Rental agency 2
Apartment
(immediate, cheap)
Municipality
system
Agency 1
Apartment?
Rental agency 1
Rental agreement
Services are loosely coupled
Rental agencies come and go
No assumptions possible
Stronger than CBSE loose coupling
Services are stateless
Rental agency cannot retain information: it
doesnt know if and when it will be invoked again,
and by whom
Services are autonomous, hide their logic
Rental agency has its own rules on how to
structure its process
Its logic does not depend on the municipality
service it is invoked by
This works two ways: outside doesnt know the
inside, and vice versa
Services are reusable
Service models a business process:
Not very fine grained
Collecting debt status from one credit company is not a
service, checking credit status is
Deciding on proper granularity raises lots of
debate
Service use open standards
Proprietary standards vendor lockin
There are lots of open standards:
How services are described
How services communicate
How services exchange data
etc
Services facilitate interoperability
Because of open standards, explicit contracts and
loose coupling
Classical CBSE solutions pose problems:
Proprietary formats
Platform differences
Etc
Interoperability within an organization (EAI) and
between (B2B)
Overview
Services, service description, service communication
Service-Oriented Architecture (SOA)
Web services
SOSE: Service-Oriented Software Engineering
Service-Oriented Architecture
Architecture:
the fundamental organization of a system in its components,
their relationships to each other and to the environment and
the principles guiding its design and evolution
SOA: Any system made out of services?
What is SOA?
Orchestration/coordination layer
service
service
Business services layer
service
Infrastructure service layer
service
service bus
physical
logical
Service bus
Event-based messaging engine
Origin: EAI, solve integration problems
Often takes care of:
Mediation: protocol translation, data transformation, etc
Quality of Service issues: security, reliable delivery of messages, etc
Management issues: logging, audit info, etc.
Service discovery
Can be central (broker, hub), or decentral (smart endpoints)
Service coordination
Orchestration: central control
Choreography: decentral control
Overview
Services, service description, service communication
Service-Oriented Architecture (SOA)
Web services
SOSE: Service-Oriented Software Engineering
Web services
Implementation means to realize services
Based on open standards:
XML
SOAP: Simple Object Access Protocol
WSDL: Web Services Description Language
UDDI: Universal Description, Discovery and Integration
BPEL4WS: Business Process Execution Language for Web
Services
Main standardization bodies: OASIS, W3C
Coordination of Web services
BPEL4WS
WSDL
Java
WSDL
Java
WSDL
Java
Web services stack
composition
description
BPEL4WS
WSDL
UDDI
messages
SOAP
network
HTTP, FTP,
discovery
XML
Looks like HTML
Language/vocabulary defined in schema:
collection of trees
Only syntax
Semantic Web, Web 2.0: semantics as well: OWL
and descendants
SOAP
Message inside an envelope
Envelop has optional header (~address), and
mandatory body: actual container of data
SOAP message is unidirectional: its NOT a
conversation
WSDL
Four parts:
Web service interfaces
Message definitions
Bindings: transport, format details
Services: endpoints for accessing service. Endpoint =
(binding, network address)
UDDI
Three (main) parts:
Info about organization that publishes the services
Descriptive info about each service
Technical info to link services to implementation
UDDI (cntd)
Original dream: one global registry
Reality: many registries, with different levels of
visibility
Mapping problems
BPEL4WS
Three main parts:
Partnerlinks: dependencies between services: who sends what to
whom
Global variables
Workflow model: program
BPEL4WS is an orchestration language; executable
WS-CDL (Web Services Choreography Description
Language) is a choreography language; not executable
Overview
Services, service description, service communication
Service-Oriented Architecture (SOA)
Web services
SOSE: Service-Oriented Software Engineering
SOSE life cycle
Service oriented
analysis
Service
development
Service
deployment
Service oriented
design
Service
testing
Service
administration
Terminology
service oriented environment (or service oriented
ecosystem)
business process + supporting services
application (infrastructure) service
business service
Task-centric business service
Entity-centric business service
hybrid service
Terminology
entity centric
order
fulfilment
service
hybrid
services
hybrid
services
entity-centric
task centric
task-centric
purchase
order
service
business
businessservices
services
infrastructure services
infrastructure
services wrapper
service
send
utility
service
customer
profile
service
notification
service
verify
PO
service
Strategies for life cycle organization
Top-down strategy
Bottom-up strategy
Agile strategy
Top-down strategy
Service oriented
analysis
Service
development
Service oriented
design
Service
testing
Service
deployment
Top-down SO analysis
step
step 1
1
Define enterprise
business models
step
step 33
Define enterprise
service model
step
step22
Compose SOA
Service oriented
design
step
step44
Perform service
oriented analysis
....
Bottom-up strategy
Model application
services
Develop
application
services
Design application
service
Test
services
application service = infrastructure service
Deploy
services
Agile strategy
Top-down
analysis
SO analysis
align with
current
state
business
models
SO design
Develop services
Test service operations
Deploy services
on-going
align with
current
state
business
models
Revisit business
(and process) services
Service oriented analysis
The process of determining how business automation
requirements can be represented through service
orientation
Goals of SO analysis
Service operation
Service candidates
candidates
(logical contexts)
Appropriateness for intended use
Identify preliminary issues that may challenge required
service autonomy
Define known preliminary composition models
3 Analysis sub-steps
step 1
Service oriented
analysis
Service oriented
design
Define
analysis scope
step 2
Identify
automation
systems
step 3
...
Model
candidate services
Step 1: Define analysis scope
Mature and understood business requirements
S = i Si, where smaller services may still be quite complex
Can lead to
process-agnostic services/service operations (generic service
portfolio)
services delivering business-specific tasks
Models: UML use case or activity diagrams
Order Fulfillment Process
start
Transform
PO
receive PO
validate PO
PO
valid
no
Send
notification
Import
PO
yes
Send PO
to queue
stop
Step 2: Identify automation systems
What is already implemented?
encapsulate
replace
Models: UML deployment diagram, mapping tables
Order Fulfillment Process
already
automated
start
by
Order
fulfillment
service
receive PO
Transform
PO
same as
validate PO
previous
same as
previous
PO
valid
no
Send
notification
Import
PO
yes
Send PO
to queue
stop
(XML -> native format)
(currently custom
component)
service candidate
(into accounting sys.)
service candidate
(currently custom legacy)
service candidate
(to accounting clerk's
work queue)
same as previous
Step 3: Model candidate services
How to compose services?
Service (candidates) conceptual model
operations + service contexts
SO principles
Focus on task- and entity-centred services
Models: BPM, UML use case or class diag.
Example service operation candidates
Receive PO document
<<include>>
Validate PO document
PO processing
service
<<include>>
...
(If PO document is invalid,)
send rejection notification
(and end process)
Transform PO document
into native
electronic PO format
Example business process logic
Not service operation candidates
if PO document is valid, proceed with the transform PO
document step
if the PO document is invalid, end process
Task- versus entity-centred services
Task-centred
(+) direct mapping of
business requirements
(-) dependent on specific
process
Entity-centred
(+) agility
(-) upfront analysis
(-) dependent on
controllers
Benefits of business-centric SOA
introduce agility
prepare for orchestration
enable reuse
Service-oriented design: design sub-steps
Service oriented
analysis
step 1
Compose SOA
Service oriented
design
...
step 2
Design entity-centric
business services
step 3
Design infrastructure services
step 4
Design task-centric
business services
step 5
Design SO
business process
Entity-centric business services
Goal: entity-centric business service layer + parent
orchestration layer
Invoice
Customer
Hours billed
Order
...
PO
*
*
<<include>>
...
Validate PO document
*
1
1 Employee
Email
Weekly hours
1
*
1 Customer
1
Receive PO document
...
PO processing
service
...
(If PO document is invalid,)
send rejection notification
(and end process)
<<include>>
Transform PO document
into native
electronic PO format
Infrastructure services
PO
processing
service
Verify
PO
service
Orchestration/coordination
layer
PO
service
Business service layer
Notification
service
Transform
service
Infrastructure service
layer
Task-centric business services
UML sequence diagram
express and refine order of invocations implicit in the UML use
case diagram
Receive PO document
<<include>>
Validate PO document
PO processing
service
...
(If PO document is invalid,)
send rejection notification
(and end process)
Verify PO
service
PO
service
get_PO
[PO data]
verify
<<include>>
Transform PO document
into native
electronic PO format
send_reject
Notification
service
Summary
Services have a long history (telephony)
Most important characteristic: dynamic discovery
of services
SOA as architectural style
Todays Web services mostly syntax-based
Key design decisions in SOSE concern service
layering, industry standards, and relevant SO
principles
SOSE differentiates from traditional life cycles
mainly in the analysis and design phases
