1 12-10-01 SEFM Keynote Service Oriented Computing: Forthcoming challenges Wolfgang Reisig Humboldt-Universität zu Berlin Theory of Programming.

1

12-10-01 SEFM Keynote

Service Oriented Computing: Forthcoming challenges

Wolfgang ReisigHumboldt-Universität zu Berlin

Theory of Programming

2

My background

currently:A PhD school on service-oriented Architectures for the Integration of Software-based Processes, exemplified by Health Care Systems and Medical Technology

Berlin - Eindhoven - Rostock Service Technology Program… to offer SOC a tool supported foundation B.E.S.T.

3

My background

generally:Theoretical Computer ScienceTheory of ProgrammingModelingDistributed AlgorithmsPetri Nets

4

1. The basics of SOCThe SOC Paradigm:a core paradigm of modern software architectures.

• loosely coupled components (services), • interface based service descriptions.

Intended to make software constructionmore flexible.

Services are intended to cooperate…

start

goal

You can't kiss by yourself.

…

start

goal

Example:goal: to reach goal.

5

Services cooperate…

start

goal

Example:goal: to reach goal.

…

start

goal

Jointly they may reach their goal.

… dependent on their internal behavior.

6

7

Voices on SOC from the software industry

“THE most relevant emerging paradigm”

“A substantial change of view as it happens at most once each decade”

“The next fundamental software revolution after OO”

“Much more than just an other type of software!”

“The foundational layer for tomorrow's information systems”

8

A recent Software AG user survey90 percent of the respondents claimed to have made some commitment to SOA adoption.

9

Recent Gartner’s reporton the hype curve for emerging technologies:

SOA is at the midpoint of the “slope of enlightenment” ,close to mainstream adoption.

10

SOC vs. SOA

providers requesters

broker(registry)

bind

p. o

ffers

ade

scrip

tion b. returns

provider’s address

r. sends a

request

The SOA triangle

11

Forthcoming challenges1. The basics of SOC

2. SOC governance in the cloud

3. Challenges for SaaS in the cloud

4. Actual Challenges for SOC

5. Models

6. Let’s start

7. Summing up

12

• Who is responsible for a provided service? Legal department? Technical proxy? • Reliability of a service also depends on the reliability of the cloud provider • Resilience guaranteed by the service provider or the cloud provider? • How transparent is the cloud location to the requesters? • Open for everyone? • Elasticity • Latency for users

2. SOC Governance in the cloud

13

Requesting services from a cloud• How can a requestor be sure the provided service meets his quality standards? • Who is responsible for privacy protection? provider, broker, requester?• How can the broker (registry) ensure a predictable uptime of a service? • Who is allowed to design a service or bring it to production? • What happens if a service is retired or changed? Will potential requestors even know? Regulated by contract?

14

Requesting services from a public cloud

• State of the art: manual selection • Contract if the service is business critical • Consuming a cloud service takes considerable ramp-up time • Local service registration is independent of service deployment e.g. on first consumption • Who owns the service? • Cost of service and other metadata known to registry ?• New compliance challenges (data location etc.) might require new rules for consumption (forbid e.g. for person data)

15

Brokering services in a cloudThe broker:

- Which services do I have?- How are they related?- How do I find services from given requester requirements? - May I offer a composed service, extended by an adapter?

- Which details about the services description, semantics, constraints, capabilities must I store ?

- How do I cope with non-functional properties such as SLA/QoS ?- How do I cope with security information ?- How can I guarantee availability ?

16

3. Challenges for SaaS in the cloudSOC vs. SAAS

Service Oriented Architecture (SOA) is a means of designing and building software. It is a manufacturing model.

Software as a Service (SaaS) is a means of providing / receiving software through an external party to your business; similar to telephone or power utilities. It is a sales and distribution model.

17

The business model of SaaS • Registry / Market place in the cloud? • Replication of relevant metadata • Automated requester admittance or licensing? • Liability • Billing • How to provide extended information? • Contractual information Just as text? if not, in which format?

18

Offering SaaS to the public • Short term vs. long term usage • Case-to-case usage? • How finds a requester a service? Market place? Just Google? • Standard description format?

• No contract = no liability? • How much liability does a user need? • Brokerage services (cheapest flight) • Business model (pay after delivery, paypal-like guarantees)

19

SaaS is dangerous for companies• How to effectively integrate the outsourced applications with the internally hosted ones? Typically web service interfaces might not fit company design patterns.

• No direct call • Performance, security and reliability (of business critical data)

are not guaranteed.• Consumption policies are unknown.• SaaS applications live outside the corporate firewall. • How to handle changes / updates of a services?

20

4. Actual Challenges for SOCHow cope with

• instantiation• refinement (horizontally, hierarchically)• correctness• substitution• equivalence• design methodology • orchestration• choreography• brokering• fault handling• compensation handling

21

• Decide whether two services may - run into a deadlock - properly terminate (weakly, strongly) - keep a bound of pending messages

• Construct adapters automatically

• Test compliance to law (e.g. Basel II) and repair automatically

• Apply SOA in contexts other than web services and business processes, e.g. wireless networks, embedded systems, physical services (pizza delivery) .

4. Actual Challenges for SOC

… can hardly be achieved

in terms of

specification languages.

Better: Use models

22

What is a model?

… a precise (formal) representation of some aspects of a system,

on a freely chosen level of abstraction

… not necessarily implementable … not even necessarily intended to be implemented

5. Models

23

… and what is a model for?A model

• clarifies meaning and logical structure of constructs,

• supports design,

• facilitates analysis,

• discriminates conceptual features from language- and implementation dependent ones, • provides measures for the expressivity of languages. Modeling means concentration onto the essentials!

24

Grady Booch: Models as a product

„ … to elevate models as to a first class citizenship ... a peer of traditional text languages (and potentially a master)“

25

… from IBM-Lab Zürich (2007)Business Driven Development

code only

code

model

code

model

code

model

code

model

code visuali-zation

Round trip Engin-eering

model centric

the model is the code

time

26

What is a good model?

expressive enough to cover aspects that you consider relevant simple enough to offer analysis techniques.

The perfect model: intuitive, abstract, as well as precise and analyzable.

27

Example

Implementation Analysis

BPEL BPMN Petri Nets(including variants)

became fundamental for BP semantics

28

Modeling alleviates analysisWe should do it in analogy to programming languages:

The semantics of a service is a mathematical object!

The composition of services is a (simple!) mathematical (or logical!) operation.

True, this is presently not the case.

BUT WE SHOULD spend effort into this!

… and this requires modeling.

29

6. Let’s starta new kind of

system:fundamentally new aspects:

- infinite runs are sensible

- environment is not trivial, deserves its own attention, should be described formally. How understand the environment? ! It is an open system, too!

open system componentreactive systemservice

30

Services can be composedLet S denote the set of all services (of interest).

Services are made to be composed. a ticket machine and a client

Two composed services behave like one service. purchase =def ticket machine and client

formally: : S S S

31

Some services are beautifulBeauty: deadlock freeweakly terminatingstrongly terminatingfinite state

ticket machine client:client gets either ticket or money backdeadlock: ticket machine crashes

formally: a "beauty" predicate, i.e. a subset b S. In most cases, b is weak termination.

32

A simple structurestructure (S ; , b )

set of services, S,composition : S S S beauty b S. This yields an amazing wealthof canonical constructs!

33

The semantics of servicesstructure (S ; , b )

Def. Let R, S S.R is a partner of S iff S R .bsem(S) =def the set of all partners of S.

Observation: S is ordered: For Q, R S : Q < R iff sem(Q) sem(R).

Def. Two services R,S are equivalent, R S, iff R < S and S < R. Intuitively: Two systems are equivalent whenever their environment can not distinguish them.

34

The semantics of servicesstructure (S ; , b )

Def. Let R, S S.R is a partner of S iff S R .bsem(S) =def the set of all partners of S.

Observation: S is ordered: For Q, R S : Q < R iff sem(Q) sem(R).

Observation: sem(S) has canoncal elements “most liberal partners” of sem(S) They yield a finite characterization of sem(S)

35

Quests at the partners of a service, S

Does S have partners at all ? Is R a partner of S ?How construct a canonical partner of S ?How characterize all partners of S ?

ControllabilityComposability

“most liberal”Operating Guideline

36

Quests at the substitution of S’ for S Can S’ substitute S ?

Given R and S : Construct T such that R is a partner of ST

Substitution

adapter generation

… on the fly

Rule basede adapters

Construct an adapter that respects requirements as given by a domain expert.

Typical requirements (business rules):

“Dollar may be changed to Euro.”“An arm chair may be put into a box.”“A request may be copied.”“Foreign Spam may be deleted.”“I may produce an order.”

37

7. Summing up:

shape of partner

acyclic

centralized

decentralized

autonomus

compatibility notion

deadlock freedom

weak termination

strong termination

bounded communication

messaging

synchronous

asynchronous queued other requirements

behavioral constraints transactions, policies, ...

38

Problem dimensions:

39

• 17 problems in various settings

• 3 powerful technologies state space, partner synthesis, operating guidelines

• Hype independent through formal modeling

• (8 Jou, 30 Conf) publications,(8 PhD, 30 Stud/Master) theses, ... since about 2004

• 9 Cooperations Uni Rostock, TU Eindhoven, Uni Stuttgart, …

• 6 tools LoLA, Fiona, BPEL2OWFN, OWFN2BPEL, RACHEL, SEDA,

For details: http://service-technology.org/

service-technology.org

40

12-10-01 SEFM Keynote

Service Oriented Computing: Forthcoming challenges

Wolfgang ReisigHumboldt-Universität zu Berlin

Theory of Programming

• Challenges are many and are not trivial

• worth to be attacked

• need research into

fundamental modeling techniques