Open Research Challenges in
Service-Oriented Computing
Schahram Dustdar
Distributed Systems Group
Institute of Information Systems
TU Wien
http://www.infosys.tuwien.ac.at/Staff/sd/
SOA in the Past
Web as Global SOA
deploy
invoke
Service
Development
register
Designer
Browser
Service
Registry
discover
copy &
paste
Consumer
SOA Evolution
 SOA triangle based on static provider/consumer
roles
 Web 2.0 trends




User centric
Participative
Web-based composition tools
Flexible interaction
 Research trends and issues
 Human Provided Services
 Self-Healing
 Trust and Reputation
SOA as of Now
Atom RSS
SOAP REST
Web as Global SOA
Service
Registry
XML
invoke
Integration - Glue
Service
Development
Designer
Search Engine
Browser
Consumer
JSON
Current SOA Research
human
service
activity scopes
invo
ke
Service
Registry
Integration - Glue
Humans and services
interact to perform work
described by activities.
Self-Healing
invo
ke
X
Run-Time Environment
Adaptation
Monitoring
Deployment with
Dependecy
Management
Process Design
Self-Healing
Policies
Trust and Reputation
Monitoring
I. invoII.
ke
Run-Time Environment
Selection
Updated
Network Data
Configuration of
Trust Constraints
Trust Management Framework
Trust Management
Policies
Agenda
 Service Oriented Computing Research Roadmap
 Theme#1:Service Foundations
 Theme#2:Service Composition/Assemblies
 Theme#3:Service Management
 Theme#4:Service Engineering
 Summary
8
Some papers to start with…

Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F. (2007). ServiceOriented Computing: State of the Art and Research Challenges, IEEE
Computer, November 2007, p 64 - 71.

Papazoglou, M., Traverso, P., Dustdar, S., Leymann, F. (2008). ServiceOriented Computing: A Research Roadmap, International Journal of
Cooperative Information Systems, 17(2), 1-33.

Dustdar, S., Papazoglou, M. (2008). Services and Service Composition - An
Introduction. it - Information Technology, April 2008, (c) Oldenbourg
Wissenschaftsverlag
9
Extended SOA (xSOA)
Modelling,
Design & Development
Methodologies
Service operator
Management &
Monitoring
Market maker
Market
Certifica
tion
Rating
OpeS
raLtiAosn
Auditing s
SC
up
opm
ortpos
it
ion
Manage
d service
Compos
ite
Coordin
ati
Conform on
a
Transac nce
tions
Service provider
Role actions
rvices
Publication
Discovery
Selection
Binding
Service client
performs
publishes
uses
becomes
services
Basic se
(Archite
Founda
cture, D
tion
escripti
on & ba
sic ope
rations
)
Capability
Interface
Behaviou
r
Semantics
Non-functional characteristics
QoS
s
Service aggregator
10
Research Challenges

Methods and Models for Design, Development, and
Evolution
 Service Composition for open complex and dynamic
systems
 Model-driven development for compliant SOC Systems
 Context-based service composition

Service Discovery in Registries






Dynamic Binding in Registries
Retrieval languages for humans and software services
Transient service providers and registries
Papazoglou, M.P., Traverso, P.,
Central/decentral/hybrid architectures
Dustdar, S., Leymann, F. (2007).
Service-Oriented Computing: State
Protocols for Coordination and Interaction
of the Art and Research
Challenges,
 Coordination of dynamic services
 Analyses of Service-Interactions (Mining, Patterns,
IEEE Computer, November 2007,
Algorithms for optimization)
 Interaction models and protocols (e.g., Policies, etc.) p 64 - 71.
QoS-optimized Internet-scale Processes
 Performance monitoring & management of service
compositions and networked open dynamic systems
 Metrics (e.g., Team forms, Orchestration Complexity,
11
Coupling metrics)
Research Themes
 Service Foundations: runtime infrastructure, architectures, e.g.,
Enterprise Service Bus, modes of service delivery = mobile, palm tops,
hand held devices, networks.
 Service Composition/Assemblies: service composition, QoS composition,
SLA composition, etc.
 Service Management: support for discovering, introspecting, securing,
and invoking resources, management functions, measurement,
performance indicators, management infrastructure services and
toolsets.
 Service Development Life Cycle (or Service Design and Development):
service analysis, design methodologies, implementation techniques,
construction and testing, provisioning, deployment, execution and
monitoring, business process modelling tools.
 Cross-cutting concerns: QoS, semantics, non-functional characteristics,
security, business transactions, etc.
12
Agenda
 Service Oriented Computing Research Roadmap
 Theme#1:Service Foundations
 Theme#2:Service Composition/Assemblies
 Theme#3:Service Management
 Theme#4:Service Engineering
 Summary
13
State of the Art
 The requirements to provide an appropriately
capable and manageable integration
infrastructure for Web services & SOA are
coalescing into the concept of the Enterprise
Service Bus (ESB).
 There are two key ideas behind this approach:
 loosely couple the systems taking part in the
integration and
 break up the integration logic into distinct easily
manageable pieces.
14
What is an Enterprise Service Bus?
 ESB is a standards-based IT backbone that leverages Messaging
Oriented Middleware functionality throughout the entire business value
chain, connecting heterogeneous components and systems.
 A way of building and deploying enterprise SOAs
 Combines features from different types of middleware into one package
 Facilitates the deployment of Web services and solves integration
problems
 Key features




Web Services: SOAP, WSDL, UDDI
Event-based, asynchronous delivery
Transformation
Routing: Publish/Subscribe, content-based, itinerary
 Platform neutral
 Connect to anything in the enterprise:
15 Java,.NET, legacy, WS-*, ..
Service
orchestration –
based custom
applications
Portals
Reliable Asynchronous Secure Messaging
service
interface
service
container
Distributed
query engine
Web
Services
Adapters
JMS/
J2EE
WebSphere, Java apps
.NET apps
Data sources
MQ
gateway
Mainframe
& legacy
apps
Multi-platform
support
Enterprise
applications
Enterprise service bus connecting diverse applications & technologies
16
The Container Model
 The basic (core) functions of the container are as follows:
 establishing connectivity and Message Exchange Patterns (MEPs)
 providing support and provision facilities such as transactions,
security, performance metrics, etc, in a declarative and composable
manner,
 providing support for dynamic configuration,
 monitoring of internal behaviour and state to management systems
(services)
 performing data and protocol adaptation,
 providing support for services discovery.
17
Key capabilities of an ESB
 Service Communication Capabilities
 Ability to route service interactions through a variety of protocols,
and to transform from one protocol to another.
 Dynamic Connectivity Capabilities
 ability to connect to Web services dynamically without using a
separate static API or proxy for each service.








Topic and Content-based Routing Capabilities
Endpoint Discovery with Multiple QoS Capabilities
Leveraging Existing (Legacy) Assets
Integration & Transformation Capabilities
Security Capabilities
Business Orchestration & Long Running Transaction Capabilities
Management & Monitoring Capabilities
Scalability Capabilities
18
Clients
service client
service client
service client
WSDL/SOAP
WSDL/SOAP
WSDL/SOAP
WSDL/SOAP
WSDL/SOAP
WSDL/SOAP
Topic-based and Content-based Publish and Subscribe Mechanisms
Process Orchestration, Transformation, Security, Management, Transport
(WS-ReliableMessaging, WS-Notification, WS-Topics)
ESB
Components
DNS Router
Internet
DNS Router
WSDL/SOAP
interface
interface
interface
WSDL/SOAP
interface
interface
interface
WSDL/SOAP
interface
interface
interface
Adapter
Adapter
Adapter
Adapter
Adapter
Adapter
Proprietary
interfaces
Proprietary
interfaces
Proprietary
interfaces
Legacy
Applications
ERP System19
Existing EIS &
Middleware
Platforms
Data
Warehouse
Procurement
Supplier order
service
Order
application
Supplier order
service
Replenishment
service
Supplier order
service
Inventory
Supplier order
service
broker
broker
Supplier order
service
broker
SOAP/
HTTP
Enterprise
Service
Bus
the vendor
of choice.
SOAP/
JMS
XML/
JMS
Purchase Order
service
Credit check
service
Invoicing
service
JCA
connector
ERP
Supplier
Legacy cc
application
Finance
Scaling services in an20enterprise service bus.
Invoice
application
Research Challenges
 Requirements for the foundations/container:







is the container model appropriate for SOC?
dynamic configuration
provisioning mechanisms, e.g., security, transactions, etc.
discovery
monitoring
composition of policies
end-to-end QoS
 Dynamically (re-)configurable run-time architectures:
 The run-time service infrastructure should be able to configure itself and be
optimized automatically in accordance with specific application requirements &
high-level policies (representing business-level objectives)
 Plug-in Architecture to deal with extensible set of QoS properties:
 How do we deal with: end-to-end security solutions, multiple SLAs,
business transactions, flexible pricing schemes, etc.
 Support for Evolvable Agreements and Negotiation
21
Research Challenges (cntd)
 Topic and content-based routing capabilities: run-time
infrastructure should be equipped with routing mechanisms
to facilitate not only topic-based routing but also, more
sophisticated, content-based routing.
 Infrastructure support for:
 Application integration
 Data integration
 Process integration
 Semantically enhanced service discovery: use of automated
means for accurate discovery of services in a manner that
demands minimal user involvement.
22
Our research - Human provided Services (HpS)
 Humans can publish “themselves” as
services, e.g.,:
 Review service
 Consulting service (consultant pattern)
 These services are integrated into
activities, e.g.,:
 ”send for review“
 ”get expert opinion“
 New opportunities for (human)
interaction pattern discovery through
improved semantics
23
Schall D., Gombotz R., Dorn C.,
Dustdar S. (2007). Human Interactions
in Dynamic Environments through
Mobile Web Services. IEEE 2007
International Conference on Web
Services (ICWS), July 9-13, 2007, Salt
Lake City, Utah, USA.
Schall, D., Truong, H.-L., Dustdar, S.
(2008). Unifying Human and Software
Services in Web-Scale Collaborations,
IEEE Internet Computing, May/June
2008
Registries - SOA Theory vs. Practice
 SOA Model intends 3 actors
using Find-Bind-Execute cycle:




Provider registers the service
Consumer finds the service...
...binds to the service provider
...and executes the service
 SOA Practice: Often no registry
 Public registries did not succeed
 Existing registry standards (UDDI
and ebXML) are to heavy-weight
 ”Best practice“: Exchange WSDLs
and endpoints per email
24
Our research – VRESCO
 Current registry standards did not succeed
 Registries should be more than just a lookup service
 Dynamic SOA needs support for:
 Dynamic (late) Binding: Linking abstract services to concrete service
implementations
 Service Composition using Quality of Service (QoS) attributes and
metadata (e.g., pre-/post-conditions)
 Notifications when certain events occur (e.g., new service is published,
QoS of services change, etc.)
 Service Versioning, Search, Service Metadata, Complex Event
Processing, etc.
Michlmayr, A. Rosenberg, F., Platzer, C., Treiber, M., Dustdar, S. (2007). Towards
Recovering the Broken SOA Triangle - A Software Engineering Perspective,
25
In Proceedings of the 2nd International Workshop on Service-oriented
Software
Engineering (IW-SOSWE'07), Dubrovnik, Croatia, September 2007, ACM Press.
Agenda
 Service Oriented Computing Research Roadmap
 Theme#1:Service Foundations
 Theme#2:Service Composition/Assemblies
 Theme#3:Service Management
 Theme#4:Service Engineering
 Summary
26
State of the Art
 On the industry front: Initiatives for developing business process
definition specifications, which aim to define and manage business
process activities and business interaction protocols comprising
collaborating services (“orchestration” and “choreography”).
 On the research front activities have mainly concentrated on:
 dynamic compositions
 modularizing compositions
 enhancing service descriptions (with, for instance, compositional
assertions) so that compositions can be assessed and formally verified
&
 on providing context-aware services to enable compositions.
 In the AI field work is mainly in the area of applying AI planning
techniques to automate the retrieval and composition of Web services.
 Lack of support for the evolution, adaptation & versioning of
business processes.
27
Research Challenges
 Composability analysis for replaceability, compatibility, and
conformance/compliance for dynamic and adaptive processes.
 Adaptive and emergent service compositions.
 Autonomic composition of services:
 Self-configuring compositions e.g., composite services capable of
automatically discovering new partners to interact with, automatically select
among available suppliers, to choose among different options available for
contracts, etc.
 Self-optimizing service compositions that automatically select partners and
options to maximize benefits and reduce costs.
 Self-healing compositions to automatically detect that some business
composition requirements are no longer satisfied by the implementation and
react to requirement violations.
 Self-adapting service compositions are able to function in spite of changes in
behaviours of external composite services, they should reduce as much as
possible the need of human intervention for adapting services to subsequent
evolutions.
28
Research Challenges (cntd)
 QoS-aware service compositions: to be able to understand &
respect each other’s policies, performance levels, security
requirements, SLA stipulations, and so forth.
 Separation of business-driven versus systems-level
compositions:
 business-driven automated compositions should exploit business and
system level separation in service compositions.
29
Our Research Methodology
• Emerging problems
• Runtime behavior
• Metrics/model dependencies
• Performance and reliability
Sensors
Effectors
Analyze
Monitor
• QoS model
• Interaction patterns and
metrics
• Context model and sharing
• Service evolution model
• Human/team metrics
• Trade-off models
• Domain-specific languages
Plan
Knowledge
Sensors
• Service Composition
• Service selection
• Activity ranking
• Human selection
• Reliable processes
• Process mashup
•
Execute
Effectors
• Individual service
• Flows and processes
• Teamwork
• Middleware
• In-situ adaptation
30
Service Evolution
Treiber, M., Truong, H.L., Dustdar, S. (2008). SEMF - Service Evolution
Management Framework, 34th EUROMICRO Conference on Software
31
Engineering and Advanced Applications (SEAA) 2008,
IEEE Computer
Society.
Trust and Reputation in SOC
Motivation
 Open and dynamic Mixed Systems
 humans and (Web) services (mixed)
 joining/leaving the environment dynamically
 performing activities and tasks
 Massive Collaboration in SOA
 large sets of humans and services
 dynamic compositions
 distributed communication and coordination
 Decisions for future interactions, collaboration
partner selection, data sharing..?
 TRUST
33
Assumptions
 Context-aware collaboration
 context models describing the activity scopes
 Connecting widely distributed actors
 Service-oriented Architectures (SoA)
 Dynamically find and use services
 need for trust in services
 Dynamically find and collaborate with humans
 need for trust in humans
34
Mixed Flexible Collaboration Environment
User perspective
Network perspective
Humans and services interacting
to perform work described by activities.
35
human
service
activity scopes
Challenges
 Identify fundamental concepts of trust in SOA
 Enable automatic determination of trust due
to the potential large sets of entities in SOA
 Identify data influencing trust
 Approach enabling collecting, managing and
analyzing data for trust determination
One uniform platform to manage trust
between humans and services in distributed
service-oriented environments.
36
Foundational Concepts (1/2):
Flexible Ad-hoc Collaboration
GenericResource
0..1
-URI
applies -Type
*
1
*
Action
describes
ActivityTemplate
-Type
*
in
Activity
-Name
parent -Description
-Progress
-StartAt
-Duration
child -Priority
-Tags
0..*
InvolvementRole
-Type
-Responsibilities
*
Requirements
-ProfileRequirements
-TrustRequirements
involved
as
* -Type
-ExecutedBy
-Receivers
-UsedResources
-Timestamp
exhibits
Actor
*
1 has 1
Profile
HPS
Software Service
-Skills
-Features
-Competencies
Human
37
HumanProfile
-Name
-Contact
*
Capabilities
ServiceProfile
-URI
-Vendor
-FOAF
has
 Activities
 describe work that
dynamically emerges
during collaboration
 are performed
collaboratively
 determine the context
of interactions
 are a means to
structure information in
flexible collaboration
environments
Activity
Foundational Concepts (2/2):
Mixed System
 Mixed System
 Mix of human- and software services collaboration
 Humans provide services using SOA concepts
 Human-Provided Services (HPS)
 User contributions as services
 Service description with WSDL
 Communication via SOAP messages
 Example: Document Review Service
 Input: document, deadline
 Output: review comments
[EEE]
D. Schall, H.-L. Truong, S. Dustdar. The Human-Provided Services Framework. IEEE 2008
Conference on Enterprise Computing, E-Commerce and E-Services (EEE), Crystal City,
Washington, D.C., USA, 2008. IEEE.
38
Definition of Trust
 Trust reflects an expectation
 based on previous interactions
 one entity has about another’s future
behavior
 to perform activities dependably,
securely, and reliably
 within a specified scope.
[WEBIST] F. Skopik, H.-L. Truong, S. Dustdar. VieTE – Enabling Trust Emergence in Service-oriented
Collaborative Environments. 5th International Conference on Web Information Systems and
Technologies (WEBIST). Lisbon, Portugal, 2009. INSTICC.
39
The Cycle of Trust
Analyzing Interactions
Establishing Trust Network
Trust-aware
collaboration planning
trust
scope
Con
AcAc
vi vi ti- tity ty
Con
WSDL
WSDL
WSDL
WSDL
Resources
Monitoring
Collaboration
interaction
context 1
Ac
vi tity
WSDL
Executing
Activities/Tasks
Resources
interaction
context 2
Ac
vi tity
WSDL
WSDL
WSDL
WSDL
[ICWE09] F. Skopik, H.-L. Truong, S. Dustdar. Trust and Reputation Mining in Professional Virtual
Communities. 10th International Conference on Web Engineering (ICWE). San Sebastian,
Spain, 2009. Springer.
40
Trust, Recommendation, Reputation

Interpretative Personal Trust Determination
 Monitor interactions (e.g., SOAP calls)
 Calculate and interpret metrics
 Second-Hand Recommendations
 Concept of transitivity
 Recommendation != Personal Trust
(not based on evidence)
 Global Reputation

“Wisdom of the crowd”
41
Use Case in the Area of Software
5. trust relation(s) wrt. to SW
Development
implementation; relation
1. delegate
the creation of
whitebox test
cases for
module X;
trust of Fred in
Jane = ?
4. previous interactions:
only rare e-mail contact,
and one joint meeting
7. recommendation
Fred
between testing and impl.?
Software
implementation
?
3. profile: BSc in
Computer Science,
3 years experience
in SW development
Jane
Software
testing
2. project structure,
required skills and
knowledge etc..
6. partner of
Jane in another
software testing
activity
Tom
8. profiles of
recommenders
42
9. relationships
of indirect
recommenders
-> reputation
’others’
Agenda
 Service Oriented Computing Research Roadmap
 Theme#1:Service Foundations
 Theme#2:Service Composition/Assemblies
 Theme#3:Service Management
 Theme#4:Service Engineering
 Summary
43
Service Mgt & Monitoring
 Composite service developments need mechanisms that
provide insights into the health of systems that implement Web
services & into the status and behaviour patterns of loosely
coupled applications.
 Failure or change of a single application component can bring down
many interdependent enterprise applications.
 The addition of new applications or components can overload existing
components, causing unexpected degradation or failure of seemingly
unrelated systems.
 Application performance depends on the combined
performance of cooperating services & their interactions.
44
Service Mgt & Monitoring (cntd)
 To counter such situations, enterprises need to
constantly monitor the health of their applications.
 The performance should be in tune at all times and under all
load conditions.
 Service management spans a range of activities from
installation and configuration to collecting metrics and
tuning to ensure responsive service execution:
 Service-Level Agreement (SLA) negotiation, management,
auditing, monitoring, and troubleshooting, service lifecycle/state
management, performance management, services and
resources provisioning, & aspects like scalability, availability and
extensibility and others.
45
State of the Art
 Service operations management gathers info about:
 the managed service platform, services and business processes and
managed resource status and performance, and supporting specific
management tasks (e.g., root cause failure analysis, SLA monitoring
and reporting, service deployment, and life cycle management and
capacity planning).
 Service operations management
 provides global visibility of running processes, comparable to that
provided by Business Process Management tools.
 defines & supports active capabilities versus traditional passive
capabilities e.g., rather than merely raising an alert when a given
service is unable to meet the performance requirements of a given
service-level agreement, is able to take corrective action itself.
 provides global visibility of running processes, comparable to that
provided by Business Process Management tools
46
WSDL
Business
Application
(Credit Validation)
Service
Interface
Mgmt
Interface
Business
Application
(Shipping Service)
Service
Interface
Management
Application
(WSDM)
Mgmt
Interface
Enterprise 1
Service
Interface
Application Channel
WSDM
Management
Channel
Enterprise 2
Service
Interface
Mgmt
Interface
Business
Application
(Order Processing)

Service
Interface
Mgmt
Interface
Business
Application
(Inventory)
Service
Interface
WSDL
Management
Application
(WSDM)
WS Distributed Mgt is an interoperability protocol mgt info & capabilities in a
distributed environment via Web services. WSDM focuses:
 Management Using WS (MUWS) uses Web services technologies as the foundation of a
modern distributed systems mgt. It defines how to describe manageability capabilities of
resources using WSDL documents.
 Management of WS (MOWS) addresses the specific requirements for managing Web
services themselves just like any other resource.
47
State of the Art (cntd)
 On the research front activities have mainly concentrated on:
 on assessing the impact of service execution from a business perspective
and, conversely, to adjust and optimize service executions based on stated
business objectives.
 Service mgt entails monitoring. Here research activities
focus on:
 dynamic monitoring techniques that are capable of employing
monitoring rules governing the control of composite services, e.g.,
BPEL processes.
 capturing and monitoring negotiations that incorporate security
policies and policy models that facilitate service life-cycle
management.
 Also research on QoS metrics for selecting Web services
and for establishing trust between trading partners.
48
Research Challenges
 Autonomic management of services:
 Self-configuring mgt services configure themselves automatically to adapt to
different environments & optimize for particular kinds of use.
 Self-adapting mgt services adapt dynamically to changes in the environment,
market and so on, using policies provided by the distributed platform
administrator.
 Self-healing mgt services can discover, diagnose and react to disruptions.
Corrective action could involve a product altering its own state or effecting
changes in other components in the environment.
 Self-optimizing mgt services can monitor and tune resources automatically to
meet end-user or business needs, e.g., reallocating resources in response to
dynamically changing workloads to improve overall utilization, or ensure that
business transactions are completed in a timely fashion.
 Self-protecting management services can anticipate, detect, identify and protect
against threats, e.g., unauthorized access and use, virus infection and
proliferation, etc & take corrective actions to make themselves less vulnerable.
49
Autonomic Services – our approach
50
Autonomic Service Adaptation
Services react (passive) to changes and to anticipate (pro-active) changes

Based on BPEL monitoring and runtime services adaptation (e.g., degradation
of QoS, based on replacement strategies and transformers)
Moser, O., Rosenberg, F., Dustdar, S., (2008). Non-Intrusive Monitoring and Adaptation for WS-BPEL.
Proceedings of the 17th International World Wide Web Conference (WWW'08), 21-25. April 2008,
Beijing, China.
Rosenberg, F., Platzer, C., Dustdar, S., (2006). Bootstrapping Performance and Dependability
Attributes of Web Services. IEEE International Conference on Web Services (ICWS'06), 18. - 22.
September 2006, Chicago, USA.

Based on activity patterns (mining of activities)
Dustdar, S., Hoffmann, T. (2007). Interaction pattern detection in process oriented information
systems, Data and Knowledge Engineering, Elsevier, 62 (2007) 138–155

Based on service patterns (e.g., mining of service dependencies)
Dustdar, S., Gombotz, R. (2007). Discovering Web service workflows using Web services Interaction
Mining. International Journal of Business Process Integration and Management (IJBPIM), pp. 256-266.
51
Finding Patterns in Ad-hoc Team Interactions
 Proxy
 1:1 relation to original
 e.g., secretary, assistant
a)
 e.g., person who is
responsible to answer all
client requests
4 7 10 15 29 34
jb:Person
10
4 7 10 15 29 34
39
15
42
38
mr:Person
mr:Person
mr:Person
fb:Person
5
6 11
13
5
12
30 32
14 31
33
41
hk:Person
 “Master/Slave”
 More patterns…(ICEIS 2007)
jb:Person
ml:Person
19
request
of interest
ks:Person
 sending identical requests
to multiple recipients
 e.g., multiple participants
are requested to state their
cost estimates
c)
16
jb:Person
 Broker
b)
candidate for proxy,
master or slave
6 11
13
ks:Person
12
30 32
11
14 31
13
12
14
33
hk:Person
ks:Person
hk:Person
40
(a) Area of interest
around performer mr
(b) Remove interactions (c) Consider only
not causally related to
one kind of
any request
request
Dustdar, S., Hoffmann, T. (2007). Interaction
pattern detection in process oriented
Information systems, Data and Knowledge
Engineering, Elsevier, 62 (2007) 138–155
52
Service Interaction Mining
 Different scopes/levels for mining
 (1) Individual Services
 (2) Service Selection (A or B)
 (3) Service Dependencies (a set of services is always used in
combination with each other)
 (4) Workflow Mining (activities in a process)
Dustdar, S., Gombotz, R. (2007). Discovering Web service workflows using Web services
Interaction Mining. International Journal of Business Process Integration and Management
(IJBPIM), Vol. 1, pp. 256-266.
53
Context
is a
beast
Baldauf, M., Dustdar, S., Rosenberg, F. (2007). A Survey on Context Aware Systems. International Journal
of Ad Hoc and Ubiquitous Computing, Vol. 2, No. 4, pp. 263-277.
54
Context Tunneling – Context Scopes
 Based on our work in the inContext project http://www.in-context.eu/
 Tunneling is based on three notions of context scopes:
Individual Context
(Complex)
Activity Context
Team Context
  We need “integration” of context (e.g., individuals collaborate on
shared activities) -> processes
55
Context Management: distributed storage
 Context information
collected from different
sources
 Centralized context store is
not suitable
 Context information is
stored in different services
 Linked through a core model
56
WORKPAD EU Project
EU STREP FP/ WORKPAD
Pervasive Software Environments for Supporting Disaster Responses
WORKPAD Scenario
(IEEE Internet Computing 1/2008)
Vimoware: Vienna mobile middleware
Context and
Interaction
Mining interactions in disaster scenario
57
Self-Healing in SOA
Application of self-healing
 Support people with the complexity of current
systems




Avoid design errors
Avoid configuration errors
Replace failing service
Handle service invocation transparently to keep
system healthy
 Support service maintenance
Definition of self-healing
 A self-healing system should recover from the
abnormal (or “unhealthy”) state and return to the
normative (“healthy”) state, and function as it
was prior to disruption.
 A system with self-healing properties can be
identified as a system that comprises faulttolerant, self-stabilizing, and survivable system
capabilities and, if needed, must be human
supported.
Self-healing origins
 Fault-tolerant system refers to a system that
continues working at a reasonable degree in the
presence of faults
 Self-stabilizing system refers to a system that
continuously stabilizes the system from any
perturbations.
 Survivable systems sustain the unexpected
Self-healing research
 IBM's autonomic computing research envisions a
layered structure that can manage itself to given highlevel objectives from administrators.
 Motivated by the amount spent on and overwhelming
effort in system maintenance
 The research tries to cover all adaptable layers down to
network and operating system
 Defines 4 properties for a self-managing system (selfCHOP):
 self-configuring: The ability to readjust itself “on-the fly”
 self-healing: Discover, diagnose, and react to disruptions
 self-optimization: Maximize resource utilization to meet end-user
needs
 self-protection: Anticipate, detect, identify, and protect itself from
attacks.
Self-healing research
 Self-adaptive systems evaluate their behavior
and adapt on system irregularities or when
better functionality or performance is possible
 The research primarily covers the application
and the middleware layers and focuses on the
system as a whole.
 Includes also self-healing as
 a combination of self-diagnosing and self-repairing
with the capabilities to diagnose and recover from
malfunctions.
Self-healing characteristics

What:
 Continuous availability by
compensating the dynamics of
a running system.

Why:
 maintenance of health
momentarily and ...
 Enduring continuity by
resilience against unintentional
behavior

How:
 Detect disruptions
 Diagnose root cause
 Derive recovery strategy
Self-healing characteristics
 When:
 Continuously in a closedloop for timely reaction
 Who:
 System itself
 Human administrator by
configuration, e.g., set of
policies
 Where:
 Complex, unpredictably
behaving systems
Self-healing requirements





Closed loop with sensor and effector interfaces
Status knowledge and state recognition
Failure classification
Recovery policies
Fitness and evolutionary aspects
Self-healing loop



detecting: filters any
suspicious status
information
diagnosing: does root
cause analysis and
calculates appropriate
recovery
recovery: carefully applies
the planned adaptations
Self-healing states



Normal: Healthy system
that signalizes intentional
functioning of the system.
Broken: Unhealthy system
with unacceptable response
(failure)
Degraded: System is in a
fuzzy transition zone. Drift
from acceptable to failure.
Recognizable by
considerable loss on
performance. Provides
additional time for recovery.
Failure classification
 Assists root cause and resolving the failure.
 Failure types:






Crash failure: undetectable malign interruption
Fail-stop: detected benign interruption
Transient: instantaneous transparent with side-effects
Omission: message loss, transmission errors
Performance: violation of constrains in execution time
Arbitrary: any type of failure with no specific pattern
Failure classification
 The three different types are:
 Action policies: no learning and immediate response is expected.
 Goal Policies: define a set of desired states. Calculate the set of
actions for the transition from the current (failure affected) to a
desired state
 Utility Function Policies: the set of states is connected to an
utility. Problem solving includes history information, adaptation
knowledge and a comprehensive system awareness

Common recovery policies are:
 Replacement, balancing, isolation, persistence, redirection,
relocation, diversity.
Fitness and evolution
 Current systems, especially self-* enhanced, are
designed for long-term service.
 Issues:
 many requirements are not known a-priori but
expose themselves and evolve over time
 malicious failures might restrict parts of the system’s
functionality to essential services
 adaptation might reach its limits in resources
 Current solution: human assisted healing
Summarizing Self-Healing in SOA
 Why is it required. What's the motivation?




Increasing complexity of current systems causes
...escalating costs
...overwhelming effort in system maintenance
...system incomprehensibility
 How does self-healing work. What are the requirements?
 Sensor and effector interfaces provide the essential awareness
(self and environment)
 Closed loop with timely information flow
 State recognition: healthy, degraded, unhealthy
 Fault classification
 Policies with recovery strategies
Agenda
 Service Oriented Computing Research Roadmap
 Theme#1:Service Foundations
 Theme#2:Service Composition/Assemblies
 Theme#3:Service Management
 Theme#4:Service Engineering
 Summary
73
Business Process: Unit of Analysis
 Each process has deep knowledge and value for an enterprise
 Need to study and focus but there are generic properties also
 Business processes







Measures of success
Control features
Formal properties and descriptions
Real-world constraints
Decomposition and composition
Contractual and expectations of cost, quality, reliability
Can be internal or external to an organization
 Business process examples




Procurement
Order & Sales management
HR pension management
Electronic chip design
74
State of the Art
 Developers in their early use of SOA implement a thin
SOAP/WSDL/UDDI veneer on top of existing applications or
components & leave the underlying component untouched.
 Conventional s/w development methodologies such as ObjectOriented Development & Component Based Development do
not address the three key elements of an SOA:
 services,
 service assemblies (composition), and
 components realizing services.
 Early research activities concentrate on how to provide
sufficient principles & guidelines to specify, construct and
refine and customize business processes from a set of internal
and external services.
75
Research Challenges
 Engineering of Service Compositions:
 Associating a services engineering methodology with standard s/w
development & business process modelling techniques:
 NOT UML!!
 Rational Unified Process - analysis and design of iterative software
development.
 Supply Chain Operations Reference (SCOR) Framework (standard guidelines
for companies that examine the configuration of their supply chains, identify &
measure metrics in the supply chain.
 Automated, transparent user centred support to the entire
business process lifecycle of composed services.
 Design techniques for managing service versioning and adaptivity.
 Service Governance to govern end-to-end business processes
that are composed out of variety76of service fragments that need to
be maintained separately by different organizations.
Business Process Decomposition
 Focus on defining business services from the business process point of
view.
 Start with some business process & decompose it into increasingly
smaller sub-processes. The resulting smallest sub-processes then
become candidate business services for implementation.
 The more business processes decomposed in this way, the more
commonality across their sub-processes is achieved, thus building an
appropriate set of reusable Services.
 Simultaneously take existing business logic ingrained in app. code &
expose it as services that specify not the overall business process, but
rather the mechanism for implementing it. This yields two categories of
Services:
 business functionality services that are reusable across multiple processes,
and fine-grained
 utility services that can provide value to various services across the
organization.
77
Service Granularity Concerns I
 Service granularity refers to the scope of functionality
exposed by a service.
 Services may come at two levels of granularity:
 A coarse-grained interface might be the complete processing for a
given service, e.g., “SubmitPO” - the message contains all business
information needed to define a purchase order.
 A fine-grained interface might have separate operations for:
“CreateNewPO”, “SetShippingAddress”, “AddItem”, etc.
 Fine-grained services might be services that provide
basic data access or rudimentary operations. These
services are of little value to business applications.
 Coarse-grained services are composed from finer
grained services.
78
Service Granularity Concerns II
 The frequency of message exchange is an important factor. Sending &
receiving more info. in a single request is more efficient than sending many
fine-grained messages.
 Several redundant, fine-grained services leads to increased message traffic
& tremendous overhead & inefficiency.
 A small collection of coarser-grained services - each of which implements
a complete business process - that are usable in multiple scenarios is a
better option.
 Heuristics identify the right level of granularity for services, e.g., clearly
identifiable business concepts, highly usable and reusable concepts,
concepts that have a high-degree of cohesion and low-degree of coupling,
etc.
 Vertical sectors, e.g., automotive, travel industry, etc, standardize business
entities & processes by choosing their own levels of granularity.
79
Summary of research roadmap
 Research activities in SOC are very fragmented.
This necessitates that a broader vision and
perspective be established—one that permeates
and transforms the fundamental requirements of
complex applications that require the use of the
SOC paradigm.
 The SOC research roadmap launches four pivotal,
inherently related, research themes to SOC:




service foundations,
service composition,
service management and monitoring, and
service-oriented engineering.
80
Conclusion
 Autonomic and adaptive Services and environments ->
shift to runtime considerations
 Novel abstractions needed to model, monitor, predict, and
execute compositions and mashups (Top-down and
Bottom-up approaches)
 Interaction Mining and Pattern detection of activities and
services
 Context (reuse across services/applications)
81
Thanks for your attention!
Prof. Dr. Schahram Dustdar
Distributed Systems Group
Institute of Information Systems
Vienna University of Technology
Austria
http://www.infosys.tuwien.ac.at/Staff/sd/
82