open research challenges in service-oriented computing

Open Research Challenges in

Service-Oriented Computing

Schahram Dustdar

Distributed Systems GroupInstitute of Information Systems

TU Wien

http://www.infosys.tuwien.ac.at/Staff/sd/


SOA in the Past

Web as Global SOA

Service Development

ServiceRegistry

DesignerConsumer

registerdiscover

invokedeploy

Browser

copy & paste

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

Web as Global SOA

Service Development

ServiceRegistry

Designer Consumer

invoke

Browser

Integration - Glue

Search Engine

SOAP

JSON

REST

Atom

XML

RSS

ServiceRegistry

Current SOA Research

Integration - Glue

invoke

human service

activity scopes

Humans and services interact to perform work described by activities.

Self-Healing

Process Design

Self-Healing Policies

Deployment with Dependecy Management

Run-Time Environment

Monitoring

invokeX

Adaptation

Trust and Reputation

Trust Management Framework

Trust Management Policies

Configuration of Trust Constraints

Run-Time Environment

invoke

I.

Selection

Monitoring II.

Updated Network Data

8

Agenda

Service Oriented Computing Research Roadmap

Theme#1:Service Foundations

Theme#2:Service Composition/Assemblies

Theme#3:Service Management

Theme#4:Service Engineering

Summary

Some papers to start with…

Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F. (2007). Service-Oriented Computing: State of the Art and Research Challenges, IEEE Computer, November 2007, p 64 - 71.

Papazoglou, M., Traverso, P., Dustdar, S., Leymann, F. (2008). Service-Oriented 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

http://www.infosys.tuwien.ac.at/Staff/sd/papers/Service-Oriented%20Computing_IEEEComputer.pdf

10

Extended SOA (xSOA)

CompositionComposition

Foundation

Foundation(Architecture, Description & basic operations)

(Architecture, Description & basic operations) Capability Interface Behaviour

Publication

Discovery Selection Binding

Service provider

Service client

performs

publishes

uses

Role actions

becomes

Service operatorMarket maker

Managed services

Composite services

Basic services

Service aggregator

Mana gement &gement &MonitoringMonitoring

MarketCertificationRating

SLAsOperationsAuditingSupport

Coordination Conformance Transactions

Semantics Non-functional characteristics QoS

Modelling,Design & Development

Methodologies

11

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 Central/decentral/hybrid architectures

Protocols for Coordination and Interaction Coordination of dynamic services Analyses of Service-Interactions (Mining, Patterns, Algorithms

for optimization) Interaction models and protocols (e.g., Policies, etc.)

QoS-optimized Internet-scale Processes Performance monitoring & management of service

compositions and networked open dynamic systems Metrics (e.g., Team forms, Orchestration Complexity, Coupling

metrics)

Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F. (2007). Service-Oriented Computing: State of the Art and Research Challenges,

IEEE Computer, November 2007, p 64 - 71.

12

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.

13

Agenda






Summary

14

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.

15

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: Java,.NET, legacy, WS-*, ..

16

Enterprise service bus connecting diverse applications & technologies

Service orchestration –based custom applications

Portals

Reliable Asynchronous Secure MessagingReliable Asynchronous Secure Messaging

service service interfaceinterface

Distributed query engine

Adapters

WebSphere, .NET apps

Java apps

Web Services

MQ gateway

Mainframe & legacy

apps

JMS/J2EE

Data sources Enterprise applications

Multi-platform support

service service containercontainer

17

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.

18

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

19

ESB Components

Clients

InternetDNS RouterDNS Router

service clientservice client service clientservice clientservice clientservice client

Proprietary interfaces

Existing EIS & Middleware Platforms

AdapterAdapterAdapter AdapterAdapterAdapter AdapterAdapterAdapter

WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP

WSDL/SOAP interfaceinterfaceinterface



WSDL/SOAP interfaceinterfaceinterface WSDL/SOAP

interfaceinterfaceinterface WSDL/SOAP

interfaceinterfaceinterface

service clientservice client service clientservice clientservice clientservice client

ERP ERP SystemSystemLegacyLegacyApplicationsApplications

DataDataWarehouseWarehouse



Topic-based and Content-based Publish and Subscribe MechanismsProcess Orchestration, Transformation, Security, Management, Transport

(WS-ReliableMessaging, WS-Notification, WS-Topics)

20

the vendor of choice. Enterprise Service BusEnterprise Service Bus

ReplenishmentReplenishmentserviceservice

ReplenishmentReplenishmentserviceservice

OrderOrderapplicationapplication

Purchase OrderPurchase Orderserviceservice

Purchase OrderPurchase Orderserviceservice

ERPERP

SOAP/HTTP

SOAP/JMS

Legacy ccLegacy ccapplicationapplication

InvoiceInvoiceapplicationapplication

XML/JMS

ProcurementProcurement

SupplierSupplierFinanceFinance

InventoryInventory

JCAJCAconnectorconnector

JCAJCAconnectorconnector

InvoicingInvoicingserviceservice

InvoicingInvoicingserviceservice

Credit check Credit check serviceservice

Credit check Credit check serviceservice

Supplier orderSupplier orderserviceservice










brokerbroker

brokerbrokerbrokerbroker

Scaling services in an enterprise service bus.

21

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

22

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.

23

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

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

24

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

25

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, In Proceedings of the 2nd International Workshop on Service-oriented Software Engineering (IW-SOSWE'07), Dubrovnik, Croatia, September 2007, ACM Press.

26

Agenda






Summary

27

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.

28

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.

29

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.

Our Research Methodology

• QoS model• Interaction patterns and metrics• Context model and sharing• Service evolution model• Human/team metrics• Trade-off models• Domain-specific languages

• Emerging problems • Runtime behavior• Metrics/model dependencies • Performance and reliability

• Service Composition• Service selection• Activity ranking• Human selection• Reliable processes• Process mashup•

• Individual service • Flows and processes• Teamwork• Middleware• In-situ adaptation

Knowledge

Plan

ExecuteMonitor

Analyze

Sensors Effectors

Sensors Effectors

30

31

Service Evolution

Treiber, M., Truong, H.L., Dustdar, S. (2008). SEMF - Service Evolution Management Framework, 34th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA) 2008, IEEE Computer Society.

Trust and Reputation in SOC

33

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..? T R U S T

34

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

35

Mixed Flexible Collaboration Environment

human service

activity scopes

Humans interactingand services

to perform work described by activities.

User perspective Network perspective

36

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.

37

Foundational Concepts (1/2): Flexible Ad-hoc Collaboration

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

-Name-Description-Progress-StartAt-Duration-Priority-Tags

Activity

Actor

-Type-Responsibilities

InvolvementRole

0..1

0..*

parent

child

-URI-Type

GenericResource

-Type-ExecutedBy-Receivers-UsedResources-Timestamp

Action

Human

Software Service

HPS

-Type

ActivityTemplate

-ProfileRequirements-TrustRequirements

Requirements

-Skills-Features-Competencies

Capabilities

*

*

-Name-Contact

HumanProfile

-URI-Vendor

ServiceProfile

-FOAF

Profile

*

1 *

*

applies

describes

exhibits

in

Act

ivity

invo

lve

d

as

has1 1

*

*

ha

s

38

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.

39

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.

40

The Cycle of Trust

WSDL

interaction context 1

interaction context 2

WSDL

WSDL

Con

trustscope

WSDL

WSDL

WSDL

Acti-

vity

Resources

WSDL

Acti-

vity

Con

Acti-

vity

WSDL

Acti-

vity WSDL

Resources

Monitoring Collaboration

Analyzing InteractionsEstablishing Trust Network

Trust-aware collaboration planning

ExecutingActivities/Tasks

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

41

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”

42

Use Case in the Area of Software Development

Fred Jane

Tom’others’

5. trust relation(s) wrt. to SW implementation; relation

between testing and impl.?1. delegate the creation of whitebox test

cases for module X;

trust of Fred in Jane = ?

7. recommendation

6. partner of Jane in another software testing

activity

3. profile: BSc in Computer Science, 3 years experience in SW development

8. profiles of recommenders

9. relationships of indirect recommenders -> reputation

?

Softwareimplementatio

n

Softwaretesting

2. project structure, required skills and

knowledge etc..

4. previous interactions: only rare e-mail contact,

and one joint meeting

43

Agenda






Summary

44

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.

45

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.

46

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

47

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.

Management Application(WSDM)

Mgmt Interface

Mgmt Interface

Mgmt Interface

Mgmt Interface

Service Interface

Service Interface

Management Application(WSDM)

Business Application

(Credit Validation)


(Shipping Service)


(Order Processing)

Business Application(Inventory)

Service Interface

Service Interface

Service Interface

Service Interface

WSDL

Enterprise 2Enterprise 2WSDL

WSDM

Enterprise 1Enterprise 1

Application Channel

Management Channel

48

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.

49

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.

50

Autonomic Services – our approach

51

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.

52

Finding Patterns in Ad-hoc Team Interactions

jb:Person ml:Person

mr:Person

ks:Person hk:Person

fb:Person

4

56

7 10

11 1213 14

15

16

19

29

3031

32 33

34

38

39

40

41

42

candidate for proxy, master or slave

request of interest

jb:Person

mr:Person

ks:Person

10

111213 14

15

hk:Person

a) c)b)

jb:Person

4 7 10 15 29 34

56 11 1213 14

3031

32 33

ks:Person hk:Person

mr:Person

Proxy 1:1 relation to original e.g., secretary, assistant

Broker e.g., person who is

responsible to answer all client requests

“Master/Slave” sending identical requests to

multiple recipients e.g., multiple participants

are requested to state their cost estimates

More patterns…(ICEIS 2007)

(a) Area of interest around performer mr

(b) Remove interactions not causally related to any request

(c) Consider only one kind of request

Dustdar, S., Hoffmann, T. (2007). Interaction pattern detection in process oriented Information systems, Data and Knowledge Engineering, Elsevier, 62 (2007) 138–155

53

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.

54

Context is a

beastBaldauf, 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.

55

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:

We need “integration” of context (e.g., individuals collaborate on shared activities) -> processes

Individual Context

Team Context

(Complex) Activity Context

56

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

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

Mining interactions in disaster scenario

Context and Interaction

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 fault-tolerant, 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 high-level 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 (self-CHOP): 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 closed-

loop 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

73

Agenda






Summary

74

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

75

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 Object-Oriented 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.

76

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 variety of service fragments that need to be maintained separately by different organizations.

77

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.

78

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.

79

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.

80

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.

81

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)

82

Thanks for your attention!

Prof. Dr. Schahram DustdarDistributed Systems GroupInstitute of Information SystemsVienna University of TechnologyAustria


open research challenges in service-oriented computing

Documents