1

FLACOS Malta October 2008

Service Oriented Architectures: The new Software Paradigm

W. Reisig

Humboldt-Universität zu Berlin

Theory of Programming

2

Service Oriented Architectures: The new Software Paradigm

I Some General Remarks

II Some First Assumptions for a Formal Framework

III A Modelling Technique for Services

IV A small Case Study

3

Service Oriented Architectures: The new Software Paradigm

I Some General Remarks

II Some First Assumptions for a Formal Framework

III A Modelling Technique for Services

IV A small Case Study

4

Voices on SOA 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”

5

The paradigm of SOA- is intended to couple encapsulated software components

("services"),

- supports flexibility and convenience of interaction.

- has very pragmatic sources and backgrounds: - Business process technology, - Web service technology.

6

Current Practice of SOA- equips business processes

with web-based communication facilities.

- is influencing - Enterprise Application Integration, - Software Engineering, - Systems Management, - Data provisioning, - BPI, - B2B.

7

Languages and Modelling TechniquesWS- BPEL,

Business Process Modelling Notation (BPMN),

YAWL,

ADEPT,

UML -ACT,

Petri Nets,

…

8

The future of SOApursues more ambitious goals: - modularization, proper interfaces, standardization for enterprise computing and enterprise application integration.

- applies SOA in contexts other than web services and business processes. e.g. wireless networks

- spawn SOA as a new paradigm of computing.

- requires a theoretical basis for SOA, independent from implementations.

i.e.

mathematic

al models

9

What is so fundamentally new?

classical theory:A computing system computes functions.

9 -1

25

moderate interest

in the environment

3 5 not terminating

10

the idea of “service”

a new kind of system:

fundamentally new aspects:

- infinite runs are sensible

- environment is not trivial,

deserves its own attention,

should be described formally.

How?

! Just as the system itself !

11

problems to be addressed by models- Service Composition, orchestrations and

choreographies:

! disambiguate these notions !

- Semantics of services:

… specified in a given modelling language

! A service may not be intended to be implemented !

- Expressive power of modelling languages:

Idea: … relative to the bare minimum of expressive power needed to specify services.

12

problems to be addressed by models- Substitutability of services: Replace S by T … also during execution of S.

- Brokering: Which information about processes should the broker

know?

- Reliability and Correctness: Verification, at varying levels of rigour.

- Design Methodology: Methods and principles of Software Engineering must be adapted to SOA.

13

Service Oriented Architectures: The new Software Paradigm

I Some General Remarks

II Some First Assumptions for a Formal Framework

III A Modelling Technique for Services

IV A small Case Study

14

Service CompositionLet S denote the set of all services.

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 purchase =def ticket machine client

15

Semantics of a serviceA (composed) service may regularly terminate.

ticket or money back

irregular: ticket machine crashes

formally: a "beauty" predicate, i.e. a subset S.

In most cases, is weak termination.

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

16

Equivalence of servicesR is at most as comprehensive as S (written R<S)

iff each partner of R is a partner of S.

formally: R < S iff sem(R) sem(S).

Consequently, two services are equivalent, R S,

iff R < S and R < S.

Apparently:

Two systems are equivalent

whenever their environment can not distinguish them.

17

Quests at the partners of a service, S

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

Controllability

Composability

“most liberal”Operating Guideline

we offer implemented analysis techniques for all of them

18

Quests at the substitution of S’ for S

• Can S’ substitute S ?• Is there a public view of S ?

• Given R and S : Construct T

such that R is a partner of ST

SubstitutionNormal form

adapter generation

that‘s what we are doing right now

19

Service Oriented Architectures: The new Software Paradigm

I Some General Remarks

II Some First Assumptions for a Formal Framework

III A Modelling Technique for Services

IV A small Case Study

20

coin

tea!

coffee!

beverage

coin

coffee!

beverage

Toy example: a vending machine

the coffee partner:

21

Beauty predicate: Proper termination

coin

beverage

with no tokens left on the interface

coin

tea!

coffee!

beverage

22

coin

tea!

beverage

Another partnerthe tea partner:

coin

tea!

coffee!

beverage

23

coin

tea!

coffee!

beverage

coin

tea!

coffee!

beverage

Are there more partners?

the coffee-or-tea partner:

24

coin

tea!

coffee!

beverage

First coffee! then coin

coin

coffee!

beverage

Swap the order

25

coin

tea!

coffee!

beverage

coin

tea!

coffee!

beverage

Three independent threads of control

This is the most permissive partner:

Each other partner can be derived from this one.

no sequential control

26

coin

tea!

coffee!

beverage

coin

tea!

coffee!

beverage

characterize the set of all partners by help of this one

This is the most permissive partner:

Each other partner can be derived from this one.

operating guideline

27

Petri Nets …

the mst generic modelling technique for services

offers the bare minimum to express yourself

good to verify properties and for canonical constructs

! translate your pet language into Petri nets

28

Service Oriented Architectures: The new Software Paradigm

I Some General Remarks

II Some First Assumptions for a Formal Framework

III A Modelling Technique for Services

IV A small Case Study

29

Case Study: BPEL Online Shop

yes no

30

open net,generated by BPEL2oWFN

31

automatically generated

partner

32

the operating guideline

one moreinterleaving

inscriptions

33

Modified Shop

yes no

decision notcommunicated!

has no partners at all

34

FLACOS Malta October 2008

Service Oriented Architectures: The new Software Paradigm

W. Reisig

Humboldt-Universität zu Berlin

Theory of Programming

the

end